数据湖（三）

各厂商的数据湖解决方案

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

一、 AWS数据湖解决方案

图7. 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查询的数据。虽然当前各类材料都在强调数据湖与数据仓库的不同；但是，从本质上，数据湖更应该是一类融合的数据管理思想的具体实现，“湖仓一体化”也很可能是未来的一个发展趋势。

图8. AWS数据湖解决方案权限分离示意

综上，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。

图9. AWS 数据湖解决方案在参考架构中的映射

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

二、华为数据湖解决方案

图10.华为数据湖解决方案
华为的数据湖解决方案相关信息来自华为官网。目前官网可见的相关产品包括数据湖探索（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（数据接入服务）对接：1）借助DIS，DLI可以定义各类数据点，这些点可以在Flink作业中被使用，做为source或者sink；2）借助CDM，DLI甚至能接入IDC、第三方云服务的数据。

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

图11 DAYU数据治理方法论流程

可以看到，本质上DAYU数据治理的方法论其实是传统数据仓库治理方法论在数据湖基础设施上的延伸：从数据模型来看，依然包括贴源层、多源整合层、明细数据层，这点与数据仓库完全一致。根据数据模型和指标模型会生成质量规则和转换模型，DAYU会和DLI对接，直接调用DLI提供的相关数据处理服务，完成数据治理。华为云整个的数据湖解决方案，完整覆盖了数据处理的生命周期，并且明确支持了数据治理，并提供了基于模型和指标的数据治理流程工具，在华为云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进。

三、 阿里云数据湖解决方案

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

图12. 阿里云数据湖解决方案

整个方案依然采用OSS作为数据湖的集中存储。在数据源的支持上，目前也支持所有的阿里云数据库，包括OLTP、OLAP和NoSQL等各类数据库。核心关键点如下：

1） 数据接入与搬迁。在建湖过程中，DLA的Formation组件具备元数据发现和一键建湖的能力，在本文写作之时，目前“一键建湖”还只支持全量建湖，但是基于binlog的增量建湖已经在开发中了，预计近期上线。增量建湖能力会极大的增加数据湖中数据的实时性，并将对源端业务数据库的压力降到最下。这里需要注意的是，DLA Formation是一个内部组件，对外并没有暴露。

2） 数据资源目录。DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理，无论数据是在“湖中”还是在“湖外”。Meta data catalog也是联邦分析的统一元数据入口。

3） 在内置计算引擎上，DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎，都和Meta data catalog深度集成，能方便的获取元数据信息。基于Spark的能力，DLA解决方案支持批处理、流计算和机器学习等计算模式。

4） 在外围生态上，除了支持各类异构数据源做数据接入与汇聚之外，在对外访问能力上，DLA与云原生数据仓库（原ADB）深度整合。一方面，DLA处理的结果可之际推送至ADB中，满足实时、交互式、ad hoc复杂查询；另一方面，ADB里的数据也可以借助外表功能，很方便的进行数据回流至OSS中。基于DLA，阿里云上各类异构数据源可以完全被打通，数据自由流动。

5） 在数据集成和开发上，阿里云的数据湖解决方案提供两种选择：一种是采用dataworks完成；另一种是采用DMS来完成。无论是选择哪种，都能对外提供可视化的流程编排、任务调度、任务管理能力。在数据生命周期管理上，dataworks的数据地图能力相对更加成熟。

6） 在数据管理和数据安全上，DMS提供了强大的能力。DMS的数据管理粒度分为“库-表-列-行”，完善的支持企业级的数据安全管控需求。除了权限管理之外，DMS更精细的地方是把原来基于数据库的devops理念扩展到了数据湖，使得数据湖的运维、开发更加精细化。

进一步细化整个数据湖方案的数据应用架构，如下图所示。

图13. 阿里云数据湖数据应用架构

