乐学 数据仓库解决方案在电子商务中有哪些应用？
比如当前火热的电商解决方案-旺店通ERP，即是使用C++/erlang和数据仓库技术开发的ERP。
业务板块是逻辑空间的定义，是基于业务特征划分的命名空间
指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件。在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。
维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）。
维度属性隶属于一个维度，如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。
原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期。可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近l天海外买家支付金额则为派生指标（最近l天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词）
用来明确数据统计的时间范围或者时间点，如最近30天、自然周、截至当日等。
是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC端等修饰词。
指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如在日志域的访问终端类型下，有修饰词PC端、无线端等。
在维度提炼的过程中，通常从业务过程或单据中相关的who、where、when、how、what、why的角度来提炼，详情参考《维度建模权威指南第3版》。
维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。
1、选择业务过程。
业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
2、选择粒度 。
在事件分析中，要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
3、识别维表 。
选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
4、选择事实 。
确定分析需要衡量的指标。
下面以维度建模作为理论基础，构建总线矩阵、划分和定义数据域、业务过程、维度、度量/原子指标、修饰类型、修饰词、时间周期、派生指标。整体遵循下面的建模规范。
1、概念层次
3、指标体系（指标组成体系之间关系）
原子指标
原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。
派生指标
1、模型架构图
*** 作数据层（ODS）
把 *** 作系统数据几乎无处理地存放在数据仓库系统中。
公共数仓层（DW）
存放明细事实数据、维表数据及公共指标汇总数据。 采用维度模型方法作为理论基础，减少事实表和维表的关联，提高明细表的易用性
明细层（dwd）
理论上明细层数据是对ods层数据进行清洗加工，提高ods层数据的可用性，对于dwd层数据是否同层引用的观点需要权衡：
汇总层(dws)
这一层依赖我们的指标体系，将dwd层的数据按照各个维度进行聚合计算。
数据集市层(dwm)
当我们有一些跨业务域的聚合统计需求时，放到这一层。
DW层其主要功能如下：
应用数据层（ADS）
存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。
实施流程主要分为：数据调研、架构设计、规范定义和模型设计
模型整体实施过程如下图所示：
数据域划分
构建总线矩阵
规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。上面也做了详细说明，此处不做展开。
模型设计主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。
维度是维度建模的基础和灵魂，数据仓库的能力直接与维度属性的质量和深度成正比。
维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。维度的作用一般是查询约束、分类汇总以及排序等。维度的设计过程就是确定维度属性的过程
当具有多层次的维度属性，按照第三范式进行规范化后形成一系列维度表，而非单一维度表，这种建模称为雪花模式。
将维度的属性层次合并到单个维度中的 *** 作称为反规范化。
不同的应用系统的数据进入数仓后需要整合在一起：
微型维度的创建是通过将一部分不稳定的属性从相对稳定的主维度中移除，放置到拥有自己代理键的新表来实现。
递归层次指的是某维表的实例值的层次关系，维度的递归层次分为有固定数量级别的均衡层次结构和无固定数量级别的非均衡层次结构。
由于数仓中一般不支持递归SQL的功能来处理这种层次结构，所以需要用到其他方式。
多值维度指事实表的一条记录在某维度表中有多条记录与之对应。
针对多值维度，常见的处理方式有三种：
杂项维度是由 *** 作型系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。
这些维度如果作为事实存在事实表中，则会导致事实表占用空间变大；如果单独建立维表，则会出现许多零碎的小维表。
这时，通常的解决方案是建立杂项维度，将这些字段建立到一个维表中，在事实表中只需保存一个外键即可，杂项维度可以理解为将许多小维表通过行转列的方式存储到一张大维表中的处理方案。
指维度属性直接存储到事实表中的维度。
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
另外一个视角划分事实表类型：
单事务事实表：
针对每个业务过程设计一个事实表。这样方便对每个业务过程进行独立的分析研究。
多事务事实表：
将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。
多事务事实表有两种方法进行事实处理：
不同业务过程的事实使用不同的事实字段进行存放；如果不是不是当前业务过程的度量，可以考虑用0值填充。
不同业务过程的事实使用同一个事实字段进行存放，但增加一列作为业务过程标签，记录该事务是否在当天完成。
4、事实表设计原则
尽可能包含所有与业务过程相关的事实。
只选择与业务过程相关的事实。
分解不可加性事实为可加的组件。
在选择维度和事实之前必须先声明粒度。
在同一个事实表中不能有多种不同粒度的事实。
事实的单位要保持一致。
对事实的null值要处理，建议用0填充。
使用退化维度提高事实表的易用性。
随着计算机应用的深入，大量数据存储在计算机中，信息的存储、管理、使用和维护显得越来越重要，而传统的数据库管理系统很难满足其要求。为了解决大数据量、异构数据集成以及访问数据的响应速度问题，采用数据仓库技术，为最终用户处理所需的决策信息提供有效方法。
1 数据仓库
数据仓库是为管理人员进行决策提供支持的一种面向主题的、集成的、非易失的并随时间而变化的数据集合。数据仓库是一种作为决策支持系统和联机分析应用数据源的结构化数据环境。
从目前数据仓库的发展来讲，数据可以存放于不同类型的数据库中，数据仓库是将异种数据源在单个站点以统一的模型组织的存储，以支持管理决策。数据仓库技术包括数据清理、数据集成、联机分析处理（OLAP）和数据挖掘（DM）。OLAP是多维查询和分析工具，支持决策者围绕决策主题对数据进行多角度、多层次的分析。OLAP侧重于交互性、快速的响应速度及提供数据的多维视图，而DM则注重自动发现隐藏在数据中的模式和有用信息。OLAP的分析结果可以给DM提供分析信息，作为挖掘的依据；DM可以拓展OLAP分析的深度，可以发现OLAP所不能发现的更为复杂、细致的信息。OLAP是联机分析处理，DM是通过对数据库、数据仓库中的数据进行分析而获得知识的方法和技术，即通过建立模型来发现隐藏在组织机构数据库中的模式和关系。这两者结合起来可满足企业对数据整理和信息提取的要求，帮助企业高层做出决策。在欧美发达国家，以数据仓库为基础的在线分析处理和数据挖掘应用，首先在金融、保险、证券、电信等传统数据密集型行业取得成功。IBM、oracle、Teradata、Microsoft、Netezza和SAS等有实力的公司相继推出了数据仓库解决方案。
近几年开始流行“分布式数据仓库”，是在多个物理位置应用全局逻辑模型。数据被逻辑地分成多个域，但不同位置不会有重复的数据。这种分布式方法可以为不同的物理数据创建安全区域，或为全球不同时区的用户提供全天候的服务。此外，有由Kognitio发起数据仓库托管服务，即DBMS厂商为客户开发和运行数据仓库。这种最初出现在业务部门，业务部门购买托管服务，而不是使用企业内IT部门提供的数据仓库。
2 数据挖掘技术
数据挖掘（DataMining），又称数据库中的知识发现（KnoWledge Discoveryin Database，KDD），是指从大型数据库或数据仓库中提取隐含的、未知的、非平凡的及有潜在应用价值并最终可为用户理解的模式过程。它是数据库研究中的很有应用价值的新领域，是人工智能、机器学习、数理统计学和神经元网络等技术在特定的数据仓库领域中的应用。数据挖掘的核心模块技术历经数十年的发展，其中包括数理统计、人工智能、机器学习。从技术角度看，数据挖掘是从大量的、不完全的、有噪声的、模糊的、随机的实际数据中，提取隐含在其中的、人们所不知道的、但又是潜在有用的信息和知识的过程。从商业应用角度看，数据挖掘是崭新的商业信息处理技术，其主要特点是对商业数据库中的大量业务数据进行抽取、转化、分析和模式化处理，从中提取辅助商业决策的关键知识。
从技术角度讲，数据挖掘可应用于以下方面：
（1）关联规则发现是在给定的事物集合中发现满足一定条件的关联规则，简单来讲，就是挖掘出隐藏在数据间的相互关系，为业务主题提供指导。
（2）序列模式分析和关联规则发现相似，但其侧重点在于分析数据间的前后关系。模式是按时间有序的。序列模式发现是在与时间有关的事物数据库中发现满足用户给定的最小支持度域值的所有有序序列。
（3）分类分析与聚类分析，分类规则的挖掘实际上是根据分类模型从数据对象中发现共性，并把它们分成不同的类的过程。聚类时间是将d维空间的n个数据对象，划分到k个类中，使得一个类内的数据对象间的相似度高于其他类中数据对象。聚类分析可以发现没有类别标记的一组数据对象的特性，总结出一个类别的特征。
（4）自动趋势预测，数据挖掘能自动在大型数据库里面寻找潜在的预测信息。一个典型的利用数据挖掘进行预测的例子就是目标营销。数据挖掘工具可以根据过去邮件推销中的大量数据找出其中最有可能对将来的邮件推销作出反应的客户。
3 联机分析（OLAP）处理技术
联机分析（OLAP）是数据仓库实现为决策提供支持的重要工具，是共享多维信息，针对特定问题的联机数据访问和分析的快速软件技术。是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来，能够真正为用户所理解，并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术（OLAP委员会的定义）。OLAP的特性包括：①快速性：系统应能在5s内对用户的大部分分析要求做出反应；②可分析性：能处理与应用有关的任何逻辑分析和统计分析；⑨多维性：多维性是OLAP的关键属性。系统必须提供对数据的多维视图和分析，包括对层次维和多重层次维的完全支持；④信息性：系统应能及时获得信息，并能管理大容量信息。
OLAP的数据结构是多维，目前存在方式：①超立方结构（Hypercube），指用三维或更多的维数来描述一个对象，每个维彼此垂直。数据的测量值发生在维的交叉点上，数据空间的各部分都有相同的维属性（收缩超立方结构。这种结构的数据密度更大，数据的维数更少，并可加入额外的分析维）；②多立方结构（Multicube），即将超立方结构变为子立方结构。面向某特定应用对维分割，它具有强灵活性，提高了数据（特别是稀疏数据）的分析效率。分析方法包括：切片、切块、旋转、钻取等。
OLAP也被称为共享的多维数据的快速分析FASMI，应用在数据密集型行业，如市场和销售分析、电子商务的分析、基于历史数据的营销、预算、财务报告与整合、管理报告、利益率、质量分析等。
4 小 结
采用数据仓库的数据挖掘及联机分析技术实现的决策支持系统，是弥补传统辅助决策系统能力不足的有效途径，具有重要的现实意义。前言 在事务处理系统中的数据 主要用于记录和查询业务情况 随着数据仓库（DW）技术的不断成熟 企业的数据逐渐变成了决策的主要依据 数据仓库是一种面向决策主题 由多数据源集成 拥有当前及历史总结数据 以读为主的数据库系统 其目的是支持决策 数据仓库要根据决策的需要收集来自企业内外的有关数据 并加以适当的组织处理 使其能有效地为决策过程提供信息 数据仓库中的数据是从许多业务处理系统中抽取 转换而来 对于这样一个复杂的企业数据环境 如何以安全 高效的方式来对它们进行管理和访问就变得尤为重要 解决这一问题的关键是对元数据进行科学有效的管理 元数据是关于数据 *** 纵数据的进程和应用程序的结构和意义的描述信息 其主要目标是提供数据资源的全面指南 元数据不仅定义了数据仓库中数据的模式 来源以及抽取和转换规则等 而且整个数据仓库系统的运行都是基于元数据的 是元数据把数据仓库系统中的各个松散的组件联系起来 组成了一个有机的整体 本文首先介绍了元数据的定义 作用和意义 然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况 最后提出了建立元数据管理系统的步骤和实施方法 元数据 元数据的概念按照传统的定义 元数据（Metadata）是关于数据的数据 在数据仓库系统中 元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据 元数据是描述数据仓库内数据的结构和建立方法的数据 可将其按用途的不同分为两类 技术元数据（Technical Metadata）和业务元数据（Business Metadata） 技术元数据是存储关于数据仓库系统技术细节的数据 是用于开发和管理数据仓库使用的数据 它主要包括以下信息 &# ; 数据仓库结构的描述 包括仓库模式 视图 维 层次结构和导出数据的定义 以及数据集市的位置和内容 &# ; 业务系统 数据仓库和数据集市的体系结构和模式 &# ; 汇总用的算法 包括度量和维定义算法 数据粒度 主题领域 聚集 汇总 预定义的查询与报告 &# ; 由 *** 作环境到数据仓库环境的映射 包括源数据和它们的内容 数据分割 数据提取 清理 转换规则和数据刷新规则 安全（用户授权和存取控制） 业务元数据从业务角度描述了数据仓库中的数据 它提供了介于使用者和实际系统之间的语义层 使得不懂计算机技术的业务人员也能够 读懂 数据仓库中的数据 业务元数据主要包括以下信息 使用者的业务术语所表达的数据模型 对象名和属性名 访问数据的原则和数据的来源 系统所提供的分析方法以及公式和报表的信息 具体包括以下信息 &# ; 企业概念模型 这是业务元数据所应提供的重要的信息 它表示企业数据模型的高层信息 整个企业的业务概念和相互关系 以这个企业模型为基础 不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数 &# ; 多维数据模型 这是企业概念模型的重要组成部分 它告诉业务分析人员在数据集市当中有哪些维 维的类别 数据立方体以及数据集市中的聚合规则 这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式 &# ; 业务概念模型和物理数据之间的依赖 以上提到的业务元数据只是表示出了数据的业务视图 这些业务视图与实际的数据仓库或数据库 多维数据库中的表 字段 维 层次等之间的对应关系也应该在元数据知识库中有所体现 元数据的作用在数据仓库系统中 元数据机制主要支持以下五类系统管理功能 （1）描述哪些数据在数据仓库中 （2）定义要进入数据仓库中的数据和从数据仓库中产生的数据 （3）记录根据业务事件发生而随之进行的数据抽取工作时间安排 （4）记录并检测系统数据一致性的要求和执行情况 （5）衡量数据质量 与其说数据仓库是软件开发项目 还不如说是系统集成项目[ ] 因为它的主要工作是把所需的数据仓库工具集成在一起 完成数据的抽取 转换和加载 OLAP分析和数据挖掘等 如图 所示 它的典型结构由 *** 作环境层 数据仓库层和业务层等组成 其中 第一层（ *** 作环境层）是指整个企业内有关业务的OLTP系统和一些外部数据源 第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层 第三层是为了完成对业务数据的分析而由各种工具组成的业务层 图中左边的部分是元数据管理 它起到了承上启下的作用 具体体现在以下几个方面 &# ; 便于集成&# ; 提高系统的灵活性&# ; 保证数据的质量&# ; 帮助用户理解数据的意义 数据仓库元数据管理现状 元数据管理的主要任务有两个方面 一是负责存储和维护元数据库中的元数据 二是负责数据仓库建模工具 数据获取工具 前端工具等之间的消息传递 协调各模块和工具之间的工作 由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的 灵魂 正是由于元数据在整个数据仓库生命周期中有着重要的地位 各个厂商的数据仓库解决方案都提到了关于对元数据的管理 但遗憾的是对于元数据的管理 各个解决方案都没有明确提出一个完整的管理模式 它们提供的仅仅是对特定的局部元数据的管理 当前市场上与元数据有关的主要工具见图 如图 所示 与元数据相关的数据仓库工具大致可分为四类 数据抽取工具 把业务系统中的数据抽取 转换 集成到数据仓库中 如Ardent的DataStage CA（原Platinum）的Decision Base和ETI的Extract等 这些工具仅提供了技术元数据 几乎没有提供对业务元数据的支持 前端展现工具 包括OLAP分析 报表和商业智能工具等 如MicroStrategy的DSS Agent Cognos的PowerPlay Business Objects的BO 以及Brio等 它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图 进而对数据仓库中的数据进行多维分析 这些工具都提供了业务元数据与技术元数据相对应的语义层 建模工具 为非技术人员准备的业务建模工具 这些工具可以提供更高层的与特定业务相关的语义 如CA的ERwin Sy ase的PowerDesigner以及Rational的Rose等 元数据存储工具 元数据通常存储在专用的数据库中 该数据库就如同一个 黑盒子 外部无法知道这些工具所用到和产生的元数据是如何存储的 还有一类被称为元数据知识库（Metadata Repository）的工具 它们独立于其它工具 为元数据提供一个集中的存储空间 包括微软的Repository CA的Repository Ardent的MetaStage和Sybase的WCC等 元数据管理的标准化 没有规矩不成方圆 元数据管理之所以困难 一个很重要的原因就是缺乏统一的标准 在这种情况下 各公司的元数据管理解决方案各不相同 近几年 随着元数据联盟MDC（Meta Data Coalition）的开放信息模型OIM（Open Information Model）和OMG组织的公共仓库模型CWM（Common Warehouse Model）标准的逐渐完善 以及MDC和OMG组织的合并 为数据仓库厂商提供了统一的标准 从而为元数据管理铺平了道路 从元数据的发展历史不难看出 元数据管理主要有两种方法 ( ) 对于相对简单的环境 按照通用的元数据管理标准建立一个集中式的元数据知识库 ( ) 对于比较复杂的环境 分别建立各部分的元数据管理系统 形成分布式元数据知识库 然后 通过建立标准的元数据交换格式 实现元数据的集成管理 下面我们分别介绍数据仓库领域中两个最主要的元数据标准 MDC的OIM标准和OMG的CWM标准 MDC的OIM存储模型MDC成立于 年 是一个致力于建立与厂商无关的 不依赖于具体技术的企业元数据管理标准的非赢利技术联盟 该联盟有 多个会员 其中包括微软和IBM等著名软件厂商 年 月MDC接受了微软的建议 将OIM作为元数据标准 OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用 它涉及了信息系统（从设计到发布）的各个阶段 通过对元数据类型的标准描述来达到工具和知识库之间的数据共享 OIM所声明的元数据类型都采用统一建模语言UML（Universal Modeling Language）进行描述 并被组织成易于使用 易于扩展的多个主题范围（Subject Areas） 这些主题范围包括 &# ; 分析与设计（Analysis and Design） 主要用于软件分析 设计和建模 该主题范围又进一步划分为 UML包（Package） UML扩展包 通用元素（Generic Elements）包 公共数据类型（Common Data Types）包和实体关系建模（Entity Relationship Modeling）包等 &# ; 对象与组件（Object and Component） 涉及面向对象开发技术的方方面面 该主题范围只包含组件描述建模（Component Description Modeling）包 &# ; 数据库与数据仓库（Database and Warehousing） 为数据库模式管理 复用和建立数据仓库提供元数据概念支持 该主题范围进一步划分为 关系数据库模式（Relational Database Schema）包 OLAP模式（OLAP Schema）包 数据转换（Data Transformations）包 面向记录的数据库模式（Record Oriented Database Schema）包 XML模式（XML Schema）包和报表定义（Report Definitions）包等 &# ; 业务工程（Business Engineering） 为企业运作提供一个蓝图 该主题范围进一步划分为 业务目标（Business Goal）包 组织元素（Organizational Elements）包 业务规则（Business Rules）包 商业流程（Business Processes）包等 &# ; 知识管理（Knowledge Management） 涉及企业的信息结构 该主题范围进一步划分为 知识描述（Knowledge lishixinzhi/Article/program/Oracle/201311/18587
信用风险
银行的经营风险的机构，那在第15节也提到了巴塞尔新资本协议对于银行风险的计量和监管要求，其中信用风险是银行经营的主要风险之一，它的管理好坏直接影响到银行的经营利润和稳定经营。信用风险是指交易对手未能履行约定契约中的义务而给银行造成经济损失的风险。典型的表现形式包括借款人发生违约或信用等级下降。借款人因各种原因未能及时、足额偿还债务/银行贷款、未能履行合同义务而发生违约时，债权人或银行必将因为未能得到预期的收益而承担财务上的损失。
那如何来表示某个交易对手的信用情况呢，一般使用信用等级或信用评分来来表示，等级越低或评分越低，发生违约的概率会增加。这个信用评分主要应用在客户的贷前和贷后管理中，贷前是指客户贷款申请阶段，银行受理客户贷款申请时会根据客户提交的信息、人行征信、其它数据源按一定的规则计算出一个违约概率和风险评分或信用等级。再根据这个评分或评级来确定客户的授信额度和利率。计算出的评分或评级越高，违约概率越低，比如在进行个人贷前评分时主要关注以下5方面：
（1）People：贷款人状况，包括历史还款表现、当前负债情况、资金饥渴度等；
（2）Payment：还款来源，如基本收入、资产水平、月收支负债比、无担保总负债等；
（3）Purpose：资金用途，如消费、买房，需要规避贷款资金用于投资或投机性质较高领域，如股票和数字货币；
（4）Protection：债权确保，主要是看是否有抵押物或担保，需要看抵押物用途、质量、价格等关键要素；
（5）Perspective：借款户展望，从地域、行业、人生阶段等考察稳定性及潜力；
贷后是指客户借款后银行持续跟进客户的信用情况，如果发现信用评分降低或者某些指标达到风险预警指标的阈值，说明风险升高，则会进行冻结额度甚至提前进行贷款收回。特别是对于逾期客户。
风险建模步骤
在进行信用评估时如何选择客户属性、如何确定评分或评级规则呢？这就需要进行风险建模，通过分析历史数据来确定哪些特征或指标对客户的违约相关性大，可以了解客户的还款能力以及还款意愿。并通过一定方法来建立评分和评级的规则。那风险建模主要分为以下步骤：
（1）业务理解：主要评估当前现状、确定业务目标，选择建模方法，比如需要进行XX贷款产品的贷前评分模型并确定准入规则，建模方式比如为评分卡，评分应用为基于评分确定贷款准入规则以及额度和利率规则，同时需要确定分析数据的好客户和坏客户标准，如逾期90天以上为坏客户；
（2）数据理解：首先需要准备建模的样本数据，如抽取近2年的获得类似产品的客户相关信息以及根据好客户和坏客户标准确定的结果。并针对业务数据进行业务含义理解、对数据进行收集、探索，了解每个变量的数据质量、缺失情况，数据分布等。比如对于客户在人行的征信数据、客户在银行的存款、理财等信息、以及客户申请填写的家庭、房产信息、外部获得的客户教育、司法等相关信息进行业务理解和数据分布、质量的探索，对缺失值比例过大的变量或准确性不高的变量进行剔除，同时也要确定对于样本数据中哪些数据进行建模，哪些数据进行验证。
（3）数据准备：主要对数据进行预处理和指标加工，指标加工指基于基础数据进行指标加工，如最近1个月的征信查询次数，最近1年的逾期次数等，数据预处理主要工作包括对每一个变量进行数据清洗、缺失值处理、异常值处理、数据标准化等，主要目的是将获取的原始数据转变成可用于建模的结构化数据。
比如对于连续变量，就是要寻找合适的切割点把变量分为几个区间段以使其具有最强的预测能力，也称为“分箱”。例如客户年龄就是连续变量，在这一步就是要研究分成几组、每组切割点在哪里预测能力是最强的。分箱的方法有等宽、等频、聚类（k-means）、卡方分箱法、单变量决策树算法（ID3、C45、CART）、IV最大化分箱法、best-ks分箱法等。如果是离散变量，每个变量值都有一定的预测能力，但是考虑到可能几个变量值有相近的预测能力，因此也需要进行分组。
通过对变量的分割、分组和合并转换，分析每个变量对于结果的相关性，剔除掉预测能力较弱的变量，筛选出符合实际业务需求、具有较强预测能力的变量。检测变量预测能力的方法有：WOE(weight of Evidence) 、IV(informationvalue)等。
（4）分析建模：即对于筛选出来的变量以及完成好坏定义的样本结果。放入模型进行拟合。如评分卡一般采用常见的逻辑回归的模型，PYTHON、SAS、R都有相关的函数实现模型拟合。以下是生成的评分卡的例子。
（5）评估及报告：即通过验证样本对模型的预测进行校验。评估模型的准确性和稳健性，并得出分析报告。常用的方法有ROC曲线、lift提升指数、KS(Kolmogorov-Smirnov)曲线、GINI系数等。
（6）应用：对模型进行实际部署和应用，如基于评分进行客户准入和产生额度，并在贷款系统进行模型部署，自动对申请客户进行评分。
（7）监测：建立多种报表对模型的有效性、稳定性进行监测，如稳定性监控报表来比较新申请客户与开发样本客户的分值分布，不良贷款分析报表来评估不同分数段的不良贷款，并且与开发时的预测进行比较，监控客户信贷质量。随着时间的推移和环境变化，评分模型的预测力会减弱，所以需要持续监控并进行适当调整或重建。
在信用风险建模中，目前评分卡建模还是主要的方式，除了申请评分（A卡（Application score card））还有B卡（Behavior score card）行为评分卡、C卡（Collection score card）催收评分卡。B卡主要进行客户贷后管理，如何进行风险预警，C卡进行催收管理，确定如何催收以及催收方式和时间点。信用风险模型中还有一个是反欺诈模型，它主要是识别假冒身份、虚假信息、批量薅羊毛等欺诈行为。随着机器学习和大数据的发展，其它的一些建模方式如决策树、深度神经网络也越来越多的应用到了风险建模中。
信用风险模型是数据仓库支持的重要数据应用之一，在风险建模分析阶段，数据仓库是建模样本数据以及衍生指标加工的主要提供者，业务人员一般在自助分析平台进行数据分析和建模，模型建立完成并部署后，会基于数据仓库数据进行模型效果的监控。在贷后管理中，风险集市也会进行贷后指标的加工。另外风险模型以及预警中会经常使用到外部数据，这部分数据也是通过数据仓库进行对接、加工和存储。
1、首先你得搞清楚建设数仓的目的是什么
是偏向于整合各系统数据，为数据分析决策服务，还是偏向于快速的完成分析决策需求？
如果是前者，那么在数据仓库建模的时候一般会选择ER建模方法；
如果是后者，一般会选择维度建模方法。
ER建模：即实体关系建模，由数据仓库之父BIll Inmon提出，核心思想是从全企业的高度去设计三范式模型，用实体关系描述企业服务。主张的是自上而下的架构，将不同的OLTP数据集中到面向主题的数据仓库中。
维度建模：由Kimball提出，核心思想是从分析决策的需求出发构建模型。这种模型由事实表和维表组成，即星型模型和雪花模型。Kimball倡导自下而上的架构，可以针对独立部门建立数据集市，再递增的构建，汇总成数据仓库。
2、其次你得进行深入的业务调研和数据调研
业务调研：深入的业务调研能使你更加明确数仓建设的目的；同时也利于后续的建模设计，随着调研的开展，如何将实体业务抽象为数仓模型会更加明朗。
数据调研：各部门或各科室的数据现状了解，包括数据分类、数据存储方式、数据量、具体的数据内容等等。这对后续的主数据串联或者维度一致性处理等等都是必须的基础。
3、然后是数据仓库工具选型
传统型数据仓库：一般会选择第三方厂家的数据库和配套ETL工具。因为有第三方支持，相对有保障；但缺点也很明显，受约束以及成本较高。
NoSQL型数据仓库：一般是基于hadoop生态的数据仓库。hadoop生态已经非常强大，可以找到各种开源组件去支持数据仓库。缺点是需要招聘专门人士去摸索，并且相对会存在一些未知隐患。
4、最后是设计与实施
设计：包括数据架构中的数据层次划分以及具体的模型设计；也包括程序架构中的数据质量管理、元数据管理、调度管理等；
实施：规范化的项目管理实施，但同时也需记住一点，数据仓库不是一个项目，它是一个过程。
基于hadoop生态搭建的电商数据仓库，整体功能架构包含数据采集、数仓搭建、数据导出、数据可视化等。
github地址
电商数据仓库
详情学习攻略请查看
hadoop安装
hive安装
hive常用命令
完善中
项目踩坑请查看
Linux卸载安装Mysql踩坑
Linux报错只读文件系统（集群非法关机、断电）踩坑
sqoop拒绝连接
kafka manager启动失败解决方案
hive拒绝连接解决方案
系统数据流程如下图：
数仓分层如下图：
hive表关系图如下图：
完善中
完善中
最近面试的时候被问到了星型模型和雪花模型的问题，然后把星座模型当成雪花模型说了为了巩固自己在这一方面的知识，决定写一篇文章来记录一下。星型模型、雪花模型和星座模型是数据仓库维度建模中重要的三种模型，接下来说一下它们的特点以及相互间的联系。
星型模型由一张事实表和多张维度表组成。事实表里包括维度表的各个主键（一般为id），以及其它没有放进维度表的内容；维度表里存储对应维度的详细信息。
以一张purchase表为例，它主要需要记录以下几个信息：
由于用户、物品、以及商店都有他们自己的详细信息，如果把它们全部放进purchase表里面的话会造成很大的冗余，以及后期不好维护。（想象一下如果后期user需要增字段的情况）因此这个时候就可以选用星型模型将这些详细信息放在维度表里，purchase表作为事实表只保留用户id，物品id，商店id以及购买的时间。（购买的时间无法拆分维度，因此仍旧放在事实表里）
整体的模型结构可以如下图所示：
可以看到这里总共有一张事实表以及三张维度表user，item和store。当所有维度表与事实表连接之后，整个模型的形状如同一颗星星一般，故其名为星型模型。
在星型模型中，维度表包括了该维度的所有信息，因为没有分层，所以维度表里面可能会有冗余出现。
为了减少维度表的冗余，这时我们可以使用雪花模型。雪花模型在星型模型的基础上，把维度表中的一些字段进行进一步的拆分，减少冗余，使其更有层次。
以之前的purchase表为例，假设store表里有几个字段是存储商店的位置信息：{省份，市，具体位置}，这个时候可以看出这几个字段其实都可以归属于“省份”这一属性，因此我们可以将这些字段拆分出来，形成一个新的维度表“省份”（Province)。这个维度表是和store维度表连接的，而不是事实表本身。从某一种角度而言，雪花模型拆分维度表有些类似于星型模型拆分事实表的过程。
对于purchase表，拆分后的雪花模型如图所示：
这里可以看到多出了一个新建的维度表。当拆分的维度表更多的时候，可以看出整个模型图会类似于雪花一样扩展，所以这种模型就被称为雪花模型。
星座模型是星型模型的拓展（可以看作是多个事实表版本的星型模型），它的一个特点是多张事实表共用模型中的维度表，适用于比星型模型和雪花模型更复杂的场合。
之前我自己将星座模型和雪花模型弄混的一个原因是它们拓展起来的形状有些类似，如果从图形的角度上来看的话，可以把每张事实表看作一个星星，星座的话因为有多个星星，所以需要存在多张事实表。而雪花模型的话是可以理解成从雪花的中心（事实表）不停向外扩展的形状。这样记忆的话就不会再混淆它们了。
0条评论