3 つの事例から、データウェアハウスのデータフローを構築する方法を学びます。

翻訳者 |張峰

企画 |趙雲

データフロー、分析、その他のソフトウェア開発など、プロジェクトごとに課題が異なります。以下に、データウェアハウスの最新化アーキテクチャとテクノロジーが大きく異なる 3 つのケーススタディを示します。例は、ソフトウェアおよびクラウドビジネス、金融サービス、物流および輸送、旅行および宿泊など、さまざまな業界の垂直分野から来ています。

1. Confluent は、Stitch を使用したバッチ ETL から Kafka を使用したストリーミング ETL へとデータウェアハウスを近代化します。

Confluent は、Salesforce データを抽出、変換、ロード (ETL) して Google BigQuery データウェアハウスに取り込み、ビジネスでデータを使用できるようにするという、ほとんどの組織でシンプルで標準的なユースケースのために、自社のソフトウェアを可能な限り活用して社内のデータウェアハウスパイプラインを最新化しようとしました。しかし、実際は思ったよりも複雑です。

組織は、CRM やその他のアプリケーションからデータウェアハウスにデータを定期的にロードするために、サードパーティの ETL ツールに依存することがよくあります。これらのバッチ処理ツールは、ビジネスイベントが Salesforce にキャプチャされた時間から、それらのイベントを消費および処理できるようになる時間の間に遅延を引き起こします。バッチワークロードにより、Salesforce レポートと内部ダッシュボードの間に矛盾が生じることが多く、データの整合性と信頼性に関する懸念が生じます。

Confluent は当初、Talend の Stitch Batch ETL ツールを使用していました。古いアーキテクチャは次のとおりです。

バッチETLとサードパーティツールを中間に

不十分で一貫性のない情報更新につながる

過去数年間、Confluent は社内データウェアハウスパイプラインにストリーム処理機能を構築することに投資してきました。 Confluent は、独自の完全に管理された Confluent Cloud コネクタ (この場合は、Salesforce CDC Source コネクタと BigQuery Sink コネクタ)、データガバナンス用の Schema Registry、信頼性の高いストリーミング ETL 用の KSQLDB+Kafka Streams を使用して、SFDC データを BigQuery に送信します。これが現代建築です。

2. PayPalは、1日あたり300億件のイベントの読み取りにかかる時間を12時間から数秒に短縮しました。

PayPal には、多くの重要な分析ワークロードに使用される多数の Kafka プロジェクトがあります。このユースケースでは、Kafka コンシューマーを 1 日あたり 300 〜 350 億イベントに拡張し、分析ワークロードを Google Cloud Platform (GCP) に移行しました。

ストリーミングアプリケーションは、Kafka からのイベントを直接 BigQuery に受信します。ほとんどの分析結果はこれに基づいているため、これは PayPal にとって重要な項目です。データウェアハウスを最新化し、クラウドネイティブアーキテクチャを構築した結果、読み取り時間が 12 時間から数秒に短縮されました。

3. Shippeo: オンプレミスのデータベースから複数のクラウドネイティブデータレイクへ

Shippeo は、企業に正確な物流配送予測情報とリアルタイムの追跡情報サービスを提供するフランスのサプライチェーン可視化管理プラットフォームです。このプラットフォームには機械学習に基づくETAアルゴリズムが搭載されており、輸送中に発生する問題を迅速に分析して警告することができ、企業が危機に効果的に対応するのに役立ちます。

Shippeo は、物流プロバイダー、荷送業者、運送業者にリアルタイムかつマルチモーダルな可視性を提供します。同社のソフトウェアは、自動化と人工知能を活用してリアルタイムの洞察を共有し、より優れたコラボレーションを実現し、サプライチェーンの潜在能力を最大限に引き出します。このプラットフォームでは、あらゆる配送に関する予測的なリアルタイム情報に即座にアクセスできます。

次の図は、Shippeo が従来のデータベース (MySQL および PostgreSQL) とクラウドネイティブデータウェアハウス (Snowflake および BigQuery) を Apache Kafka および Debezium と統合する方法を示しています。

これは、データウェアハウスと分析を構築するための「ベストオブブリード」アプローチを活用したクラウドネイティブエンタープライズアーキテクチャの優れた例です。 Kafka は分析ワークロードをトランザクションシステムから分離し、低速なコンシューマーのバックプレッシャーを処理します。

4. Sykes Cottages は Confluent Cloud、Kafka Connect、Snowflake を使用してエンドツーエンドのパイプラインを完全に管理しています。

Sykes Holiday Cottages は、英国、アイルランド、ニュージーランドに 19,000 軒以上の別荘を所有し、英国有数かつ最も急成長している独立系別荘レンタル代理店の 1 つです。

