一提到企业数据平台，人们往往想到的是各种数据目录结构、数据质量监控、CI/CD、以及数据民主公众化(DataDemocratization，即：提供数据查询的公共渠道)等方面。它们在满足用户的多元化需求与体验的同时，不断通过合理的架构、以及高效的分拣手段，来持续提高其自身的质量和使用价值。不过，我们在数据获取、过滤、以及分析环节，往往会受到因素的限制：
团队成员的知识储备。
在云服务中的使用效率。
与现有业务和产品的集成度。
总体处置的成本。
自定义的数据获取引擎
基于上述考虑，企业在搭建与集成数据平台时，往往会以开源技术作为平台的核心，以流式和批处理的方式提供数据服务，并试图将数据服务层与数据持久化引擎进行解耦。当然，他们也可以一股脑地将这些任务交给诸如：BigQuery、Redshift、以及Snowflake等增值服务提供商、及其特定产品来实现。
数据平台架构的示例
数据模型(域驱动设计)
说到数据平台，它往往需要全局性的数据模型定义。目前，许多企业、特别是一些技术类型的公司，都会采用域驱动设计(DomainDrivenDesign，DDD)的方法。该方法通常会涉及到如下方面：
生产者(producers)和消费者(consumers)。其中，消费者域是由来自多个生产者域的数据组合而成。
特定的数据可以拥有一个主域和一个辅域。
数据域的组织结构并非一成不变，可能会出现更改、合并、演化、以及移除。
在数据域处置方面，我们常用的方法是遵循自底向上的设计原则。这意味着：从生产者的数据域开始，数据产品将被视为自己的消费者进行构建。因此，数据平台需要为它们提供所有必要的工具、服务、支持、标准化流程、以及集成。
从生产者域到消费者域(数据即产品)
销售域是消费者数据域的一个极其常见的例子，当然也是非常复杂的。在那些拥有多渠道订单(如：电子商务、社交媒体、实体店等)的大公司中，渠道和部门之间有关销售的概念虽然略有不同，但是它往往是由那些来自多个域的数据所组成。
销售域
例如：由于每个团队所需要的数据、数据的验证过程、以及衡量指标有所不同，因此电商部门和财务部门的销售数据产品就可能不一样。
数据的获取模式
众所周知，数据平台最具价值的资源便是数据。同时，数据也是最为复杂的。我们通常有两种上传数据的方式：
拉式(Pull)：核心团队基于集中式的管理，通过开发数据管道，将数据引入平台中。不过，由于最初鲜少有与其他团队的依赖关系，因此该方法比较有效;但是到了后期，则可能陷入瓶颈。
推式(Push)：它对于运营、架构和范式来说是绝好的方法，但不一定适合其他团队。例如，分销团队在分析销售数据时，需要销售团队将他们的数据推送到数据平台中。而由于销售团队业务繁忙，而且这并不是他们的首要任务，因此分销团队可能会等待较长的时间。
可见，“推式”方法虽好，但是许多公司往往有着各种遗留下来的系统，以至于团队无法及时准备好适合推送的数据。而通过提供“拉式”方法，我们则可以开发自动化的数据获取引擎服务。
什么是数据获取引擎服务(DataIngestionEngineService)?
总的说来，它是一个无需代码，只需各种SQL语句和映射，即可创建ETL流程和数据流程的自助服务平台。其目标是通过提供多种风格，来涵盖如下方面：
允许团队自行将数据推送到交换区。
提供一个集中式的核心团队，为非技术团队上传数据。
通过提供自助服务平台，来简化技术团队的数据获取过程。
如果我们对所有类型的数据获取管道，都采取相同的方法，将会拥有一整套自动化的连接器，可方便团队推送他们的各种数据。例如：变更数据的捕获，各类事件、镜像、以及文件等。也就是说，通过为产品所有者构建可用于数据推送的通用组件，我们将能够实现自动化的获取层。
批处理的数据流
如上图所示，我们必须提供各种工具和标准化的流程(包括：数据获取与质量控制等)，以允许生产者将他们的数据，通过Web门户或GitOps等自动化的方式，推送到数据平台上。
下面，我们将重点讨论如何开发一个获取引擎。
微服务架构之推送
事件驱动型的微服务架构，是被应用到基于数据流的“推送策略(PushStrategy)”的最佳场景之一。此类架构通常是基于诸如ApacheKafka等持久性的消息传递系统，并遵循的是“发布-订阅(publish-subscribe)”的通信模式。
微服务架构模式
如上图所示，这种模式提供了一种可扩展的、松散耦合的架构，即：
发布者向主题(topic)发送一条消息。
所有已注册该主题的订阅者都会收到此消息，也就实现了：事件被一次产生，多次消费的效果。
由于发布者和订阅者之间并无依赖关系，因此他们的操作可以彼此独立。
我们可以通过提供标准化的获取连接器，来订阅此类主题，并将各种事件以近乎实时的方式，获取到我们的数据平台。当然，此类架构在信息范围方面会存在着如下缺陷：
由于持久性主题通常具有基于时间或大小的限制，因此在出现错误时，其重新处理的过程较为复杂。
不具备重新发送历史数据的流程。
不提供针对各种海量场景的异步数据质量性API。
数据湖(DataLake)
在存储与分析原始数据，以及机器学习环境中，也就产生了数据湖的概念。它是一种基于对象存储的数据存储库，能够方便我们进行如下存储：
来自关系型数据库的结构化数据。
来自NoSQL或其他来源(如：CSV、XML、JSON等)的半结构化数据。
非结构化数据和二进制数据(如：文档、视频、图像等)。
目前，云存储服务既能够为频繁调用的数据提供高性能与低延迟的处理能力，又能够为非频繁调用的数据提供低成本的大容量存储空间。因此，我们可以通过选用AzureDataLakeStorageGen2，来为云对象的存储提供如下功能：
卷：可以管理海量数据、PB级信息、以及千兆位(gigabits)的吞吐量。
性能：针对各种待分析的用例进行优化。
安全性：允许对目录或单个文件设置POSIX(可移植操作系统接口，PortableOperatingSystemInterface)权限。即：使用服务主体和OAuth2.0，将AzureDataLakeStorageGen2的文件系统挂载到DBFS(数据库文件系统)上。
事件：作为一种服务，可以为每个执行操作(如：创建和删除文件)自动生成一个事件。通过这些事件，我们可以设计事件驱动的数据流程。
我们需要根据用户的实际需求和用例做到：
提供对于数据的只读访问权限，以便让数据湖成为所有用户的数据来源，以及单一的数据存储库。
结构化数据和半结构化数据能够通过诸如DeltaLake的存储库，以列的格式存储。
让数据能够按照业务域进行分区存储，并分布在多个对象存储中。
提供Hive的Metastore服务，并通过使用各种外部表提供spark-SQL的访问。这将允许用户从数据的物理位置中抽象出来，并拥有数据的单独镜像。
Spark-SQL流经MariaDB
如上图所示，我们可以使用外部开源版本的HiveMetastore，而非具有集成限制的供应商管理服务，来自由地集成任何Spark平台环境(如：Databricks、Cloudera等)。
Spark-SQL和HiveMetastore
Spark-SQL为我们提供了一个分布式的查询引擎，以方便我们以更为优化的方式使用结构化与半结构化数据，并使用类似于数据目录的HiveMetastore。通过SQL，我们可以从如下位置查询到数据：
数据帧和数据集API。
外部工具，如DatabricksNotebooks便是一个用户友好的工具。它能够协助非技术用户去消费数据。
Spark-SQL和HiveMetastore的流程
数据湖即服务(DataLakeasaService)
基于上述理论与知识基础，我们可以设计和构建出具有如下特征的数据湖平台：
其数据获取引擎负责获取数据，创建和管理在HiveMetastore的元数据。
其核心是由对象存储层和HiveMetastore两个主要组件构成，它们提供了计算层即服务(
转载请注明：http://www.0431gb208.com/sjszlfa/7268.html
