为了说明为什么Debezium和Delta Lake是一个有趣的组合，尤其是对于涉及微服务应用程序和大数据的用例，我将分享我最近遇到的一个故事。
客户的用例
我们的一位客户通过以下故事与我联系：
- 该公司正在开发微服务应用程序
- 他们的每个客户都在运行它自己的应用程序实例以及它自己的数据库
- 他们希望捕获所有应用程序实例（所有客户）中的数据更改，以更新中央数据湖，该数据湖包含最新数据库状态的复制。
- 然后，他们想使用数据湖进行汇总和分析
他们尝试的一个简单的解决方案是维护“ last_updated”时间戳列，并定期提取自上次提取时间戳以来的所有更改。这种方法有几个缺点：
- 如果开发人员不更新“ last_updated”列，则更改不会到达
- 拉取过程不是容错的-例如，在发生网络错误时，它不知道从中断处取回
- 应用程序开销–他们必须在应用程序核心之上维护其他代码，以管理此任务
什么是Debezium？
Debezium是用于捕获变更数据的开源分布式平台。启动它，将其指向您的数据库，您的应用程序可以开始响应其他应用程序提交给数据库的所有插入，更新和删除操作。Debezium持久且快速，因此即使出现问题，您的应用程序也可以快速响应，并且不会错过任何事件。
由于Debezium负责读取数据库日志：
- 我们不再依赖开发人员更新特定列-Debezium负责捕获每个更改的行
- 无需额外的代码
- 使用消息时的容错能力
Debezium也可以读取Kafka日志中记录数据更改的历史记录，您的应用程序将可以使用这些历史记录。这使您的应用程序可以轻松，正确，完整地使用所有事件。即使您的应用程序停止（或崩溃），在重新启动时，它也会开始使用中断处的事件，因此不会丢失任何内容。
描述更改的数据的JSON消息一些有趣的字段：
- “ op”：操作码（c —创建，u —更新，d —删除，r —首次读取）
- “before”：更改之前的行
- “after”：更改后的行
- “source”：包含有关更改来源的服务器，数据库和表的一些有用信息
高级策略概述
- Debezium读取数据库日志，生成描述更改的json消息并将其流式传输到Kafka
- Kafka传输消息并将其存储在S3文件夹中。我们称其为青铜Bronze表，因为它存储原始消息
- 通过将Spark与Delta Lake结合使用，我们可以将消息转换为INSERT，UPDATE和DELETE操作，然后在目标数据Lake表上运行它们。该表保存所有源数据库的最新状态。我们称它为银表
- 接下来，我们可以在Silver表上执行进一步的汇总以进行分析。我们称它为金表
对于Tikal的黑客马拉松，我们组建了一个团队，在一天之内建立示例端对端项目，以演示上述流程：
可以在我们的GitHub存储库中找到代码以及更多详细信息
局限性
在使用Debezium和Delta Lake之前，请考虑以下限制和未解决的问题：
- 视图/表联接：Debezium没有这种概念。它知道如何捕获单个表中的更改，但是如果您不付出额外的努力，就无法告诉“如果此表发生更改-捕获整个连接的视图”
- 继续流式传输：Delta Lake 对流式传输的支持仅限于微型批处理流。由于它正在处理文件，因此不支持实时连续流
总结
- 我们看到了一个客户的用例，涉及在微服务应用程序和大数据环境中更改了数据捕获
- 我们看到了组装这样的管道的一些挑战
- 我们看到了Debezium和Delta Lake如何应对这些挑战
- 我们看到了用Debezium-Delta Lake组合组装管道的高级策略
- 我们看到了端到端管道的示例