Stream Processing (2) - Chande Data Capture

保持同步

资料工程师修炼之路走到现在，真的没有一个系统能同足满足资料储存、查询和逻辑处理，现实世界的应用程序都是由多个不同的系统组件搭建起来；举例来说我们会使用 OLTP 资料库来服务客户，使用快取系统帮 request 加速，使用文字检索搜寻引擎处理搜寻需求，最後使用资料仓储做 OLAP，每一个系统组件都为了特地目的而优化。

当你的应用程序需要因应事件发生，需要同步资料到所有系统组件上时该怎麽做呢？

资料仓储的同步一般都是使用 ETL，取得资料库的复制并转换，也就是批次处理 (Day 23)。

如果预期资料库的 dump 很慢，我们的另一个选择就是使用 双重写入 (dual writes) ：当资料改变时同时写到所有系统组件中。举例来说就是当资料库第一次被写入时，同时更新搜寻引擎索引、快取和其他系统组件。

然而双重写入可能会发生如下图 11-4 的 竞争条件 (race condition) 写入：2 个 Client 并发的更新资料库和索引，因为网路或其他理由的时间差，最终导致 2 边的值不一致。

除非你在这 2 个系统间额外实做并发写入检测机制 (2020 Day 26 - Detecting Concurrent Writes)，否则你根本不会知道并发写入发生。

另一个双重写入的问题是可能会有部份写入成功，也是导致 2 边的值不一致，想当然尔，面对这种 atomic commit 问题还是有方法可以解，但在多个系统上实做的代价很昂贵 (可参考 Day 20 - Atomic Commit and Two-Phase Commit 的介绍)。

Change Data Capture

变更资料补获 (change data capture - CDC) 是一个能观察资料写入至资料库并提取它们让其他系统能复制的过程。

如下图 11-5，CDC 能补获所有资料库的变更，并写入到一个 log 里，其他的系统组件担任消费者的角色，以 相同顺序 取得资料，我们称这些 log 消费者为 衍生数据系统 (derived data systems) 。

实现变更资料补获

衍生数据系统视为资料的多种不同的面向，CDC 机制能确保所有的变更能如实的反应在衍生数据系统上。

至於实现 CDC 的一个好选择就是用 基於 log 的讯息代理 (log-based message broker) 啦！它很适合从源头资料库传递变更并保留讯息的顺序。

写 2 期的 资料工程师修炼之路 结束罗！

感谢 Designing Data-Intensive Applications 书中的精采内容才会有这些文章产生，可以的话还是拜读原文吧！这系列文只是我挑选个人觉得重要的部份来分享，更何况我的文笔也没有这麽好 XD

希望工程师们能从系统文了解一些常用工具的黑科技，跟这本书一样，也希望能帮助工程师建立符合 Reliable、Scalable 和 Maintainable 的系统。

拜啦！