在数据大爆炸时代，随着企业的业务数据体量的不断发展，半结构化以及无结构化数据越来越多，传统的数据仓库面临重大挑战。通过以Hadoop, Spark为代表的大数据技术来构建新型数据仓库，已经成为越来越多的企业应对数据挑战的方式。
本期极客说邀请了来自腾讯云大数据基础团队负责人，大数据技术专家堵俊平来为我们分享介绍大数据领域最近的技术趋势，包含介绍Hadoop与Spark技术的最新进展。通过一些实际的应用案例，来介绍腾讯大数据是如何在云上构建PB级的数据仓库，以及如何解决一些工程难题的。
嘉宾简介
堵俊平，腾讯云大数据基础团队负责人，大数据技术专家。曾任EMC，VMware资深研发工程师，Hortonworks美国YARN团队负责人。深耕云计算，大数据方向10余年，在多个社区均享有极高知名度，包括Apache Hadoop社区Committer & PMC，并领导hadoop 2.6、2.8等应用非常广泛的社区release。曾领导开发多个Hadoop在云平台上优化与拓展的项目与产品。目前在腾讯致力于领导腾讯云大数据及人工智能产品研发。
本期的内容主要是为大家带来大数据数仓的相关内容。主要从大数据的技术发展与趋势、数据仓库技术介绍、云数仓架构与实践和介绍一下大数据的新趋势展望——数据湖的相关内容。
大数据技术发展趋势
首先来回顾一下大数据的发展历史。谈到大数据，我们应该从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架构，都希望在一套平台里能统一数据的批处理和流计算。
这里举几个例子来看看Spark或Hadoop最新的技术进展。以Hadoop为例，下一代的原生数据库存储——Ozone，它是脱胎于HDFS，但又不限于HDFS。它克服了HDFS原生的一些问题，比如之前HDFS把大量的matadata信息放在了NameNode上，这样会造成HDFS在几千个节点之后很难去向外扩张。同样，这样的元数据存放方式会让HDFS不是很适合大量的小文件存储。
Ozone从机制上解决了这个问题，通过重构了元数据的分配方式，以Storage Container的方式来重构元数据的存放，解决了海量小文件存储的问题。同时它还提供了对象存储的接口。现在很多应用都已经适应云上的对象存储接口了。能够支持对象存储接口也是对Hadoop整个生态系统的一个进化。
同样的，它也能对Kubernetes提供一个高性能的基于Hadoop的原生对象存储。值得一提的是，它能够做到拓扑感知，即感知数据存放的位置，机架信息和节点信息等。这对大数据系统来说，data-locality是非常重要的。 如果没有data-locality的话，相当于牺牲了大数据很多的优势。
在Ozone这个项目成熟之前，在云上的方式对对象存储的方式有个集中式loading的过程。整个loading的过程，对于一些访问方式（如腾讯云的COS，AWS S3）比较类似于以往的SAN等集中化的存储方式。虽然它实现了计算和存储分离，但实际上很多大数据处理速度会受限于网络带宽。
在Ozone技术成熟之后，因为有了data-locality，在此基础之上有很多计算可以利用数据本地化，做很多的优化工作。
刚才提到的一些文件系统的变化，在Hadoop的计算资源调度框架YARN上面也有很多新的变化趋势。
首先在Hadoop3里面，比较明显的感觉就是Hadoop在向K8S借鉴了很多特点。比如说它对于Long Running Service的一个支持，对于Docker的容器化的引入。同时像在一些开发的过程中，比如潜水艇项目Submarine，它的一个特点是可以更好的去集成TensorFlow或者是MxNet等这样的一些深度学习的框架。他们的核心是通过YARN来部署一个TensorFlow的框架，然后通过GPU调度以及GPU的资源隔离，来感知资源的存在。
这个项目可以说集成了一些LinkedIn的开源项目，所以它目前还是在一个社区的发展过程中。像刚刚提到的Ozone，我们腾讯云的团队也正在参与整个的开发过程。
另外值得一提的是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技术，不同框架实现的方式是不一样的。因为Impala是C++的，它可以直接生成本地可执行的二进制代码，通过LLVM生成一些高效的SIMD指令。SparkSQL Tungsten则是能够通过反射机制，利用动态生成的java字节码。使用了Code Generation后，可以提高刚刚所说的CPU的计算执行，同时可以优化内存。
总体而言，数仓引擎性能的优化除了才提到的CPU优化，还有IO优化和内存优化。
IO优化就是将数据本地化，对于传统的MapReduce类的大数据框架而言，有data-locality，它的性能会好很多。但在内存方面则有很多的点需要考量，很多的执行引擎都是通过把热点数据进行cache，来提高整个的查询性能。这时候就需要考虑内存占用，如何提高CPU cache的命中率和如何减少GC次数和时间。
刚才提到的都是数仓的一些通用的技术和优化，接下来简单介绍一下数仓的几个技术流派以及它的发展趋势。
主要的技术流派可以分为早期的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：数据中台这个说法应该是少数厂商提出来的一个概念，并不是在国内外业界普遍认可的提法，大家听到更多的应该还是数据湖。在数据中台的概念里可能会有所谓的业务中台跟数据中台，它可能是以数据为决策性的出发点，从数据仓库来说，它也是一个位于核心中心的点，数据仓库也能做数据中台的事情。而数据湖可以支持数据在不同的平台上关联和查询的能力，相对来说它定义的面会更宽广一些。
新一代大数据技术 构建PB级云端数仓实践 v1.0.pptx
欢迎大家扫码入群，参与直播讨论