バッチ ETL は終わり、Kafka がデータ処理の未来となるのでしょうか?

QCon San Francisco で、Neha Narkhede 氏は「ETL は終わり、リアルタイム ストリーミング万歳」と題して講演し、エンタープライズ データ処理が直面している課題について議論しました。講演の中心的な前提は、オープンソースの Apache Kafka ストリーム処理プラットフォームが、データの変換と処理に対する最新のニーズをサポートする柔軟で統合されたフレームワークを提供するというものです。

Narkhede 氏は Confluent の共同創設者兼 CTO です。彼は演説でまず、過去 10 年間におけるデータとデータ システムの重要な変化について説明しました。この分野の従来の機能には、オンライン トランザクション処理 (OLTP) を提供する運用データベースや、オンライン分析処理 (OLAP) を提供するリレーショナル データ ウェアハウスなどがあります。さまざまな運用データベースからのデータは、1 日に 1 回または 2 回実行されるバッチでデータ ウェアハウス マスター スキーマにロードされます。このデータ統合プロセスは、抽出、変換、ロード (ETL) と呼ばれることがよくあります。

最近のデータ開発のトレンドにより、従来の ETL アーキテクチャに大きな変化がもたらされました。

• 単一サーバー データベースは、企業全体で実行される分散データ プラットフォームに置き換えられています。
• トランザクション データに加えて、ログ、センサー、インジケーター データなど、より多くの種類のデータ ソースが存在するようになりました。
• ストリーミング データは広く普及しており、ビジネスでは日常のバッチ処理よりも高速な処理が求められています。

これらの傾向の結果、従来のデータ統合アプローチは、エンタープライズ サービス バス (ESB) やメッセージ キュー (MQ) などのエンタープライズ グレードのミドルウェアと Hadoop などのバッチ処理テクノロジを使用して、カスタム変換スクリプトを組み合わせた混乱したものになってしまいます。

最新のストリーム処理技術がこれらの問題をどのように軽減できるかを検討する前に、Narkhede 氏はデータ統合の歴史を簡単に振り返ります。 1990 年代の小売業界では、新しい形式のデータが企業で利用できるようになり、購入者の行動傾向を分析する必要性が増加しました。

OLTP データベースに保存されている運用データは、抽出され、ターゲット ウェアハウス スキーマに変換されてから、中央データ ウェアハウスにロードされる必要があります。このテクノロジーは過去 20 年間で成熟してきましたが、データ ウェアハウスのデータ範囲は、主に ETL の次の欠点により、依然として比較的狭い範囲にとどまっています。

• グローバルモデルが必要です。
• データのクリーニングと管理には手作業が必要であり、エラーが発生しやすくなります。
• ETL の運用にはコストがかかります。多くの場合、処理速度が遅く、多くの時間とリソースを消費します。
• ETL ビルドの範囲は非常に限られており、バッチ処理方式でデータベースとデータ ウェアハウスを接続することにのみ重点が置かれています。

リアルタイム ETL に関しては、早期導入アプローチは、ESB と MQ を使用してデータ統合を実現するエンタープライズ アプリケーション統合 ​​(EAI) でした。これはリアルタイム処理には効果的ですが、これらの手法を広範囲に拡張することは難しい場合がよくあります。これにより、従来のデータ統合にジレンマが生じます。リアルタイムだがスケーラブルではない、またはスケーラブルだがバッチ処理ソリューションを使用するというジレンマです。

Narkhede 氏は、現代のストリーム処理にはデータ統合に対する新たな要件があると指摘しました。

• 大量かつ多様なデータを処理する能力。
• プラットフォームは根本からリアルタイム処理をサポートする必要があり、これによりイベント中心への根本的な移行が促進されます。
• 前方互換性のあるデータ アーキテクチャを使用する必要があり、同じデータを異なる方法で処理する可能性のある新しいアプリケーションの追加をサポートできる必要があります。

