各厂商的数据湖解决方案

2022 年 7 月 17 日
本文字数：5930 字
阅读完需：约 19 分钟

各厂商的数据湖解决方案

数据湖作为当前的一个风口，各大云厂商纷纷推出自己的数据湖解决方案及相关产品。本节将分析各个主流厂商推出的数据湖解决方案，并将其映射到数据湖参考架构上，帮助大家理解各类方案的优缺点。

1 AWS 数据湖解决方案

图 7 是 AWS 推荐的数据湖解决方案。整个方案基于 AWS Lake Formation 构建，AWS Lake Formation 本质上是一个管理性质的组件，它与其他 AWS 服务互相配合，来完成整个企业级数据湖构建功能。上图自左向右，体现了数据流入、数据沉淀、数据计算、数据应用四个步骤。我们进一步来看其关键点：

1. 数据流入。

数据流入是整个数据湖构建的起始，包括元数据的流入和业务数据流入两个部分。元数据流入包括数据源创建、元数据抓取两步，最终会形成数据资源目录，并生成对应的安全设置与访问控制策略。解决方案提供专门的组件，获取外部数据源的相关元信息，该组件能连接外部数据源、检测数据格式和模式（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 等组件支持数据的自由流动。

2. 数据沉淀。

采用 Amazon S3 作为整个数据湖的集中存储，按需扩展/按使用量付费。

3. 数据计算。

整个解决方案利用 AWS GLUE 来进行基本的数据处理。GLUE 基本的计算形式是各类批处理模式的 ETL 任务，任务的出发方式分为手动触发、定时触发、事件触发三种。不得不说，AWS 的各类服务在生态上实现的非常好，事件触发模式上，可以利用 AWS Lambda 进行扩展开发，同时触发一个或多个任务，极大的提升了任务触发的定制开发能力；同时，各类 ETL 任务，可以通过 CloudWatch 进行很好的监控。

4. 数据应用。

在提供基本的批处理计算模式之外，AWS 通过各类外部计算引擎，来提供丰富的计算模式支持，例如通过 Athena/Redshift 来提供基于 SQL 的交互式批处理能力；通过 EMR 来提供各类基于 Spark 的计算能力，包括 Spark 能提供的流计算能力和机器学习能力。

5. 权限管理。

AWS 的数据湖解决方案通过 Lake Formation 来提供相对完善的权限管理，粒度包括“库-表-列”。但是，有一点例外的是，GLUE 访问 Lake Formation 时，粒度只有“库-表”两级；这也从另一个侧面说明，GLUE 和 Lake Formation 的集成是更为紧密的，GLUE 对于 Lake Formation 中的数据有更大的访问权限。

Lake Formation 的权限进一步可以细分为数据资源目录访问权限和底层数据访问权限，分别对应元数据与实际存储的数据。实际存储数据的访问权限又进一步分为数据存取权限和数据存储访问权限。数据存取权限类似于数据库中对于库表的访问权限，数据存储权限则进一步细化了对于 S3 中具体目录的访问权限（分为显示和隐式两种）。如图 8 所示，用户 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 的数据湖解决方案中，流计算和机器学习并不是固定捆绑的，只是作为计算能力扩展，能方便的集成。

最后，让我们回到图 6 的数据湖组件参考架构，看看 AWS 的数据湖解决方案的组件覆盖情况，参见图 9。

综上，AWS 的数据湖解决方案覆盖了除质量管理和数据治理的所有功能。其实质量管理和数据治理这个工作和企业的组织结构、业务类型强相关，需要做大量的定制开发工作，因此通用解决方案不囊括这块内容，也是可以理解的。事实上，现在也有比较优秀的开源项目支持这个项目，比如 Apache Griffin，如果对质量管理和数据治理有强诉求，可以自行定制开发。

2 华为数据湖解决方案

华为的数据湖解决方案相关信息来自华为官网。目前官网可见的相关产品包括数据湖探索（Data Lake Insight，DLI）和智能数据湖运营平台（DAYU）。其中 DLI 相当于是 AWS 的 Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。官网上没找到关于 DLI 的整体架构图，我根据自己的理解，尝试画了一个，主要是和 AWS 的解决方案有一个对比，所以形式上尽量一致，如果有非常了解华为 DLI 的同学，也请不吝赐教。

