文章整理自下方视频

在数据大爆炸时代，随着企业的业务数据体量的不断发展，半结构化以及无结构化数据越来越多，传统的数据仓库面临重大挑战。通过以 Hadoop, Spark 为代表的大数据技术来构建新型数据仓库，已经成为越来越多的企业应对数据挑战的方式。

大数据技术发展与趋势

大数据的发展历史

首先来回顾一下大数据的发展历史。谈到大数据，我们应该从 Google 的三篇论文开始，分别是 GFS，MapReduce（2004）BigTable（2006）。

GFS 相当于是一个分布式的文件系统，MapReduce 相当于是一个执行引擎，这两个系统对于后面 Hadoop 的诞生以及引领大数据时代的来临都是非常至关重要的。大数据时代的开启实际上是在 2006 年开始的，在 08 年 HBase 项目也从 Hadoop 项目中分离出来，成为一个顶级的项目，它是第一个基于 Hadoop 项目的 NoSQL 数据库。值得一提的是，09 年的时候 AWS 推出了 EMR 的服务，这个相当于第一款在云上提供的大数据产品，从这里开始，大数据开启了云的时代。 2011 年 Facebook 开源了 Apache 的 Hive 项目，在这个项目里面相当于是传统的数仓或者 SQL 引擎第一次在 Hadoop 生态里面得到了发展。通年 Storm 开源，开启了流计算的时代。2012 年时，Hadoop 创始团队孵化了 Yarn，即 Hadoop 2.0. 与 1.0 相比，Yarn 成为了通用的调度计算框架，除了 MapReduce 之外能有更多的大数据计算框架可以加入进来，包括 Spark 项目。2013 年 Spark 正式加入 Apache，成为一个独立的项目。这个事件可以看作是大数据进入新的内存计算时代。2017 年年底，Hadoop3.0 发布，象征着大数据向容器化方向进化，并且跟 AI 的联系会越来越紧密。

如果将大数据的整个发展历程分为三个阶段的话，2006 年至 2008 年是起步阶段，2008-2018 年这十年的黄金发展阶段，现在大数据算是进入到一个比较成熟的阶段，同样也存在着非常多的机会。

大数据技术生态圈

下面我们来盘点一下大数据的生态圈。其实聊大数据的时候，很多技术还是会以 Hadoop 为核心，这些技术围绕了很多方面，比如大数据的存储，我们有 HDFS，也会有新的未来对象存储 Ozone；计算框架则是有传统的 MapReduce，到速度更快的内存计算框架 Spark，还有 MapReduce 的升级版 Tez。SQL 领域的话是比较热闹的，待会我们会具体讲到，在这里就先不赘述了。流计算领域也有很多项目，比如早期的 Storm，再到 Spark Streaming 的横空出世，在 Storm 的基础上进行了很大的提升，Flink 在架构上也有很大的革新， 兼具了 Storm 和 Spark Streaming 的优点。除了刚刚说到的这些领域之外呢，还有 NoSQL 和 Ambari 的监控，都在 Hadoop 生态中积极生长。

大数据技术发展趋势

这里简单总结一下大数据发展的一个趋势:

1. 大数据在向云上迁移，简化 DevOps 很多早期的大数据用户会觉得大数据技术太复杂，运维起来非常麻烦。所以简化 DevOps 是一个方向，往云上迁移自然是一个趋势，因为从云的角度来看它可以简化整个部署，并且让整个 IT 环境变得更为简单。 对于大数据而言，很多云有原生的优势，比如资源的弹性，存储的低廉，天然也是适合大数据发展的方向。容器化除了能在底层更好地隔离资源之外，还能统一私有云和公有云和很多应用级的接口。如果一个程序或是一个软件能在私有云上很好地运行的话，搬迁到公有云时能降低很多成本。

2. 大数据技术在很多 AI 平台做一个集成 AI 是近期的一个热点，个人看来近几年 AI 能在技术上有这么大的进展，还是跟我们数据处理的能力和技术的成熟有着密切的关系。现在的趋势就是希望打造一个大数据和 AI 一站式的数据分析和机器学习平台。这个趋势会让更多融合性的技术产生。

