对比传统的基于 RDBMS 之上的数据仓库和商业智能项目，尝试着说说，Hadoop 之上的数据仓库，从ETL, 数据存储，到分析展现。重点围绕数据建模方面做分析，因为这是本文的重点，介绍一份新的数据建模方式 Data Vault 2.0.
ETL 最基本的构建来自于 转换和工作流。
工作流，作用是规划一条完整的数据转换流。
转换，是 ETL 最中心的组件。可以用 MapReduce 来完成，也可以用 Spark, Hive .而使用 Spark, Hive 的益处，是在于 Spark, Hive 能将 MapReduce 封装起来。MapReduce 可以由多种语言编写，Java, Python, C++等。为了完成数据转换，而对每一次的转换计算都去用高级语言编程，成本过高。因此用 Spark, Hive 集成的函数和 HQL 语法，完成一些数据转换操作，针对传统基于 RDBMS 转醒过来的开发人员，学习成本会降低很多。
假设我们的电商系统后台是用 MySQL, 体量已经达到 10 TB。
用Sqoop 将这 10TB 同步到 Hive, 报表分析专家在分析的时候，就可以利用分布式计算优势了。简单的事务性事实表，通过传统的 ETL 工具抽取完成之后，直接再由 Sqoop 转入到 Hive.而复杂的二次聚合事实表，可以先由 Sqoop 转入 Hive, 再由 Hive 聚合生成事实表，导入 MySQL 做分布式存储或者报表源头。
hadoop 作为数据仓库，不再仅仅是分布式存储，还可以应用生态工具，Spark,Kylin 做计算。将最终的结果或传回传统的 RDBMS， 或存储到 Hive 这类分布式存储库里。
除了 Kim ball 的维度建模理论， Data Vault 也是数据仓库建模的一种方法。
Data Vault 简单实例，建模思想以及优点劣势，如下所述：
《Hadoop 构建数据仓库实践》中对 Data Vault 做了一些介绍。
从关系表转换成 Data Vault 模型，是对 中心实体，关系产生和消亡，实体及其关系属性的建模。
中心表 - Hubs：
实体，中心表的建模。每个实体都应该单独作为一个中心表的一个记录存在。
中心表，记录实体的代理键和主键，创建时间与创建源。
链接表 - Links：
链接两个实体的关系表。中心表是一个个独立的代表实体的表，没有父子关系存在，没有关联关系存在。因此作为审核两个实体关系的鉴证，链接表必须存储中心表的代理键，关系生效时间，消亡时间。
附属表 - Satellites：
中心表，链接表记录的都是一些维度主体信息，而更细粒度的维度属性信息，事实特征信息则由附属表记录。
让我们看看维基百科上，对 Data Vault 的解释：
https://en.wikipedia.org/wiki/Data_vault_modeling
Focused on the business process, the Data Vault as a data integration architecture, has robust standards and definitional methods which unite information in order to make sense if it. The Data Vault model is comprised of three basic table types:
HUB (blue): containing a list of unique business keys having its own surrogate key. Metadata describing the origin of the business key, or record ‘source’ is also stored to track where and when the data originated.
LNK (red): establishing relationships between business keys (typically hubs, but links can link to other links); essentially describing a many-to-many relationship. Links are often used to deal with changes in data granularity reducing the impact of adding a new business key to a linked Hub.
SAT (yellow): holding descriptive attributes that can change over time (similar to a Kimball Type II slowly changing dimension). Where Hubs and Links form the structure of the data model, Satellites contain temporal and descriptive attributes including metadata linking them to their parent Hub or Link tables. Metadata attributes within a Satellite table containing a date the record became valid and a date it expired provide powerful historical capabilities enabling queries that can go ‘back-in-time’.
重点来了，那么为什么我们需要 Data Vault 建模呢？
参考这篇文来做解释：
https://www.talend.com/blog/2015/03/27/what-is-the-data-vault-and-why-do-we-need-it
There are several key advantages to the Data Vault approach:
Simplifies the data ingestion process
Removes the cleansing requirement of a Star Schema
Instantly provides auditability for HIPPA and other regulations
Puts the focus on the real problem instead of programming around it
Easily allows for the addition of new data sources without disruption to existing schema
Simply put, the Data Vault is both a data modeling technique and methodology which accommodates historical data, auditing, and tracking of data.
“The Data Vault is the optimal choice for modeling the EDW in the DW 2.0 framework”
Bill Inmon
文中提出的在 big data 中遇见的现实问题
problem #1 : The one constant is change, so how well can an EDW/BI solution adapt?
当常规的应用场景变化之后，EDW/BI 还能无更改适用吗？
我在这里强调无更改适用，是和需求变更区分开来。
需求变化了，底层结构不可能不变化，变化多大是需要衡量的。
每一次需求变化，底层结构都要彻底重构，那么成本是极高的。
所以在需求更替的情况下，底层结构如果能做到尽可能小的变更，这个问题就解决了。
每个行业都会有自己的业务模型，针对这些业务模型，专家们可以做出最佳实践来设计数据结构。
一方面，最佳实践来自于专家的经验，经验有来自于时间与案例。
如果这些专家的最佳实践并没有被公开，没有被推广，那么年轻一代依旧是无法掌握的。
年轻的工程师依然需要去走一遭前人趟过的坑，才能转化为自己的见识。
另一方面，业务是不断变化的，昨天的最佳实践，用到今天可能不会有太多效率的提高。比如一直遵循的范式设计，在 OLTP 阶段还能管用，但是在 OLAP 阶段就不适合了。分析场景如果用范式设计，效率差的不是一个级别，有可能就是跑不出来数据。
在前人的基础上，加上自己的一点领悟，与时俱进进行改造，才是正确的做事方法。
problem #2: Really Big Data, often characterized as :Volume, Velocity, Variety, Variability, Veracity, Visualization, & Value!
在商业应用领域，各种分析需要用到很多数据。捕获，清晰，转换，分析报告等各种技术是通过培训可以理解和掌握的。这些无形的应用技术与分析手段可以成为公司竞争的有力条件。随着社交，医疗，互联网金融的发展，数据的应用越来越多，数据的格式也越来越多样化。大数据行业带来的是传统数据应用技术无法交付的挑战。数据应用技术究竟在大数据时代该怎么规范，怎么适应潮流发展，是不是还有传统数据应用的规律可循？都等着去发现。
problem #3: Complexity
基于大数据的 ETL, Data Modeling, Reporting 都会变得比以往复杂。
仅仅是 ETL, 就涉及到了传统数据库与 NoSQL, Hadoop, Hive 的交互。这些交互使用的工具与编程语言是有很多选择性的。比如可以用使用 Java 编写 MapReduce, Sqoop 连接 RDBMS 和 Hadoop, 还可以应用 Talend, Kettle 等 ETL 工具。报表分析工具随着分析需求的变化，又变得多样化。传统的报表工具， BO, SSRS 可能已经不能满足需求，起码这部分工具是直连 RDBMS 而不能直连到 HDFS. 可视化的要求，可能涉及到自定义图像需求，比如聚合，分类，图连接，都需要借助 d3.js, Echarts 等的 Javascript 编程实现。Python, R 等用来分析机器学习结果，也都开发了自己的库。
problem #4： The Business Domain:
业务分析需求多样化。
人工智能与机器学习当下火热的两个领域，分析需求是多样化而且多变性的。
每个学习模型需要的数据格式，可能都需要大量随时可灵活变化。而机器学习专家们是不会去做数据收集这么繁琐的工作，理解他们的需求就变的更有成本。往往给非所需，词不达意。这是更需要数据模型的灵活性建模，在每个需求变化了之后，原先模型都能快速转变为可用的数据原型，供数据科学家使用。
problem #5: Flexibility
综合前面四点，我们要做的就是弹性化的设计方案，ETL ，Data Modeling ，分析与报表都要弹性化。需求随时有变化，上游数据结构也会随时变化以适应需求的更改，因此作为数据应用下游的数据仓库，在设计方面需要考虑到灵活性与可扩展性。而整个数据仓库设计的中心，就是数据建模。一来数据模型是 ETL 的目标结构，可以说 ETL 的设计就是基于数据模型而开展的；二来数据模型是数据分析的基石，决定了报表逻辑以及机器学习等数据挖掘工具的数据输入格式。
以及 Data Vault 对这几个现实问题的解决方案
problem #1 : The one constant is change, so how well can an EDW/BI solution adapt?
我们将实体分为三种存在形式：一是实体的 key 值，二是实体的属性值， 三是实体的 relationship(关系）。Data Vault 2.0 将这些都分开存储，解决了耦合的复杂度，变得更加灵活与可扩展，也就是弹性化程度更高了。
key, relationship都是固定的几列值，相对稳定。
实体的属性值是可以随时变化的，而这种变化反映在Data Vault 2.0 模型上，就是增加几个列。
所以可扩展性非常高。
problem #2: big data
传统的 BI 工具，在ETL 方向上是需要做脏数据处理的，比如删掉一些不符合逻辑的数据。而 Data Vault 2.0 是基于客观事实做的数据增量抽取，不做逻辑校验，因此可以大规模的抽取和处理数据，更符合大数据特征。
problem #3: Complexity:
传统的 BI 工具，建模会有很多的可变性，比如 SCD(Slowly Change Dimension), Fact 表的多变性。而 Data Vault 2.0 就只有 Hub, Link, SAT(Satellite), Link-Satellite 表。区分清楚这些表，剩下的重点就只有设计和调度 ETL了。在建模这一步反而更简单了。
problem #4: The business Domain:
我们不应该把 Data Vault 当做处理脏数据的地方，他仅仅是反映了上游系统数据的真实性，无论是正确还是逻辑错误的数据，都应该在 Data Vault 数据仓库里面反映出来。基于Data Vault 2.0 模型，很快就可以生成业务分析需要的数据模型。这才是需要处理验证逻辑的地方。
problem #5: The Flexibility
Data Vault 2.0 是联合了 Six Sigma, TQM, SDLC 制定的符合 SEI/CMMI Level 5的标准。有着更短的发布周期，一般2-3周即可发布。因此更快更方便的更替业务需求。
