关于数据仓库的一些认识

做了将近3年的数据库和数据仓库（DW）工作，经历了数据仓库从无到有，从基于关系型数据库到现在基于大数据平台，有过很多感受和认识。在构建数据仓库初期，我们整合的数据非常少。为了及时满足需求，我们采用独立数据集市架构，把更多的时间和精力放在ETL开发和报表制作。等到需求越来越多，并且已有数据初具规模时，我们开始思考如何设计真正的数据仓库，当时有两种普遍的架构设计，一是企业信息工厂（CIF）的中心辐射型架构，一是Kimball总线架构。通过对比发现两者最根本的区别在于：CIF在有一层标准化数据结构，并且核心数据以标准化形式存储，这样的直接结果是有两份存储（标准化和维度），开发ETL工作量增加。而Kimball则要更加灵活、易用且易于理解。考虑到成本和开发周期，并且当时大数据技术已经比较流行，迭代建设数据仓库已成定局，我们选择了Kimball总线架构。目前，我们正在将数据仓库迁移至Hadoop平台，主要是应对未来数据量爆发式的增长，以及为满足实时需求（如支持日常运营决策）增加实时处理功能，但核心的Kimball总线数据架构仍未改变。

关于Kimball总线架构的具体细节，大家可以到网上搜索。以hadoop平台为技术基础的DW，我会用专门的一篇文章详细阐述。下面主要谈一谈我认为在DW建设中比较重要并且容易出现错误的主题、团队以及项目管理等方面的问题。

一些重要主题：

DW工程师的使命：DW工程师处于业务用户和IT技术人员之间，这种状态有时让他们很难找到自己合适的位置。因此，定义使命能让他们更加专注于正确的事情，用一句话概况就是：维护数据资产，交付正确数据。DW工程师当然可以对诸如商务分析、平台架构、数据挖掘等产生兴趣，但始终不要忘记自己最初的使命。

需求：需求分析伴随着DW建设的整个周期。DW团队中要有专门对接人，在工程初期主动收集需求，在DW形成一定服务能力后，业务方会主动提出需求。对接人要建立业务知识储备，包括公司的业务架构、价值链和关键的业务过程等，以减少在与业务方沟通时的阻碍，最终交付给团队需求分析文档和业务过程模型图（BPM）。

企业数据现状：调查企业目前的数据现状。包括验证数据源是否可用，确定权威数据源（systems of record），确定主数据和衍生数据等，最后交付源系统追踪报告。

暂存区：设置暂存区的目的是缓解对业务数据库频繁或复杂访问的压力。如果业务数据库性能足够好，可以去掉暂存区。但一般的做法是保留。暂存区对业务用户是不可见的。

操作型数据存储（ODS）：在DW1.0时代，ODS处于业务系统和DW之间，作为缓冲用以满足业务用户在事务级别的查询。主要是因为当时的DW还不能做到快速更新以及支持事务级别的查询。但随着技术发展，现代DW已经能做到按天拉取数据，甚至实时更新，也比从前更加面向事务级别。因此，ODS作为一个单独的子系统存在已无必要。切记不要混淆暂存区与ODS概念。

缓慢变化维度（SCD）：在维度变化中，缓慢变化是最常出现的。处理SCD有三种方式：类型1会销毁历史，重写属性；类型2会创建一个新的维度记录并附加时间戳；类型3会增加字段。具体处理方法要根据字段的业务含义来确定，比如用户的联系方式变化，无需保留历史，可以采用类型1，而用户地址变化，需保留历史，应采用类型2。兼顾记录历史和后面的维度建模，通常采用类型2处理方法，创建代理键，再增加新记录生效的开始日期、结束日期、维度版本号和记录有效标识4个字段。

维度建模：将事物数据转换成维度数据。在这个阶段，要区分维度表和事实表。在建立星形模型之前，要仔细做好以下四步：选择业务过程，声明粒度，识别维度，识别事实。具体参考下一篇文章《维度建模》。