3. 数据湖 数据湖是兼容并蓄各种各样的数据，并不要求数据进入之前有个严格的 ETL 清洗的过程，或者规范化的过程。可以让数据更自由灵活，更能满足应用需求。

4. 批处理与流计算结合 在业界可以看到各种各样新的架构出现，比如 Lambda 架构,kappa 架构，都希望在一套平台里能统一数据的批处理和流计算。

下一代 Hadoop 原生湖存储 - Ozone

这里举几个例子来看看 Spark 或 Hadoop 最新的技术进展。以 Hadoop 为例，下一代的原生数据库存储——Ozone，它是脱胎于 HDFS，但又不限于 HDFS。它克服了 HDFS 原生的一些问题，比如之前 HDFS 把大量的 matadata 信息放在了 NameNode 上，这样会造成 HDFS 在几千个节点之后很难去向外扩张。同样，这样的元数据存放方式会让 HDFS 不是很适合大量的小文件存储。

Ozone 从机制上解决了这个问题，通过重构了元数据的分配方式，以 Storage Container 的方式来重构元数据的存放，解决了海量小文件存储的问题。同时它还提供了对象存储的接口。现在很多应用都已经适应云上的对象存储接口了。能够支持对象存储接口也是对 Hadoop 整个生态系统的一个进化。

同样的，它也能对 Kubernetes 提供一个高性能的基于 Hadoop 的原生对象存储。值得一提的是，它能够做到拓扑感知，即感知数据存放的位置，机架信息和节点信息等。这对大数据系统来说，data-locality 是非常重要的。 如果没有 data-locality 的话，相当于牺牲了大数据很多的优势。

Ozone 将带来的改变

在 Ozone 这个项目成熟之前，在云上的方式对对象存储的方式有个集中式 loading 的过程。整个 loading 的过程，对于一些访问方式（如腾讯云的 COS，AWS S3）比较类似于以往的 SAN 等集中化的存储方式。虽然它实现了计算和存储分离，但实际上很多大数据处理速度会受限于网络带宽。

在 Ozone 技术成熟之后，因为有了 data-locality，在此基础之上有很多计算可以利用数据本地化，做很多的优化工作。

刚才提到的一些文件系统的变化，在 Hadoop 的计算资源调度框架 YARN 上面也有很多新的变化趋势。

Hadoop Submarine 项目

首先在 Hadoop3 里面，比较明显的感觉就是 Hadoop 在向 K8S 借鉴了很多特点。比如说它对于 Long Running Service 的一个支持，对于 Docker 的容器化的引入。同时像在一些开发的过程中，比如潜水艇项目 Submarine，它的一个特点是可以更好的去集成 TensorFlow 或者是 MxNet 等这样的一些深度学习的框架。他们的核心是通过 YARN 来部署一个 TensorFlow 的框架，然后通过 GPU 调度以及 GPU 的资源隔离，来感知资源的存在。

这个项目可以说集成了一些 LinkedIn 的开源项目，所以它目前还是在一个社区的发展过程中。像刚刚提到的 Ozone，我们腾讯云的团队也正在参与整个的开发过程。

Spark 技术趋势

另外值得一提的是 Spark。大家都知道这几年 Spark 的技术发展的非常快，发展劲头也不容忽视。最近在 2.2, 2.3 这两个版本中，可以看到一个趋势是，它对 SQL 和 Streaming 方面的改进非常大，比如说加入了所谓的 CPO（基于代价的优化），以及刚刚提到的流计算方面的更新，从微批（micro batch）架构进化到了一个纯流式的架构。后面 Spark 和机器学习和深度学习框架的集成和增强会是一个非常重要的方向，其中以氢（Hydrogen）项目为代表。它的核心主要是希望将深度学习的框架整合进整个 Spark 生态体系中去。通过一套语言，一套应用接口，来统一数据分析，机器学习，包括深度学习。为了达到这个目的，在新的 2.4 和之后的 Release 里面，Spark 里面有非常多重要的 Feature，包括 Barrier Execution Mode（提供 Gang Scheduling 的能力，可以一次性批量性地调度一批任务或者起一批的计算，从而更好地去适应深度学习，还有框架的执行要求）Optimized Data Exchange（因为传统的 Spark 任务和深度学习的框架之间希望有更多更高效的数据交换，所以他们对数据接口进行了更新和升级）和 Accelerator Aware Scheduling（能够了解异构的数据平台，因为可能在未来很长的一段时间都是 CPU 机器和 GPU 机器甚至 FPGA，在这个集群里混用这些模式，如果 Spark 的调度性能识别出带该属性的资源，在选择时能更聪明地调动机器学习任务）。腾讯云的团队也参与了该 Feature 在社区的开发工作。