华为的数据湖解决方案比较完整，DLI 承担了所有的数据湖构建、数据处理、数据管理、数据应用的核心功能。DLI 最大的特色是在于分析引擎的完备性，包括基于 SQL 的交互式分析以及基于 Spark+Flink 的流批一体处理引擎。在核心存储引擎上，DLI 依然通过内置的 OBS 来提供，和 AWS S3 的能力基本对标。华为数据湖解决方案在上下游生态上做的比 AWS 相对完善，对于外部数据源，几乎支持所有目前华为云上提供的数据源服务。

DLI 可以与华为的 CDM（云数据迁移服务）和 DIS（数据接入服务）对接：

借助 DIS，DLI 可以定义各类数据点，这些点可以在 Flink 作业中被使用，做为 source 或者 sink；
借助 CDM，DLI 甚至能接入 IDC、第三方云服务的数据。

为了更好的支持数据集成、数据开发、数据治理、质量管理等数据湖高级功能，华为云提供了 DAYU 平台。DAYU 平台是华为数据湖治理运营方法论的落地实现。DAYU 涵盖了整个数据湖治理的核心流程，并对其提供了相应的工具支持；甚至在华为的官方文档中，给出了数据治理组织的构建建议。DAYU 的数据治理方法论的落地实现如图 11 所示（来自华为云官网）。

可以看到，本质上 DAYU 数据治理的方法论其实是传统数据仓库治理方法论在数据湖基础设施上的延伸：从数据模型来看，依然包括贴源层、多源整合层、明细数据层，这点与数据仓库完全一致。根据数据模型和指标模型会生成质量规则和转换模型，DAYU 会和 DLI 对接，直接调用 DLI 提供的相关数据处理服务，完成数据治理。

华为云整个的数据湖解决方案，完整覆盖了数据处理的生命周期，并且明确支持了数据治理，并提供了基于模型和指标的数据治理流程工具，在华为云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进。

3 阿里云数据湖解决方案

阿里云上数据类产品众多，因为本人目前在数据 BU，所以本节方案将关注在如何使用数据库 BU 的产品来构建数据湖，其他云上产品会略有涉及。阿里云的基于数据库产品的数据湖解决方案更加聚焦，主打数据湖分析和联邦分析两个场景。阿里云数据湖解决方案如图 12 所示。

整个方案依然采用 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 和云原生数仓在以下两点上深度融合。

使用同源的 SQL 解析引擎。DLA 的 SQL 与 ADB 的 SQL 语法上完全兼容，这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。
都内置了对于 OSS 的访问支持。OSS 直接作为 DLA 的原生存储存在；对于 ADB 而言，可以通过外部表的能力，很方便的访问 OSS 上的结构化数据。借助外部表，数据可以自由的在 DLA 和 ADB 之间流转，做到真正的湖仓一体。

DLA+ADB 的组合真正做到了云原生的湖仓一体（关于什么是云原生，不在本文的讨论范畴）。本质上，DLA 可以看成一个能力扩展的数据仓库贴源层。与传统数仓相比，该贴源层：

可以保存各类结构化、半结构化和非结构化数据；
可以对接各类异构数据源；
具备元数据发现、管理、同步等能力；
内置的 SQL/Spark 计算引擎具备更强的数据处理能力，满足多样化的数据处理需求；
具备全量数据的全生命周期管理能力。基于 DLA+ADB 的湖仓一体化方案，将同时覆盖“大数据平台+数据仓库”的处理能力。

DLA 还有一个重要能力是构建了一个“四通八达”的数据流动体系，并以数据库的体验对外提供能力，无论数据在云上还是云下，无论数据在组织内部还是外部；借助数据湖，各个系统之间的数据不再存在壁垒，可以自由的流进流出；更重要的是，这种流动是受监管的，数据湖完整的记录了数据的流动情况。

4 Azure 数据湖解决方案

Azure 的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层，如图 15 所示（来自 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 之间的转化。