Why streaming data is essential to empower the ‘Modern Data Stack' の翻訳です。

2022年7月12日

モダン・データ・スタック」を強化するためにストリーミング・データが不可欠な理由

バッチデータよりもストリーミングの方が優れているケースは増え続けている。私たちの経験がどのようにそれを裏付けているかをご覧ください。

なぜストリーミング・データがモダン・データ・スタックに不可欠なのか

製品主導の企業として、Aivenは先駆的な分析機能の構築に大きく投資しています。そのため、私たちは常にデータを取得・収集する最善の方法を模索しています。

私はAnton Heikinheimoと申します。Aivenでデータエンジニアとして、信頼性が高く、スケーラブルでメンテナンス可能なデータパイプラインを構築しています。Aivenは、2016年の創業以来、毎年従業員数を2倍以上に増やし、企業として飛躍的な成長を遂げてきました。しかし、2020年の発足以来、データエンジニアリング部門は成長する必要がなく、実際、わずか2人のデータエンジニアでAiven社内のアナリティクスを強化することができました。オープンソースを支持し、常にマネージド・ソリューションを選択することは、当社の成功に不可欠でした。オープンソースのおかげで、信頼性の高いソフトウェアを構築し、成長に合わせてコストをコントロールすることができました。一方、マネージド・ソリューションのおかげで、インフラストラクチャの管理ではなく、ビジネス・ロジックの構築に集中することができました。

バッチとストリーミングの議論は古くから行われており、常にストリーミングが前進であるというのがコンセンサスでした。しかし最近、データ分野のトレンドの多くが、この比較をさらにストリーミングに有利に進めている。このブログポストでは、これらのトレンドがどのようなものか、そしてなぜストリーミングがそれらを実現するのに適しているのかについてお話しします。

なぜデータチームはストリーミングに向かうのか？

近年、データ・スタックを再考する機会に恵まれたデータ・チームは、通常、ストリーミングとストリーム処理を中心に構築されたスタックを選択している。バッチと比較してストリーミング・パイプラインを設定する利点を考えれば、これは驚くことではない。バッチインジェストジョブはセットアップが簡単なため、初期コストは低くなりますが、長く続けている人なら誰でも、バッチインジェストによってもたらされる複雑さ、例えば、到着が遅れたディメンション（同期していないデータ）や、データの遅延のために下流のアプリケーションで犠牲にしなければならないことを理解しているでしょう。ストリーミング取り込みパイプラインを設定するには、より多くの先行投資が必要ですが、主な利点は次のように分類できます：

• データの適時性**、データウェアハウス上に構築されたアプリケーションはデータの到着を何時間も待つ必要がない。
• データ品質と完全性**、CDC（Change Data Capture）とストリーム処理により、データチームは取り込む前にデータの完全性と品質を管理できる。
• コスト削減**、取り込み前にデータを集約・結合することで、チームは通常、ストレージや処理のコストを削減することができます。
• 運用上のオーバーヘッドが少ない**、ストリーム処理を中心に構築されたデータ・スタックでは、データの同期不良を心配する必要がない。

データの適時性

従来のダッシュボードやレポーティングだけでなく、データチームは現在、ビジネスの流れに直接影響を与える業務ユースケースにも取り組んでいる。データ領域の新しいトレンドはリバースETLであり、データは業務システムからデータウェアハウスに送られ、データウェアハウスでエンリッチされた後、再び業務システムに送られる。リバースETLの例としては、マーケティング・メッセージングがあり、顧客向けのメッセージングは、CLTV（顧客生涯価値）、顧客セグメンテーション、顧客ヘルス・スコアなどの計算値に基づいてパーソナライズされる。

データウェアハウスにおけるこのような新しい業務ユースケースにより、データの適時性の重要性が大幅に高まりました。Aiven社内では、データがバックエンドで生成されてから各業務システムに到着するまでの時間を短縮することをKPIの1つとしています。Apache Kafka®を使えば、データが生成されたらすぐに送信することができ、Apache Flink®のようなストリーム処理フレームワークを使えば、その場でデータをリッチ化することができます。

データの品質と完全性

最新のデータスタックはELT（Extract Load Transform）のプロセスを中心に構築されている。従来のETL（Extract Transform Load）との主な違いは、生データがデータウェアハウスにロードされる前に変換されないことである。ELTの意図しない結果の1つは、データチームが複雑な変換で品質の低さを修正しようとするため、質の低いデータがステージング・エリアに入り込み、技術的負債を抱えることになることです。さらに、ELTではデータモデルがミュータブルであるため、正確な履歴データを取得することが難しくなります。変更可能なモデルと低いデータ品質では、ステージングデータに新機能が導入されるたびに、正確な履歴を取得することは指数関数的に難しくなる。

