文章链接：

1 数据库

1.1 ETL

ETL简介**ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL**一词较常用在数据仓库，但其对象并不限于数据仓库。

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据， ETL是BI（商业智能）项目重要的一个环节。

ETL所描述的过程，一般常见的作法包含ETL或是ELT（Extract-Load-Transform），并且混合使用。通常越大量的数据、复杂的转换逻辑、目的端为较强运算能力的数据库，越偏向使用ELT，以便运用目的端数据库的平行处理能力。

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

定义

操作型数据库

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

分析型数据库

主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；
那么为什么要”分家”？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？答案是NO。一个显然的原因是它们会”打架”…如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已”貌合神离”。接下来看看它们到底有哪些不同吧。 两者差异

因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。

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

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

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

操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据，又有汇总数据，但对于用户来说，重点关注的是汇总数据部分。
操作型数据库中自然也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。
而对于分析型数据库来说，因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。

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

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

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

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

技术差别 - 数据更新差别

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

技术差别 - 数据冗余差别

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

功能差别 - 数据读者差别

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

功能差别 - 数据定位差别

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

2 数据仓库

2.1 OLTP&OLAP

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

• 首先，要求速度很快， 基本上都是高可靠的在线操作（比如银行）
• 其次，这些操作涉及的数据内容不会特别大（否则速度也就相应的降低）

• 最后，“事务”型的操作往往都要求是精准操作，比如你去银行取款，必须要求一个具体的数字，不可能对着柜台员工说大概想取400到500之间 OLAP （Online Analytical Processing 联机分析处理） 它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。

• 其中F是快速性(Fast)，指系统能在数秒内对用户的多数分析要求做出反应；

• A是可分析性(Analysis)，指用户无需编程就可以定义新的专门计算，将其作为分析的一部 分，并以用户所希望的方式给出报告；
• M是多维性(Multi—dimensional)，指提供对数据分析的多维视图和分析；
• I是信息性(Information)，指能及时获得信息，并且管理大容量信息。

这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂，但这里我举一个简单的例子，大家就很容易理解了。
比如说，沃尔玛超市的数据库里有很多张表格，记录着各个商品的交易记录。超市里销售一种运动饮料，我们不妨称之为红牛。

• 数据库中有一张表A，记录了红牛在一年的各个月份的销售额；
• 还有一张表B，记录了红牛每个月在美国各个州的销售额；
• 甚至还有一张表C，记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；
• 甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表。

好，最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下，什么季节，什么天气，美国哪个州最好卖？
凭借我们的经验，可能会得出，夏季的晴天，在美国的佛罗里达，最好卖，而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的，但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼。
科学是不相信直觉的，如果我们人工进行手动分析，会发现这个要考虑的维度实在太多了，根本无法下手，何况这才四五个维度，要是更多了怎么办？

OLAP就是为了解决这样的问题诞生的，但糟糕的是，传统数据库是无法满足OLAP所需要的数据信息的。

2.2 数据仓库概述（Data Warehouse）

发展历史

数据库的大规模应用，使得信息行业的数据爆炸式的增长，为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用OLAP来为决策者进行分析，探究一些深层次的关系和信息。但很显然，不同的数据库之间根本做不到数据共享，就算同一家数据库公司，数据库之间的集成也存在非常大的挑战（最主要的问题是庞大的数据如何有效合并、存储）。

1988年，为解决企业的数据集成问题，IBM的两位研究员（Barry Devlin和Paul Murphy）创造性地提出了一个新的术语：数据仓库（Data Warehouse）。

1992年，后来被誉为“数据仓库之父”的比尔 恩门（Bill Inmon）给出了数据仓库的定义：
数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。

数据仓库的概念可以从两个层次予以理解：

• 首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;
• 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。

简单的理解，其实就是我们为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。

原来各个数据孤岛中的数据，可能会在物理位置（比如沃尔玛在各个州可能都有自己的数据中心）、存储格式（比如月份是数值类型，但天气可能是字符类型）、商业平台（不同数据库可能用的是Oracle数据库，有的是微软SQL Server数据库）、编写的语言（Java或者Scale等）等等各个方面完全不同，数据仓库要做的工作就是将他们按照所需要的格式提取出来，再进行必要的转换（统一数据格式）、清洗（去掉无效或者不需要的数据）等，最后装载进数据仓库（我们所说的ETL工具就是用来干这个的）。

