リアルタイム分析システムの構築

第7章. 変更データキャプチャで製品の変更を取得する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

AATDの演算子は現在、注文数と事業の収益についてしっかりとした概要を把握することができる。欠けているのは、製品レベルで何が起きているのかがわからないことだ。事業の他の部分からの苦情によると、注文が急増している商品もあれば、在庫が多すぎる商品もあるという。

現在、個々の商品に関するデータはMySQLデータベースに保存されているが、それをリアルタイム分析アーキテクチャに取り込む必要がある。 この章では、変更データキャプチャ（CDC）と呼ばれるテクニックを使って、これを行う方法を学ぶ。

演算子データベースからの変更点の取得

ビジネスでは、 トランザクションを演算子、つまりOLTP データベースに記録することが多い。しかし、どのように分析すればよいのだろうか。

従来、ETLパイプラインは、演算子データベースからデータウェアハウスのような分析用データベースにデータを移動するために使用されてきた。 これらのパイプラインは定期的に実行され、ソースデータベースから大量のバッチでデータを抽出した後、分析用データベースにロードする前にデータを変換していた。

この古典的なアプローチの問題点は、データ収集から意思決定までの遅延が大きいことであった。 例えば、典型的なバッチパイプラインでは、オペレーションデータから洞察を得るまでに数分、数時間、数日を要する。

もし、ソース・データベースに加えられた変更を、その都度リアルタイムで捕捉する仕組みがあるとしたらどうだろう？ CDCテクノロジーの出番である。

変更データの取得

このセクションでは、CDCを定義し、なぜそれが必要なのかを説明し、それを実現するためのテクニックを説明する。 最後に、CDCツールのデファクトスタンダードとして登場したDebeziumについて説明する。

なぜCDCが必要なのか？

アプリケーションを構築し始めた当初は、、すべてのデータニーズに対して単一のデータベースを使用することで済ませられることが多い。しかし、アプリケーションが進化するにつれて、異なるデータアクセスパターンを持つようになり、異なるデータモデルを必要とするようになる。

例えば、全文検索を行う検索エンジン、読み取りを高速化するキャッシュ、データの複雑な履歴分析を行うデータウェアハウスなどが必要になるかもしれない。

図7-1は、アプリケーションが複数のデータシステムをどのように使用するかを示している。

図7-1. 複数の場所にデータを持つアプリケーション

複数のシステムにデータを持つことは、データの信頼できる情報源に関する新たな問題を引き起こす。 データの信頼できる情報源とは、権威のあるバージョンである。 異なるシステムのデータの間に矛盾がある場合、私たちは信頼できる情報源を信頼する。

したがって、データソースの1つを信頼できる情報源として指定する必要がある。 他のシステムは、図7-2に示すように、そのソースデータを取得し、独自の変換を適用し、独自の表現で保存することができる。 これらのシステムは、実質的に派生データでオペレーティングシステムを作成している。データを失っても、信頼できる情報源から再作成できるので、特に問題にはならない。 ...