【.com快译】引言本文是DataPlatform-as-a-Service的后续研究，描述其高层数据湖描述于细节。架构重要的不是供应商或特定产品，而是我们使用的组件的功能。最终，产品的选择取决于许多因素：?团队的知识。?云服务的使用效率。?与我们现有产品集成的能力。?运营成本。自定义数据域引擎在这个例子中，我们设计了一个主要基于Azure服务的解决方案。同时，设计了一个架构，允许以敏捷的方式集成或迁移到其他云服务。云数据平台架构拥有一个不限制供应商的敏捷云数据平台取决于：?使用开源技术作为平台的核心。这使我们能够将我们的平台转移到另一个云提供商。?为数据的流式处理和批处理提供数据中心服务。?自动化数据管道使我们能够轻松地将数据移动到不同的数据存储库。?数据服务层与数据持久化引擎分离。数据模型（领域驱动设计）数据平台需要全局数据模型定义。目前很多企业，尤其是一些技术型公司，都会采用领域驱动设计（DomainDrivenDesign，DDD）的方法。关于数据域的一些重要事项如下：?数据域有两个视图，即生产者数据域和消费者数据域。通常，这些域是不同的，因为消费者的域由来自多个生产者域的数据组成。?特定数据可以有主域和辅助域。?数据域组织不是静态的。可以更改、合并、演变或删除。在数据域方面，一种常见的方法是遵循自下而上的设计。这意味着从生产者数据域开始，数据产品将被构建为自己的消费者。因此，数据平台需要为他们提供所有必要的工具、服务、支持、标准化流程和集成。将域从生产者出售给消费域是消费者数据域的一个非常常见的用例，并且非常复杂。什么是销售？在拥有多渠道订单（电子商务、社交媒体、实体店……）的大公司中，渠道和部门之间的销售概念略有不同。但它们由来自多个域的数据组成。销售领域因为每个团队可能有不同的数据产品，需要不同的数据、数据验证流程和指标。好像电商部和财务部的销售数据产品是一样的？这取决于许多因素。数据摄取模式众所周知，新数据平台最有价值的资源就是数据。数据上传有两种方式：?Pull：基于核心团队，集中管理，开发数据管道，将数据引入平台。?推送：在操作、架构和范例方面，这是最好的方法，但它取决于其他团队。例如，分销团队需要分析销售数据。拥有销售数据需要销售团队将数据推送到数据平台。就操作、体系结构和范例而言，遵循“推送”方法是一个很好的决定。根据企业架构的实际情况，我们必须提供“拉”功能，因为在很多公司中，往往有很多遗留系统或团队还没有准备好推送数据。在我们看来，提供“拉”服务的最佳方式是开发一个自动化的数据摄取引擎服务。什么是数据摄取引擎服务？数据摄取引擎服务是一个自助服务平台，只需要SQL语句和映射，不需要代码，并允许创建ETL流程和流处理。它的目标是通过提供多种风格来涵盖以下内容：?允许团队自己将数据推送到交换区域。?提供一个核心和集中的团队来为非技术团队上传数据。?提供自助服务平台，简化技术团队的数据摄取。如果我们对所有类型的数据摄取管道采用相同的方法，我们将拥有一组自动化的连接器，供团队推送他们的各种数据。例如：?更改数据捕获。?事件。?图像、文件等...这里的主要思想是通过构建产品所有者将来用于推送数据的通用组件，将不需要的“拉取策略”转变为“推送模型”。这会启用自动摄取层。批量数据流如图所示，我们必须提供所有工具和标准流程（摄取、数据质量等），以允许生产者自动将他们的数据推送到数据平台。这种自助服务可以是Web门户或GitOps解决方案。下面的文章将详细介绍如何开发摄取引擎。微服务架构：推送事件驱动的微服务架构是应用基于流的“推送策略”的最佳解决方案之一。这些架构遵循发布-订阅通信模式，通常基于持久消息系统，例如ApacheKafka。微服务架构模式该模式提供了一种可扩展且松散耦合的架构：?发布者向主题发送消息。?所有注册到该主题的订阅者都将收到此消息。事件生成一次，消费多次。?发布者和订阅者操作??可以彼此独立运行。它们之间没有依赖关系。我们可以提供一个标准的接受连接器来订阅这些主题并将事件实时摄取到数据平台中。这些架构在信息范围方面存在挑战，并且通常不涵盖：?这些持久性主题通常具有基于时间或大小的限制。在错误场景的情况下，重新处理更复杂。?重新发送历史数据的过程。?用于大规模场景的异步数据质量API。数据湖数据湖是分析、机器学习环境和存储原始数据的自然选择。数据湖是一个数据存储库，通常基于对象存储，它允许我们存储以下内容：?关系数据库中的结构化数据。?来自NoSQL或其他来源（CSV、XML、JSON）的半结构化数据。?非结构化和二进制数据（文档、视频、图像）。?目前，云存储服务已经有了很大的改进，提供了不同质量的服务，使我们能够：?为热点数据提供高性能和低延迟。?以更低的成本为冷热数据提供更大的存储容量和更高的延迟。作为云对象存储，我们选择了AzureDataLakeStorageGen2。这个对象存储提供了一些有趣的属性：?容量：它可以管理大量数据、PB级信息和千兆级吞吐量。?性能：针对分析用例进行了优化。?安全性：它允许对目录或单个文件进行POSIX权限。使用服务主体和OAuth2.0事件将AzureDataLakeStorageGen2文件系统装载到DBFS：它提供了一种服务，可以为执行的每个操作（例如文件创建和删除）自动生成一个事件。这些事件允许设计事件驱动的数据流。我们必须根据用户和用例做出多项决定：?提供对数据的只读访问。为所有用户提供单一数据存储库。?结构化和半结构化数据以列格式存储。?数据按业务数据域分区和存储，并分布在多个对象存储中。?提供HiveMetastore服务，通过使用外部表提供spark-SQL访问。这允许拥有数据的单个图像并将用户从数据的物理位置中抽象出来。MariaDB现在，我们可以使用我们管理的外部hivemetastore，一个开源版本，而不是具有集成限制的供应商管理的服务。这使我们可以自由地集成任何Spark环境，而不管由谁提供Spark平台环境（Databricks、Cloudera等）。Spark-SQL和HiveMetastoreSparkSQL为我们提供了一个分布式查询引擎，以更优化的方式使用结构化和半结构化数据，并使用类似于数据目录的HiveMetastore。使用SQL，我们可以从以下方面查询数据：?DataFrame和DatasetAPI。?外部工具，例如DatabricksNotebooks。它是一种用户友好的工具，有助于非技术用户使用数据。HiveMetastoreDataLakeasaService如果我们将到目前为止描述的所有部分放在一起，我们可以设计和构建一个数据湖平台：?数据摄取引擎负责摄取数据，在HiveMetastore中创建和管理元数据。?数据湖的核心由对象存储层和HiveMetastore组成。这是允许我们将计算层作为服务提供的两个主要组件。?计算层由集成到数据湖中的多个spark集群组成。这些集群允许使用spark作业、SQL分析或Databrick笔记本访问这些数据。数据湖即服务在我们看来，提供这种动态且可扩展的计算/服务层的能力使我们能够将数据湖平台作为服务提供，否则我们将拥有与传统本地数据湖更相似的东西。我们可以创建一个24x7永久集群，也可以创建临时集群来运行我们的作业。Spark集群是计算服务层的核心。它是我们将在数据湖平台中提供的服务目录的最小公约数。比如我们要为我们的数据产品团队提供沙盒分析服务。我们将为每个人创建一个隔离的计算环境，但所有人都可以访问相同的数据。为了将这些功能作为服务提供，我们需要：?定义构成基于Spark技术的沙箱分析的组件。?通过网络服务目录或代码方式(git-ops)提供自助服务功能。自助服务组件这是一个非常简化的视图，因为我们没有定义安全、高可用性或数据质量服务。三角洲湖提供什么？DeltaLake是一个开源层，提供ACID功能并确保读者永远不会看到不一致的数据。数据管道可以在不影响正在运行的spark进程的情况下刷新数据。数据管道还具有其他重要特性，例如：Schemaon-write：它在写入数据时强制执行模式检查，并在检测到模式不匹配时使作业失败。?SchemaEvolution：它支持兼容的模式演进，例如添加新列。?时间旅行：数据版本控制是机器学习用例中的一个重要特征。允许在代码中管理数据。作为代码存储库，用户可以对其数据进行版本控制，并且对于数据集的每次更改，都会在其整个生命周期中生成数据的新版本。?合并：支持复杂摄取场景的合并、更新和删除操作。数据湖的演变几年前，传统数据湖、数据仓库和数据中心之间的区别既有概念上的，也有技术上的。三者的区别在于，基于Hadoop、Spark、Parquet、Hive的数据湖技术有很多局限性。目前，DeltaLake和ApacheHudi等其他选项为数据湖生态系统增加了新功能。这些特性与解耦架构（计算层和存储层）、无服务器和其他新功能（例如来自数据库的SQL分析或Delta引擎）相结合，正在开发新一代数据湖平台。Databricks将这个新一代的LakeHouse命名为LakeHouse。在我们看来，新一代的成熟让数据湖发挥了两个新的作用：?数据中心。数据中心?数据仓库详细信息和缩减概要。DataWarehouse数据仓库的能力已经提升了很多，但此时，它仍然需要高水平的技术知识来分发数据，并达到与其他产品如Snowflake、Bigquery或OracleAutonomousDataWarehouse相同的性能。结语结合Kafka等事件中心，新一代数据湖成为我们数据平台的核心是一个不错的选择。它是一项成熟的技术，主要基于开源，在性价比方面非常有竞争力，不断发展，我们可以在所有云提供商中提供它。【翻译稿件，合作网站转载请注明原译者和出处.com】