数据仓库技术

数据库与数据仓库对比

可能提到数据仓库很多人会有误解，觉得这个跟数据库没有什么区别，尤其是很多做应用开发的同学。觉得都是 SQL 接口，也是关系型的数据，数据仓库的技术也是脱胎于数据库的。从这个角度看确实数据库和数据仓库有很大的相似度。

但是呢，这两者从应用场景到实际采用的技术区别还是挺大的。

首先，他们的应用场景不同。数据库主要是偏向事务型处理，它更多的是对于数据的更新，数据的变动或是数据的追加。而数据仓库是基于很多很多的数据，在上面进行一些分析型的任务。

从数据库的角度来看它更多的是面向应用，需要设计数据存储的格式，需要频繁更新，主要是为日常工作而服务，会要求响应速度快。而数据仓库它会有很多面向主题的方式，只会更新小量的数据，但是会批量追加数据。它主要是为决策服务，比如有些静态报表或者动态的 Ad Hoc 查询，可以容忍一些的延迟，尤其是在制作定期的报表的刷新。

从技术上看数据库一次性处理的数据量是非常小的，针对的很多都是更新操作，一般采用行存的方式。但数据仓库主要是面向主题的，它单次处理数据的量会非常大，这些面向主题的数据仓库无论是在 join 的过程中还是在分析平台过程中，它只会看少数的列，而不是看所有的列，这种情况下大多采用列存的形式。

数据仓库模型

因为这两者的不同呢，所以在整个建模方面数据库和数据仓库也是不完全相同的。可以说数据仓库是数据库的一个超集。它除了传统关系模型之外，还有其他的建模方式，比如多维模型和 Data Vault 模型。

对于关系模型大家一定不陌生，但数据仓库的关系模型跟数据库的关系模型还是有点区别的，数据库的关系模型是多种多样的，可以有各种范式。但是数据仓库的关系模型主要是以三范式为主，最早是由数仓之父 Bill Inmon 他所提出的建模方法，站在全公司的角度设计一个三范式的 ER 模型，来表达企业的业务。他的出发点呢是说将各个系统的数据按照一些主题进行组合合并，它的特点就是需要对企业的业务和数据有深层次的了解，同时实施的周期非常长，对建模的人的业务能力要求也非常高。比较典型的代表就是 Teradata，基于金融业务发表了 FS-LDM 的模型。在深层了解金融业务的领域下，对金融业务进行了抽象，将业务分成了 10 大主题，金融公司就可以根据自身的情况在这些主题里面选择合适自己的模型进行调整或者扩展，再落地实施。

在建模的过程中，还是以实际分析的业务需要，最重要的是去选择颗粒度，粒度越大，要求存放的空间就越多，可以展现的细节也就越多，但进行汇总查询的时候性能就会越慢。这个需要自行权衡。按照维表和实施表？的这种逻辑结构，一般可以分为星型模型和雪花模型。

第三种比较常见的 Data Vault 模型其实是从传统 ER 模型中衍生出来的，跟 ER 模型比较类似。但实际操作中，它更强调可审计的基础数据层，强调数据历史性，追述性和原子性，而并非强调严格的一致性处理。相对传统 ER 模型而言更具灵活性。其实还有一些其他的小众模型没有列在这里，因为时间有限就不详细说了。

数据仓库中的数据层次

刚才说到了数仓建模的模型，当这些逻辑模型定下来之后呢，就可以运用一些层次化的方法来构建数仓和数据应用了。一般来说，我们说数据仓库的层次可以分为数据运营层（ODS），数据仓库层（DW），数据集市层（DM）和应用数据层（ADS）。

数据仓库层又分为明细数据层和汇总数据层，明细数据层包括了大量的数据细节，汇总则更多的是面向主题的数据。

