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

翻訳者について

51CTOコミュニティの編集者である張鋒氏は、運用保守/クラウドネイティブ分野を中心に長年技術コンサルタント業務に従事してきました。彼はネットワークのトラブルシューティングに精通しており、大手銀行の運用・保守ツールの構築において豊富な実務経験を持っています。