数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统，其实就是我们现在说的商务智能（Business Intelligence）即BI。

数据仓库为OLAP解决了数据来源问题，数据仓库和OLAP互相促进发展，进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的，正是我们现在热谈的下一代技术：数据挖掘。

数据仓库特点

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

操作型数据库是为了支撑各种业务而建立，而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立。

主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；
面向主题：是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。 集成性集成性是指数据仓库会将不同源数据库中的数据汇总到一起。

具体来说，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。 企业范围数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来。 历史性较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年。 时变性时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；
数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库与BI

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

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

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

数据仓库系统作用与定位

数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。

• 是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具；
• 是主要用于历史性、综合性和深层次数据分析；
• 数据来源是ERP（例:SAP）系统或其他业务系统；
• 能够提供灵活、直观、简洁和易于操作的多维查询分析;
• 不是日常交易操作系统，不能直接产生交易数据。

数据仓库能提供什么

2.3 数据仓库组件

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

业务系统

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

ETL

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

提取extraction

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

转换transformation

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

加载load

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

前端应用

和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用。
数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。

2.4 数据仓库开发流程

数据仓库开发流程

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.5 数据仓库系统管理

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

2.6 数据质量体系

用一句话概括，数据质量就是衡量数据能否真实、及时反映客观世界的指标。具体来说，数据质量包含以下几大指标：

指标说明

准确性

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

唯一性（视情况而定）

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

完整性

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

一致性

一致性要求不同关系、或者同一关系不同字段的数据意义不发生冲突。
比如某关系中昨天存货量字段+当天进货量字段-当天销售量字段等于当天存货量就可能是数据质量有问题；

及时性

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

统一性

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

数据质量和数据具体意义有很大相关性，因此无法单凭理论来保证。且由于具体业务及真实世界的复杂性，数据质量问题必然会存在，不可能完全预防得了。因此很多公司都提供了数据质量工程服务/软件，用来识别和校正数据库系统中的各种数据质量问题。

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

• 企业范围还是部门范围
• 先建立数据仓库还是数据集市
• 建立领航系统还是直接实施
• 数据集市是否相互独立

数据集市可以理解为是一种”小型数据仓库”，它只包含单个主题，且关注范围也非全局。
数据集市可以分为两种:
一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；
另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的子集。

3 数据湖

3.1 数据湖概述

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

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

数据湖还有以下特点：

• 从源系统导入所有的数据，没有数据流失。
• 数据存储时没有经过转换或只是简单的处理。
• 数据转换和定义schema 用于满足分析需求。

3.2 数据湖定义

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

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

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

数据湖可以包括:
来自关系数据库（行和列）的结构化数据
半结构化数据（CSV，日志，XML，JSON）
非结构化数据（电子邮件，文档，PDF）和二进制数据（图像，音频，视频）。

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

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

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

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

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

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

数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。
综上，个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。

3.3 数据湖的处理架构

数据湖引擎介于管理数据系统、分析可视化和数据处理工具之间。数据湖引擎不是将数据从数据源移动到单个存储库，而是部署在现有数据源和数据使用者的工具(如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)探索、分析数据，而不用关心数据在哪存、结构如何。

有些数据源可能不适合分析处理，也无法提供对数据的有效访问。数据湖引擎提供了优化数据物理访问的能力。有了这种能力，可以在不改变数据使用者访问数据的方式和他们使用的工具的情况下优化各个数据集。

3.4 数据仓库与数据湖的区别

4 数据中台

4.1 概述

企业在过去信息化的历程中形成了大量生产经营及专业业务应用成果，同时也累积了大量的企业数据资产。限于传统的数据仓库技术手段，数据管理和分析能力成为信息化工作中的短板。

企业信息系统众多，系统管理独立，数据存储分散，横向的数据共享和分析应用仅由具体业务驱动，难以对全局数据开展价值挖掘，从规模上和效果上都无法真正体现集团庞大数据资产的价值。

传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。

而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。

4.2 中台目标

中台其实就是一个共享服务的体系结构。我们需要在日常的开发过程中将通用的服务抽离出来做到共享服务的体系结构当中。

• 首先、把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。
  例如我们从外呼业务中梳理出工单管理和问卷管理的能力；从知识库中梳理出知识搜索的能力；从85电商平台中梳理出商品销售和库存管理的能力等等。
