现在，随着诸如互联网以及物联网等技能的不断发展，越来越多的数据被生产出来-据统计，天天大约有超过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的数据湖包罗一切使得开辟者、数据科学家、分析师能更简朴的存储、处置处罚数据的本领，这些本领使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做全部类型的分析和处置处罚。数据湖在能帮助用户加速应用数据的同时，消除了数据收罗和存储的复杂性，同时也能支持批处置处罚、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的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等。
可参考
- 解读阿里巴巴集团的“大中台、小前台”组织战略
- 互联网中台紧张性
- What is a Lakehouse? by Ben Lorica, Michael Armbrust, Ali Ghodsi, Reynold Xin and Matei Zaharia Posted in COMPANY BLOGJanuary 30, 2020
- 带你读《企业数据湖》之一：数据导论
- 带你读《企业数据湖》之二：数据湖概念概览
- 带你读《企业数据湖》之三：Lambda架构：一种数据湖实现模式
- 阿里云-什么是数据湖分析
- EOF -
推荐书籍：《分布式商业生态战略：数字商业新逻辑与企业数字化转型新策略》
素材泉源官方媒体/网络新闻
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
