クラウドネイティブなデータ ウェアハウスとデータ レイクを構築するためのベスト プラクティス

レポートや分析のために保存データを保存する場合、リアルタイムのワークロードを継続的に処理するために移動中のデータを保存する場合とは異なる機能とサービス レベル アグリーメント (SLA) が必要です。オープンソース フレームワーク、商用製品、SaaS クラウド サービスは数多くあります。残念ながら、これらの基盤となるテクノロジーは誤解されることが多く、モノリシックで柔軟性のないアーキテクチャで過剰に使用され、ベンダーによって間違ったユースケースに使用されています。この記事では、このジレンマを探り、クラウドネイティブ テクノロジーを使用して最新のデータ スタックを構築する方法を学びます。

クラウドネイティブなデータ ウェアハウスとデータ レイクを構築するためのベスト プラクティス

データ ウェアハウス、データ レイク、データ ストリーム、レイク ハウスを使用してクラウド ネイティブのデータ分析インフラストラクチャを構築することから得られた教訓を探ってみましょう。

レッスン 1: データを適切な場所で処理して保存する

まず自分自身に問いかけてください: データの使用例は何ですか?

以下に、データの使用例とビジネスの使用例を実装するためのサンプル ツールをいくつか示します。

• サイクル レポートの管理 => データ ウェアハウスとすぐに使用できるレポート ツール。
• 構造化データと非構造化データのインタラクティブな分析 => データ ウェアハウスまたはその他のデータ ストア上の Tableau、Power BI、Qlik、TIBCO Spotfire などのビジネス インテリジェンス ツール。
• トランザクション ビジネス ワークロード => Kubernetes 環境またはサーバーレス クラウド インフラストラクチャで実行されるカスタム Java アプリケーション。
• 履歴データを理解するための高度な分析 => TensorFlow などの強力な AI/ML アルゴリズムを適用するためにデータ レイクに保存された生データ セット。
• 新しいイベントに対するリアルタイムのアクション => ストリーミング アプリケーションは、関連性が高まるにつれてデータを継続的に処理し、相関させます。

（１）必要に応じて適切なプラットフォーム上でリアルタイムまたはバッチコンピューティングを実行する

バッチ ワークロードは、その目的のために構築されたインフラストラクチャ上で最適に実行されます。たとえば、Hadoop や Apache Spark などです。リアルタイム ワークロードは、それ用に構築されたインフラストラクチャ上で最適に実行されます。たとえば、Apache Kafka です。

ただし、両方のプラットフォームを使用できる場合もあります。基盤となるインフラストラクチャを理解して、それを可能な限り最善の方法で活用します。 Apache Kafka はデータベースを置き換えることができます。ただし、これは、それが意味をなす少数のシナリオ（アーキテクチャを簡素化したり、ビジネス価値を高めたりするなど）でのみ実行する必要があります。

たとえば、イベントのシーケンス (タイムスタンプによる順序の保証) としての再生可能性は、不変の Kafka ログに組み込まれています。 Kafka からの履歴データの再生と再処理は簡単で、次のような多くのシナリオに最適なユースケースです。

• 新しい消費者向けアプリケーション
• エラー処理
• コンプライアンス/規制処理
• 既存のイベントを照会して分析する
• プラットフォームモデルの変更を分析する
• モデルトレーニング

一方、マップ削減や変換などの複雑な分析、数十の結合を含む SQL クエリ、センサー イベントの堅牢な時系列分析、取り込まれたログ情報に基づく検索インデックスなどを行う必要がある場合もあります。次に、ユースケースに応じて Spark、Rockset、Apache Druid、または Elasticsearch を選択するのが最適です。

（２）クラウドネイティブオブジェクトストレージを使用して階層型ストレージを実装し、効率性を向上させてコストを削減する

単一のストレージ インフラストラクチャでは、これらすべての問題を解決することはできません。したがって、上記のユースケースでは、すべてのデータを単一のシステムに取り込むことは成功しません。したがって、最善の方法を選択する必要があります。

最新のクラウドネイティブ システムでは、ストレージとコンピューティングが分離されています。 Apache Kafka などのデータ ストリーミング プラットフォームや、Apache Spark、Snowflake、Google Big Query などの分析プラットフォームでも同様です。 SaaS ソリューションは革新的な階層型ストレージ ソリューション (内部に隠されているため目に見えない) を可能にし、ストレージとコンピューティングを低コストで分離します。

最新のデータ ストリーミング サービスでも階層型ストレージが活用されています。

レッスン2: 保存されているデータをリバースエンジニアリングしない

自問してみてください: データを後ではなく今処理した場合 (後が何を意味するかは関係ありません)、追加のビジネス価値はありますか?

もしそうなら、最初のステップは、データをデータベース、データ レイク、またはデータ ウェアハウスに保存しないことです。データは保存されたままであり、リアルタイム処理には利用できなくなります。ユースケースで低速データよりもリアルタイム データが優先される場合は、Apache Kafka のようなデータ ストリーミング プラットフォームが適切な選択です。

