点击上面的芋道源码，选择星标
管她前浪还是后浪？
能浪的浪，是好浪！
每天 8:55 更新文章，每天掉1亿点头发...
源代码精品专栏
原创 | Java 2020 超神之路，很肝~
中文详细注释的开源项目
RPC 框架 Dubbo 源码解析
网络应用框架 Netty 源码解析
消息中间件 RocketMQ 源码解析
数据库中间件 Sharding-JDBC 和 MyCAT 源码解析
中间调度中间件 Elastic-Job 源码解析
分布式事务中间件 TCC-Transaction 源码解析
Eureka 和 Hystrix 源码解析
Java 并发源码
来源：修鹏李
1.1 数据库
-
1.2 操作数据库和分析数据库
1.3 操作数据库 VS 分析数据库
2.1 概述
-
2.2 OLTP和OLAP
2.3 数据仓库概念
2.4 数据仓库组件
2.5 数据仓库开发流程
2.6 数据仓库系统管理
2.7 数据质量体系
4.1 概述
-
4.2 数据湖定义
4.3 数据湖的处理结构
4.4 数据湖能给企业带来多种能力
4.5 数据湖和数据仓库的区别
4.6 数据湖和数据仓库理解误解
4.7 数据湖建设的基本过程
4.8 主流厂商数据湖解决方案
4.9 典型的数据湖应用案例
4.10 LakeHouse
5.1 基础概念
-
5.2 数据中台与数仓的关系
5.4 公司平台分层，大中台小前台战略
5.5 定义和处理数据中的架构
5.6 数据平台带来价值
5.7 传统数据仓库与数据中心的差异
6.1 数据仓库vs.数据集市
-
6.2 数据仓库vs.ODS
6.3 关系数据库vs.数据仓库和数据湖
如今，随着互联网、物联网等技术的不断发展，越来越多的数据被生产出来——据统计，每天大约有2个.5亿亿字节的各种各样数据产生。这些数据需要被存储起来并且能够被方便的分析和利用。
随着大数据技术的不断更新和迭代，数据管理工具得到了飞速的发展，相关概念如雨后春笋一般应运而生，如从最初决策支持系统(DSS)到商业智能(BI)、数据仓库、数据湖、数据据仓库、数据湖、数据中心平台等。本文系统分析了这些术语和内涵，方便读者全面了解数据平台的相关概念。
1.1 数据库
关系数据库本质上是一种二维关系，简单，是一种二维表格，对普通人来说，最简单的理解是一种Excel表格。这种数据库类型具有结构化程度高、独立性强、冗余度低等优点，突然促进了计算机的发展。
1.2 操作数据库和分析数据库
随着关系数据库理论的提出，一系列经典应运而生RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：
操作数据库
主要用于业务支持。一个公司经常使用和维护几个操作数据库，它保存了公司的日常操作数据，如商品购买、酒店预订、学生成绩输入等；
分析数据库
主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；
那为什么呢？"分家"？在一起不合适吗？能否构建同样适合操作和分析的统一数据库？NO。一个明显的原因是它们会"打架"…如果操作任务和分析任务抢资源怎么办？而且，它们有太多的差异，以至于它们已经存在了"貌合神离"。让我们来看看它们到底有什么不同。
1.3 操作数据库 VS 分析数据库
由于不同的主导功能（面向操作/面向分析），两种数据库在细节上存在许多差异。这就像同一个人，但和尚和穆斯林必须有许多不同的行为/概念。
接下来，本文将详细分析两类数据库的区别：
数据组成差异 - 数据时间范围的差异
一般来说，操作数据库只存储在90天内，而分析数据库存储在几年内。这也是将操作数据与分析数据物理分离的主要原因。
数据组成差异 - 不同层次的数据细节
操作数据库主要存储细节数据，虽然分析数据库中有细节数据和汇总数据，但用户关注汇总数据部分。
操作数据库中自然有汇总需求，但汇总数据本身不存储，只存储其生成公式。这是因为操作数据是动态变化的，所以每次查询都会动态生成汇总数据。
对于分析数据库，由于汇总数据相对稳定，不会改变，计算量相对较大（由于时间跨度大），可以考虑提前计算汇总数据，避免重复计算。
数据组成差异 - 数据时间表示差异
操作数据通常反映现实世界的当前状态；分析数据库既有当前状态，也有过去时刻的快照。分析数据库的用户可以根据所有快照对每个历史阶段进行统计分析。
技术差别 - 查询数据总量与查询频率的差异
操作查询数据量少，频率高，分析查询反过来，数据量大，频率低。不可能同时实现这两种情况的配置优化，这也是两种数据库物理分离的原因之一。
技术差别 - 数据更新差异
操作数据库允许用户添加、删除、更改和检查；分析数据库用户只能查询。
技术差别 - 数据冗余差异
数据的意义是什么？减少数据冗余，避免异常更新。如5所述，分析数据库中没有更新。因此，减少数据冗余并不重要。
现在回到开头是提到的第二个问题"某大公司Hadoop Hive内部关系表不完全满足完整/参考约束、范式要求，甚至第一范式也不完全满足。这种情况正常吗？"，回答是正常的。因为Hive它是一种数据仓库，数据仓库与分析数据库密切相关（稍后将讨论）。它只提供查询接口，不提供更新接口，这使得许多消除冗余的措施不需要特别严格执行。
功能差别 - 不同的数据读者
操作数据库的用户是业务环境中的各个角色，如用户、商家、采购商等；分析数据库只被少数用户用于综合决策。
功能差别 - 数据定位差异
这里的定位主要是指组织的目的。操作数据库也被称为支持特定业务的目的"面向应用数据库"；分析数据库是针对特定业务主题域的分析任务创建的，因此也被称为"面向主题数据库"。
2.1 概述
数据仓库是为了解决数据库无法解决的问题而提出的。那么数据库不能解决什么样的问题呢？我们必须先谈谈什么OLAP和OLTP。
2.2 OLTP和OLAP
2.2.1 OLTP
OLTP（OnLine Transaction Processing 联机事务处理) 。更简单的是数据库的添加、删除和更改。例如，当你去银行取一笔钱或转账时，，或者转账，或者只是想检查你还有多少存款，这些都是针对事务类型的操作。这种操作有几个显著的特点：
首先要求速度快， 基本上是高可靠的在线操作(如银行)， 这些操作涉及的数据内容不会特别大(否则速度会相应降低)， 最后，事务操作往往需要精确操作。例如，当你去银行取款时，你必须要求一个具体的数字。你不可能告诉柜台员工我可能想在400到500之间取款，这样人们就会脸懵逼。
2.2.2 OLAP
这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂，但这里我举一个简单的例子，大家就很容易理解了。
比如说，沃尔玛超市的数据库里有很多张表格，记录着各个商品的交易记录。超市里销售一种运动饮料，我们不妨称之为红牛。数据库中有一张表A，记录了红牛在一年的各个月份的销售额；还有一张表B，记录了红牛每个月在美国各个州的销售额：；甚至还有一张表C，记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表。好，最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下，什么季节，什么天气，美国哪个州最好卖？凭借我们的经验，可能会得出，夏季的晴天，在美国的佛罗里达，最好卖，而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的，但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼。
科学是不相信直觉的，如果我们人工进行手动分析，会发现这个要考虑的维度实在太多了，根本无法下手，何况这才四五个维度，要是更多了怎么办？OLAP就是为了解决这样的问题诞生的，但糟糕的是，传统数据库是无法满足OLAP所需要的数据信息的。
2.3 数据仓库概念
2.3.1 概述
数据库的大规模应用，使得信息行业的数据爆炸式的增长，为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用OLAP来为决策者进行分析，探究一些深层次的关系和信息。但很显然，不同的数据库之间根本做不到数据共享，就算同一家数据库公司，数据库之间的集成也存在非常大的挑战（最主要的问题是庞大的数据如何有效合并、存储）。
1988年，为解决企业的数据集成问题，IBM（卧槽，又是IBM）的两位研究员（Barry Devlin和Paul Murphy）创造性地提出了一个新的术语：数据仓库（Data Warehouse）。看到这里读者朋友们可能要问了，然后呢？然后…然后就没然后了。就在这个创世纪的术语诞生了之后，IBM就哑火了，只是将这个名词作为市场宣传的花哨概念，并没有在技术领域有什么实质性的研究和突破（可悲我大IBM=。=）。
然而，尽管IBM不为所动，其他企业却在加紧对数据仓库的研究和开发，大家都想在这个领域寻找到第一桶金。终于，到了1992年，后来被誉为“数据仓库之父”的比尔 恩门（Bill Inmon）给出了数据仓库的定义，二十多年后的今天他的定义依然没有被时代淘汰。我们来看看他是怎么定义的：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。
对于数据仓库的概念我们可以从两个层次予以理解：
首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。
我们可以不用管这个定义，简单的理解，其实就是我们为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。
这个数据仓库在技术上是怎么建立的读者朋友们并不需要关心，但是我们要知道，原来各个数据孤岛中的数据，可能会在物理位置（比如沃尔玛在各个州可能都有自己的数据中心）、存储格式（比如月份是数值类型，但但天气可能是字符类型）、商业平台（不同数据库可能用的是Oracle数据库，有的是微软SQL Server数据库）、编写的语言（Java或者Scale等）等等各个方面完全不同，数据仓库要做的工作就是将他们按照所需要的格式提取出来，再进行必要的转换（统一数据格式）、清洗（去掉无效或者不需要的数据）等，最后装载进数据仓库（我们所说的ETL工具就是用来干这个的）。这样，拿我们上面红牛的例子来说，所有的信息就统一放在了数据仓库中了。
自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统，其实就是我们现在说的商务智能（Business Intelligence）即BI。
可以这么说，数据仓库为OLAP解决了数据来源问题，数据仓库和OLAP互相促进发展，进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的，正是我们现在热谈的下一代技术：数据挖掘。
2.3.2 数据仓库特点
面向主题特性是数据仓库和操作型数据库的根本区别。
操作型数据库是为了支撑各种业务而建立。
而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。
集成性
集成性是指数据仓库会将不同源数据库中的数据汇总到一起；
具体来说，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。
企业范围
数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；
历史性
较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；
时变性
时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；
数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
2.3.3 数据仓库与BI
数据仓库平台逐步从BI报表为主到分析为主、到预测为主、再到操作智能为目标。
从过去报表发生了什么—>分析为什么过去会发生---->将来会发生什么---->什么正在发生----->让正确的事情发生
商务智能（BI，Business Intelligence）是一种以提供决策分析性的运营数据为目的而建立的信息系统。
是属于在线分析处理：On Line Analytical Processing(OLAP)，将预先计算完成的汇总数据，储存于魔方数据库(Cube) 之中，针对复杂的分析查询，提供快速的响应。
在前10年，BI报表项目比较多，是数据仓库项目的前期预热项目（主要分析为主的阶段，是数据仓库的初级阶段），制作一些可视化报表展现给管理者:
它利用信息科技，将分散于企业内、外部各种数据加以整合并转换成知识，并依据某些特定的主题需求，进行决策分析和运算；用户则通过报表、图表、多维度分析的方式，寻找解决业务问题所需要的方案；这些结果将呈报给决策者，以支持策略性的决策和定义组织绩效，或者融入智能知识库自动向客户推送。
2.3.4 数据仓库系统作用和定位
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。
是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具；
是主要用于历史性、综合性和深层次数据分析；
数据来源是ERP（例:SAP）系统或其他业务系统；
能够提供灵活、直观、简洁和易于操作的多维查询分析;
不是日常交易操作系统，不能直接产生交易数据。
传统离线数据仓库针对实时数据处理，非结构化数据处理能力较弱，以及在业务在预警预测方面应用相对有限。
但现在已经开始兴起实时数仓。
2.3.5 数据仓库能提供什么
2.4 数据仓库组件
数据仓库的核心组件有四个：业务系统各源数据库，ETL，数据仓库，前端应用。如下图所示：
业务系统
业务系统包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；
ETL
数据仓库会周期不断地从源数据库提取清洗好了的数据，因此也被称为"目标系统"。ETL分别代表：
提取extraction
表示从操作型数据库搜集指定数据
转换transformation
表示将数据转化为指定格式，并进行数据清洗保证数据质量
加载load
加载过程表示将转换过后满足指定格式的数据加载进数据仓库。
前端应用
和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用。
数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。
数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。
2.5 数据仓库开发流程
2.5.1 概述
数据仓库的开发流程和数据库的比较相似，因此本文仅就其中区别进行分析。
下图为数据仓库的开发流程：
2.5.2 数据仓库需求
需求搜集是所有环节中最重要的一步，吃透了用户需求，往往就成功了大半。这些需求将指导后面如需求建模、实现、以及前端应用程序开发等。通常来说，需求都会通过ER图来表示(参考数据库需求与ER建模)，并和各业务方讨论搜集得到，最终整理成文档。
要特别强调的一点是数据仓库系统开发需求阶段过程是循环迭代式的，一开始的需求集并不大，但随着项目的进展，需求会越来越多。而且不论是以上哪个阶段发生了需求变动，整个流程都需要重新走一遍，决不允许隐式变更需求。
比如为一个学生选课系统进行ER建模，得到如下结果：
2.5.3 数据仓库建模
也就是逻辑模型建模，可参考第二篇：数据库关系建模
ER建模环节完成后，需求就被描述成了ER图。之后，便可根据这个ER图设计相应的关系表了。
但从ER图到具体关系表的建立还需要经过两个步骤：1. 逻辑模型设计 2. 物理模型设计。其中前者将ER图映射为逻辑意义上的关系表，后者则映射为物理意义上的关系表。
逻辑意义上的关系表可以理解为单纯意义上的关系表，它不涉及到表中字段数据类型，索引信息，触发器等等细节信息。
概念模型 VS 逻辑模型
我们首先可以认为【概念模型建模和ER建模，需求可视化】表达的是一个意思。在这个环节中，数据开发人员绘制ER图，并和项目各方人员协同需求，达成一致。由于这部分的工作涉及到的人员开发能力比较薄弱，甚至不懂开发，因此ER图必须清晰明了，不能涉及到过多的技术细节，比如：要给多对多联系/多值属性等多建一张表，要设置外码，各种复合主码等，它们应当对非开发人员透明。而且ER图中每个属性只会出现一次，减少了蕴含的信息量，是更好的交流和文档化工具。在ER图绘制完毕之后，才开始将它映射为关系表。这个映射的过程，就叫做逻辑模型建模或者关系建模。
还有，ER模型所蕴含的信息，也没有全部被逻辑模型包含。比如联系的自定义基数约束，比如实体的复合属性，派生属性，用户的自定义约束等等。因此ER模型在整个开发流程(如物理模型建模，甚至前端开发)中是都会用到的，不能认为ER模型转换到逻辑模型后就可以扔一边了。
逻辑模型VS物理模型
逻辑模型设计好后，就可以开始着手数据仓库的物理实现了，他也被称为物理模型建模，这个阶段不但需要参照逻辑模型，还应当参照ER图。
2.5.4 数据仓库实现
这一步的本质就是在空的数据仓库里实现2种前面创建的关系模型，一般通过使用SQL或者提供的前端工具实现。
2.5.5 开发前端应用程序
前端应用开发在需求搜集好了之后就开始进行，主要有网站、APP等前端形式。另外前端程序的实际实现涉及到和数据仓库之间交互，因此这一步的最终完成在数据库建模之后。
2.5.6 ETL工程
较之数据库系统开发流程，数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别，所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位，大的公司甚至专门聘请ETL专家。
2.5.7 数据仓库部署
顾名思义，这一步就是部署数据库系统的软硬件环境。数据库部署往往还包含将初始数据填入数据库中的意思。对于云数据仓库，这一步就叫"数据上云"。
2.5.8 数据仓库使用
这一步没啥多讲的，就再讲一个有关的故事吧。同样是在A公司，有一次某政企私有云项目完成后，我们有人被派去给他们培训如何使用。结果去的人回来后说政企意见很大，认为让他们学习SQL以外的东西都不行。拒绝用Python写UDF，更拒绝MR编程接口，只要SQL和图形界面操作方式。一开始我对政企的这种行为有点看不起，但后来我想，就是因为有这群挑剔的用户，才使得A公司云产品的易用性如此强大，从而占领国内云计算的大部分市场。用户的需求才是技术的唯一试金石。
2.5.9 数据库管理和维护
严格来讲，这部分不算开发流程，属于数据库系统开发完成后的工作。
2.6 数据仓库系统管理
数据仓库系统发行后，控制权便从数据仓库设计、实现、部署的团队移交给了数据仓库管理员，并由他们来对系统进行管理，涵盖了确保一个已经部署的数据仓库系统正确运行的各种行为。为了实现这一目标，具体包含以下范畴：
2.7 数据质量体系
数据仓库系统需要重视数据质量问题。用一句话概括，数据质量就是衡量数据能否真实、及时反映客观世界的指标。具体来说，数据质量包含以下几大指标：
准确性
准确性要求数据能够正确描述客观世界。比如某用户姓名拼音mu chen错误的录入成了muc hen，就应该弹出警告语；
唯一性（视情况而定）
唯一性要求数据不能被重复录入，或者不能有两个几乎相同的关系。比如张三李四在不同业务环境下分别建立了近乎相同的关系，这时应将这两个关系合并；
完整性
完整性要求进行数据搜集时，需求数据的被描述程度要高。比如一个用户的购买记录中，必然要有支付金额这个属性；规则验证。
一致性
一致性要求不同关系、或者同一关系不同字段的数据意义不发生冲突。
比如某关系中昨天存货量字段+当天进货量字段-当天销售量字段等于当天存货量就可能是数据质量有问题；
及时性
及时性要求数据库系统中的数据"保鲜"。比如当天的购买记录当天就要入库；
统一性
统一性要求数据格式统一。比如nike这个品牌，不能有的字段描述为"耐克"，而有的字段又是"奈克"；
小结
数据质量和数据具体意义有很大相关性，因此无法单凭理论来保证。且由于具体业务及真实世界的复杂性，数据质量问题必然会存在，不可能完全预防得了。因此很多公司都提供了数据质量工程服务/软件，用来识别和校正数据库系统中的各种数据质量问题。
Bill Inmon说过一句话叫“IT经理们面对最重要的问题就是到底先建立数据仓库还是先建立数据集市”，足以说明搞清楚这两者之间的关系是十分重要而迫切的！通常在考虑建立数据仓库之前，会涉及到如下一些问题：
采取自上而下还是自下而上的设计方法
企业范围还是部门范围
先建立数据仓库还是数据集市
建立领航系统还是直接实施
数据集市是否相互独立
数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。
数据集市可以分为两种:
一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；
另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的子集。
4.1 概述
Pentaho首席技术官James Dixon创造了“数据湖”一词。它把数据集市描述成一瓶水（清洗过的，包装过的和结构化易于使用的）。
而数据湖更像是在自然状态下的水，数据流从源系统流向这个湖。用户可以在数据湖里校验，取样或完全的使用数据。
这个也是一个不精确的定义。数据湖还有以下特点：
从源系统导入所有的数据，没有数据流失。
数据存储时没有经过转换或只是简单的处理。
数据转换和定义schema 用于满足分析需求。
数据湖为什么叫数据湖而不叫数据河或者数据海？一个有意思的回答是：
“河”强调的是流动性，“海纳百川”，河终究是要流入大海的，而企业级数据是需要长期沉淀的，因此叫“湖”比叫“河”要贴切；
同时，湖水天然是分层的，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的，“热”数据在上层，方便应用随时使用；温数据、冷数据位于数据中心不同的存储介质中，达到数据存储容量与成本的平衡。
不叫“海”的原因在于，海是无边无界的，而“湖”是有边界的，这个边界就是企业/组织的业务边界；因此数据湖需要更多的数据管理和权限管理能力。
叫“湖”的另一个重要原因是数据湖是需要精细治理的，一个缺乏管控、缺乏治理的数据湖最终会退化为“数据沼泽”，从而使应用无法有效访问数据，使存于其中的数据失去价值。
4.2 数据湖定义
4.2.1 维基百科对数据湖的定义
数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖是以其自然格式存储的数据的系统或存储库，通常是对象blob或文件。
数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据。
数据湖从企业的多个数据源获取原始数据，并且针对不同的目的，同一份原始数据还可能有多种满足特定内部模型格式的数据副本。因此，数据湖中被处理的数据可能是任意类型的信息，从结构化数据到完全非结构化数据。
企业对数据湖寄予厚望，希望它能帮助用户快速获取有用信息，并能将这些信息用于数据分析和机器学习算法，以获得与企业运行相关的洞察力。
数据湖可以包括:
来自关系数据库（行和列）的结构化数据
半结构化数据（CSV，日志，XML，JSON）
非结构化数据（电子邮件，文档，PDF）和二进制数据（图像，音频，视频）。
目前，HDFS是最常用的部署数据湖的技术，所以很多人会觉得数据湖就是HDFS集群。数据湖是一个概念，而HDFS是用于实现这个概念的技术。
4.2.2 AWS对数据湖的定义
AWS定义数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。
4.2.3 微软对数据湖的定义
微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义，数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。
Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics. Azure Data Lake works with existing IT investments for identity, management, and security for simplified data management and governance. It also integrates seamlessly with operational stores and data warehouses so you can extend current data applications. We’ve drawn on the experience of working with enterprise customers and running some of the largest scale processing and analytics in the world for Microsoft businesses like Office 365, Xbox Live, Azure, Windows, Bing, and Skype. Azure Data Lake solves many of the productivity and scalability challenges that prevent you from maximizing the value of your data assets with a service that’s ready to meet your current and future business needs.
Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。
4.2.4 数据湖定义小结
数据湖需要提供足够用的数据存储能力 这个存储保存了一个企业/组织中的所有数据。
数据湖可以存储海量的任意类型的数据 包括结构化、半结构化和非结构化数据。
数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
数据湖需要具备完善的数据管理能力（完善的元数据） 可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
数据湖需要具备多样化的分析能力 包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。
综上，个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。
4.3 数据湖的处理架构
4.3.1 概述
数据湖引擎介于管理数据系统、分析可视化和数据处理工具之间。数据湖引擎不是将数据从数据源移动到单个存储库，而是部署在现有数据源和数据使用者的工具(如BI工具和数据科学平台)之上。
BI分析工具，如Tableau、Power BI、R、Python和机器学习模型，是为数据生活在一个单一的、高性能的关系数据库中的环境而设计的。然而，多数组织使用不同的数据格式和不同的技术在多种解决方案中管理他们的数据。多数组织现在使用一个或多个非关系型数据存储，如云存储(如S3、ADLS)、Hadoop和NoSQL数据库(如Elasticsearch、Cassandra)。
当数据存储在一个独立的高性能关系数据库中时，BI工具、数据科学系统和机器学习模型可以很好运用这部分数据。然而，就像我们上面所说的一样，数据这并不是存在一个地方。因此，我们通常应用自定义ETL开发来集成来自不同系统的数据，以便于我们后续分析。通常分析技术栈分为以下几类：
ODS
数据从不同的数据库转移到单一的存储区域，如云存储服务(如Amazon S3、ADLS)、HDFS。
数据仓库
虽然可以在Hadoop和云存储上直接执行SQL查询，但是这些系统的设计目的并不是提供交互性能。因此，数据的子集通常被加载到关系数据仓库或MPP数据库中，也就是构建数据仓库。
数据集市
为了在大型数据集上提供交互性能，必须通过在OLAP系统中构建多维数据集或在数据仓库中构建物化聚合表对数据进行预聚合
这种多层体系架构带来了许多挑战。例如：
灵活性，比如数据源的变化或新的数据需求，必须重新访问数据仓库每一层，以确保后续应用人员来使用，可能会花费较长的实施周期。
复杂性，数据分析人员必须了解所有存储数据的查询语法，增加了不必要的复杂性。
技术成本，该架构需要广泛的定制ETL开发、DBA专业知识和数据工程来满足业务中不断发展的数据需求。
基础设施成本，该架构需要大量的专有技术，并且通常会导致存储在不同系统中的数据产生许多副本。
数据治理，该架构如果血缘关系搞的不好，便使得跟踪、维护变得非常困难。
数据及时性，在ETL的过程中需要时间，所以一般数据是T-1的统计汇总。
数据湖引擎采用了一种不同的方法来支持数据分析。数据湖引擎不是将数据移动到单个存储库中，而是在数据原本存储的地方访问数据，并动态地执行任何必要的数据转换和汇总。此外，数据湖引擎还提供了一个自助服务模型，使数据使用者能够使用他们喜欢的工具(如Power BI、Tableau、Python和R)探索、分析数据，而不用关心数据在哪存、结构如何。
有些数据源可能不适合分析处理，也无法提供对数据的有效访问。数据湖引擎提供了优化数据物理访问的能力。有了这种能力，可以在不改变数据使用者访问数据的方式和他们使用的工具的情况下优化各个数据集。
与传统的解决方案相比，数据湖引擎使用多种技术使数据消费者能够访问数据，并集成这些技术功能到一个自助服务的解决方案中。
数据湖可以认为是新一代的大数据基础设施。为了更好的理解数据湖的基本架构，我们先来看看大数据基础设施架构的演进过程。
4.3.2 第一阶段-以Hadoop为代表的离线数据处理基础设施
数据湖可以认为是新一代的大数据基础设施。为了更好的理解数据湖的基本架构，我们先来看看大数据基础设施架构的演进过程。
如下图所示，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施。
围绕HDFS和MR，产生了一系列的组件，不断完善整个大数据平台的数据处理能力，例如面向在线KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了Tez、Spark、Presto、Flink等计算引擎，MR模型也逐渐进化成DAG模型。
DAG模型一方面增加计算模型的抽象并发能力：对每一个计算过程进行分解，根据计算过程中的聚合操作点对任务进行逻辑切分，任务被切分成一个个的stage，每个stage都可以有一个或者多个Task组成，Task是可以并发执行的，从而提升整个计算过程的并行能力；
另一方面，为减少数据处理过程中的中间结果写文件操作，Spark、Presto等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力。
4.3.3 第二阶段：lambda架构
随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。
然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求；而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出，如下图所示。
Lambda架构的核心理念是“流批一体”，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过统一服务层对应用提供，确保访问的一致性，底层到底是批或流对用户透明。
4.3.4 第三阶段：Kappa架构
Lambda架构虽然解决了应用读取数据的统一性问题，但是“流批分离”的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。
4.3.5 大数据基础设施架构小结
综上，从传统的hadoop架构往lambda架构，从lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中，除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳入大数据平台来进行统一的处理。
然而，目前的大数据平台基础架构，都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理，这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。
大数据基础架构的演进，其实反应了一点：在企业/组织内部，数据是一类重要资产已经成为了共识；为了更好的利用数据，企业/组织需要对数据资产进行如下操作：
进行长期的原样存储，以便可回溯重放原始数据
进行有效管理与集中治理；
提供多模式的计算能力满足处理需求；
以及面向业务，提供统一的数据视图、数据模型与数据处理结果。
数据湖就是在这个大背景下产生的，除了有大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。
落到具体的实现上，数据湖需要包括一系列的数据管理组件，包括：
数据接入；
数据搬迁；
数据治理；
数据质量管理；
资产目录；
访问控制；
任务管理；
任务编排；
元数据管理等。
如下图所示，给出了一个数据湖系统的参考架构。
对于一个典型的数据湖而言，它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力，能提供多模式的数据处理能力；增强点在于数据湖提供了更为完善的数据管理能力，具体体现在：
更强大的数据接入能力。
数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
更强大的数据管理能力。
管理能力具体又可分为基本管理能力和扩展管理能力：
基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的，后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。
扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下，数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据，来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题，一般情况下，数据湖系统不会直接提供相关功能，但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
可共享的元数据。
数据湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据。
好的数据湖系统，计算引擎在处理数据时，能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理，而无需进行人工/编程干预。更进一步，好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别。
还有一点应该指出的是，前面数据湖系统的参考架构图的集中式存储更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。
我们可以再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式，数据在数据湖中的整个生命周期如下图所示。理论上，一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化，以满足业务的需要。
4.4 数据湖能给企业带来多种能力
数据湖能给企业带来多种能力，例如，能实现数据的集中式管理，在此之上，企业能挖掘出很多之前所不具备的能力。
另外，数据湖结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。数据湖能从以下方面帮助到企业：
实现数据治理（data governance）；
通过应用机器学习与人工智能技术实现商业智能；
预测分析，如领域特定的推荐引擎；
信息追踪与一致性保障；
根据对历史的分析生成新的数据维度；
有一个集中式的能存储所有企业数据的数据中心，有利于实现一个针对数据传输优化的数据服务；
帮助组织或企业做出更多灵活的关于企业增长的决策。
4.5 数据湖与数据仓库区别
对于数据仓库与数据湖的不同之处，你可以想象一下仓库和湖泊的区别：仓库存储着来自特定来源的货物，而湖泊的水来自河流、溪流和其他来源，并且是原始数据。
数据仓库供应商包括AWS、Cloudera、IBM、谷歌、微软、甲骨文、Teradata、SAP、SnapLogic和Snowflake等。数据湖提供商包括AWS、谷歌、Informatica、微软、Teradata等。
4.5.2 数据湖保留全部的数据
存储范围
数据仓库开发期间，大量的时间花费在分析数据源，理解商业处理和描述数据。结果就是为报表设计高结构化的数据模型。这一过程大部分的工作就是来决定数据应不应该导入数据仓库。通常情况下，如果数据不能满足指定的问题，就不会导入到数据仓库。这么做是为了简化数据模型和节省数据存储空间。
相反，数据湖保留所有的数据。不仅仅是当前正在使用的数据，甚至不被用到的数据也会导进来。数据会一直被保存所有我们可以回到任何时间点来做分析。
因为数据湖使用的硬件与数据仓库的使用的不同，使这种方法成为了可能。现成的服务器与便宜的存储相结合，使数据湖扩展到TB级和PB级非常经济。
存储来源
数据仓库主要存储来自运营系统的大量数据
而数据湖则存储来自更多来源的数据，包括来自企业的运营系统和其他来源的各种原始数据资产集。
4.5.3 数据湖支持所有数据类型
在储存方面上，数据湖中数据为非结构化的，所有数据都保持原始形式，并且仅在分析时再进行转换。
数据仓库一般由从事务系统中提取的数据组成，并由定量度量和描述它们的属性组成。诸如Web服务器日志，传感器数据，社交网络活动，文本和图像等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现，但是消费和存储它们可能是昂贵和困难的。
数据湖方法包含这些非传统数据类型。在数据湖中，我们保留所有数据，而不考虑源和结构。我们保持它的原始形式，并且只有在我们准备好使用它时才会对其进行转换。这种方法被称为“读时模式”。
数据仓库则是捕获结构化数据并将其按模式组织。
4.5.4 适用人群
由于数据湖中的数据可能不准确，并且可能来自企业运营系统之外的来源，因此不是很适合普通的业务分析用户;数据湖更适合数据科学家和其他数据分析专家，使用他们需要的非常庞大和多样化的数据集。
其他用户则可以使用更为结构化的数据视图如数据仓库来提供他们使用的数据，数据仓库非常适用于月度报告等操作用途，因为它具有高度结构化。
4.5.5 数据湖很容易适应变化
关于数据仓库的主要抱怨之一是需要多长时间来改变它们。在开发过程中花费大量时间来获得仓库的结构。一个好的仓库设计可以适应变化，但由于数据加载过程的复杂性以及为简化分析和报告所做的工作，这些更改必然会消耗一些开发人员资源并需要一些时间。
许多业务问题都迫不及待地让数据仓库团队适应他们的系统来回答问题。日益增长的对更快答案的需求促成了自助式商业智能的概念。
另一方面，在数据湖中，由于所有数据都以其原始形式存储，并且始终可供需要使用它的人访问，因此用户有权超越仓库结构以新颖方式探索数据并回答它们问题在他们的步伐。
如果一个探索的结果被证明是有用的并且有重复的愿望，那么可以应用更正式的模式，并且可以开发自动化和可重用性来帮助将结果扩展到更广泛的受众。如果确定结果无用，则可以丢弃该结果，并且不会对数据结构进行任何更改，也不会消耗开发资源。
所以，在架构方面：
数据湖通常在存储数据之后定义架构，使用较少的初始工作并提供更大的灵活性。
在数据仓库中存储数据之前定义架构。
4.5.6 数据湖支持快速洞察数据
最后的区别实际上是其他区别结果。由于数据湖包含所有数据和数据类型，因为它使用户能够在数据转换，清理和结构化之前访问数据，从而使用户能够比传统数据仓库方法更快地获得结果。
但是，这种对数据的早期访问是有代价的。通常由数据仓库开发团队完成的工作可能无法完成分析所需的部分或全部数据源。这让驾驶座位的用户可以根据需要探索和使用数据，但上述第一层业务用户可能不希望这样做。他们仍然只想要他们的报告和KPI。
在数据湖中，这些操作报告的使用者将利用更加结构化的数据湖中数据的结构视图，这些视图与数据仓库中以前一直存在的数据相似。不同之处在于，这些视图主要存在于位于湖泊中的数据之上的元数据，而不是需要开发人员更改的物理刚性表格。
4.6 数据湖和数据仓库理解误区
误解一：数据仓库和数据湖二者在架构上只能二选一
很多人认为数据仓库和数据湖在架构上只能二选一，其实这种理解是错误的。数据湖和数据仓库并不是对立关系，相反它们的并存可以互补给企业架构带来更多的好处：
数据仓库存储结构化的数据，适用于快速的BI和决策支撑，
而数据湖可以存储任何格式的数据，往往通过挖掘能够发挥出数据的更大作为。
所以在一些场景上二者的并存是可以给企业带来更多效益的。
误解二：相对于数据湖，数据仓库更有名更受欢迎
人工智能（AI）和机器学习项目的成功往往需要数据湖来做支撑。因为数据湖可让您存储几乎任何类型的数据而无需先准备或清理，所以可以保留尽可能多的潜在价值。而数据仓库存储的数据都是经过清洗，往往会丢失一些有价值的信息。
数据仓库虽然是这两种中比较知名的，但是随着数据挖掘需求的发展，数据湖的受欢迎程度可能会继续上升。数据仓库对于某些类型的工作负载和用例工作良好，而数据湖则是为其他类型的工作负载提供服务的另一种选择。
误解三：数据仓库易于使用，而数据湖却很复杂
确实，数据湖需要数据工程师和数据科学家的特定技能，才能对存储在其中的数据进行分类和利用。数据的非结构化性质使那些不完全了解数据湖如何工作的人更难以访问它。
但是，一旦数据科学家和数据工程师建立了数据模型或管道，业务用户就可以利用建立的数据模型以及流行的业务工具（定制或预先构建）的来访问和分析数据，而不在乎该数据存储在数据仓库中还是数据湖中。
4.7 数据湖建设的基本过程
个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施，完善在数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性，例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等，无一不是为了更好的贴近业务，更好的方便客户使用。数据湖所强调的一些基本的技术特性，例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等，也是为了满足业务需求，并且给业务方提供最具性价比的TCO。
数据湖的建设过程应该与业务紧密结合；但是数据湖的建设过程与传统的数据仓库，甚至是大热的数据中台应该是有所区别的。区别在于，数据湖应该以一种更敏捷的方式去构建，“边建边用，边用边治理”。为了更好的理解数据湖建设的敏捷性，我们先来看一下传统数仓的构建过程。业界对于传统数仓的构建提出了“自下而上”和“自顶而下”两种模式，分别由Inmon和KimBall两位大牛提出。具体的过程就不详述了，不然可以再写出几百页，这里只简单阐述基本思想。
1）Inmon提出自下而上（EDW-DM）的数据仓库建设模式，即操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层；ODS层中的数据，根据预先设计好的EDW（企业级数据仓库）范式进行加工处理，然后进入到EDW。EDW一般是企业/组织的通用数据模型，不方便上层应用直接做数据分析；因此，各个业务部门会再次根据自己的需要，从EDW中处理出数据集市层（DM）。
优势：易于维护，高度集成；劣势：结构一旦确定，灵活性不足，且为了适应业务，部署周期较长。此类方式构造的数仓，适合于比较成熟稳定的业务，例如金融。
2）KimBall提出自顶而下（DM-DW）的数据架构，通过将操作型或事务型系统的数据源，抽取或加载到ODS层；然后通过ODS的数据，利用维度建模方法建设多维主题数据集市（DM）。各个DM，通过一致性的维度联系在一起，最终形成企业/组织通用的数据仓库。
优势：构建迅速，最快的看到投资回报率，敏捷灵活；劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。常应用于中小企业或互联网行业。
其实上述只是一个理论上的过程，其实无论是先构造EDW，还是先构造DM，都离不开对于数据的摸底，以及在数仓构建之前的数据模型的设计，包括当前大热的“数据中台”，都逃不出下图所示的基本建设过程。
1） 数据摸底。
对于一个企业/组织而言，在构建数据湖初始工作就是对自己企业/组织内部的数据做一个全面的摸底和调研，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量等。在这个阶段一个隐含的重要工作是借助数据摸底工作，进一步梳理企业的组织结构，明确数据和组织结构之间关系。为后续明确数据湖的用户角色、权限设计、服务方式奠定基础。
2） 模型抽象。
针对企业/组织的业务特点梳理归类各类数据，对数据进行领域划分，形成数据管理的元数据，同时基于元数据，构建通用的数据模型。
3） 数据接入。
根据第一步的摸排结果，确定要接入的数据源。根据数据源，确定所必须的数据接入技术能力，完成数据接入技术选型，接入的数据至少包括：数据源元数据、原始数据元数据、原始数据。各类数据按照第二步形成的结果，分类存放。
4） 融合治理。
简单来说就是利用数据湖提供的各类计算引擎对数据进行加工处理，形成各类中间数据/结果数据，并妥善管理保存。数据湖应该具备完善的数据开发、任务管理、任务调度的能力，详细记录数据的处理过程。在治理的过程中，会需要更多的数据模型和指标模型。
5） 业务支撑。
在通用模型基础上，各个业务部门定制自己的细化数据模型、数据使用流程、数据访问服务。
上述过程，对于一个快速成长的互联网企业来说，太重了，很多情况下是无法落地的，最现实的问题就是第二步模型抽象，很