数据仓库层可以看作是数据仓库层的子集，它会面向不同的场景和用户。因为它的量相对于数仓来说要小，所以它的访问速度会更快些，更加接近应用。

在逻辑模型定下来，确定数仓层次之后，下一件很重要的事情就是数据集成了。

数据集成-变化数据捕获

数据集成一般包括批量的数据导入和抽取，以及数据变化的捕获。数据的批量导入一般都是相对简单的，相对复杂的是针对变化数据的更新。通常有四种方式：

1. 时间戳 主要是基于时间戳比较，即在原表上增加时间戳段，系统在修改表数据的时候，可以同时更新时间戳的值。当进行时间抽取的时候，通过比较系统时间和时间戳字段来决定抽取哪些数据。时间戳方式相对来说性能会比较好，数据抽取也会相对来说比较简单。但对于业务系统有较大的侵入性（对系统的元数据造成影响），甚至有些数据库并不支持时间戳自动更新，需要添加额外的业务逻辑来更新时间戳，这种方式比较有局限性。

2. 快照（全表扫描比对） 一开始 ETL 的工具可以为这些表抽取一个类似于 MD5 的快照临时表。它记录了原表中的一些组件，以及根据所有字段计算出来的 MD5 的校验码，每次做数据抽取的时候可以做 MD5 的校验码比对，来查看原表中的数据有没有变化或者删除。相比起时间戳的方式，快照方式的侵入性要相对小一些，但性能较差，对准确性也会有一定的影响。

3. 触发器 这个方法就是在所需要的表上建立修改，插入，删除三个触发器，一旦原表中的数据发生变化，就会有一个 trigger，写入临时表中。在抽取过程中就会有标记。触发器抽取性能较高，但需要业务表能建立触发器，多少会对业务系统有点影响。

4. 日志 这种方式最为常见，比如说以 MySQL 数据库而言，它里面的数据变更可以通过 binlog 监控来感知数据的变化。这种方式无论是从性能方面还是其他方面都是影响最小的。

刚刚介绍了了数据集成，接下来我们可以讲一下关于数仓的核心技术，当然这些都是比较通用型的技术。影响数仓性能的核心是它的查询优化器，这里给出了一个 SparkSQL 的 Catalyst 的查询优化器示意图，这个架构是比较通用的。它一共有几个过程，首先是语法解析的过程，先有 SQL 的表达式，通过语法解析变成抽象语法树，即 AST 树。在这个树的基础上生成一个未优化的逻辑计划。再通过一些优化的规则，生成优化过的逻辑查询计划。最后再通过一些特别的优化手段，比如基于代价的优化模型生成物理执行计划，再进行实际的执行。这整个形成了数仓查询优化器的一个相对完整的过程。

数仓查询

简单来说，对于整个查询优化器而言，它大致有两种优化策略。一种是基于规则的优化器（RBO），这个方法是相对比较简单，易实现的。它主要是通过内置的规则来决定查询计划的执行和优化，就相当于是设置一些静态的规则。相比之下比较复杂的就是基于代价的优化（CBO）。它其实是比较有挑战性的工作，一个好的 CBO 会依赖于详细的统计信息，比如每列的最大值最小值，表的大小以及表分区信息等。所以这个对于大数据的数据仓库来说，它的工程实践挑战是比较大的。所以在很多基于大数据的 SQL 引擎刚面世的时候，其实都是没有 CBO 的。但 CBO 带来的好处就是它在实际运行过程中带来了较高的性能，所以慢慢地一些主流大数据数仓，比如 Hive，SparkSQL 都对其进行了实现，实际的效果也非常的好。

查询优化器其实它的核心就是优化表的 join 操作，因为表的 join 操作是 OLAP 分析场景里最常见，也是最复杂，在执行中代价最高的一个操作。所以针对不同的场景，一般多数的数仓都会设计多种的 join 算法，大概分为以下三类：

1. Broadcast join 它的思想就是把小表广播到每个计算节点，然后进行一个 hash join。这个 Broadcast join 的性能是最高的，但适用范围有限，仅限于大表 join 小表，如果两个都是小表的话，可能在一个节点上就能完成。