調査では、多くの人が生データをすべてデータ ストアに保存し、後でそのデータをリアルタイムで活用できることに気付いたことがわかりました。次に、リバース ETL ツールを起動した後、変更データ キャプチャ (CDC) または同様の方法を通じてデータ レイク内のデータに再度アクセスします。または、Spark Structured Streaming (="リアルタイム") を使用している場合でも、「リアルタイム ストリーミング」のデータを取得するために最初に行うことが、S3 オブジェクト ストレージ (="保存後すぐに") からデータを読み取ることである場合、これは適切ではありません。

（1）リバースETLはリアルタイムユースケースには適したアプローチではない

データをデータ ウェアハウスまたはデータ レイクに保存する場合、データは既に保存されているため、リアルタイムで処理できなくなります。これらのデータ ストアは、インデックス作成、検索、バッチ処理、レポート作成、モデル トレーニング、およびストレージ システムが適切なその他のユース ケース向けに構築されています。ただし、静的ストレージから動的データをリアルタイムで処理することはできません。

（２）データストリームはリアルタイムかつ継続的なデータ処理のために構築される

ここでイベント ストリームが役立ちます。 Apache Kafka などのプラットフォームを使用すると、トランザクションおよび分析ワークロードで移動中のデータをリアルタイムで処理できます。

最新のイベント駆動型アーキテクチャでは、リバース ETL は必要ありません。これは、すぐに使用できるアーキテクチャに「組み込まれて」います。適切かつ技術的に実行可能な場合、各ユーザーはデータをリアルタイムで直接使用します。データ ウェアハウスやデータ レイクは、依然としてほぼリアルタイムまたはバッチ速度でデータを処理します。

繰り返しますが、これはデータをデータ ウェアハウスやデータ レイクに配置してはいけないという意味ではありません。ただし、後でデータを分析する必要がある場合にのみこれを実行してください。静的データストレージはリアルタイム作業には適していません。

レッスン3: バッチとリアルタイムのワークロードを分離するのにLambdaアーキテクチャは必要ありません

自問してみてください: お気に入りのデータ分析テクノロジーを使用して、受信データを消費および処理する最も簡単な方法は何ですか?

（１）リアルタイムデータは低速データに勝るが、必ずしもそうではない

自分が属する業界、所属する事業部門、解決しようとしている問題、構築している革新的なアプリケーションを考慮してください。リアルタイムのデータは遅いデータよりも優れています。この記述はほぼ常に正しいです。あるいは、収益を増やし、コストを削減し、リスクを軽減し、顧客体験を向上させます。

保存データとは、データベース、データ ウェアハウス、またはデータ レイクにデータを保存することを意味します。この方法では、リアルタイム ストリーミング コンポーネント (Kafka など) がデータを受信して​​も、多くのユース ケースではデータの処理が遅すぎます。データ処理は依然として、問題に対する結果を提供できない Web サービス呼び出し、SQL クエリ、またはマップ削減バッチ プロセスです。

保存されているデータは悪いことではありません。レポート (ビジネス インテリジェンス)、分析 (バッチ処理)、モデル トレーニング (機械学習) など、このアプローチが適切に機能するユース ケースはいくつかあります。しかし、他のほとんどすべてのユースケースでは、リアルタイムのパフォーマンスがバッチ処理よりも優れています。

（２）Kappaアーキテクチャはバッチおよびリアルタイムワークロードのインフラストラクチャを簡素化する

Kappa アーキテクチャは、トランザクションおよび分析ワークロードのあらゆる規模のすべてのデータをリアルタイムで処理できるイベントベースのソフトウェア アーキテクチャです。

Kappa アーキテクチャの基本的な前提は、単一のテクノロジー スタックを使用してリアルタイム処理とバッチ処理の両方を実行できることです。これは、よく知られている Lambda アーキテクチャとはまったく異なるアプローチです。後者は、バッチ ワークロードとリアルタイム ワークロードを別々のインフラストラクチャとテクノロジー スタックに分離します。

Kappa のインフラストラクチャの中核はストリーミング構造です。まず、イベント ストリーミング プラットフォームは、受信データをログに記録して保存します。そこから、ストリーム処理エンジンは、リアルタイム、ほぼリアルタイム、バッチ、要求応答などの任意の通信パラダイムと速度を介して、データをリアルタイムで継続的に処理したり、他の分析データベースやビジネス アプリケーションに取り込んだりすることができます。

レッスン4: 静的データ共有とストリーミングデータ交換のトレードオフを理解する

自問してみてください: データを他の社内事業部門や外部企業とどのように共有する必要があるでしょうか?

（１）データストリーム、データレイク、データウェアハウス、データレイクハウスを使用したハイブリッドおよびマルチクラウドレプリケーションのユースケース

データ センター、リージョン、クラウド プロバイダー間でデータを複製する理由は多数あります。

• 災害復旧と高可用性: 災害復旧クラスターを作成し、業務中断の際にフェイルオーバーを実行します。
• グローバルおよびマルチクラウド レプリケーション: リージョンやクラウド間でデータを移動および集約します。
• データ共有: 他のチーム、事業部門、または企業とデータを共有します。
• データ移行: データとワークロードをあるクラスターから別のクラスターに移行します (従来のオンプレミス データ ウェアハウスからクラウドネイティブ データ レイク ハウスに移動するなど)。

