震惊！这篇文章解读数据仓库、数据湖、数据中台等概念，竟然写了4万字！
作者丨修鹏李
全文共37817个字，建议pc端阅读更佳
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 数据湖与数据仓库区别
4.5.1 概述
对于数据仓库与数据湖的不同之处，你可以想象一下仓库和湖泊的区别：仓库存储着来自特定来源的货物，而湖泊的水来自河流、溪流和其他来源，并且是原始数据。
数据仓库供应商包括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） 业务支撑。
在通用模型基础上，各个业务部门定制自己的细化数据模型、数据使用流程、数据访问服务。
上述过程，对于一个快速成长的互联网企业来说，太重了，很多情况下是无法落地的，最现实的问题就是第二步模型抽象，很多情况下，业务是在试错、在探索，根本不清楚未来的方向在哪里，也就根本不可能提炼出通用的数据模型；没有数据模型，后面的一切操作也就无从谈起，这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。
数据湖应该是一种更为“敏捷”的构建方式，我们建议采用如下步骤来构建数据湖。
对比，依然是五步，但是这五步是一个全面的简化和“可落地”的改进。
1） 数据摸底。
依然需要摸清楚数据的基本情况，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量。但是，也就需要做这么多了。数据湖是对原始数据做全量保存，因此无需事先进行深层次的设计。
2） 技术选型。
根据数据摸底的情况，确定数据湖建设的技术选型。事实上，这一步也非常的简单，因为关于数据湖的技术选型，业界有很多的通行的做法，基本原则个人建议有三个：“计算与存储分离”、“弹性”、“独立扩展”。建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；计算引擎上建议重点考虑批处理需求和SQL处理能力，因为在实践中，这两类能力是数据处理的关键，关于流计算引擎后面会再讨论一下。无论是计算还是存储，建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了，再考虑构建专属集群。
3） 数据接入。
确定要接入的数据源，完成数据的全量抽取与增量接入。
4） 应用治理。
这一步是数据湖的关键，我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看，数据应用和数据治理应该是相互融合、密不可分的。从数据应用入手，在应用中明确需求，在数据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 HUDI的能力。
让我们再回到本文开头的第一章，我们说过，数据湖的主要用户是数据科学家和数据分析师，探索式分析和机器学习是这类人群的常见操作；流式计算（实时模式）多用于在线业务，严格来看，并非数据湖目标用户的刚需。但是，流式计算（实时模式）是目前大多数互联网公司在线业务的重要组成部分，而数据湖作为企业/组织内部的数据集中存放地，需要在架构上保持一定的扩展能力，可以很方便的进行扩展，整合流式计算能力。
5） 业务支撑。虽然大多数数据湖解决方案都对外提供标准的访问接口，如JDBC，市面上流行的各类BI报表工具、大屏工具也都可以直接访问数据湖中的数据。但是在实际的应用中，我们还是建议将数据湖处理好的数据推送到对应的各类支持在线业务的数据引擎中去，能够让应用有更好的体验。
4.8 主流厂商数据湖解决方案
4.8.1 AWS数据湖解决方案
整个方案基于AWS Lake Formation构建，AWS Lake Formation本质上是一个管理性质的组件，它与其他AWS服务互相配合，来完成整个企业级数据湖构建功能。上图自左向右，体现了数据流入、数据沉淀、数据计算、数据应用四个步骤。我们进一步来看其关键点：
数据流入
数据流入是整个数据湖构建的起始，包括元数据的流入和业务数据流入两个部分。
元数据流入包括数据源创建、元数据抓取两步，最终会形成数据资源目录，并生成对应的安全设置与访问控制策略。解决方案提供专门的组件，获取外部数据源的相关元信息，该组件能连接外部数据源、检测数据格式和模式（schema），并在对应的数据资源目录中创建属于数据湖的元数据。
业务数据的流入是通过ETL来完成的。
在具体的产品形式上，元数据抓取、ETL和数据准备AWS将其单独抽象出来，形成了一个产品叫AWS GLUE。AWS GLUE与AWS Lake Formation共享同一个数据资源目录，在AWS GLUE官网文档上明确指出：“Each AWS account has one AWS Glue Data Catalog per AWS region”。
对于异构数据源的支持。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推出了专门的流计算组件Kinesis，Kinesis中的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）借助DIS，DLI可以定义各类数据点，这些点可以在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还有一个重要能力是构建了一个“四通八达”的数据流动体系，并以数据库的体验对外提供能力，无论数据在云上还是云下，无论数据在组织内部还是外部；借助数据湖，各个系统之间的数据不再存在壁垒，可以自由的流进流出；更重要的是，这种流动是受监管的，数据湖完整的记录了数据的流动情况。
4.8.4 Microsoft Azure数据湖解决方案
Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层，如下图所示（来自Azure官网）。
存储层是基于Azure object Storage构建的，依然是对结构化、半结构化和非结构化数据提供支撑。
接口层为WebHDFS，比较特别的是在Azure object Storage实现了HDFS的接口，Azure把这个能力称为“数据湖存储上的多协议存取”。
在资源调度上，Azure基于YARN实现。
计算引擎上，Azure提供了U-SQL、hadoop和Spark等多种处理引擎。
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进行扩展，满足定制开发需求。
多计算引擎的适配：SQL, Apache Hadoop和Apache Spark。这里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服务），Spark包括Azure Databricks。- 多种不同引擎任务之间的自动转换能力。微软推荐U-SQL为数据湖的缺省开发工具，并提供各类转换工具，支持U-SQL脚本与Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之间的转化。
4.8.5 小结
本文所讨论的是数据湖的解决方案，不会涉及到任何云厂商的单个产品。我们从数据接入、数据存储、数据计算、数据管理、应用生态几个方面，简单做了一个类似下表的总结。
出于篇幅关系，其实知名云厂商的数据湖解决方案还有谷歌和腾讯的。这两家从其官方网站上看，数据湖解决方案相对来讲比较简单，也仅仅是一些概念上的阐述，推荐的落地方案是“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提升了分析性能。
4.9.2 游戏运营分析
数据湖是一类TCO表现极其优秀的大数据基础设施。对于很多快速增长的游戏公司而言，一个爆款游戏，往往在短期内相关数据增长极快；同时，公司的研发人员的技术栈很难在短期内与数据的增量和增速进行匹配；此时，呈爆发增长的数据很难被有效利用。数据湖是一个解决此类问题的技术选择。
YJ是一家高速成长的游戏公司，公司希望能依托相关用户行为数据进行深入分析，指导游戏的开发和运营。数据分析背后的核心逻辑在于随着游戏行业市场竞争局面的扩大，玩家对于品质的要求越来越高，游戏项目的生命周期越来越短，直接影响项目的投入产出比，通过数据运营则可以有效的延长项目的生命周期，对各个阶段的业务走向进行精准把控。而随着流量成本的日益上升，如何构建经济、高效的精细化数据运营体系，以更好的支撑业务发展，也变得愈发重要起来。数据运营体系就需要有其配套的基础支撑设施，如何选择这类基础支撑设施，是公司技术决策者需要思考的问题。思考的出发点包括：
1） 要有足够的弹性。对于游戏而言，往往就是短时间爆发，数据量激增；因此，能否适应数据的爆发性增长，满足弹性需求是一个重点考量的点；无论是计算还是存储，都需要具备足够的弹性。
2） 要有足够的性价比。对于用户行为数据，往往需要拉到一个很长的周期去分析去对比，比如留存率，不少情况下需要考虑90天甚至180天客户的留存率；因此，如何以最具性价比的方式长期存储海量数据是需要重点考虑的问题。
3） 要有够用的分析能力，且具备可扩展性。许多情况下，用户行为体现在埋点数据中，埋点数据又需要与用户注册信息、登陆信息、账单等结构化数据关联分析；因此，在数据分析上，至少需要有大数据的ETL能力、异构数据源的接入能力和复杂分析的建模能力。
4） 要与公司现有技术栈相匹配，且后续利于招聘。对于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） 对于一些高级分析功能，如依赖于自定义标签的客户圈选、客户自定义扩展等功能，统一的数据分析服务无法满足的；特别是一些自定义的标签依赖于商家自定义的算法，无法满足客户的高级分析需求。
3） 数据的资产化管理需求。在大数据时代，数据是一个企业/组织的资产已经成为了大家的共识，如何能让属于商家的数据合理、长期的沉淀下来，也是SaaS服务需要考虑的事情。
综上，我们在上图的基本模式上引入了数据湖模式，让数据湖作为商家沉淀数据、产出模型、分析运营的基础支撑设施。引入数据湖后的SaaS数据智能服务模式如下。
图21. 基于数据湖的数据智能服务
如图21所示，平台方为每个用户提供一键建湖服务，商家使用该功能构建自己的数据湖，“一键建湖”能力一方面帮助商家将所有埋点数据的数据模型（schema）同步至数据湖中；另一方面，将属于该商家的所有埋点数据全量同步至数据湖中，并基于“T+1”的模式，将每天的增量数据归档入湖。基于数据湖的服务模式在传统的数据分析服务的基础上，赋予了用户数据资产化、分析模型化和服务定制化三大能力：
1） 数据资产化能力。利用数据湖，商家可以将属于自己的数据持续沉淀下来，保存多长时间的数据，耗费多少成本，完全由商家自主决定。数据湖还提供了数据资产管理能力，商家除了能管理原始数据外，还能将处理过的过程数据和结果数据分门别类保存，极大的提升了埋点数据的价值。
2） 分析模型化能力。数据湖中不仅仅有原始数据，还有埋点数据的模型（schema）。埋点数据模型体现了全域数据智能服务平台对于业务逻辑的抽象，通过数据湖，除了将原始数据作为资产输出外，还将数据模型进行了输出，借助埋点数据模型，商家可以更深入的理解埋点数据背后所体现的用户行为逻辑，帮助商家更好的洞察客户行为，获取用户需求。
3） 服务定制化能力。借助数据湖提供的数据集成和数据开发能力，基于对埋点数据模型的理解，商家可以定制数据处理过程，不断对原始数据进行迭代加工，从数据中提炼有价值的信息，最终获得超越原有数据分析服务的价值。
4.10 LakeHouse
4.11 数据湖总结
数据湖作为新一代大数据分析处理的基础设施，需要超越传统的大数据平台。个人认为目前在以下方面，是数据湖解决方案未来可能的发展方向。
云原生架构
关于什么是云原生架构，众说纷纭，很难找到统一的定义。但是具体到数据湖这个场景，个人认为就是以下三点特征：
存储和计算分离，计算能力和存储能力均可独立扩展；
多模态计算引擎支持，SQL、批处理、流式计算、机器学习等；
提供serverless态服务，确保足够的弹性以及支持按需付费。
足够用的数据管理能力
数据湖需要提供更为强大的数据管理能力，包括但不限于数据源管理、数据类目管理、处理流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等。
大数据的能力，数据库的体验
目前绝大多数数据分析人员都只有数据库的使用经验，大数据平台的能力虽强，但是对于用户来说并不友好，数据科学家和数据数据分析师应该关注数据、算法、模型及其与业务场景的适配，而不是花大量的时间精力去学习大数据平台的开发。
数据湖要想快速发展，如何为用户提供良好的使用体验是关键。基于SQL的数据库应用开发已经深入人心，如何将数据湖的能力通过SQL的形式释放出来，是未来的一个主要方向。
完善的数据集成与数据开发能力
对各种异构数据源的管理与支持，对异构数据的全量/增量迁移支持，对各种数据格式的支持都是需要不断完善的方向。同时，需要具备一个完备的、可视化的、可扩展的集成开发环境。
与业务的深度融合与集成
典型数据湖架构的构成基本已经成为了业界共识：分布式对象存储+多模态计算引擎+数据管理。
决定数据湖方案是否胜出的关键恰恰在于数据管理，无论是原始数据的管理、数据类目的管理、数据模型的管理、数据权限的管理还是处理任务的管理，都离不开与业务的适配和集成；未来，会有越来越多的行业数据湖解决方案涌现出来，与数据科学家和数据分析师形成良性发展与互动。如何在数据湖解决方案中预置行业数据模型、ETL流程、分析模型和定制算法，可能是未来数据湖领域差异化竞争的一个关键点。
5.1 基础概念
5.1.1 产生的背景
企业在过去信息化的历程中形成了大量生产经营及专业业务应用成果，同时也累积了大量的企业数据资产。限于传统的数据仓库技术手段，数据管理和分析能力成为信息化工作中的短板。
企业信息系统众多，系统管理独立，数据存储分散，横向的数据共享和分析应用仅由具体业务驱动，难以对全局数据开展价值挖掘，从规模上和效果上都无法真正体现集团庞大数据资产的价值。
市场竞争和产业链日益全球化，企业不只满足于内部数据的分析，更要通过互联网、微信、APP等新技术手段结合外部市场数据进行整体分析。
传统的数据仓库不能满足数据分析需求 企业在数据分析应用方面呈现“五大转变”（从统计分析向预测分析转变、从单领域分析向跨领域转变、从被动分析向主动分析转变、从非实时向实时分析转变、从结构化数据向多元化转变），并且对统一的数据中台平台诉求强烈，对数据中台的运算能力、核心算法、及数据全面性提出了更高的要求。
数据中台的处理架构发生了变化
传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。
而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。
一是以Hadoop、Spark等分布式技术和组件为核心的“计算&存储混搭”的数据处理架构，能够支持批量和实时的数据加载以及灵活的业务需求。
二是数据的预处理流程正在从传统的ETL结构向ELT转变：
5.1.2 阿里集团为什么要建立一个“大中台、小前台“？
我们从阿里共享业务事业部的发展史说起。起初，阿里只有一个淘宝事业部，后来成立了天猫事业部，此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系，两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因，阿里集团又成立了共享业务事业部，其成员主要来自之前的淘宝技术团队，同时将两套电商业务做了梳理和沉淀
中台其实就是一个共享服务的体系结构。
我们需要在日常的开发过程中将通用的服务抽离出来做到共享服务的体系结构当中。大中台，小前台的体系结构可以使得管理更加高效，小团队更加扁平化。
由于资源的共享可以让开发更加敏捷，更能够知道需要做什么，该怎么做？
通过抽象各条业务线，把共用的服务抽象出来共享，不限于用户、订单等基础模块服务，还包括具体的业务的抽象，比如教育培训相关的课程、讲师、学员等服务，通过抽象并以微服务的形式实现，避免重复投入资源造轮子。
5.1.3 中台目标
首先、把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。例如我们从外呼业务中梳理出工单管理和问卷管理的能力；从知识库中梳理出知识搜索的能力；从85电商平台中梳理出商品销售和库存管理的能力等等。
其次、将重复、类似的服务进行整合。同时在单个服务的完善和增强的过程中注意服务的通用性，避免其他相似“双胞胎”服务的出现。
最后，由于服务能力的集中管控，很大程度会促进我们一体化运维的能力，但在“大中台、小前台”的模式下，每一个服务都负责对N多个前端业务应用提供支持，这就要求运维在信息安全、备份、监控等方面要有更强的能力。
5.1.4 中台分类
甄别是不是中台，还要回到中台要解决的问题上，一切以“以用户为中心的持续规模化创新”为目的，将后台各式各样的资源转化为前台易于使用的能力，帮助我们打赢这场以用户为中心的战争的平台，我们都可以称之为中台：
业务中台提供重用服务 例如用户中心，订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；
数据中台提供了数据分析能力 帮助我们从数据中学习改进，调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；
移动及算法中台提供了战场一线火力支援能力 帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
技术中台提供了自建系统部分的技术支撑能力 帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
研发中台提供了自建系统部分的管理和技术实践支撑能力 帮助我们快速搭建项目，管理进度，测试，持续集成，持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；
组织中台为我们的项目提供投资管理、风险管理、资源调度等， 是战场的指挥部，战争的大脑，指挥前线，调度后方。
所以，评判一个平台是否称得上中台，最终评判标准不是技术也不是长什么模样，最终还是得前台说了算，毕竟前台才是战争的关键，才是感受得到战场的残酷、看得见用户的那部分人。
5.2 数据中台和数仓的关系
5.2.1 传统数仓
传统数仓有几个特点：
数据具有历史性
基于文件存储
以表为形态，自带元数据存储（比如Hive）
在数仓的数据是其他原始数据的拷贝或者拷贝的加工 传统数仓需要拷贝数据的重要原因是数据计算和数据存储需要尽可能的近。所以我们需要把MySQL等数据源的数据同步到数仓，才能进行进一步处理。（这里有点疑问，我觉得是因为需要直接对数仓数据进行离线操作，而不是对业务数据库进行繁重的操作，也就是说数据分析不能影响业务）
另外传统数仓更关注的是数据的历史状态，所以导致数据规模庞大。数仓本身也具备计算能力，同时也可以作为存储供其他计算系统使用。
5.2.2 数据中台
数据中台概念，不同于数据平台。数据中台，业务侧包含
数据触手(埋点)
数据接入(标准化)
数据仓库(抽象化)
数据治理(可靠性)
数据服务(产品化)
整体是一个闭环的解决方案 其中，闭环是最重要的一点。
数据服务接口
数据中台设计立足点本身是数据计算和存储分离的。那就意味着，数据中台本身并没有数据，数据来源是其他地方，比如传统数仓、业务数据库、用户在中台上传的文件（临时使用）、各个业务系统的API(瞬时，我们不关心API之前的数据结果是什么样的)。因为数据中台拥有这些数据源的适配器，所以相当于建立了互联管道。
关于元数据
我们知道数仓的优势是有元数据，通过表的方式很好的规整了数据。数据需要加工，所以一般数仓是有分层的，往上走一层，数据信息损耗就高一些。
数据中台也有一个全局的元数据管理系统，管理也是以表为主，粒度到字段级别。数据中台这个元信息包含了各个子存储的元信息，以数据中台需要的形态进行组织。
数据地图
数据中台的元数据其中承载的一个重要功能是数据地图，虽然在数据中台中，修建了通往所有数据的道路，但是当用户进来的时候无法知道具体某个数据的地址，也就没办法利用这些修好的道路。
数据地图就是解决这个问题 我们需要结合自然语言处理，检索技术，目录分类技术，机器学习以及数据规范化来帮助找到数据地址。数据地址从来都不是面向人类友好的。
通过数据中台的数据地图，以及数据中台到各数据源的建立好的管道，那么我们就可以很好的找到我们要的数据以及对他们进行关联和处理，分析，甚至进一步成为机器学习的素材。
数据地图和传统数仓元数据的区别在于：
它记录了散落在各个孤岛的数据，而不像传统数仓，只是在自己的数据。
数据格式是异构的，不仅仅是文件或表。
他不仅仅存储表以及字段相关信息，同时还让这些信息可检索，可查询，可以更好的面向人而不是机器。
5.2.3 结论
数仓是数据中台的一个重要组成部分，也是元数据的一个重要来源，但是随着技术的发展，数据计算和存储必定是分离的，这就需要一个新的元信息系统（数据地图）来进行承载。
5.3 数据中台建设是数字化转型的支撑
数据中台成为热点，“中台”这个概念，是相对于前台和后台而生，是前台和后台的链接点，将业务共同的工具和技术予以沉淀。数据中台是指数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台，在大数据生态中处于承上启下的功能，提供面向数据应用支撑的底座能力。
广义上来给数据中台一个企业级的定义：“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。
中台战略核心是数据服务的共享。中台战略并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，数据中台是围绕向上层应用提供数据服务构建的，中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环，也就是实现应用与数据之间解藕，并实现紧密交互。
5.4 公司平台分层与大中台小前台战略
5.4.1 互联网巨头“大中台，小前台”战略
阿里巴巴在2015年12月进行组织升级，就是“大中台，小前台”的模式。主要的思路是打破原来树状结构，小前台距离一线更近，业务全能，这样便于快速决策、敏捷行动；支持类的业务放在中台，扮演平台支撑的角色。
其实，这个最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司:
这家看似很小的公司，设置了一个强大的技术平台，来支持众多的小团队进行游戏研发。这样一来，他们就可以专心创新，不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致。对于这种多项目并行，各项目相对独立，但业务需求所需要的支持类似的公司，“中台”就有存在的价值。
这种类似的思维应用到大企业中，就是需要一个资源整合和能力沉淀的平台，对不同的部门进行总协调和支持，“中台”也就应运而生。
中台战略是构建符合DT时代的更具备创新性和灵活性的组织机制和业务机制，实现管理模式的创新。将公共的业务、数据、技术等公共能力从前台下沉，成为独立的中台，并且通过组织结构的调整物理拆分为独立的中台部门。
大中台，小前台”适用场景
不适合初创公司！初创公司的初创阶段没有任何的公共资源的积累，没有下沉为中台的内容。初创公司的首要任务是积累所有资源活下来，快速迭代主要业务，保存自己和核心竞争力。
适合高速发展公司或者快速成长公司。有一定的公共资源的积累，公共部分下沉为中台，保其高可用高性能，为前端业务百花齐放，快速迭代提供坚实的后盾。
5.4.2 公司平台分层
5.4.2.1 概述
阿里组织架构，业务中台、数据中台、技术中台公共组成中台。：
前台
由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 app，微信公众号等都属于前台范畴。
中台
“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。
“前台”要做什么业务，需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷。
后台
由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。后台并不为前台而生
另外，由于后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。
5.4.2.2 敏捷前台/小前台
一线作战单元，强调敏捷交互及稳定交付的组织能力建设。
对于阿里来说，小前台就是各个业务部门，个性化的各种前台服务，例如阿里的天猫、淘宝、河马、支付宝等一系列的品牌。
5.4.2.3 业务中台
能力固化与赋能，固化通用能力，赋能前线部队，提升配置效率，加快前线响应，产品化业务化，开辟全新生态。
具体来说，业务中台对应公司的公共基础业务和通用服务，例如短信中心、用户中心、支付中心交易中心、搜索服务等。下图中的公共逻辑层，就是业务中台。
5.4.2.4 技术中台
技术中台主要负责基础服务、基础组件、基础平台、存储体系、云平台、运维相关等技术支撑。
5.4.2.5 数据中台
负责大数据统计分析相关的DaaS（数据即服务）和PaaS（平台即服务）相关服务建设，资产整合与共享，整合多维数据，统一资产管理，连通数据孤岛，共享数据资源，深入挖掘数据，盘活资产价值。
5.4.2.6 稳定后台
以共享中心建设为核心，为前中台提供专业的内部服务支撑。
5.5 数据中台定义及处理架构
数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台建立后，会形成数据API，为企业和客户提供高效各种数据服务。
数据中台整体技术架构上采用云计算架构模式，将数据资源、计算资源、存储资源充分云化，并通过多租户技术进行资源打包整合，并进行开放，为用户提供“一站式”数据服务。
利用大数据技术，对海量数据进行统一采集、计算、存储，并使用统一的数据规范进行管理，将企业内部所有数据统一处理形成标准化数据，挖掘出对企业最有价值的数据，构建企业数据资产库，提供一致的、高可用大 数据服务。
数据中台不是一套软件，也不是一个信息系统，而是一系列数据组件的集合，企业基于自身的信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义，基于能力定义利用数据组件搭建自己的数据中台。
5.6 数据中台带来价值
数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据解藕。这样企业就可以不受限制地按需构建满足业务需求的数据应用。
构建了开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。
利用大数据智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足集团总部和各分子公司各级数据分析应用需求。
深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。
5.7 传统数据仓库与数据中台的差异点
作为工业企业，一般采用混搭架构：
6.1 数据仓库vs.数据集市
数据集市和数据仓库经常会被混淆，但两者的用途明显不同。
数据集市通常是数据仓库的子集;它等数据通常来自数据仓库 – 尽管还可以来自其他来源。数据集市的数据专门针对特定的用户社区(例如销售团队)，以便他们能够快速找到所需的数据。通常，数据保存在那里用于特定用途，例如财务分析。
数据集市也比数据仓库小得多 – 它们可以容纳数十千兆字节，相比之下，数据仓库可以存储数百千兆字节到PB级数据，并可用于数据处理。
数据集市可从现有数据仓库或其他数据源系统构建，你只需设计和构建数据库表，使用相关数据填充数据库表并决定谁可以访问数据集即可。
6.2 数据仓库vs.ODS
操作数据存储(ODS)是一种数据库，用作所有原始数据的临时存储区域，这些数据即将进入数据仓库进行数据处理。我们可以将其想象成仓库装卸码头，货物在此处交付、检查和验证。在ODS中，数据在进入仓库前可以被清理、检查(因为冗余目的)，也可检查是否符合业务规则。
在ODS中，我们可以对数据进行查询，但是数据是临时的，因此它仅提供简单信息查询，例如正在进行的客户订单状态。
ODS通常运行在关系数据库管理系统(RDBMS)或Hadoop平台。
6.3 关系型数据库vs.数据仓库和数据湖
数据仓库、数据湖与关系数据库系统之间的主要区别在于：
关系数据库用于存储和整理来自单个来源(例如事务系统)的结构化数据，
而数据仓库则用于存储来自多个来源的结构化数据。
数据湖的不同之处在于它可存储非结构化、半结构化和结构化数据。
关系数据库创建起来相对简单，可用于存储和整理实时数据，例如交易数据等。关系数据库的缺点是它们不支持非结构化数据库数据或现在不断生成的大量数据。这使得我们只能在数据仓库与数据湖间做出选择。尽管如此，很多企业仍然继续依赖关系数据库来完成运营数据分析或趋势分析等任务。
内部或云端可用的关系数据库包括Microsoft SQL Server、Oracle数据库、MySQL和IBM Db2、以及Amazon Relational Database Service、Google Cloud Spanner等。
全文完