ウェブ上の顧客体験は最優先事項であり、競争力を維持するための手段です。私たちの目標は、お客様の別荘での体験と楽しみをあらゆる段階で完璧なものにすることです。このイノベーションを推進するデータパイプラインを備えることは非常に重要です。データウェアハウスの近代化とデータストリーミングは、データ主導のアプローチを通じて Web エクスペリエンスをさらに革新する新しい方法を提供します。

5. 一貫性がなく遅いバッチワークロードから

数年間使用されていたものの、既存のパイプに問題があり、このサイクルに影響を及ぼしていました。このパイプラインの初期段階では、ETL プロセスによってデータが行と列 (構造化データ) に変換されます。さまざまなコピーが作成され、結果は静的レポートを通じて提示されました。新しいイベントやコンテキスト情報などの変更を処理するには、データエンジニアが必要です。これは主に手作業で行われるため、規模拡大も困難です。

Sykes Holiday Cottages では、データがウェアハウスに取り込まれるまで厳密に半構造化形式で保持され、その後 ELT を使用してデータを一度変換することで、パイプラインが簡素化され、柔軟性が向上します。

6. イベントベースのリアルタイム更新と継続的なストリーム処理

新しい Web イベント (およびそれに関連付けられたコンテキスト) は、メッセージにラップされ、コードを変更することなくウェアハウスまで流れていきます。その後、Web チームはクエリまたは視覚化ツールを使用して新しいイベントを取得できます。

現在のスループットは、1 分あたり約 50K (ピーク時は 300K を超える) メッセージです。新しいイベントがキャプチャされると、この数は大幅に増加します。さらに、上記の各コンポーネントはそれに応じてスケーリングする必要があります。

新しいアーキテクチャにより、Web チームはデータエンジニアリングに頼ることなく、セルフサービスツールを使用して新しいイベントをキャプチャし、データを分析できるようになります。

全体として、これを実行するビジネスケースは説得力があります。当社のテストと予測に基づくと、この投資は 3 年以内に少なくとも 10 倍の ROI をもたらすと予想されます。

7. マルチパイプラインからスノーフレーク統合までのDoorDashのデータフロー

自社のデータセンターにレガシーアプリケーションを置かずにクラウドでビジネスを運営しているデジタルネイティブ企業であっても、ビジネスプロセスを改善し、コストを削減し、下流のアプリケーションにリアルタイムの情報を提供するために、エンタープライズアーキテクチャを最新化する必要があります。

同様の目的を達成しようとする複数のパイプラインを構築するのはコスト効率が悪いです。 DoorDash は、Amazon SQS や Amazon Kinesis などのクラウドネイティブの AWS メッセージングおよびストリーミングデータ処理システムを使用して、Snowflake データウェアハウスにデータを取り込みます。

異なるタイプのデータ伝送を混在させ、その周囲の可観測性を慎重に設計せずに複数のメッセージング/キューイングシステムに渡すと、運用上の困難が生じます。

これらの問題により、DoorDash ではデータの遅延が大きくなり、コストが膨大になり、運用上のオーバーヘッドも増加しました。そのため、DoorDash は、データを Snowflake に取り込む前に、継続的なストリーム処理のために Apache Kafka と Apache Flink を搭載したクラウドネイティブストリーミングプラットフォームに移行しました。

データストリーミングプラットフォームへの移行により、DoorDash には多くのメリットがもたらされました。

Confluent REST Proxy を使用した REST API を含む、異種データソースと宛先
アクセスが簡単
Confluent Schema Registry によるスキーマ制約とスキーマ進化によるエンドツーエンドのデータガバナンス
スケーラブルでフォールトトレラント、小規模チームでも簡単に操作可能

Kafka や Flink を使用してスケーラブルなリアルタイムイベント処理を構築する方法など、このクラウドネイティブインフラストラクチャの最適化に関する詳細が多数あります。

8. クラウドネイティブプロジェクトの実際のケーススタディがビジネス価値を証明

データウェアハウスとデータレイクの最新化は、ビジネス価値がある場合にのみ意味を持ちます。 Snowflake、Databricks、Google BigQuery などのクラウドサービスの大きな利点は、柔軟なスケーリング、運用の複雑さの軽減、市場投入までの時間の短縮です。

Dataflow は、従来のデータソースとクラウドネイティブのデータソースの統合、継続的なストリーミング ETL、データソース間の真の分離、複数のデータシンク (データレイク、データウェアハウス、ビジネスアプリケーション) を実現するこれらの取り組みにおいて重要な役割を果たします。

Confluent、PayPal、Shippeo、Sykes Cottages、DoorDash のケーススタディでは、リアルタイムの可視性と分析を向上させるためにクラウドネイティブインフラストラクチャに移行したさまざまな成功事例を紹介しています。弾力的なスケーリングと完全に管理されたエンドツーエンドのパイプラインは、継続的に更新される情報を通じてビジネス価値を引き出すための重要な成功要因です。

オリジナルリンク: https://dzone.com/articles/case-studies-cloud-native-data-streaming-for-data