ストリーム処理は、ETLとELTの長所を組み合わせ、ETLT（Extract Transform Load Transform）と呼ばれる処理を行うことで、これらの問題に対処することができる。ETLTでは、データ取り込み時にいくつかの予備的な変換が行われ、これらの変換はApache Flinkのようなストリーミングデータ処理ツールで実行できる。データ取り込み中に変換を行う根拠は、ステージング領域でのデータ品質を保証するために、いくつかのデータチェックをオンザフライで実行できるからだ。このようなチェックの例としては、NULLのチェック、結合の実行、スキーマの強制などがある。例えばAivenでは、2つのイベントソースを結合している：APIリクエストとAPIリクエストレスポンスです。これには2つの目的がある：

1.各レスポンスがリクエストを持っていることを検証する
2.データをその場で事前結合し、データウェアハウスでの高価な（そして遅い）結合を回避する。

もう1つの問題はデータの完全性にある。バッチ処理ではポーリング間隔を使用して、例えば1時間ごとや1日ごとなど、あらかじめ定義された間隔でテーブルに問い合わせを行う。もし基礎となるデータの変更がポーリング間隔よりも頻繁に起こり、テーブルがその状態を明示的に追跡していなければ、貴重な情報を見逃してしまう危険性があります。例えば、不変の customer_action_log には "email updated" というアクションが含まれますが、顧客がすぐに値を変更したため、バッチ処理では顧客テーブルの email の更新値を取得できませんでした。このため、例えばDebezium CDC (Change Data Capture) コネクタを使用したログベースのデータベースレプリケーションは、データベースのネイティブロギングソースに基づいてレプリケーションを行うため、はるかに優れています。

最後に、ストリーム処理は、GDPRに準拠したデータパイプラインの可能性を広げます。このパイプラインでは、PIIデータは転送中に匿名化され、そうすることによって、PIIデータがストレージコンテナ、ログ、または未使用のテーブルでごろごろするリスクを回避できます。

コスト削減

ストリーム処理では、転送中のデータを集約しエンリッチ化することで、大幅なデータ節約を実現できる。

データの事前集約は、メトリクスやその他のIoTデータを取り込む際に一般的に行われる。メトリクス・データの粒度は秒単位であることが多く、このような大量のデータはストレージと計算のコストを急増させる可能性があります（20万台のノードがあり、すべてのノードが数秒ごとにデータを送信しているシナリオを想像してみてください）。Aivenでは、Apache Flinkのスライディング・ウィンドウを使用して、取り込み時にデータの粒度を定義し、ビジネスに最適な粒度を正確に取り込んでいます。Flinkウィンドウでデータをバケットにグループ化する際、集計関数を定義する必要がありますが、当社では通常、最小値、最大値、平均値、および分布メトリックを定義しています。

データスペースのもう1つのトレンドは、アクティビティスキーマです。異なるソースからのイベントやデータが正規化され、1つのテーブルに解析されます。Flinkは、SQLでネストされたJSON構造を扱うための優れたサポートを持っているので、この目的のための優れたツールです。

運用上のオーバーヘッドが少ない

バッチ・インジェストで苦労することの一つは、異なるスケジュールで様々な異なるソースを抽出する際に生じる運用上のオーバーヘッドである。データは頻繁に不整合になり、このようなテストに失敗した場合の解決策は、ジョブを再実行する前に1～2時間待つことです。その理由は、1回の抽出失敗がデータの整合性を壊してしまうからかもしれません。しかし、ストリーミング、特にApache Flinkでは、（処理時間ではなく）イベント時間に基づいて変換を行うことができるため、リカバリーが容易です。

ストリーミング・データ・インジェストでは、データが生成されるとすぐに送信されるため、このようなシナリオはあり得ない。最後に、ストリーミングでは、Apache KafkaやApache Flinkといった、試行錯誤が繰り返されたオープンソースのツールを使うことができる。これらのツールは成熟した状態にあり、パイプラインが稼働すれば（魔法のように）機能する。ツールはオープンソースなので、特定のベンダーやソフトウェアに縛られるリスクもない。価格設定も予測可能で、使用量に応じて指数関数的に増加することはありません。実際には全く逆で、KafkaとFlinkで作業する際にはスケールメリットが頻繁に発揮されます。

結論

データ領域における最近のトレンドは、ストリーミングを中心にデータウェアハウスを構築する必要性を加速させていると結論づけることができる。もしデータ部門がビジネスの速度に対応する信頼性の高いデータ・インターフェースを提供できなければ、意思決定は答えが出ないか、ビジネスが目隠しされたまま意思決定することになるでしょう。Aivenでは、Apache KafkaやApache Flinkのようなオープンソースのツールをプラットフォーム上で使用することで、アナリストやビジネス・ステークホルダーに力を与えることに成功しています。Aivenのプラットフォームで作業することの意図しない結果の1つは、自社の製品部門と緊密な協力関係を築き、データ・エンジニアが日常的に遭遇する摩擦を特定し、現実世界の問題を解決する製品を構築するのに役立っていることです。