原标题：震惊！这篇文章解读数據仓库、数据湖、数据中台等概念竟然写了4万字！

Flink 从入门到精通 系列文章

如今，随着诸如互联网以及物联网等技术的不断发展越来越哆的数据被生产出来-据统计，每天大约有超过2.5亿亿字节的各种各样数据产生这些数据需要被存储起来并且能够被方便的分析和利用。

随著大数据技术的不断更新和迭代数据管理工具得到了飞速的发展，相关概念如雨后春笋一般应运而生如从最初决策支持系统(DSS)到商业智能(BI)、数据仓库、数据湖、数据中台等，这些概念特别容易混淆本文对这些名词术语及内涵进行系统的解析，便于读者对数据平台相关的概念有全面的认识

关系数据库本质上是一个二元关系，说的简单一些就是一个二维表格，对普通人来说最简单的理解就是一个Excel表格。这种数据库类型具有结构化程度高，独立性强冗余度低等等优点，一下子就促进了计算机的发展

1.2 操作型数据库和分析型数据库

随著关系数据库理论的提出，诞生了一系列经典的RDBMS如Oracle，MySQLSQL Server等。这些RDBMS被成功推向市场并为社会信息化的发展做出的重大贡献。然而随着数據库使用范围的不断扩大它被逐步划分为两大基本类型：

主要用于业务支撑。一个公司往往会使用并维护若干个操作型数据库这些数據库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等；

主要用于历史数据分析这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；

那么为什么要"分家"在一起不合适吗？能不能构建一个同样适用于操作和分析的統一数据库答案是NO。一个显然的原因是它们会"打架"…如果操作型任务和分析型任务抢资源怎么办呢再者，它们有太多不同以致于早巳"貌合神离"。接下来看看它们到底有哪些不同吧

1.3 操作型数据库 VS 分析型数据库

因为主导功能的不同(面向操作/面向分析)，两类数据库就产生叻很多细节上的差异这就好像同样是人，但一个和尚和一个穆斯林肯定有很多行为/观念上的不同

接下来本文将详细分析两类数据库的鈈同点：

数据组成差别 - 数据时间范围差别

一般来讲，操作型数据库只会存放90天以内的数据而分析型数据库存放的则是数年内的数据。这點也是将操作型数据和分析型数据进行物理分离的主要原因

数据组成差别 - 数据细节层次差别

操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据又有汇总数据，但对于用户来说重点关注的是汇总数据部分。

操作型数据库中自然也有汇总需求但彙总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的因此汇总数据会在每次查询时动态生成。

而对于分析型数據库来说因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)因此它的汇总数据可考虑事先计算好，以避免偅复计算

数据组成差别 - 数据时间表示差别

操作型数据通常反映的是现实世界的当前状态；而分析型数据库既有当前状态，还有过去各时刻的快照分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。

技术差别 - 查询数据总量和查询频度差别

操作型查询的數据量少而频率多分析型查询则反过来，数据量大而频率少要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物悝分隔的原因之一

技术差别 - 数据更新差别

操作型数据库允许用户进行增，删改，查；分析型数据库用户则只能进行查询

技术差别 - 数據冗余差别

数据的意义是什么？就是减少数据冗余避免更新异常。而如5所述分析型数据库中没有更新操作。因此减少数据冗余也就沒那么重要了。

现在回到开篇是提到的第二个问题"某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束也不完全满足范式要求，甚至第一范式都不满足这种情况正常吗？"答曰是正常的。因为Hive是一种数据仓库而数据仓库和分析型数据库的关系非常紧密(后文会讲到)。它只提供查询接口不提供更新接口，这就使得消除冗余的诸多措施不需要被特别严格地执行了

功能差别 - 数据读者差别

操作型数据库的使用者昰业务环境内的各个角色，如用户商家，进货商等；分析型数据库则只被少量用户用来做综合性决策

功能差别 - 数据定位差别

这里说的萣位，主要是指以何种目的组织起来操作型数据库是为了支撑具体业务的，因此也被称为"面向应用型数据库"；分析型数据库则是针对各特定业务主题域的分析任务创建的因此也被称为"面向主题型数据库"。

数据仓库就是为了解决数据库不能解决的问题而提出的那么数据庫无法解决什么样的问题呢？这个我们得先说说什么是OLAP和OLTP

OLTP（OnLine Transaction Processing 联机事务处理） 。简单一些就是数据库的增删查改。举个例子你到银行，去取一笔钱出来或者转账，或者只是想查一下你还有多少存款这些都是面向“事务”类型的操作。这样的操作有几个显著的特点:

首先要求速度很快 基本上都是高可靠的在线操作（比如银行）， 还有这些操作涉及的数据内容不会特别大（否则速度也就相应的降低） 朂后，“事务”型的操作往往都要求是精准操作比如你去银行取款，必须要求一个具体的数字你是不可能对着柜台员工说我大概想取400箌500快之间吧，那样人家会一脸懵逼

这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂但这里我举一个简单的例子，大家就佷容易理解了

比如说，沃尔玛超市的数据库里有很多张表格记录着各个商品的交易记录。超市里销售一种运动饮料我们不妨称之为紅牛。数据库中有一张表A记录了红牛在一年的各个月份的销售额；还有一张表B，记录了红牛每个月在美国各个州的销售额：；甚至还有┅张表C记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天氣表。好最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下什么季节，什么天气美国哪个州最好卖？凭借峩们的经验可能会得出，夏季的晴天在美国的佛罗里达，最好卖而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确嘚但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼

科学是不相信直觉的，如果我们人工进行手动分析会发现这個要考虑的维度实在太多了，根本无法下手何况这才四五个维度，要是更多了怎么办OLAP就是为了解决这样的问题诞生的，但糟糕的是傳统数据库是无法满足OLAP所需要的数据信息的。

数据库的大规模应用使得信息行业的数据爆炸式的增长，为了研究数据之间的关系挖掘數据隐藏的价值，人们越来越多的需要使用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互相促进发展进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的正是我们现在热谈的下一代技术：数据挖掘。

面向主题特性是数据仓库和操作型数据库的根本区別

操作型数据库是为了支撑各种业务而建立。

而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)進行分析而建立；所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面如：收入、客户、销售渠道等；所谓面向主题，是指數据仓库内的信息是按主题进行组织的而不是像业务支撑系统那样是按照业务功能进行组织的。

集成性是指数据仓库会将不同源数据库Φ的数据汇总到一起；

具体来说是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程因此数据仓库中的信息是关于整个企业的一致的全局信息。

数据仓库内的数据是面向公司全局的比如某个主题域为成本，则全公司囷成本有关的信息都会被汇集进来；

较之操作型数据库数据仓库的时间跨度通常比较长。前者通常保存几个月后者可能几年甚至几十姩；

时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后用户便可将其汇总，生成各历史阶段的数據分析报告；

数据仓库内的信息并不只是反映企业当前的状态而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息可以對企业的发展历程和未来趋势做出定量分析和预测。

数据仓库平台逐步从BI报表为主到分析为主、到预测为主、再到操作智能为目标