2. Shuffle hash join 即在 Map 阶段就按照 join key 执行 hash shuffle，结束之后在每个节点上会有两个表在当前 key 范围的相关数据，在本地执行这个。相对于 Broadcast join 性能就没那么好，因为它早期有个 shuffle 的过程，它比较适合大表 join 中等表。

3. Bucket join 对于大表 join 大表，Bucket join 就比较合适了。它是先将表按照 bucket 分区，进行排序之后再执行 merge join。

除了优化 join 算法，优化 join 的顺序也是非常重要的。表的 join 顺序主要有两种，一种是 Left-deep tree，就是像上图所示。它是一个最简单最自然的过程，比如我要做 ABCD 四个表的 join 操作，就先将 AB 组合，再跟 C 来 join，最后跟 D 来 join，是一个串行的 join。但这样做会产生大量的中间的临时表，不大适合 OLAP 场景中的一些复杂的查询。还有一个就是平衡的 Bushy tree，这个顺序可以动态调整 join 的顺序，让它更平衡。这样的话中间过程可能只会生成比较少的中间临时表。它的速度也会更快，更适合星型模型和雪花模型。

除了调整 join 的算法和顺序之外，其实传统数仓的执行计划也有很多其他的优化手段，比如说列值剪裁，谓词下推等等。这些方法可以帮助在做数据 scan 的时候跳过一些没有用的 column，或是没用的 row，这样可以避免加载大量的没有用的数据，提高性能。

到了所谓的物理执行计划阶段呢，这个过程也是非常重要的。物理执行引擎其实对于查询的性能影响较大，所以这也是各个数据引擎在大力优化的点。

物理执行计划

最早的模型是火山模型 volcano style，这种模型里查询计划是由 operator 组成的 tree 或者 DAG（有向无环图）。 Operator 含有三个函数：Open、Next 和 Close。在 Open 函数里主要是申请资源，分配资源或是打开文件之类的。Close 用于释放资源，Next 则用来递归调用子 operator 的 next 方法生成元组。火山模型的 next 方法一般是实现一些虚函数，在编译器中，虚函数调用会需要查找虚函数表，算是一种非直接跳转的方式，经常会导致 CPU 的分支预测错误，会消耗很大一部分 CPU 开销。所以在这种情况下，早期的火山模型并不是性能最高的一个方式。现在新的 OLAP 场景下的 SQL Engine 很多支持向量化执行模型。

其实向量化执行模型也是在火山模型的基础上发展出来的。最早的方式是叫 Column-at-a-time，相对于之前每次 next 调用返回一个列，在这里它就可能会返回多个列，每个列都以数组的形式返回。这种方式有非常高的查询效率，但缺点就是它在返回过程中这些列数据都需要被物化到内存甚至是硬盘上，这就会导致很高内存占用或是 IO 开销，数据也不能直接放入 CPU cache 当中，也会导致 CPU cache 命中率没有那么高。

再往前进化就是 Vectored iterator 模型，这种模型可以说是前一个 Column-at-a-time 模型的演进。next 调用返回时不是返回一个列，而是返回开一个可以放入 CPU cache 的向量。这种方式不仅能避免 CPU cache 命中率低的缺点，同时可以跟运行时编译技术 JIT 相结合，生成 SIMD 指令来优化执行器的处理效率，从而提高系统性能。

新型数仓很多都引入了向量化的执行引擎，比如 Hive，Impala，Presto，Spark 等等，尽管大家实现的细节不同，但核心思想还是一致的，尽可能在一次的 next 方法调用返回多项数据，通过一些动态代码生成技术来优化循环，减少解释执行的开销，提高 CPU cache 的命中率。

动态代码生成 - Code Generation

这里也要提一下动态代码生成-Code Generation 技术，不同框架实现的方式是不一样的。因为 Impala 是 C++的，它可以直接生成本地可执行的二进制代码，通过 LLVM 生成一些高效的 SIMD 指令。SparkSQL Tungsten 则是能够通过反射机制，利用动态生成的 java 字节码。使用了 Code Generation 后，可以提高刚刚所说的 CPU 的计算执行，同时可以优化内存。

数仓执行引擎的性能优化