一致性：首先要统一命名规范和建立通用标签。不同的业务用户对相同的名称有不同的含义，或者对相同的含义有不同的命名。比如对“活跃用户”的定义，市场部门可能会与客服部门不同。其次建立一致性维度和事实。数据整合最直接的形式就是实现一致性维度。一致性维度，如时间、用户、产品、位置和组织结构等。一致性事实的重点在于统一事实的计算规则，比如计算客服的业绩，相关部门要统一计算规则。建立一致性是数据整合的关键阶段，识别出分歧点，推动各个业务方和源系统用户召开一致性维度和事实设计会议，在出现困难时，要请管理者出面协调，最终要在维度和事实达成一致。

总线架构：总线架构是Kimball方法的核心，是各个独立部门有效共享数据的蓝图。总线架构是矩阵形式，行表示业务过程，列表示相应的维度。建立总线架构是一个从高层次向低层次不断细化的过程。在收集需求后，从高层次上对核心业务过程和维度画出一个草图，然后可以横向扩展矩阵，包含业务功能，如市场、销售和财务等，也可包含对分析每一个业务过程结果的应用程序，如仪表盘等，这样可为BI程序设计提供指导，还可以通过纵向拆分详细的业务子过程向低层次细化以包含更多的细节。总线架构是DW的数据架构，是与各方沟通的媒介，其质量的好坏直接决定DW的内部数据结构。因此，要给这一阶段分配足够多的资源。

ETL：这个阶段有三点值得注意：首先，ETL是以过程为导向，所以要以价值链的思想为指导，其中每一步数据处理都是应该是简单并且有效的，对最终结果增值。其次，在实施ETL之前，先画出一个数据处理流程图，它独立于任何ETL工具，便于内部人员交流，很难想象没有流程图，你写的一大段SQL能让别人短时间内看懂。最后，要有详细的元数据描述，包括过程元数据、技术元数据和业务元数据三方面。如果自己搭建ETL平台，背后应有强大的IT技术力量作为支撑，特别是在大数据背景下。

数据质量：这个主题再怎么强调也不过分。数据经常会在两个阶段出现问题，一是数据源；二是DW的ETL过程。 在实际工作中，经常是由业务方发现数据问题，反馈给DW团队，我们再通过数据沿袭确定产生问题环节，这会极大地影响问题的处理效率和他们工作进展。正确的做法是在问题发生的环节及时处理，避免传递到下游。因此，有三个数据质量筛选的阶段。首先应该在需求文档中定义数据质量要求，与业务方沟通确定一些简单的业务规则，比如每天事实的行数、可加事实的总和等。其次，在维度建模中。最后在ETL过程中，要嵌入数据质量筛选过程。在这些阶段中，拥有数据归档工具是必要的，在最开始甚至可以用SQL语句来检查质量，随着工程的发展，可以定量分析数据质量，建立相应的指标体系，开发仪表盘用以动态监测数据质量。

数据及时性：每个DW工程师心中都有一条数据高速公路。根据数据延迟依次划分为：初始数据源程序（立即显现）、实时程序（秒级）、业务活动程序（分钟级）、头条程序（24小时）和EDW程序（天、季度和年）。与数据质量一样，及时性也是交付正确数据的一种衡量。

团队：

团队分工：仔细划分工作，如需求采集、源数据调查、维度管理、事实管理、模型设计、ETL、BI程序设计等。可以一个人身兼多职，但最好削减每个人的具体工作至一到两项，然后通过沟通使得每个人都能了解各自工作以及全局概况。成员多样性是团队力量的保障之一。

标准化和规范化：DW已是一门非常成熟的学科，其中很多理论是上个世纪90年代出现的。因此，团队成员在具体实践过程中应遵循统一的标准和规范。在业务过程描述，可以遵循BPMN2.0规范，在DW设计方法，可以遵循Kimball总线架构等。

统一术语：在具体的方法论框架内，内部人员沟通应采用统一的术语。如果在维度建模中，还出现“实体”、“关系”等词汇，就说明还未真正理解维度建模的含义。

学习型组织：数据作为企业的信息流，从产生到应用，流经各个业务过程。在沿途中，与每个过程的相互作用都是一次学习机会。DW工程师应作为学习动力的内核，让团队成员意识到只有不断地学习才是应对外在变化的最有效方法。

开放性思维：数据整合的背后是各方观点达成一致的过程。所以每一次决策都要充分考虑各种因素，如团队实力、各方权重等，最后制定出一个符合DW规范的、各方都较为满意的方案。