こうした要求により、一連のカスタマイズされたツールではなく、統合されたデータ統合プラットフォームの出現が促進されています。プラットフォームは、最新のアーキテクチャとインフラストラクチャの基本概念を採用し、フォールト トレラントで、並列処理が可能で、複数の配信セマンティクスをサポートし、効果的な操作と監視を提供し、スキーマ管理を可能にする必要があります。 LinkedIn によって 7 年前に開発された Apache Kafka は、次のような機能により組織内のデータの中枢神経系として機能できるオープン ソース ストリーミング プラットフォームの 1 つです。

• アプリケーション用のリアルタイムでスケーラブルなメッセージ バスであるため、EAI は必要ありません。
• すべてのメッセージ処理の宛先からソースの現実への導管を提供します。
• ステートフル ストリーム処理マイクロサービスの基本的な構成要素として機能します。

Apache Kafka は現在 LinkedIn で 1 日あたり 14 兆件のメッセージを処理しており、Cisco、Netflix、PayPal、Verizon などの Fortune 500 企業を含む世界中の何千もの組織に導入されています。 Kafka は急速にストリーミング データのストレージ ソリューションとなり、複数のデータ センターにまたがるアプリケーション統合のためのスケーラブルなメッセージング バックボーンを提供します。

Kafka の基礎は、追加のみ可能な完全に順序付けられたデータ構造であるログの概念です。ログ自体はパブリッシュ サブスクライブ (pubsub) セマンティクスを使用します。パブリッシャーは不変の形式でログにデータを簡単に追加でき、サブスクライバーは現在処理中のメッセージを示す独自のポインターを維持できます。

Kafka は、ETL の E と L である Kafka Connect API を通じてストリーミング データ パイプラインを構築できます。 Connect API は、Kafka のスケーラビリティを活用し、Kafka のフォールト トレランス モデルを基盤として、すべてのコネクタを監視するための統一された方法を提供します。ストリーム処理と変換は、ETL の T を提供する Kafka Streams API を通じて実現できます。 Kafka をストリーム処理プラットフォームとして使用すると、ターゲット シンク、データ ストア、またはシステムごとにカスタム (重複する可能性がある) 抽出、変換、およびロード コンポーネントを作成する必要がなくなります。抽出された後、ソースからのデータは構造化されたイベントとしてプラットフォームに投入され、その後、ストリーム処理を通じて任意の変換を実行できます。

講演の最初の部分で、Narkhede 氏はストリーム処理の概念、つまりストリーミング データの変換について詳しく説明し、リアルタイム MapReduce とイベント駆動型マイクロサービスという 2 つの相反するビジョンを提案しました。リアルタイム MapReduce は分析ユースケースに適しており、集中型クラスターとカスタム パッケージング、デプロイメント、および監視が必要です。 Apache Storm、Spark Streaming、Apache Flink はこのパターンを実装しています。 Narkhede 氏は、イベント駆動型マイクロサービス アプローチ (Kafka Streams API を通じて実装) により、Java アプリケーションに組み込みライブラリを追加して Kafka クラスターを設定するだけで、あらゆるユースケースでストリーム処理を利用できるようになると考えています。

Kafka Streams API は、join、map、filter、window などの演算子を備えた便利な Fluent DSL を提供します。

これは、マイクロバッチ処理のない、真のイベントごとのストリーム処理であり、データフロー スタイルのウィンドウ アプローチを使用して、イベントの時間に基づいて後続の到着データを処理します。 Kafka Streams にはローカル状態のサポートが組み込まれており、高速なステートフルかつフォールト トレラントな処理をサポートします。また、ストリームの再処理もサポートしており、アプリケーションの更新、データの移行、A/B テストの実行時に便利です。

Narkhede 氏は、ログがバッチ処理とストリーム処理を統合すると結論付けました。ログはバッチウィンドウ方式で消費でき、各要素が到着するたびにチェックしてリアルタイム処理を実現することもできます。 Apache Kafka は「ETL の新たな未来」を提供することができます。