总体而言，数仓引擎性能的优化除了才提到的 CPU 优化，还有 IO 优化和内存优化。 IO 优化就是将数据本地化，对于传统的 MapReduce 类的大数据框架而言，有 data-locality，它的性能会好很多。但在内存方面则有很多的点需要考量，很多的执行引擎都是通过把热点数据进行 cache，来提高整个的查询性能。这时候就需要考虑内存占用，如何提高 CPU cache 的命中率和如何减少 GC 次数和时间。

刚才提到的都是数仓的一些通用的技术和优化，接下来简单介绍一下数仓的几个技术流派以及它的发展趋势。

OLAP 分析数据仓库主要的技术流派

主要的技术流派可以分为早期的 Share Disk 模式， 利用 SMP 架构方式来处理，就像 Oracle 和 DB2 这些早期的数据库，都会在数据库的基础上提供数据仓库的服务，但它的扩展能力就比较差，性能没有分布式的数据仓库来得快。 第二种就是 Sharding 模式，即早期分布式数据库的分库分表模式。这种方式有很多限制，也不易扩容，SQL 的很多功能也进行了阉割。 现在用的最多的是 Share Nothing 架构，它又分为 MPP 和 SQL on Hadoop。

MPP 算是比较传统的数仓架构，从 Teradata 到 Greenplum，甚至到云数仓 AWS Redshift，都是采用这种方式。它的特点就是性能非常高，对于数据查询相当于分散到每个节点上，这些节点都是独立的数据库，它的数据访问都是本地化的，动态查询性能很高。但它的缺点也是非常明显的，MPP 的架构会有一定的扩展性瓶颈，比如集群达到 100 个点以上就很难进行扩容。一个集群扩大到一定规模之后多多少少会面临所谓的节点失效或是磁盘失效的问题，在上百个节点之后会发生的更多更频繁。因为 MPP 架构它的查询结果依赖于每个 query 执行节点的结果，就会有所谓的木桶（短板）效应，一旦一个节点出了问题，它就会拖累整个 job，这也是为什么它容错性较低。而较差的容错性会拖累整个复杂查询的进度，同时它的并发性也会被这个架构所影响，因为增加节点并不会带来并发性的增长。

与之相比的 SQL on Hadoop 的架构，它是基于 HDFS 之上构建的数仓引擎。这里面又分为以 Hive，SparkSQL 为代表的基于任务的或基于 DAG 模型的 SQL 引擎，以及 Impala，Presto，HAWQ 等这种 MPP 架构与 Hadoop 结合的数仓引擎，这两者还是有区分的。他们的性能高低不均，比如 Hive 的执行就非常稳定，但查询效率较低（不算上 LLAP）。大家通常会它更适合做离线任务或 ETL 任务，而不是即时查询。Impala 则是基于 MPP 架构的模型，它做 ad hoc 查询能力非常好，但不善长做大规模数据的 ETL 计算。SparkSQL 则是结合了两者的优势，既能做 ETL，又能做 ad hoc 查询。

可以看出数据仓库的体系是在不断地演化，从传统的数据库和数据仓库的一体机，大家都是一个节点，操作型数据也都在里面，数据仓库也在里面，在这个基础上出现了分库分表，再慢慢发展到 MPP 数据库，以及后来发展的云原生的数据仓库。这些都在不断地推动数据仓库的架构向前演进和发展。

云数仓的架构和实践

构建云端数据仓库

云端的数据仓库和传统的数据仓库是不一样的。云端的用户数据分散在不同的数据服务里，比如 MySQL 或是 Relational DBMS 上，数据也可能存放在 Object Store 上，会有流计算的场景，包括其他的一些大数据服务，这就要求云端的数据要有比较强的集成能力。

在云数仓形成一个有层次化的仓库，产生了数据集市之后，它要被更多的 PaaS 或是 SaaS 应用和服务来对接，比如云上 SaaS 的一些 BI 产品，machine learning 的算法或是框架平台等。这样是构建云端数仓的一个大致流程。

云端数据仓库参考架构

