Adobe Experience Platform 使用 Delta Lake 进行海量数据处理
Adobe Experience Platform 使用 Delta Lake 进行海量数据处理
2023 年 3 月，Denny Lee 和 Adobe 高级工程经理 Yeshwanth Vijayakumar 讨论了 Adobe Experience Platform (AEP) 如何将数据湖仓一体架构与其实时客户档案架构相结合，以提高 Apache Spark™ 批处理工作负载的吞吐量并降低成本，同时通过 Delta Lake 保持功能。了解 Adobe 的统一档案团队如何使用 Apache Spark 和 Delta Lake 构建经济高效且可扩展的数据管道。
如果您想观看完整对话，请查看 YouTube 上的录音。
YouTube 视频：Adobe Experience Platform 使用 Delta Lake 进行海量数据处理
什么是 Adobe Experience Platform (AEP)？
用 Yeshwanth 的话来说，AEP 是一个有机构建的平台，专注于从各种客户那里摄取用户数据、市场数据、第一方数据和第二方数据。Adobe 的客户（公司）从多个来源获取其客户的数据，将其整合到单个统一且可集中访问的档案中，然后使用它为不同的受众创建体验。这些公司客户与他们的网站和营销系统的日常互动数据通过 Adobe 系统（特别是 AEP）流动。Yeshwanth 是其中一位负责人的统一档案团队负责摄取所有这些海量数据。
系统固有的问题
AEP 每天摄取数 TB 的数据，并作为统一档案产品的一部分为客户管理数 PB 的数据。其核心是复杂的数据摄取，包括规范化和非规范化数据，以及由中央身份图支持的各种链接场景。这有助于在电子邮件、广告等多个平台和渠道中激活的各种营销场景。
最初，AEP 的设置存在不少问题。当您加入一个已经成熟的团队或开始开发一个成熟的产品时，很多基础工作都已为您完成。但在 AEP 的案例中，一切都需要从头开始构建。最佳实践——甚至是基础设施的最佳实践——都必须制定出来。事实上，甚至尝试启动一个简单的 Spark 集群都非常困难。
AEP 主要运行在 Azure 上，而 Data Lake Gen1 的可伸缩性不如 Gen2。每一个点击、应用程序链接和其他操作都实时输入 AEP 系统。Adobe 的统一档案团队最初尝试使用 HDInsights 在 HBase 上建模所有这些数据，但它不稳定。然后他们转移到基于 Azure 的 HBase，这基本上是在他们自己的 VM 和 Azure Storage 上运行。当这也行不通时，他们转向了自己的托管 NoSQL 存储。最初这进展顺利，但成本极高。此外，由于需要实时事务操作，他们在尝试进行分析时遇到了问题。他们不得不在数据仓库解决方案之上进行构建，这导致了过多的延迟。
开发解决方案
Adobe 团队必须以相同的优先级处理两个相互竞争的需求：扫描查询访问计划“类似 Spark”的能力和支持 NoSQL 定点查询。他们旨在提供一流且率先上市的产品，因此他们不能简单地放弃其中任何一个，但同时他们也面临着快速找到解决方案的压力。他们愿意承担架构债务来实现这一目标，只要他们花的钱少于他们赚的钱。他们计划在过程中不断发展架构，但也希望确保内置足够的“逃生通道”，以便在可行时切换到不同的基础设施或架构。
主要里程碑
在迁移、移动或复制任何内容之前，他们选择强化现有系统。因此，AEP 统一平台团队的第一个里程碑是简化整个复制过程，这样他们就永远不必重建整个系统。为此，他们构建了一个自定义事件源系统，旨在馈送到下游系统，以及一个变更数据捕获 (CDC) 系统，以确保主存储中每次发生更改时，都会向其集中式 Kafka 主题发出更改通知。这意味着即使他们有数千个客户或数据库，所有通知都将馈送到一个“消防水带”。这将为下游系统提供更简单的迁移路径。
第二个里程碑是让依赖于热存储的实际工作负载通过这个自定义复制过程进行处理。这是一个很大的优势，因为它将范围缩小到一对一匹配。在迁移方面，如果您有十个不同的工作负载依赖于热存储，您不需要重写所有十个工作负载；相反，一个团队可以编写一个映射函数，确保其余作业认为它们正在与热存储通信。每个作业只关心它在管道顶部获得的模式；其余流程保持不变。为了实现这一点，当团队将具有特定模式的作业切换为使用 Delta Lake 作为源时，他们需要确保来自 Delta Lake 的数据与来自热存储的数据看起来完全相同，以减少摩擦。换句话说，热存储和 Delta Lake 需要与下游系统匹配，以便它们可以抽象出下游摄取并避免不必要的数据重写。
主要问题
虽然使用上述带有热存储的自定义复制系统找到了一种工程解决方案，但该系统成本过高。对于任何 NoSQL 存储，一旦您提高处理并发的能力，成本就会飙升。他们面临的第二个问题，由于数据量巨大，是数据混洗。他们必须在档案级别同化数据。例如，假设“Gloria”是一个档案，并且您有许多与此档案相关的事件。为了进行个性化过程，必须在做出任何决定之前将来自多个来源的数据组合起来；否则， resulting personalization will be incomplete，这将导致在下游系统中应用错误的逻辑。考虑到 AEP 中数百万的用户档案，所需的数据混洗将非常昂贵。
使用 Delta Lake 的好处
最初，热存储被复制到中央 Delta Lake。仅通过这种原始 Delta Lake 镜像，AEP 就能显著提高读取吞吐量。通过存储在 Delta Lake 中的数据，他们目前看到的数据压缩率是热存储中存储数据的 10-15 倍。他们通过更有效地使用核心，通过跨优化大小的分区并行查询来提高读取性能。通过使用 Delta Lake 的 CDC 功能 为下游系统提供通知，简化了用户档案的同化。得益于 Delta Lake，AEP 获得了所需的性能、压缩和统计数据，并能够更高效地进行复制。虽然团队仍然依赖 NoSQL 热存储的功能，但使用它的成本显著降低。
需要注意的是，在此场景中，从 A 到 B 的数据复制不仅仅是追加新数据。AEP 复制以插入、更新插入和删除的形式进行，这本身就可能成本高昂。Delta Lake ZORDER 在这里发挥了巨大作用，将处理时间从数小时缩短到数分钟。ZORDER 在 Delta Lake 2.0 中开源，打消了 AEP 性能依赖于专有功能的任何顾虑。
信息：Adobe 和社区的其他成员推动 Delta Lake 更快地开源像 ZORDER 这样的功能，以便所有人都能使用它们。这是客户和社区高度一致的完美示例！
Adobe 目前拥有超过 5,000 个活跃的 Delta 表，并且还在不断增加，这些表正在被多个下游系统利用。使用 Delta Lake 维护所有这些表实际上非常容易，因为只有一个维护作业负责协调清理、优化等。Delta Lake 通过简化其下游系统的操作，帮助 Adobe Experience Platform 解决了它面临的许多问题。