（２）リアルタイムのデータ複製は、遅いデータ共有よりも優れている

内部または外部のデータ共有に関する話は、他のアプリケーションの場合と変わりません。リアルタイムのレプリケーションは、低速なデータ交換よりも優れています。したがって、リアルタイムの情報がビジネス価値を高める場合、保存データを保存してから別のデータセンター、リージョン、またはクラウド プロバイダーに複製することはアンチパターンです。

次の例は、独立した利害関係者 (つまり、異なる企業内のドメイン) が企業間のストリーミング データ交換をどのように使用できるかを示しています。

イノベーションはその境界で止まるものではありません。ストリーミング レプリケーションは、低速データ (ほとんどのシナリオに適しています) よりもリアルタイム データが優先されるすべてのユース ケースに適しています。以下にいくつか例を挙げます。

（３）サプライヤーからメーカー、仲介業者、アフターサービスに至るまでのエンドツーエンドのサプライチェーンの最適化

• クロスカントリー追跡。
• サードパーティのアドオン サービスを独自のデジタル製品に統合します。
• 外部サービスを埋め込み、組み合わせて新しい製品を構築するためのオープン API。

また、API (=REST/HTTP) とデータ ストリーム (=Apache Kafka) が競合するものではなく、補完的である理由も理解します。

レッスン5: データグリッドは単一の製品や技術ではない

自問してみてください: より効果的に革新し、ビジネス上の問題をより早く解決するために、柔軟で俊敏なエンタープライズ アーキテクチャをどのように構築できるでしょうか?

（１）データグリッドは物理的なビューではなく論理的なビューである

データ メッシュは、ドメインを主な焦点として扱い、プラットフォーム思考を適用してセルフサービス データ インフラストラクチャを作成し、データを製品として扱い、オープン標準化を実装して相互運用可能な分散データ製品エコシステムを実現するという、最新の分散アーキテクチャから借用したパラダイムに移行します。

以下はデータ グリッドの例です。

データ メッシュは、ドメイン駆動設計、データ マート、マイクロサービス、イベント ストリーミングなどの既存のパラダイムを組み合わせます。

（２）データウェアハウスやデータレイクはデータグリッド全体ではないし、またそうはなり得ない。

データ グリッド インフラストラクチャの中核は、リアルタイム、分離、信頼性、拡張性に優れたものである必要があります。 Kafka は、最新のクラウドネイティブなエンタープライズ統合プラットフォームです (最近では iPaaS とも呼ばれます)。したがって、Kafka はデータ グリッドの基盤を形成するために必要なすべての機能を提供します。

ただし、すべてのコンポーネントが Kafka ベースになるわけではありませんし、そうすべきでもありません。マイクロサービス アーキテクチャの利点は、各アプリケーションが適切なテクノロジーを選択できることです。アプリケーションには、データベース、分析ツール、またはその他の補足コンポーネントが含まれる場合と含まれない場合があります。データ製品の入力および出力データ ポートは、選択したソリューションから独立している必要があります。

Kafka は、クラウドネイティブ データ グリッドの戦略的なコンポーネントになることができます。ただし、データ ストリームを使用せず、静的データのみを使用してデータ グリッドを構築する場合でも、特効薬はありません。単一の製品、テクノロジー、またはベンダーを使用してデータ グリッドを構築しようとしないでください。ツールがリアルタイムのデータストリーミング、バッチ処理と分析、または API ベースのインターフェースに重点を置いているかどうか。 Starburst は、オープンソースの Trino (旧称 Presto) を搭載した SQL ベースの MPP クエリ エンジンであり、さまざまなデータ ストアでの分析をサポートします。

（３）クラウドネイティブデータウェアハウスのベストプラクティスはSaaS製品の範囲を超えている

クラウドネイティブのデータ ウェアハウスまたはデータ レイクの構築は大規模なプロジェクトです。データの取り込み、データの統合、分析プラットフォームへの接続、データのプライバシーとセキュリティ モデルなどが必要です。これらすべては、レポート作成や分析の実際のタスクを開始する前に必要です。

データ ウェアハウスやデータ レイクを超えて拡張される完全なエンタープライズ アーキテクチャはさらに複雑です。回復力、拡張性、弾力性、コスト効率に優れたデータ分析インフラストラクチャを構築するには、ベスト プラクティスを適用する必要があります。サービス レベル アグリーメント (SLA)、レイテンシ、稼働時間は、ビジネス ドメインによって要件が大きく異なります。最善のアプローチは、仕事に適したツールを選択することです。ビジネス ユニットとアプリケーション間の真の分離により、特定のビジネス問題の解決に集中できるようになります。

ストレージとコンピューティングの分離、バッチとリアルタイムの分離ではなく統合されたリアルタイム パイプライン、リバース ETL などのアンチパターンの回避、適切なデータ共有の概念により、クラウド ネイティブのデータ分析が可能になります。