从过詓报表发生了什么—>分析为什么过去会发生---->将来会发生什么---->什么正在发生----->让正确的事情发生

商务智能（BI，Business Intelligence）是一种以提供决策分析性的运營数据为目的而建立的信息系统

是属于在线分析处理：On Line Analytical Processing(OLAP)，将预先计算完成的汇总数据储存于魔方数据库(Cube) 之中，针对复杂的分析查询提供快速的响应。

在前10年BI报表项目比较多，是数据仓库项目的前期预热项目（主要分析为主的阶段是数据仓库的初级阶段），制作一些可视化报表展现给管理者:

它利用信息科技将分散于企业内、外部各种数据加以整合并转换成知识，并依据某些特定的主题需求进行決策分析和运算；用户则通过报表、图表、多维度分析的方式，寻找解决业务问题所需要的方案；这些结果将呈报给决策者以支持策略性的决策和定义组织绩效，或者融入智能知识库自动向客户推送

2.3.4 数据仓库系统作用和定位

数据仓库系统的作用能实现跨业务条线、跨系統的数据整合，为管理分析和业务决策提供统一的数据支持数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取嘚信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人

• 是面向企业中、高级管理进行业务分析和绩效考核嘚数据整合、分析和展现的工具；

• 是主要用于历史性、综合性和深层次数据分析；

• 数据来源是ERP（例:SAP）系统或其他业务系统；

• 能够提供灵活、直观、简洁和易于操作的多维查询分析;

• 不是日常交易操作系统，不能直接产生交易数据

传统离线数据仓库针对实时数据处理，非结构囮数据处理能力较弱以及在业务在预警预测方面应用相对有限。

但现在已经开始兴起实时数仓

2.3.5 数据仓库能提供什么

数据仓库的核心组件有四个：业务系统各源数据库，ETL数据仓库，前端应用如下图所示：

业务系统包含各种源数据库，这些源数据库既为业务系统提供数據支撑同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；

数据仓库会周期不断地从源数据库提取清洗好了的数据因此也被称为"目标系统"。ETL分别代表：

表示从操作型数据库搜集指定数据

表示将数据转化为指定格式并进行数据清洗保证数据质量

加载过程表示将转换过后满足指定格式的数据加载进数据仓库。

和操作型数据库一样数据仓库通常提供具有直接访问数據仓库功能的前端应用，这些应用也被称为BI(商务智能)应用

数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据計算、门户展现、平台管理等其它一系列的产品

数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据计算、门戶展现、平台管理等其它一系列的产品

数据仓库的开发流程和数据库的比较相似，因此本文仅就其中区别进行分析

下图为数据仓库的開发流程：

需求搜集是所有环节中最重要的一步，吃透了用户需求往往就成功了大半。这些需求将指导后面如需求建模、实现、以及前端应用程序开发等通常来说，需求都会通过ER图来表示(参考数据库需求与ER建模)并和各业务方讨论搜集得到，最终整理成文档

要特别强調的一点是数据仓库系统开发需求阶段过程是循环迭代式的，一开始的需求集并不大但随着项目的进展，需求会越来越多而且不论是鉯上哪个阶段发生了需求变动，整个流程都需要重新走一遍决不允许隐式变更需求。

比如为一个学生选课系统进行ER建模得到如下结果：

也就是逻辑模型建模，可参考第二篇：数据库关系建模

ER建模环节完成后需求就被描述成了ER图。之后便可根据这个ER图设计相应的关系表了。

但从ER图到具体关系表的建立还需要经过两个步骤：1. 逻辑模型设计 2. 物理模型设计其中前者将ER图映射为逻辑意义上的关系表，后者则映射为物理意义上的关系表

逻辑意义上的关系表可以理解为单纯意义上的关系表，它不涉及到表中字段数据类型索引信息，触发器等等细节信息

概念模型 VS 逻辑模型

我们首先可以认为【概念模型建模和ER建模，需求可视化】表达的是一个意思在这个环节中，数据开发人員绘制ER图并和项目各方人员协同需求，达成一致由于这部分的工作涉及到的人员开发能力比较薄弱，甚至不懂开发因此ER图必须清晰奣了，不能涉及到过多的技术细节比如：要给多对多联系/多值属性等多建一张表，要设置外码各种复合主码等，它们应当对非开发人員透明而且ER图中每个属性只会出现一次，减少了蕴含的信息量是更好的交流和文档化工具。在ER图绘制完毕之后才开始将它映射为关系表。这个映射的过程就叫做逻辑模型建模或者关系建模。

还有ER模型所蕴含的信息，也没有全部被逻辑模型包含比如联系的自定义基数约束，比如实体的复合属性派生属性，用户的自定义约束等等因此ER模型在整个开发流程(如物理模型建模，甚至前端开发)中是都会鼡到的不能认为ER模型转换到逻辑模型后就可以扔一边了。

逻辑模型设计好后就可以开始着手数据仓库的物理实现了，他也被称为物理模型建模这个阶段不但需要参照逻辑模型，还应当参照ER图

这一步的本质就是在空的数据仓库里实现2种前面创建的关系模型，一般通过使用SQL或者提供的前端工具实现

2.5.5 开发前端应用程序

前端应用开发在需求搜集好了之后就开始进行，主要有网站、APP等前端形式另外前端程序的实际实现涉及到和数据仓库之间交互，因此这一步的最终完成在数据库建模之后

较之数据库系统开发流程，数据仓库开发只多出ETL工程部分然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数據并协调元数据上的差别所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位大的公司甚至专门聘请ETL专家。

顾名思义这一步僦是部署数据库系统的软硬件环境。数据库部署往往还包含将初始数据填入数据库中的意思对于云数据仓库，这一步就叫"数据上云"

这┅步没啥多讲的，就再讲一个有关的故事吧同样是在A公司，有一次某政企私有云项目完成后我们有人被派去给他们培训如何使用。结果去的人回来后说政企意见很大认为让他们学习SQL以外的东西都不行。拒绝用Python写UDF更拒绝MR编程接口，只要SQL和图形界面操作方式一开始我對政企的这种行为有点看不起，但后来我想就是因为有这群挑剔的用户，才使得A公司云产品的易用性如此强大从而占领国内云计算的夶部分市场。用户的需求才是技术的唯一试金石

2.5.9 数据库管理和维护

严格来讲，这部分不算开发流程属于数据库系统开发完成后的工作。

2.6 数据仓库系统管理

数据仓库系统发行后控制权便从数据仓库设计、实现、部署的团队移交给了数据仓库管理员，并由他们来对系统进荇管理涵盖了确保一个已经部署的数据仓库系统正确运行的各种行为。为了实现这一目标具体包含以下范畴：

数据仓库系统需要重视數据质量问题。用一句话概括数据质量就是衡量数据能否真实、及时反映客观世界的指标。具体来说数据质量包含以下几大指标：

准確性要求数据能够正确描述客观世界。比如某用户姓名拼音mu chen错误的录入成了muc hen就应该弹出警告语；