项目管理：

三思而后行：切记在实际工作中仓促启动项目，并一开始就写代码，设计表结构，或者选择购买软硬件。花费一周时间仔细思考如以下几个问题：1.关于业务需求：团队是否需要一个固定的KPI小组持续地与业务方接触，分析需求，然后为支持新的KPI而接入新的数据源；2.战略数据归档：调查数据源状况，如果不可用，应及早告知业务方；3.战术数据归档：组织内是否有强制的命令，采用高质量数据用来辅助业务过程？最现实的方法就是检查数据采集的入口点，思考采集的数据是否满足业务需要，是否存在质量问题；4.整合和延迟：组织内是否有强制的命令，跨部门建立一致性描述和度量？已有的技术平台是否满足各种数据延迟需求？

好的开始是成功的一半：如果人员足够充足，可以合理分配资源。具体来说，至少有两项工作可以并行展开，一是需求采集；二是数据现状调查。接下来，可以同时开展三项工作，分别是维度建模、技术架构设计和BI程序设计。

设置milestones：依次需求采集、暂存区、操作型数据存储 、数据仓库和数据集市等各个阶段设置milestone来监测项目的进展情况，其中重要的依据就是交付的文档。

DW之外的事：

组织问题：在企业内部，缺乏信息整合是组织问题，而不是技术问题。整合的程度是数据质量所关注的问题。低层次的整合会营造一种假象，表面上是满足了业务方的需求，其实只是做了一件数据传递的工作，把一方的业务系统数据传给另一方使用。 实现更高层次的整合要在各个部门之间进行协调。实话说，这是一件很令人头疼的事情，尤其是在有部门壁垒情况出现时，一个比较有效的办法是：在接入数据之前，一定要先了解对方业务需求，问问自己能为对方做什么？

获得支持：建设DW是一项复杂的、长期的工程，需要企业持续投入资金、技术和劳动力。并且所获得的收益不能立刻显现， 但从长远来看，会带来很多无形的好处，其中最重要的收获就是数据质量的提高。经过一段时间的数据积累和沉淀，应用高质量的数据进行数据分析可以为公司日常运营、战术和战略各层次的决策制定提供支撑。所以要与相关管理人员共同建立一种长期的视角。

这段时间重新思考并总结之前所做的事，关于DW，我认为最重要的一点就是：这是一份责任感极强的工作。DW不是一个任务，一个项目，它是一项长期的工作。数据整合和数据质量是最重要的两个主题，至于数据治理，那是以后的事情。数据整合是內显的，整合的程度和质量的高低对于外部（业务用户）是不可见的。数据质量同时具有內显和外显性，在数据进入DW内部各个阶段，要保证数据质量。而在最终投放给用户使用前，更要确保质量。所以只要把正确的数据及时送到用户手中，数据整合和DW内部数据质量出现的问题根本无法被发现。在DW初次投放使用的很长一段时间里，一个好的DW和糟糕的DW相比，并无太大差异。只有经过长时间的检验或者系统经历过一次较大的外部变化，问题才会凸显出来。与其它系统或产品在上线前经过严格的测试相比，DW的测试要显得宽松很多，元数据确实是一种有效监测手段，但不足以覆盖全部问题。因此，我说这是一份责任感极强的工作。在以结果为导向的文化氛围里，DW团队更要注重以过程为导向，尤其是在数据整合环节，一定要充分理解用户需求以及将来可能产生的变化，设计出高质量的数据模型，做到问心无愧。

PS：本人目前正在寻找一份数据仓库和数据挖掘的工作。关于数据仓库，熟悉Kimball总线架构，有比较完整的经历；关于数据挖掘，熟悉地理数据的处理和分析方法，上学时有过完整的经历，现在初步学习在MapReduce下编写数据挖掘算法。了解目前通用的计算引擎，如Hadoop、Storm、Spark和Tez，现在能写一些简单的Hadoop、Spark和Storm程序。

我现在能为您做什么？ 实现Kimball总线架构，构建企业数据仓库，为业务用户交付正确的数据。

我的特点：快速学习，适应全英文阅读环境，如果您对数据应用和计算平台有技能要求，并且愿意培养新人，我会用较短时间弥补这些gap。