【51CTO.com快译】一提到企业数据平台，人们往往想到的是各种数据目录结构、数据质量监控、CI/CD、以及数据民主公众化(Data Democratization，即：提供数据查询的公共渠道)等方面。它们在满足用户的多元化需求与体验的同时，不断通过合理的架构、以及高效的分拣手段，来持续提高其自身的质量和使用价值。不过，我们在数据获取、过滤、以及分析环节，往往会受到因素的限制：
- 团队成员的知识储备。
- 在云服务中的使用效率。
- 与现有业务和产品的集成度。
- 总体处置的成本。
自定义的数据获取引擎
基于上述考虑，企业在搭建与集成数据平台时，往往会以开源技术作为平台的核心，以流式和批处理的方式提供数据服务，并试图将数据服务层与数据持久化引擎进行解耦。当然，他们也可以一股脑地将这些任务交给诸如：BigQuery、Redshift、以及Snowflake等增值服务提供商、及其特定产品来实现。
数据平台架构的示例
数据模型(域驱动设计)
说到数据平台，它往往需要全局性的数据模型定义。目前，许多企业、特别是一些技术类型的公司，都会采用域驱动设计(Domain Driven Design，DDD)的方法。该方法通常会涉及到如下方面：
- 生产者(producers)和消费者(consumers)。其中，消费者域是由来自多个生产者域的数据组合而成。
- 特定的数据可以拥有一个主域和一个辅域。
- 数据域的组织结构并非一成不变，可能会出现更改、合并、演化、以及移除。
在数据域处置方面，我们常用的方法是遵循自底向上的设计原则。这意味着：从生产者的数据域开始，数据产品将被视为自己的消费者进行构建。因此，数据平台需要为它们提供所有必要的工具、服务、支持、标准化流程、以及集成。
从生产者域到消费者域(数据即产品)
销售域是消费者数据域的一个极其常见的例子，当然也是非常复杂的。在那些拥有多渠道订单(如：电子商务、社交媒体、实体店等)的大公司中，渠道和部门之间有关销售的概念虽然略有不同，但是它往往是由那些来自多个域的数据所组成。
销售域
例如：由于每个团队所需要的数据、数据的验证过程、以及衡量指标有所不同，因此电商部门和财务部门的销售数据产品就可能不一样。如果您对该专题感兴趣的话，请参阅有关Data Mesh范例的文章。
数据的获取模式
众所周知，数据平台最具价值的资源便是数据。同时，数据也是最为复杂的。我们通常有两种上传数据的方式：
- 拉式(Pull)：核心团队基于集中式的管理，通过开发数据管道，将数据引入平台中。不过，由于最初鲜少有与其他团队的依赖关系，因此该方法比较有效;但是到了后期，则可能陷入瓶颈。
- 推式(Push)：它对于运营、架构和范式来说是绝好的方法，但不一定适合其他团队。例如，分销团队在分析销售数据时，需要销售团队将他们的数据推送到数据平台中。而由于销售团队业务繁忙，而且这并不是他们的首要任务，因此分销团队可能会等待较长的时间。
可见，“推式”方法虽好，但是许多公司往往有着各种遗留下来的系统，以至于团队无法及时准备好适合推送的数据。而通过提供“拉式”方法，我们则可以开发自动化的数据获取引擎服务。
什么是数据获取引擎服务(Data Ingestion Engine Service)?
总的说来，它是一个无需代码，只需各种SQL语句和映射，即可创建ETL流程和数据流程的自助服务平台。其目标是通过提供多种风格，来涵盖如下方面：
- 允许团队自行将数据推送到交换区。
- 提供一个集中式的核心团队，为非技术团队上传数据。
- 通过提供自助服务平台，来简化技术团队的数据获取过程。
如果我们对所有类型的数据获取管道，都采取相同的方法，将会拥有一整套自动化的连接器，可方便团队推送他们的各种数据。例如：变更数据的捕获，各类事件、镜像、以及文件等。也就是说，通过为产品所有者构建可用于数据推送的通用组件，我们将能够实现自动化的获取层。
批处理的数据流
如上图所示，我们必须提供各种工具和标准化的流程(包括：数据获取与质量控制等)，以允许生产者将他们的数据，通过Web门户或GitOps等自动化的方式，推送到数据平台上。
下面，我们将重点讨论如何开发一个获取引擎。
微服务架构之推送
事件驱动型的微服务架构，是被应用到基于数据流的“推送策略(Push Strategy)”的最佳场景之一。此类架构通常是基于诸如Apache Kafka等持久性的消息传递系统，并遵循的是“发布-订阅(publish-subscribe)”的通信模式。
微服务架构模式
如上图所示，这种模式提供了一种可扩展的、松散耦合的架构，即：
- 发布者向主题(topic)发送一条消息。
- 所有已注册该主题的订阅者都会收到此消息，也就实现了：事件被一次产生，多次消费的效果。
- 由于发布者和订阅者之间并无依赖关系，因此他们的操作可以彼此独立。
我们可以通过提供标准化的获取连接器，来订阅此类主题，并将各种事件以近乎实时的方式，获取到我们的数据平台。当然，此类架构在信息范围方面会存在着如下缺陷：
- 由于持久性主题通常具有基于时间或大小的限制，因此在出现错误时，其重新处理的过程较为复杂。
- 不具备重新发送历史数据的流程。
- 不提供针对各种海量场景的异步数据质量性API。
数据湖(Data Lake)
在存储与分析原始数据，以及机器学习环境中，也就产生了数据湖的概念。它是一种基于对象存储的数据存储库，能够方便我们进行如下存储：
- 来自关系型数据库的结构化数据。
- 来自NoSQL或其他来源(如：CSV、XML、JSON等)的半结构化数据。
- 非结构化数据和二进制数据(如：文档、视频、图像等)。
目前，云存储服务既能够为频繁调用的数据提供高性能与低延迟的处理能力，又能够为非频繁调用的数据提供低成本的大容量存储空间。因此，我们可以通过选用Azure Data Lake Storage Gen2，来为云对象的存储提供如下功能：
- 卷：可以管理海量数据、PB级信息、以及千兆位(gigabits)的吞吐量。
- 性能：针对各种待分析的用例进行优化。
- 安全性：允许对目录或单个文件设置POSIX(可移植操作系统接口，Portable Operating System Interface)权限。即：使用服务主体和OAuth2.0，将Azure Data Lake Storage Gen2的文件系统挂载到DBFS(数据库文件系统)上。
- 事件：作为一种服务，可以为每个执行操作(如：创建和删除文件)自动生成一个事件。通过这些事件，我们可以设计事件驱动的数据流程。
我们需要根据用户的实际需求和用例做到：
- 提供对于数据的只读访问权限，以便让数据湖成为所有用户的数据来源，以及单一的数据存储库。
- 结构化数据和半结构化数据能够通过诸如Delta Lake的存储库，以列的格式存储。
- 让数据能够按照业务域进行分区存储，并分布在多个对象存储中。
- 提供Hive的Metastore服务，并通过使用各种外部表提供spark-SQL的访问。这将允许用户从数据的物理位置中抽象出来，并拥有数据的单独镜像。
Spark-SQL流经MariaDB
如上图所示，我们可以使用外部开源版本的Hive Metastore，而非具有集成限制的供应商管理服务，来自由地集成任何Spark平台环境(如：Databricks、Cloudera等)。
Spark-SQL和HiveMetastore
Spark-SQL为我们提供了一个分布式的查询引擎，以方便我们以更为优化的方式使用结构化与半结构化数据，并使用类似于数据目录的Hive Metastore。通过SQL，我们可以从如下位置查询到数据：
- 数据帧和数据集API。
- 外部工具，如Databricks Notebooks便是一个用户友好的工具。它能够协助非技术用户去消费数据。
Spark-SQL和HiveMetastore的流程
数据湖即服务(Data Lake as a Service)
基于上述理论与知识基础，我们可以设计和构建出具有如下特征的数据湖平台：
- 其数据获取引擎负责获取数据，创建和管理在Hive Metastore的元数据。
- 其核心是由对象存储层和Hive Metastore两个主要组件构成，它们提供了计算层即服务(compute layer as a service)。
- 其中的计算层是由集成到数据湖中的多个Sparks群集组成。它们通过各种Spark作业、SQLAnalytics或Databrick Notebook来访问数据。
数据湖即服务的架构
数据湖平台即服务是一种动态且可扩展的计算与服务层能力。其中，作为核心的Spark集群是数据湖平台的最小服务目录。我们既可以创建一个7x24的永久性集群，又可以创建一个临时的工作集群。例如，若想为数据产品团队提供沙盒分析服务，我们可以为每个成员都创建一个包含有相同数据，但彼此隔离的计算环境。对此，我们需要实现：
- 根据Spark技术，来定义组成沙箱分析的组件。
- 通过Web服务目录、或代码方式(如git-ops)，提供自助式的服务功能。
自助式的服务层
当然，上图只是一个非常简单化的视图，其中并没有定义安全性、高可用性、以及数据质量的相关服务。
数据湖能够提供什么?
如下图所示，作为一个开源层，数据湖提供了ACID功能，并确保用户能够看到一致性的数据。各种数据管道可以被用来刷新数据，但不会影响正在运行中的Spark过程。
ACID：原子性、一致性、隔离性、持久性
其他重要的功能还包括：
- Schemaon-write：它在写入数据时强制执行模式检查，如果检测到模式不匹配，则返回作业失败。
- SchemaEvolution：它支持诸如添加新的列等，针对兼容性方案的模式进化。
- Time travel：数据版本控制可方便我们将数据作为代码进行管理。在代码存储库中，用户能够让数据集的每次更改，都会在其整个生命周期中生成新的数据版本。
- Merge：支持合并、更新和删除操作，以实现复杂的数据获取场景。
数据湖的进化
如下图所示，传统的数据湖、数据仓库、以及数据中心(Hub)之间有着概念性和技术性的区别。
数据湖、数据中心、数据仓库图表
Apache Hudi为传统的、基于Hadoop、Spark、Parquet、Hive等数据湖技术生态，添加了新的实用功能。其中包括：将计算和存储层进行架构上的解耦、无服务器化、SQL分析、Delta Engine、以及Databricks等新一代的数据湖平台。而根据Databricks的理论，Lake House可以被理解为新一代、更为成熟的数据湖。它包含了如下两个部分：
数据中心流程图
- 用于特定或简化场景的数据仓库
数据仓库流程图
目前，随着数据仓库的能力得到了大幅提升，诸如Snowflake、Bigquery、以及Oracle Autonomous Data Warehouse等技术产品，在数据分发等方面都表现出了不俗的性能。
小结
总的说来，结合了Kafka等事件中心的新一代数据湖，是我们构建数据平台核心的优先选择。它作为一项成熟的技术，不但开源、持续进化，而且具有极具竞争力的性价比。我们可以将其部署到各种云端服务环境中，以更好地发掘数据的价值。
原文标题：Data Platform: The New Generation Data Lakes，作者：Miguel Garcia和Albert Palau
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