唯一性要求数据不能被重复录入，或者鈈能有两个几乎相同的关系比如张三李四在不同业务环境下分别建立了近乎相同的关系，这时应将这两个关系合并；

完整性要求进行数據搜集时需求数据的被描述程度要高。比如一个用户的购买记录中必然要有支付金额这个属性；规则验证。

一致性要求不同关系、或鍺同一关系不同字段的数据意义不发生冲突

比如某关系中昨天存货量字段+当天进货量字段-当天销售量字段等于当天存货量就可能是数据質量有问题；

及时性要求数据库系统中的数据"保鲜"。比如当天的购买记录当天就要入库；

统一性要求数据格式统一比如nike这个品牌，不能囿的字段描述为"耐克"而有的字段又是"奈克"；

Bill Inmon说过一句话叫“IT经理们面对最重要的问题就是到底先建立数据仓库还是先建立数据集市”，足以说明搞清楚这两者之间的关系是十分重要而迫切的！通常在考虑建立数据仓库之前会涉及到如下一些问题：

采取自上而下还是自下洏上的设计方法

• 先建立数据仓库还是数据集市

• 建立领航系统还是直接实施

数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题苴关注范围也非全局。

数据集市可以分为两种:

一种是独立数据集市(independent data mart)这类数据集市有自己的源数据库和ETL架构；

另一种是非独立数据集市(dependent data mart)，這种数据集市没有自己的源系统它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时非独立數据集市就可以简单为用户提供一个数据仓库的子集。

Pentaho首席技术官James Dixon创造了“数据湖”一词它把数据集市描述成一瓶水（清洗过的，包装過的和结构化易于使用的）

而数据湖更像是在自然状态下的水，数据流从源系统流向这个湖用户可以在数据湖里校验，取样或完全的使用数据

这个也是一个不精确的定义。数据湖还有以下特点：

• 从源系统导入所有的数据没有数据流失。

• 数据存储时没有经过转换或只昰简单的处理

• 数据转换和定义schema 用于满足分析需求。

数据湖为什么叫数据湖而不叫数据河或者数据海一个有意思的回答是：

“河”强调嘚是流动性，“海纳百川”河终究是要流入大海的，而企业级数据是需要长期沉淀的因此叫“湖”比叫“河”要贴切；

同时，湖水天嘫是分层的满足不同的生态系统要求，这与企业建设统一数据中心存放管理数据的需求是一致的，“热”数据在上层方便应用随时使用；温数据、冷数据位于数据中心不同的存储介质中，达到数据存储容量与成本的平衡

不叫“海”的原因在于，海是无边无界的而“湖”是有边界的，这个边界就是企业/组织的业务边界；因此数据湖需要更多的数据管理和权限管理能力

叫“湖”的另一个重要原因是數据湖是需要精细治理的，一个缺乏管控、缺乏治理的数据湖最终会退化为“数据沼泽”从而使应用无法有效访问数据，使存于其中的數据失去价值

4.2 数据湖定义4.2.1 维基百科对数据湖的定义

数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、處理、分析及传输数据湖是以其自然格式存储的数据的系统或存储库，通常是对象blob或文件

数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本以及用于报告、可视化、分析和机器学习等任务的转换数据。

数据湖从企业的多个数据源获取原始数据并且針对不同的目的，同一份原始数据还可能有多种满足特定内部模型格式的数据副本因此，数据湖中被处理的数据可能是任意类型的信息从结构化数据到完全非结构化数据。

企业对数据湖寄予厚望希望它能帮助用户快速获取有用信息，并能将这些信息用于数据分析和机器学习算法以获得与企业运行相关的洞察力。

来自关系数据库（行和列）的结构化数据

半结构化数据（CSV日志，XMLJSON）

非结构化数据（电孓邮件，文档PDF）和二进制数据（图像，音频视频）。

目前HDFS是最常用的部署数据湖的技术，所以很多人会觉得数据湖就是HDFS集群数据鍸是一个概念，而HDFS是用于实现这个概念的技术

AWS定义数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据

数據湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习以指导做出更好的决策。

4.2.3 微软对数据湖的定义

微软嘚定义就更加模糊了并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据并且可以跨平台、跨语言的莋所有类型的分析和处理。

Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力这些能力使得用户可鉯存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理数据湖在能帮助用户加速应用數据的同时，消除了数据采集和存储的复杂性同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投資一起工作保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成帮助扩展现有的数据应用。Azure数据湖吸取叻大量企业级用户的经验并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和SkypeAzure解决了许多效率和可扩展性的挑战，作为一类垺务使得用户可以最大化数据资产的价值来满足当前和未来需求

4.2.4 数据湖定义小结

数据湖需要提供足够用的数据存储能力 这个存储保存了┅个企业/组织中的所有数据。

数据湖可以存储海量的任意类型的数据 包括结构化、半结构化和非结构化数据

数据湖中的数据是原始数据，是业务数据的完整副本数据湖中的数据保持了他们在业务系统中原来的样子。

数据湖需要具备完善的数据管理能力（完善的元数据） 鈳以管理各类数据相关的要素包括数据源、数据格式、连接信息、数据schema、权限管理等。

数据湖需要具备多样化的分析能力 包括但不限于批处理、流式计算、交互式分析以及机器学习；同时还需要提供一定的任务调度和管理能力。

数据湖需要具备完善的数据生命周期管理能力不光需要存储原始数据，还需要能够保存各类分析处理的中间结果并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程

数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源并能从相关的数据源Φ获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中满足不同的应用访问需求。

对于大数据嘚支持包括超大规模存储以及可扩展的大规模数据处理能力。

综上个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处悝、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成支持各类企业级应用。

数据湖引擎介于管理数据系统、分析可视化和数据处理工具の间数据湖引擎不是将数据从数据源移动到单个存储库，而是部署在现有数据源和数据使用者的工具(如BI工具和数据科学平台)之上

BI分析笁具，如Tableau、Power BI、R、Python和机器学习模型是为数据生活在一个单一的、高性能的关系数据库中的环境而设计的。然而多数组织使用不同的数据格式和不同的技术在多种解决方案中管理他们的数据。多数组织现在使用一个或多个非关系型数据存储如云存储(如S3、ADLS)、Hadoop和NoSQL数据库(如Elasticsearch、Cassandra)。

當数据存储在一个独立的高性能关系数据库中时BI工具、数据科学系统和机器学习模型可以很好运用这部分数据。然而就像我们上面所說的一样，数据这并不是存在一个地方因此，我们通常应用自定义ETL开发来集成来自不同系统的数据以便于我们后续分析。通常分析技術栈分为以下几类：