• 其次、将重复、类似的服务进行整合。同时在单个服务的完善和增强的过程中注意服务的通用性，避免其他相似“双胞胎”服务的出现。
• 最后，由于服务能力的集中管控，很大程度会促进我们一体化运维的能力，但在“大中台、小前台”的模式下，每一个服务都负责对N多个前端业务应用提供支持，这就要求运维在信息安全、备份、监控等方面要有更强的能力。

4.3 数据中台和数仓的关系

传统数仓

传统数仓有几个特点：

• 数据具有历史性
• 基于文件存储
• 以表为形态，自带元数据存储（比如Hive）

在数仓的数据是其他原始数据的拷贝或者拷贝的加工，传统数仓需要拷贝数据的重要原因是数据计算和数据存储需要尽可能的近。所以我们需要把MySQL等数据源的数据同步到数仓，才能进行进一步处理。（这里有点疑问，我觉得是因为需要直接对数仓数据进行离线操作，而不是对业务数据库进行繁重的操作，也就是说数据分析不能影响业务）
另外传统数仓更关注的是数据的历史状态，所以导致数据规模庞大。数仓本身也具备计算能力，同时也可以作为存储供其他计算系统使用。

数据中台

数据中台概念，不同于数据平台。数据中台，业务侧包含：

• 数据触手(埋点)
• 数据接入(标准化)
• 数据仓库(抽象化)
• 数据治理(可靠性)
• 数据服务(产品化)

整体是一个闭环的解决方案 其中，闭环是最重要的一点。

结论

数仓是数据中台的一个重要组成部分，也是元数据的一个重要来源，但是随着技术的发展，数据计算和存储必定是分离的，这就需要一个新的元信息系统（数据地图）来进行承载。

4.4 数据中台是数字化转型的支撑

数据中台成为热点，“中台”这个概念，是相对于前台和后台而生，是前台和后台的链接点，将业务共同的工具和技术予以沉淀。

数据中台是指数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台，在大数据生态中处于承上启下的功能，提供面向数据应用支撑的底座能力。

广义上来给数据中台一个企业级的定义：“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。

中台战略核心是数据服务的共享。中台战略并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，数据中台是围绕向上层应用提供数据服务构建的，中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环，也就是实现应用与数据之间解藕，并实现紧密交互。

5 区别

5.1 数据仓库vs数据集市

数据集市和数据仓库经常会被混淆，但两者的用途明显不同。

数据集市通常是数据仓库的子集;它等数据通常来自数据仓库 – 尽管还可以来自其他来源。数据集市的数据专门针对特定的用户社区(例如销售团队)，以便他们能够快速找到所需的数据。通常，数据保存在那里用于特定用途，例如财务分析。

数据集市也比数据仓库小得多 – 它们可以容纳数十千兆字节，相比之下，数据仓库可以存储数百千兆字节到PB级数据，并可用于数据处理。

数据集市可从现有数据仓库或其他数据源系统构建，你只需设计和构建数据库表，使用相关数据填充数据库表并决定谁可以访问数据集即可。

6.2 数据仓库vsODS

操作数据存储(ODS)是一种数据库，用作所有原始数据的临时存储区域，这些数据即将进入数据仓库进行数据处理。我们可以将其想象成仓库装卸码头，货物在此处交付、检查和验证。在ODS中，数据在进入仓库前可以被清理、检查(因为冗余目的)，也可检查是否符合业务规则。

在ODS中，我们可以对数据进行查询，但是数据是临时的，因此它仅提供简单信息查询，例如正在进行的客户订单状态。

ODS通常运行在关系数据库管理系统(RDBMS)或Hadoop平台。

6.3 关系型数据库vs数据仓库vs数据湖

数据仓库、数据湖与关系数据库系统之间的主要区别在于：

• 关系数据库用于存储和整理来自单个来源(例如事务系统)的结构化数据，
• 而数据仓库则用于存储来自多个来源的结构化数据。
• 数据湖的不同之处在于它可存储非结构化、半结构化和结构化数据。

关系数据库创建起来相对简单，可用于存储和整理实时数据，例如交易数据等。关系数据库的缺点是它们不支持非结构化数据库数据或现在不断生成的大量数据。这使得我们只能在数据仓库与数据湖间做出选择。尽管如此，很多企业仍然继续依赖关系数据库来完成运营数据分析或趋势分析等任务。