这是构建云数仓的一个参考架构，这里主要也是展现一些逻辑模型。首先底层就是跟公有云的 IaaS 层做一个对接，还需要一个强大的 Query Engine，这些数仓引擎需要一个合适的，满足业务场景需要的技术路线。再有就是需要 DB IDE 和 Notebook 组件来对接 Query Engine 包括数据查询的监控。同时它还要提供数据管理服务，包括数据目录，元数据管理，数据治理等，再往上对接各种数据应用等。最后，还需要一个云数仓的管理监控模块，使其能够自动部署以及提供监控和运维等功能。

我们从某个大型交易平台的数仓案例来看，这里可以比较清晰地看清一个数据仓库构建的过程。

首先它的需求是需要 PB 级的海量数据接入，要通过 OLAP 分析来优化业务运行效率，这也是数仓的基本要求，能够识别出数据价值，为业务分析来服务。因为数据来源比较分散，所以需要在上游和下游进行血缘追踪，还要对数据质量进行控制。由于业务发展快，也需要扩展性强的数仓架构。这样来看，它在云上搭建数据仓库是个非常不错的选择。

数据源能通过各种 ETL 的手段迁移到云端的数据仓库中，通过一些全量或是增量的数据抽取的手段，进入 ODS 操作型数据层，慢慢汇总，然后再到做数据集市。在整个数据平台上提供原数据管理，包括数据血缘管理和数据质量管理，或是一些任务管理，从而能够完成需求。 最后我们来展望一下数仓发展的新趋势——数据湖。

数据湖

何为数据湖

对于数据湖而言，很多人觉得 Hadoop 就是数据湖，这样去理解的话，数据湖的时代已经到来了，Hadoop 已经是非常普及了。从严格的意义上来看，数据湖包括了大数据的存储、管理和分析等一整套的服务能力。它跟传统数仓的核心区别在于，不要求数据是 ETL 方式或是规范化的方式进来，它更像是 ELT 的方式，先加载数据进来，再去做相关转化过程。这样的优势在于传统数据仓需要一个比较规范化的过程，会有很多限制条件，后期如果应用发生变化，或是主题模型无法再套用现有应用和数据结构，这个过程就会比较难办。数据湖能够突破这些限制，从而带来更多的自由和灵活程度。所以从逻辑存储的角度来说，数据湖需要提供存放结构化，非结构化以及半结构化的数据存储。对于数据湖的管理而言，它讲究的的是对于多个数据源，不管数据是在数据库上还是在数据对象存储上，它都可以有效地管理起来，把原数据抽取出来。这是数据湖强大的数据管理能力。

趋势展望：从数据仓库到数据湖

数据湖不像传统数仓，需要实体的存储。数据湖是个松散的存储结构，不需要数据的物化过程，也不需要所谓的 ETL 优先的过程。

展望未来的话，数据湖可能如图中所展示的，往下能对接非常多类型的数据源。往上也能支撑非常多的应用接口，它都可以用一站式的方式管理好数据的查询和分析，这就是我理解的数仓发展的新的阶段。

今天的演讲就到此结束，接下来是问答时间。

Q：能不能分享一下管理 PB 级数仓的经验？ A：传统上管理 PB 级的数仓主要是看规模，一个很大的挑战就是集群的规模。当集群规模越来越大之后，管理这个集群会有很大的挑战。但对于 Hadoop 或是一些云上对象存储已经慢慢越来越成熟了，Hadoop 本身有很强的容错能力，从运维角度来看其实难度还好。对于 PB 级的数据一定要去做好数据颗粒的把握，两级粒度做的不好的话，数据汇总不够，会导致数据分析应用会跑的非常慢，因为数据粒度在一个比较细的情况下在运营。但在抽象层次太高了的话，你会发现很多细节照顾不到，你会发现很难再转到你想要的数据粒度，所以对于 PB 级的数据颗粒度的掌握十分重要。

Q：这里说的数据湖跟最近听到比较多的数据中台很类似？ A：数据中台这个说法应该是少数厂商提出来的一个概念，并不是在国内外业界普遍认可的提法，大家听到更多的应该还是数据湖。在数据中台的概念里可能会有所谓的业务中台跟数据中台，它可能是以数据为决策性的出发点，从数据仓库来说，它也是一个位于核心中心的点，数据仓库也能做数据中台的事情。而数据湖可以支持数据在不同的平台上关联和查询的能力，相对来说它定义的面会更宽广一些。