数据湖概念架构及特征

问题导读：
1、什么是数据湖？
2、数据湖的基本特征有哪些？
3、基本架构如何理解？
4、数据湖与数据仓库的区别是什么？

数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖？有不同的定义。

•     Wikipedia上说数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件，包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。
•     AWS定义数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。
•     微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义，数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。
  

关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开：

•     数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。
•     数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
•     数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
•     数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
•     数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
•     数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
•     数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
•     对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。
  

综上，个人认为数据湖目前只是一种概念，日后应该会成为一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。

数据湖的基本特征

•     保真性
  

数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。

•     灵活性
  

写入型schema vs 读取型schema，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。

写入型schema背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。

数据湖强调的读取型schema，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据按需贴合业务的能力。因此，个人认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。

因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。

•     可管理
  

数据湖应该提供完善的数据管理能力。既然数据要求“保真性”和“灵活性”，那么至少数据湖中会存在两类数据：原始数据和处理后的数据。数据湖中的数据会不断的积累、演化。

因此，对于数据管理能力也会要求很高，至少应该包含以下数据管理能力：数据源、数据连接、数据格式、数据schema（库/表/列/行）。同时，数据湖是单个企业/组织中统一的数据存放场所，因此，还需要具有一定的权限管理能力。

•     可追溯
  

数据湖是一个组织/企业中全量数据的存储场所，需要对数据的全生命周期进行管理，包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现，需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的，能够清楚的重现数据完整的产生过程和流动过程。

•     丰富的计算引擎
  

从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。

•     数据的加载、转换、处理会使用批处理计算引擎；
•     需要实时计算的部分，会使用流式计算引擎；
•     对于一些探索式的分析场景，可能又需要引入交互式分析引擎。 随着大数据技术与人工智能技术的结合越来越紧密，各类机器学习/深度学习算法也被不断引入，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此，对于一个合格的数据湖项目而言，计算引擎的可扩展/可插拔，应该是一类基础能力。
  

基本架构

先看看大数据平台基础设施架构的演进过程

第一阶段

以Hadoop为代表的离线数据处理基础设施。如下图所示，Hadoop是以HDFS为核心存储，以MapReduce（MR）为基本计算模型的批量数据处理基础设施。围绕HDFS和MR，产生了一系列的组件，不断完善整个大数据平台的数据处理能力，例如面向在线KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。

同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了Tez、Spark、Presto等计算引擎，MR模型也逐渐进化成DAG模型。DAG模型一方面，增加计算模型的抽象并发能力：对每一个计算过程进行分解，根据计算过程中的聚合操作点对任务进行逻辑切分，任务被切分成一个个的stage，每个stage都可以有一个或者多个Task组成，Task是可以并发执行的，从而提升整个计算过程的并行能力；另一方面，为减少数据处理过程中的中间结果写文件操作，Spark、Presto、impala等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力。



第二阶段

lambda架构。随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求；而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出，如下图所示。



Lambda架构的核心理念是流批一体，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。

第三阶段

Kappa架构。Lambda架构解决了应用读取数据的一致性问题，但是流批分离的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的时间窗口，来统一批处理与流式处理两种计算模式。

那如何用流计算系统对全量数据进行重新计算，步骤如下：

1. 用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。
2. 当需要全量计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。
3. 当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除。

其他

随着OLAP技术的提升，有些公司也在逐渐重用OLAP引擎，所以自然而然引出一种新的架构。 起名叫实时OLAP吧。

主要思路就是把大量的聚合、分析、计算由实时OLAP引擎来承担，减轻流计算的压力，只需要简答的处理。这样就可以保证在数据应用层能灵活的面对各种业务分析的需求变更，整个架构更灵活。

三者对比如下：


综上，从传统的Hadoop架构往Lambda架构，从Lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中，除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳入大数据平台来进行统一的处理。

然而，目前的大数据平台基础架构，都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理，这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。

大数据基础架构的演进，其实反应了一点：在企业/组织内部，数据是一类重要资产已经成为了共识；为了更好的利用数据，企业/组织需要对数据资产有如下要求：

1. 进行长期的原样存储
2. 进行有效管理与集中治理
3. 提供多模式的计算能力满足处理需求
4. 以及面向业务，提供统一的数据视图、数据模型与数据处理结果

数据湖就是在这个大背景下产生的，除了大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。落到具体的实现上，数据湖需要包括一系列如下的数据管理组件：

1. 数据接入
2. 数据搬迁
3. 数据治理
4. 质量管理
5. 资产目录
6. 访问控制
7. 任务管理
8. 任务编排
9. 元数据管理




上图的“集中式存储”更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。

数据湖从本质上来讲，是一种企业数据架构方法，物理实现上则是一个数据存储平台，用来集中化存储企业内海量的、多来源，多种类的数据，并支持对数据进行快速加工和分析。从实现方式来看，目前Hadoop是最常用的部署数据湖的技术，但并不意味着数据湖就是指Hadoop集群。为了应对不同业务需求的特点，MPP数据库+Hadoop集群+传统数据仓库这种“混搭”架构的数据湖也越来越多出现在企业信息化建设规划中。

企业使用数据湖架构，核心出发点就是把不同结构的数据统一存储，使不同数据有一致的存储方式，在使用时方便连接，真正解决数据集成问题。因此，数据湖架构最主要的特点，一是支持异构数据聚合，二是无需预定义数据模型即可进行数据分析。

数据湖与数据仓库的区别

•     存储数据类型不同。数据仓库中存储的主要是结构化数据，对于加载到数据仓库中的数据，首先需要定义数据存储模型。而数据湖以其原生格式保存大量原始数据，包括结构化的、半结构化的和非结构化的数据，并且在使用数据之前，不对数据结构进行定义。
•     数据处理模式不同。数据仓库是高度结构化的架构，数据在清洗转换之后才会加载到数据仓库，用户获得的是处理后数据。而在数据湖中，数据直接加载到数据湖中，然后根据分析的需要再处理数据。
•     服务对象不同。从用户差异上来看，数据仓库适合企业中大数据产品开发人员和业务用户。而数据湖最适合数据分析师或数据科学家，他们直接基于数据沙箱做自由探索和分析，这些人要求有技术背景，会写代码或熟悉SQL。
  

总结下来就三点

•     计算。 现在流行的是spark的delta lake，但是普及度也没有很高，我还没学明白，不妄加评论。我们公司使用的是presto，计算速度没得吐槽，毕竟全内存计算，而且支持的数据结构足够多。
•     数据异构同质化。 presto也能实现，能支持多种数据源。
•     OLAP + 实时流。 OLAP依靠的是kudu，增删改查全不怕，但是运维成本不低，没有SSD性能下降很快。spark structured streaming 在处理实时方面虽然不如flink，但是在生态方面和稳定方面我更看好前者。
  

分析下来你会发现，目前数据湖还是一个概念，还没有太过规范。企业发展到一定阶段，一定会为了适应用户需求和市场需要做一些技术调整，只不过是调整之后的架构正好符合数据湖的设计。

作者：simbafl
来源：https://github.com/simbafl/DataW ... 6%8D%AE%E6%B9%96.md

最新经典文章，欢迎关注公众号