自左向右从数据的流向来看，数据生产者产生各类数据（云下/云上/其他云），利用各类工具，上传至各类通用/标准数据源，包括OSS/HDFS/DB等。针对各类数据源，DLA通过数据发现、数据接入、数据迁移等能力，完整建湖操作。对于“入湖”的数据，DLA提供基于SQL和Spark的数据处理能力，并可以基于Dataworks/DMS，对外提供可视化的数据集成和数据开发能力；在对外应用服务能力上，DLA提供标准化的JDBC接口，可以直接对接各类报表工具、大屏展示功能等。阿里云的DLA的特色在于背靠整个阿里云数据库生态，包括OLTP、OLAP、NoSQL等各类数据库，对外提供基于SQL的数据处理能力，对于传统企业基于数据库的开发技术栈而言，转型成本相对较低，学习曲线比较平缓。

阿里云的DLA解决方案的另一个特色在于“基于云原生的湖仓一体化”。传统的企业级数据仓库在大数据时代的今天，在各类报表应用上依然是无法替代的；但是数仓无法满足大数据时代的数据分析处理的灵活性需求；因此，我们推荐数据仓库应该作为数据湖的上层应用存在：即数据湖是原始业务数据在一个企业/组织中唯一官方数据存储地；数据湖根据各类业务应用需求，将原始数据进行加工处理，形成可再次利用的中间结果；当中间结果的数据模式（Schema）相对固定后，DLA可以将中间结果推送至数据仓库，供企业/组织开展基于数仓的业务应用。阿里云在提供DLA的同时，还提供了云原生数仓（原ADB），DLA和云原生数仓在以下两点上深度融合。
1） 使用同源的SQL解析引擎。DLA的SQL与ADB的SQL语法上完全兼容，这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。
2） 都内置了对于OSS的访问支持。OSS直接作为DLA的原生存储存在；对于ADB而言，可以通过外部表的能力，很方便的访问OSS上的结构化数据。借助外部表，数据可以自由的在DLA和ADB之间流转，做到真正的湖仓一体。

DLA+ADB的组合真正做到了云原生的湖仓一体（关于什么是云原生，不在本文的讨论范畴）。本质上，DLA可以看成一个能力扩展的数据仓库贴源层。与传统数仓相比，该贴源层：（1）可以保存各类结构化、半结构化和非结构化数据；（2）可以对接各类异构数据源；（3）具备元数据发现、管理、同步等能力；（4）内置的SQL/Spark计算引擎具备更强的数据处理能力，满足多样化的数据处理需求；（5）具备全量数据的全生命周期管理能力。基于DLA+ADB的湖仓一体化方案，将同时覆盖“大数据平台+数据仓库”的处理能力。

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

四、 Azure数据湖解决方案

Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层，如图15所示（来自Azure官网）。存储层是基于Azure object Storage构建的，依然是对结构化、半结构化和非结构化数据提供支撑。接口层为WebHDFS，比较特别的是在Azure object Storage实现了HDFS的接口，Azure把这个能力称为“数据湖存储上的多协议存取”。在资源调度上，Azure基于YARN实现。计算引擎上，Azure提供了U-SQL、hadoop和Spark等多种处理引擎。

图15. Azure Data lake analysis 架构

Azure的特别之处是基于visual studio提供给了客户开发的支持。

1）开发工具的支持，与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进行扩展，满足定制开发需求。

2）多计算引擎的适配： SQL, Apache Hadoop和Apache Spark。这里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服务），Spark包括Azure Databricks。

3）多种不同引擎任务之间的自动转换能力。微软推荐U-SQL为数据湖的缺省开发工具，并提供各类转换工具，支持U-SQL脚本与Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之间的转化。

五、小结

本文所讨论的是数据湖的解决方案，不会涉及到任何云厂商的单个产品。我们从数据接入、数据存储、数据计算、数据管理、应用生态几个方面，简单做了一个类似下表的总结。

出于篇幅关系，其实知名云厂商的数据湖解决方案还有谷歌和腾讯的。这两家从其官方网站上看，数据湖解决方案相对来讲比较简单，也仅仅是一些概念上的阐述，推荐的落地方案是“oss+hadoop（EMR）”。其实数据湖不应该从一个简单的技术平台视角来看，实现数据湖的方式也多种多样，评价一个数据湖解决方案是否成熟，关键应该看其提供的数据管理能力，具体包括但不限于元数据、数据资产目录、数据源、数据处理任务、数据生命周期、数据治理、权限管理等；以及与外围生态的对接打通能力。