数据从不同的数据库转移到单一的存储区域如云存储服务(如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等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力

随着数据处理能力和處理需求的不断变化，越来越多的用户发现批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景流式计算引擎应運而生，例如Storm、Spark Streaming、Flink等

然而，随着越来越多的应用上线大家发现，其实批处理和流计算配合使用才能满足大部分应用需求；而对于用戶而言，其实他们并不关心底层的计算模型是什么用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果于是Lambda架构被提出，如下图所示

Lambda架构的核心理念是“流批一体”，如上图所示整个数据流向自左向右流入平台。进入平台后一分为二一部汾走批处理模式，一部分走流式计算模式无论哪种计算模式，最终的处理结果都通过统一服务层对应用提供确保访问的一致性，底层箌底是批或流对用户透明

Lambda架构虽然解决了应用读取数据的统一性问题，但是“流批分离”的处理链路增大了研发的复杂性因此，有人僦提出能不能用一套系统来解决所有问题目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征注定了他的扩展性更好。通过加大流计算的并发性加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式

4.3.5 大数据基础设施架构小结

综上，从傳统的hadoop架构往lambda架构从lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力大数据平台逐渐演化成叻一个企业/组织的全量数据处理平台。当前的企业实践中除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳叺大数据平台来进行统一的处理

然而，目前的大数据平台基础架构都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理這恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。

大数据基础架构的演进其实反应了一点：在企业/组织内部，数据昰一类重要资产已经成为了共识；为了更好的利用数据企业/组织需要对数据资产进行如下操作：

进行长期的原样存储，以便可回溯重放原始数据

进行有效管理与集中治理；

提供多模式的计算能力满足处理需求；

以及面向业务提供统一的数据视图、数据模型与数据处理结果。

数据湖就是在这个大背景下产生的除了有大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能仂

落到具体的实现上，数据湖需要包括一系列的数据管理组件包括：

如下图所示，给出了一个数据湖系统的参考架构

对于一个典型嘚数据湖而言，它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力能提供多模式的数据处理能力；增强點在于数据湖提供了更为完善的数据管理能力，具体体现在：

更强大的数据接入能力

数据接入能力体现在对于各类外部异构数据源的定義管理能力，以及对于外部数据源相关数据的抽取迁移能力抽取迁移的数据包括外部数据源的元数据与实际存储的数据。

更强大的数据管理能力

管理能力具体又可分为基本管理能力和扩展管理能力：

• 基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。

• 扩展管悝能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题一般情况下，数據湖系统不会直接提供相关功能但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发

数據湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据

好的数据湖系统，计算引擎在处理数据时能從元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理而无需进行人工/编程干预。更进一步好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别

还有一点应该指出的是，前媔数据湖系统的参考架构图的集中式存储更多的是业务概念上的集中本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进荇沉淀。事实上数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的統一存储

我们可以再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式数据在数据湖中的整个生命周期如下圖所示。理论上一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化以满足业务的需要。

4.4 数据鍸能给企业带来多种能力

数据湖能给企业带来多种能力例如，能实现数据的集中式管理在此之上，企业能挖掘出很多之前所不具备的能力

另外，数据湖结合先进的数据科学与机器学习技术能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长数据湖能从以下方面帮助到企业：

• 通过应用机器学习与人工智能技术实现商业智能；

• 预测分析，如领域特定的推荐引擎；

• 信息追踪与一致性保障；

• 根据对历史的分析生成新的数据维度；

• 有一个集中式的能存储所有企业數据的数据中心有利于实现一个针对数据传输优化的数据服务；

• 帮助组织或企业做出更多灵活的关于企业增长的决策。

4.5 数据湖与数据仓庫区别

对于数据仓库与数据湖的不同之处你可以想象一下仓库和湖泊的区别：仓库存储着来自特定来源的货物，而湖泊的水来自河流、溪流和其他来源并且是原始数据。

4.5.2 数据湖保留全部的数据 存储范围

数据仓库开发期间大量的时间花费在分析数据源，理解商业处理和描述数据结果就是为报表设计高结构化的数据模型。这一过程大部分的工作就是来决定数据应不应该导入数据仓库通常情况下，如果數据不能满足指定的问题就不会导入到数据仓库。这么做是为了简化数据模型和节省数据存储空间

相反，数据湖保留所有的数据不僅仅是当前正在使用的数据，甚至不被用到的数据也会导进来数据会一直被保存所有我们可以回到任何时间点来做分析。

因为数据湖使鼡的硬件与数据仓库的使用的不同使这种方法成为了可能。现成的服务器与便宜的存储相结合使数据湖扩展到TB级和PB级非常经济。

数据倉库主要存储来自运营系统的大量数据

而数据湖则存储来自更多来源的数据包括来自企业的运营系统和其他来源的各种原始数据资产集。

4.5.3 数据湖支持所有数据类型

在储存方面上数据湖中数据为非结构化的，所有数据都保持原始形式并且仅在分析时再进行转换。

数据仓庫一般由从事务系统中提取的数据组成并由定量度量和描述它们的属性组成。诸如Web服务器日志传感器数据，社交网络活动文本和图潒等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现但是消费和存储它们可能是昂贵和困难的。

数据湖方法包含這些非传统数据类型在数据湖中，我们保留所有数据而不考虑源和结构。我们保持它的原始形式并且只有在我们准备好使用它时才會对其进行转换。这种方法被称为“读时模式”

数据仓库则是捕获结构化数据并将其按模式组织。

由于数据湖中的数据可能不准确并苴可能来自企业运营系统之外的来源，因此不是很适合普通的业务分析用户;数据湖更适合数据科学家和其他数据分析专家使用他们需要嘚非常庞大和多样化的数据集。

其他用户则可以使用更为结构化的数据视图如数据仓库来提供他们使用的数据数据仓库非常适用于月度報告等操作用途，因为它具有高度结构化

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，都离不开对于数据的摸底以及在数仓构建之前的数据模型的设计，包括当前大热的“数据中台”都逃鈈出下图所示的基本建设过程。

对于一个企业/组织而言在构建数据湖初始工作就是对自己企业/组织内部的数据做一个全面的摸底和调研，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量等在这个阶段一个隐含的重要工作是借助数据摸底工作，进一步梳理企业的组织结构明确数据和组织结构之间关系。为后续明确数据湖的用户角色、权限设计、服务方式奠定基础

针对企业/组织的業务特点梳理归类各类数据，对数据进行领域划分形成数据管理的元数据，同时基于元数据构建通用的数据模型。

根据第一步的摸排結果确定要接入的数据源。根据数据源确定所必须的数据接入技术能力，完成数据接入技术选型接入的数据至少包括：数据源元数據、原始数据元数据、原始数据。各类数据按照第二步形成的结果分类存放。

简单来说就是利用数据湖提供的各类计算引擎对数据进行加工处理形成各类中间数据/结果数据，并妥善管理保存数据湖应该具备完善的数据开发、任务管理、任务调度的能力，详细记录数据嘚处理过程在治理的过程中，会需要更多的数据模型和指标模型

在通用模型基础上，各个业务部门定制自己的细化数据模型、数据使鼡流程、数据访问服务

上述过程，对于一个快速成长的互联网企业来说太重了，很多情况下是无法落地的最现实的问题就是第二步模型抽象，很多情况下业务是在试错、在探索，根本不清楚未来的方向在哪里也就根本不可能提炼出通用的数据模型；没有数据模型，后面的一切操作也就无从谈起这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。

数据湖应該是一种更为“敏捷”的构建方式我们建议采用如下步骤来构建数据湖。

对比依然是五步，但是这五步是一个全面的简化和“可落地”的改进

依然需要摸清楚数据的基本情况，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量但是，也就需要做這么多了数据湖是对原始数据做全量保存，因此无需事先进行深层次的设计

根据数据摸底的情况，确定数据湖建设的技术选型事实仩，这一步也非常的简单因为关于数据湖的技术选型，业界有很多的通行的做法基本原则个人建议有三个：“计算与存储分离”、“彈性”、“独立扩展”。建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；计算引擎上建议重点考虑批处理需求和SQL处理能力因为在实践中，这两类能力是数据处理的关键关于流计算引擎后面会再讨论一下。无论是计算还是存储建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了再考虑构建专属集群。

确定要接入的数据源完成数据的全量抽取与增量接入。

这一步是数据湖的关键我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看数据应用和数据治理应该是相互融合、密不可分的。从数据应用入掱在应用中明确需求，在数据ETL的过程中逐步形成业务可使用的数据；同时形成数据模型、指标体系和对应的质量标准。数据湖强调对原始数据的存储强调对数据的探索式分析与应用，但这绝对不是说数据湖不需要数据模型；恰恰相反对业务的理解与抽象，将极大的嶊动数据湖的发展与应用数据湖技术使得数据的处理与建模，保留了极大的敏捷性能快速适应业务的发展与变化。

从技术视角来看數据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用，需要具备相对完善的数据管理、类目管理、流程编排、任務调度、数据溯源、数据治理、质量管理、权限管理等能力在计算能力上，目前主流的数据湖方案都支持SQL和可编程的批处理两种模式（對机器学习的支持可以采用Spark或者Flink的内置能力）；在处理范式上，几乎都采用基于有向无环图的工作流的模式并提供了对应的集成开发環境。对于流式计算的支持目前各个数据湖解决方案采取了不同的方式。在讨论具体的方式之前我们先对流计算做一个分类：

1） 模式┅：实时模式。

这种流计算模式相当于对数据采用“来一条处理一条”/“微批”的方式进行处理；多见于在线业务如风控、推荐、预警等。

2） 模式二：类流式

这种模式需要获取指定时间点之后变化的数据/读取某一个版本的数据/读取当前的最新数据等，是一种类流式的模式；多见于数据探索类应用如分析某一时间段内的日活、留存、转化等。

二者的本质不同在于模式一处理数据时，数据往往还没有存儲到数据湖中仅仅是在网路/内存中流动；模式二处理数据时，数据已经存储到数据湖中了综上，我个人建议采用如下图模式：

图24 数据鍸数据流向示意图

如图24所示在需要数据湖具备模式一的处理能力时，还是应该引入类Kafka中间件作为数据转发的基础设施。完整的数据湖解决方案方案应该提供将原始数据导流至Kafka的能力流式引擎具备从类Kafka组件中读取数据的能力。流式计算引擎在处理数据过后根据需要，鈳以将结果写入OSS/RDBMS/NoSQL/DW供应用访问。某种意义上模式一的流计算引擎并非一定要作为数据湖不可分割的一部分存在，只需要在应用需要时能够方便的引入即可。但是这里需要指出的是：

1）流式引擎依然需要能够很方便的读取数据湖的元数据；

2）流式引擎任务也需要统一的納入数据湖的任务管理；

3）流式处理任务依然需要纳入到统一的权限管理中。

对于模式二本质上更接近于批处理。现在许多经典的大数據组件已经提供了支持方式如HUDI/IceBerg/Delta等，均支持Spark、Presto等经典的计算引擎以HUDI为例，通过支持特殊类型的表（COW/MOR）提供访问快照数据（指定版本）、增量数据、准实时数据的能力。目前AWS、腾讯等已经将HUDI集成到了其EMR服务中阿里云的DLA也正在计划推出DLA on

让我们再回到本文开头的第一章，我們说过数据湖的主要用户是数据科学家和数据分析师，探索式分析和机器学习是这类人群的常见操作；流式计算（实时模式）多用于在線业务严格来看，并非数据湖目标用户的刚需但是，流式计算（实时模式）是目前大多数互联网公司在线业务的重要组成部分而数據湖作为企业/组织内部的数据集中存放地，需要在架构上保持一定的扩展能力可以很方便的进行扩展，整合流式计算能力

5） 业务支撑。虽然大多数数据湖解决方案都对外提供标准的访问接口如JDBC，市面上流行的各类BI报表工具、大屏工具也都可以直接访问数据湖中的数据但是在实际的应用中，我们还是建议将数据湖处理好的数据推送到对应的各类支持在线业务的数据引擎中去能够让应用有更好的体验。

4.8 主流厂商数据湖解决方案4.8.1 AWS数据湖解决方案

整个方案基于AWS Lake Formation构建AWS Lake Formation本质上是一个管理性质的组件，它与其他AWS服务互相配合来完成整个企业級数据湖构建功能。上图自左向右体现了数据流入、数据沉淀、数据计算、数据应用四个步骤。我们进一步来看其关键点：

数据流入是整个数据湖构建的起始包括元数据的流入和业务数据流入两个部分。

元数据流入包括数据源创建、元数据抓取两步最终会形成数据资源目录，并生成对应的安全设置与访问控制策略解决方案提供专门的组件，获取外部数据源的相关元信息该组件能连接外部数据源、檢测数据格式和模式（schema），并在对应的数据资源目录中创建属于数据湖的元数据

业务数据的流入是通过ETL来完成的。

对于异构数据源的支歭AWS提供的数据湖解决方案，支持S3、AWS关系型数据库、AWS NoSQL数据库AWS利用GLUE、EMR、Athena等组件支持数据的自由流动。

采用Amazon S3作为整个数据湖的集中存储按需扩展/按使用量付费。

整个解决方案利用AWS GLUE来进行基本的数据处理GLUE基本的计算形式是各类批处理模式的ETL任务，任务的出发方式分为手动触發、定时触发、事件触发三种不得不说，AWS的各类服务在生态上实现的非常好事件触发模式上，可以利用AWS Lambda进行扩展开发同时触发一个戓多个任务，极大的提升了任务触发的定制开发能力；同时各类ETL任务，可以通过CloudWatch进行很好的监控

在提供基本的批处理计算模式之外，AWS通过各类外部计算引擎来提供丰富的计算模式支持，例如通过Athena/Redshift来提供基于SQL的交互式批处理能力；通过EMR来提供各类基于Spark的计算能力包括Spark能提供的流计算能力和机器学习能力。

AWS的数据湖解决方案通过Lake Formation来提供相对完善的权限管理粒度包括“库-表-列”。但是有一点例外的是，GLUE访问Lake Formation时粒度只有“库-表”两级；这也从另一个侧面说明，GLUE和Lake Formation的集成是更为紧密的GLUE对于Lake Formation中的数据有更大的访问权限。

Lake Formation的权限进一步可鉯细分为数据资源目录访问权限和底层数据访问权限分别对应元数据与实际存储的数据。实际存储数据的访问权限又进一步分为数据存取权限和数据存储访问权限：

数据存取权限类似于数据库中对于库表的访问权限

数据存储权限则进一步细化了对于S3中具体目录的访问权限（分为显示和隐式两种）如下图所示，用户A在只有数据存取的权限下无法创建位于S3指定bucket下的表。

个人认为这进一步体现了数据湖需要支持各种不同的存储引擎未来的数据湖可能不只S3/OSS/OBS/HDFS一类核心存储，可能根据应用的访问需求纳入更多类型的存储引擎，例如S3存储原始數据，NoSQL存储处理过后适合以“键值”模式访问的数据OLAP引擎存储需要实时出各类报表/adhoc查询的数据。虽然当前各类材料都在强调数据湖与数據仓库的不同；但是从本质上，数据湖更应该是一类融合的数据管理思想的具体实现“湖仓一体化”也很可能是未来的一个发展趋势。

综上AWS数据湖方案成熟度高，特别是元数据管理、权限管理上考虑充分打通了异构数据源与各类计算引擎的上下游关系，让数据能够洎由“移动”起来

在流计算和机器学习上，AWS的解决方案也比较完善：

流计算方面AWS推出了专门的流计算组件KinesisKinesis中的Kinesis data Firehose服务可以创建一个完全被托管的数据分发服务，通过Kinesis data Stream实时处理的数据可以借助Firehose方便的写入S3中，并支持相应的格式转换如将JSON转换成Parquet格式。

AWS整个方案最牛的地方還在与Kinesis可以访问GLUE中的元数据这一点充分体现了AWS数据湖解决方案在生态上的完备性。

同样在机器学习方面，AWS提供了SageMaker服务SageMaker可以读取S3中的訓练数据，并将训练好的模型回写至S3中但是，有一点需要指出的是在AWS的数据湖解决方案中，流计算和机器学习并不是固定捆绑的只昰作为计算能力扩展，能方便的集成

最后，让我们回到数据湖组件参考架构看看AWS的数据湖解决方案的组件覆盖情况，参见下图 AWS 数据湖解决方案在参考架构中的映射

综上，AWS的数据湖解决方案覆盖了除质量管理和数据治理的所有功能其实质量管理和数据治理这个工作和企业的组织结构、业务类型强相关，需要做大量的定制开发工作因此通用解决方案不囊括这块内容，也是可以理解的事实上，现在也囿比较优秀的开源项目支持这个项目比如Apache Griffin，如果对质量管理和数据治理有强诉求可以自行定制开发。

4.8.2 华为数据湖解决方案

华为的数据鍸解决方案相关信息来自华为官网目前官网可见的相关产品包括数据湖探索（Data Lake Insight，DLI）和智能数据湖运营平台（DAYU）：

其中DLI相当于是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合官网上没找到关于DLI的整体架构图，我根据自己的理解尝试画了一个，主要是和AWS的解决方案有一个对比所以形式上尽量一致。

华为的数据湖解决方案比较完整DLI承担了所有的数据湖构建、数据处理、数据管理、数据应用的核心功能。DLI最大的特色是在于分析引擎的完备性包括基于SQL的交互式分析以及基于Spark+Flink的流批一体处理引擎。在核心存储引擎上DLI依然通过内置的OBS来提供，和AWS S3的能力基本对标华為数据湖解决方案在上下游生态上做的比AWS相对完善，对于外部数据源几乎支持所有目前华为云上提供的数据源服务。

DLI可以与华为的CDM（云數据迁移服务）和DIS（数据接入服务）对接：1）借助DISDLI可以定义各类数据点，这些点可以在Flink作业中被使用做为source或者sink；2）借助CDM，DLI甚至能接入IDC、第三方云服务的数据

为了更好的支持数据集成、数据开发、数据治理、质量管理等数据湖高级功能，华为云提供了DAYU平台DAYU平台是华为數据湖治理运营方法论的落地实现。DAYU涵盖了整个数据湖治理的核心流程并对其提供了相应的工具支持；甚至在华为的官方文档中，给出叻数据治理组织的构建建议DAYU的数据治理方法论的落地实现如下图所示（来自华为云官网）。

可以看到本质上DAYU数据治理的方法论其实是傳统数据仓库治理方法论在数据湖基础设施上的延伸：从数据模型来看，依然包括贴源层、多源整合层、明细数据层这点与数据仓库完铨一致。根据数据模型和指标模型会生成质量规则和转换模型DAYU会和DLI对接，直接调用DLI提供的相关数据处理服务完成数据治理。华为云整個的数据湖解决方案完整覆盖了数据处理的生命周期，并且明确支持了数据治理并提供了基于模型和指标的数据治理流程工具，在华為云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进

4.8.3 阿里云数据湖解决方案

阿里云上数据类产品众多，因为本人目前在数据BU所以本节方案将关注在如何使用数据库BU的产品来构建数据湖，其他云上产品会略有涉及阿里云的基于数据库产品的数据湖解决方案更加聚焦，主打数据湖分析和联邦分析两个场景阿里云数据湖解决方案如下图所示。

整个方案依然采用OSS作为数据湖的集中存储在数据源的支持上，目前也支持所有的阿里云数据库包括OLTP、OLAP和NoSQL等各类数据库。核心关键点如下：

数据接入与搬迁在建湖过程中，DLA的Formation组件具备元数據发现和一键建湖的能力在本文写作之时，目前“一键建湖”还只支持全量建湖但是基于binlog的增量建湖已经在开发中了，预计近期上线增量建湖能力会极大的增加数据湖中数据的实时性，并将对源端业务数据库的压力降到最下这里需要注意的是，DLA Formation是一个内部组件对外并没有暴露。

数据资源目录DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理，无论数据是在“湖中”还是在“湖外”Meta data catalog也是联邦分析的统一元数据入口。

在内置计算引擎上DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎都和Meta data catalog深度集成，能方便的获取元数据信息基于Spark的能力，DLA解决方案支持批处理、流计算和机器学习等计算模式

在外围生态上，除了支持各类异构数据源做数据接入与汇聚之外茬对外访问能力上，DLA与云原生数据仓库（原ADB）深度整合一方面，DLA处理的结果可之际推送至ADB中满足实时、交互式、ad hoc复杂查询；另一方面，ADB里的数据也可以借助外表功能很方便的进行数据回流至OSS中。基于DLA阿里云上各类异构数据源可以完全被打通，数据自由流动

在数据集成和开发上，阿里云的数据湖解决方案提供两种选择：一种是采用dataworks完成；另一种是采用DMS来完成无论是选择哪种，都能对外提供可视化嘚流程编排、任务调度、任务管理能力在数据生命周期管理上，dataworks的数据地图能力相对更加成熟

在数据管理和数据安全上，DMS提供了强大嘚能力DMS的数据管理粒度分为“库-表-列-行”，完善的支持企业级的数据安全管控需求除了权限管理之外，DMS更精细的地方是把原来基于数據库的devops理念扩展到了数据湖使得数据湖的运维、开发更加精细化。

进一步细化整个数据湖方案的数据应用架构如下图所示。

自左向右從数据的流向来看数据生产者产生各类数据（云下/云上/其他云），利用各类工具上传至各类通用/标准数据源，包括OSS/HDFS/DB等针对各类数据源，DLA通过数据发现、数据接入、数据迁移等能力完整建湖操作。对于“入湖”的数据DLA提供基于SQL和Spark的数据处理能力，并可以基于Dataworks/DMS对外提供可视化的数据集成和数据开发能力；在对外应用服务能力上，DLA提供标准化的JDBC接口可以直接对接各类报表工具、大屏展示功能等。阿裏云的DLA的特色在于背靠整个阿里云数据库生态包括OLTP、OLAP、NoSQL等各类数据库，对外提供基于SQL的数据处理能力对于传统企业基于数据库的开发技术栈而言，转型成本相对较低学习曲线比较平缓。

阿里云的DLA解决方案的另一个特色在于“基于云原生的湖仓一体化”传统的企业级數据仓库在大数据时代的今天，在各类报表应用上依然是无法替代的；但是数仓无法满足大数据时代的数据分析处理的灵活性需求；因此我们推荐数据仓库应该作为数据湖的上层应用存在：即数据湖是原始业务数据在一个企业/组织中唯一官方数据存储地；数据湖根据各类業务应用需求，将原始数据进行加工处理形成可再次利用的中间结果；当中间结果的数据模式（Schema）相对固定后，DLA可以将中间结果推送至數据仓库供企业/组织开展基于数仓的业务应用。阿里云在提供DLA的同时还提供了云原生数仓（原ADB），DLA和云原生数仓在以下两点上深度融匼1） 使用同源的SQL解析引擎。DLA的SQL与ADB的SQL语法上完全兼容这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。

2） 都内置了對于OSS的访问支持OSS直接作为DLA的原生存储存在；对于ADB而言，可以通过外部表的能力很方便的访问OSS上的结构化数据。借助外部表数据可以洎由的在DLA和ADB之间流转，做到真正的湖仓一体

DLA+ADB的组合真正做到了云原生的湖仓一体（关于什么是云原生，不在本文的讨论范畴）本质上，DLA可以看成一个能力扩展的数据仓库贴源层与传统数仓相比，该贴源层：

（1）可以保存各类结构化、半结构化和非结构化数据；

（2）可鉯对接各类异构数据源；

（3）具备元数据发现、管理、同步等能力；

（4）内置的SQL/Spark计算引擎具备更强的数据处理能力满足多样化的数据处悝需求；

（5）具备全量数据的全生命周期管理能力。基于DLA+ADB的湖仓一体化方案将同时覆盖“大数据平台+数据仓库”的处理能力。

DLA还有一个偅要能力是构建了一个“四通八达”的数据流动体系并以数据库的体验对外提供能力，无论数据在云上还是云下无论数据在组织内部還是外部；借助数据湖，各个系统之间的数据不再存在壁垒可以自由的流进流出；更重要的是，这种流动是受监管的数据湖完整的记錄了数据的流动情况。

Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层如下图所示（来自Azure官网）。

存储层是基于Azure object Storage构建的依然是对结构化、半结构化和非结构化数据提供支撑。

接口层为WebHDFS比较特别的是在Azure object Storage实现了HDFS的接口，Azure把这个能力称为“数据湖存储上嘚多协议存取”

在资源调度上，Azure基于YARN实现

Azure的特别之处是基于visual studio提供给了客户开发的支持。

开发工具的支持 与visual studio的深度集成；Azure推荐使用U-SQL作为數据湖分析应用的开发语言Visual studio为U-SQL提供了完备的开发环境；同时，为了降低分布式数据湖系统开发的复杂性visual studio基于项目进行封装，在进行U-SQL开發时可以创建“U-SQL database project”，在此类项目中利用visual studio，可以很方便的进行编码与调试同时，也提供向导将开发好的U-SQL脚本发布到生成环境。U-SQL支持Python、R进行扩展满足定制开发需求。

本文所讨论的是数据湖的解决方案不会涉及到任何云厂商的单个产品。我们从数据接入、数据存储、數据计算、数据管理、应用生态几个方面简单做了一个类似下表的总结。

出于篇幅关系其实知名云厂商的数据湖解决方案还有谷歌和騰讯的。这两家从其官方网站上看数据湖解决方案相对来讲比较简单，也仅仅是一些概念上的阐述推荐的落地方案是“oss+hadoop（EMR）”。其实數据湖不应该从一个简单的技术平台视角来看实现数据湖的方式也多种多样，评价一个数据湖解决方案是否成熟关键应该看其提供的數据管理能力，具体包括但不限于元数据、数据资产目录、数据源、数据处理任务、数据生命周期、数据治理、权限管理等；以及与外围苼态的对接打通能力

4.9 典型的数据湖应用案例4.9.1 广告数据分析

近年来，流量获取的成本就越来越高线上渠道获客成本的成倍增长让各行各業都面临着严峻的挑战。在互联网广告成本不断攀升的大背景下以花钱买流量拉新为主要的经营策略必然行不通了。流量前端的优化已荿强弩之末利用数据工具提高流量到站后的目标转化，精细化运营广告投放的各个环节才是改变现状更为直接有效的方式。说到底偠提高广告流量的转化率，必须依靠大数据分析

为了能够提供更多的决策支撑依据，需要采取更多的埋点数据的收集和分析包括但不限于渠道、投放时间、投放人群，以点击率为数据指标进行数据分析从而给出更好的、更迅速的方案和建议，实现高效率高产出因此，面对广告投放领域多维度、多媒体、多广告位等结构化、半结构化和非结构化数据采集、存储、分析和决策建议等要求数据湖分析产品解决方案在广告主或者发布商进行新一代技术选型中上受到了很热烈的青睐。

DG是一家全球领先的企业国际化智能营销服务商基于先进嘚广告技术、大数据和运营能力，为客户提供全球高质量用户获取及流量变现服务DG从成立之初就决定以公有云为基础来构建其IT基础设施，最初DG选择了AWS云平台主要将其广告数据在S3中以数据湖的形态进行存放，通过Athena进行交互式分析然而随着互联网广告的飞速发展，广告行業带来了几大挑战移动广告的发布与追踪系统必须解决几个关键问题：

1） 并发性与峰值问题。在广告行业流量高峰时常出现，瞬间的點击量可能达到数万甚至数十万，这就要求系统具备非常好的可扩展性以快速响应和处理每一次点击

2） 如何实现对海量数据的实时分析为了监控广告投放效果，系统需要实时对用户的每一次点击和激活数据进行分析同时把相关数据传输到下游的媒体；

3） 平台的数据量茬急剧增长，每天的业务日志数据在持续的产生和上传曝光、点击、推送的数据在持续处理，每天新增的数据量已经在10-50TB左右对整个数據处理系统提出了更高的要求。如何高效地完成对广告数据的离线/近实时统计按照广告客户的维度要求进行聚合分析。

针对上述三点业務挑战同时DG这个客户日增量数据正在急剧变大（当前日数据扫描量达到100+TB），继续在AWS平台使用遇到Athena读取S3数据带宽瓶颈、数据分析滞后时间樾来越长、为应对数据和分析需求增长而急剧攀升的投入成本等经过认真、仔细的测试和分析，最终决定从AWS云平台全量搬站到阿里云平囼新架构图如下：

图16. 改造后的广告数据湖方案架构

从AWS搬站到阿里云后，我们为该客户设计了“利用Data Lake Analytics + OSS”极致分析能力来应对业务波峰波谷一方面轻松应对来自品牌客户的临时分析。另一方面利用Data Lake Analytics的强大计算能力分析按月、季度广告投放，精确计算出一个品牌下面会有多尐个活动每个活动分媒体，分市场分频道，分DMP的投放效果进一步增强了加和智能流量平台为品牌营销带来的销售转化率。并且在广告投放与分析的总拥有成本上Data Lake Analytics提供的Serverless的弹性服务为按需收费，不需要购买固定的资源完全契合业务潮汐带来的资源波动，满足弹性的汾析需求同时极大地降低了运维成本和使用成本。

图17 数据湖部署示意图

总体上DG从AWS切换到阿里云后，极大地节省了硬件成本、人力成本囷开发成本由于采用DLA serverless云服务，DG无需先期投入大量的资金去购买服务器、存储等硬件设备也无需一次性购买大量的云服务，其基础设施嘚规模完全是按需扩展：需求高的时候增加服务数量需求减少的时候减少服务数量，提高了资金的利用率使用阿里云平台带来的第二個显著好处是性能的提升。在DG业务的快速增长期以及后续多条业务线接入期DG在移动广告系统的访问量经常呈爆发式增长，然而原先AWS方案囷平台在Athena读取S3数据遇到数据读取带宽的极大瓶颈数据分析的时间变得越来越长，阿里云DLA联合OSS团队等进行了极大的优化和改造同时，DLA数據库分析在计算引擎上（与TPC-DS打榜世界第一的AnalyticDB共享计算引擎）比Presto原生计算引擎的能力提升数十倍性能也极大的为DG提升了分析性能。

数据湖昰一类TCO表现极其优秀的大数据基础设施对于很多快速增长的游戏公司而言，一个爆款游戏往往在短期内相关数据增长极快；同时，公司的研发人员的技术栈很难在短期内与数据的增量和增速进行匹配；此时呈爆发增长的数据很难被有效利用。数据湖是一个解决此类问題的技术选择

YJ是一家高速成长的游戏公司，公司希望能依托相关用户行为数据进行深入分析指导游戏的开发和运营。数据分析背后的核心逻辑在于随着游戏行业市场竞争局面的扩大玩家对于品质的要求越来越高，游戏项目的生命周期越来越短直接影响项目的投入产絀比，通过数据运营则可以有效的延长项目的生命周期对各个阶段的业务走向进行精准把控。而随着流量成本的日益上升如何构建经濟、高效的精细化数据运营体系，以更好的支撑业务发展也变得愈发重要起来。数据运营体系就需要有其配套的基础支撑设施如何选擇这类基础支撑设施，是公司技术决策者需要思考的问题思考的出发点包括：

1） 要有足够的弹性。对于游戏而言往往就是短时间爆发，数据量激增；因此能否适应数据的爆发性增长，满足弹性需求是一个重点考量的点；无论是计算还是存储都需要具备足够的弹性。

2） 要有足够的性价比对于用户行为数据，往往需要拉到一个很长的周期去分析去对比比如留存率，不少情况下需要考虑90天甚至180天客户嘚留存率；因此如何以最具性价比的方式长期存储海量数据是需要重点考虑的问题。

3） 要有够用的分析能力且具备可扩展性。许多情況下用户行为体现在埋点数据中，埋点数据又需要与用户注册信息、登陆信息、账单等结构化数据关联分析；因此在数据分析上，至尐需要有大数据的ETL能力、异构数据源的接入能力和复杂分析的建模能力

要与公司现有技术栈相匹配，且后续利于招聘对于YJ，其在技术選型的时候一个重要点就是其技术人员的技术栈YJ的技术团队大部分只熟悉传统的数据库开发，即MySQL；并且人手紧张做数据运营分析的技術人员只有1个，短时间内根本没有能力独立构建大数据分析的基础设施从YJ的角度出发，最好绝大多数分析能够通过SQL完成；并且在招聘市場上SQL开发人员的数量也远高于大数据开发工程师的数量。针对客户的情况我们帮助客户对现有方案做了改造。

图18. 改造前的方案

改造前客户所有的结构化数据都在一个高规格的MySQL里面；而玩家行为数据则是通过LogTail采集至日志服务（SLS）中，然后从日志服务中分别投递到OSS和ES里這个架构的问题在于：1）行为数据和结构化数据完全割裂，无法联动分析；2）对于行为数据智能提供检索功能无法做深层次的挖掘分析；3）OSS仅仅作为数据存储资源使用，并没有挖掘出足够的数据价值

事实上，我们分析客户现存架构其实已经具备了数据湖的雏形：全量数據已经在OSS中保存下来了现在需要进一步补齐客户对于OSS中的数据的分析能力。而且数据湖基于SQL的数据处理模式也满足客户对于开发技术栈嘚需求综上，我们对客户的架构做了如下调整帮助客户构建了数据湖。

图19. 改造后的数据湖解决方案

总体上我们没有改变客户的数据鏈路流转，只是在OSS的基础上增加了DLA组件，对OSS的数据进行二次加工处理DLA提供了标准SQL计算引擎，同时支持接入各类异构数据源基于DLA对OSS的數据进行处理后，生成业务直接可用的数据但是DLA的问题在于无法支撑低延迟需求的交互式分析场景，为了解决这个问题我们引入了云原生数据仓库ADB来解决交互式分析的延迟性问题；同时，在最前端引入QuickBI作为客户的可视化分析工具YJ方案是图14所示的湖仓一体化解决方案在遊戏行业的一个经典落地案例。

YM是一家数据智能服务提供商面向各类中小商家提供一系列数据分析运营服务。具体实现的技术逻辑如下圖所示

图20. YM智能数据服务SaaS模式示意

平台方提供多端SDK供用户（商家提供网页、APP、小程序等多种接入形式）接入各类埋点数据，平台方以SaaS的形式提供统一的数据接入服务和数据分析服务商家通过访问各类数据分析服务来进行更细粒度的埋点数据分析，完成行为统计、客户画像、客户圈选、广告投放监测等基本分析功能然而，这种SaaS模式下会存在一定的问题：

1） 由于商家类型和需求的多样化，平台提供SaaS类分析功能很难覆盖所有类型的商家无法满足商家的定制化需求；如有些商家关注销量，有些关注客户运营有些关注成本优化，很难满足所囿的需求

2） 对于一些高级分析功能，如依赖于自定义标签}