データウェアハウスアーキテクチャは、クラウドネイティブ、レイクウェアハウス統合、オフラインリアルタイム統合、SaaSなど、進化と発展を続けています。

データ ウェアハウスについて話すとき、私たちはしばしば「データ」という言葉を見落としがちです。 Alibaba Cloud には、さまざまなビジネス シナリオとビジネス システムがあります。これらのデータ アプリケーションでデータをどのように管理するのでしょうか?データ ウェアハウスはどのように役立ち、どのように進化してきましたか?

データ ウェアハウスの概念は 1990 年に提案され、4 つの主要な段階を経てきました。初期のデータベースの進化からデータ ウェアハウス、MPP アーキテクチャ、ビッグ データ時代のデータ ウェアハウス、そして今日のクラウド ネイティブ データ ウェアハウスまで。継続的な進化の過程で、データ ウェアハウスはさまざまな課題に直面します。

まず、初期費用が高く、建設期間が長く、価値をすぐに検証することが難しい

データ ウェアハウスの構築者が直面する課題は、ビジネス担当者がデータ ウェアハウスの構築サイクルを短縮することを望んでいることです。従来のデータ ウェアハウスは、サーバーの購入から物理ウェアハウスの構築、論理ウェアハウスの構築まで長いサイクルを経ることが多いため、データ ウェアハウスが直面する最初の課題は、構築サイクルをいかに短縮するかです。

第二に、多様なデータを扱い、新しい技術を取り入れ、データの価値を最大限に引き出す方法

ビッグデータの登場により、従来のデータ ウェアハウスでは主に構造化されたデータが管理されるようになりました。半構造化データをどのように統一的かつ包括的に管理するかが、従来のデータ ウェアハウスが直面する 2 番目の課題になります。

第三に、企業のデータ資産を共有することは難しく、データイノベーションのコストは高い。

データ ウェアハウスでは、管理とセキュリティがより重視されます。セキュリティを重視しながら、組織内および上流と下流のエコシステム全体でデータをより適切に共有および交換する方法が新たな課題となっています。たとえば、企業内の部門間や事業間には依然として多数のデータ アイランドが存在し、データ共有のコストが高く、企業レベルでの統一されたデータ取得エクスポートが欠如しています。その結果、データ利用者がデータを取得してセルフサービス分析を行うことが困難になり、企業の幅広いデータニーズを満たすために IT 部門のサポートに大きく依存することになります。

4番目のプラットフォームはアーキテクチャが複雑で運用コストが高い

データ処理タイプの多様化とデータ量の継続的な増加により、さまざまなテクノロジが重ね合わされ、データ ウェアハウス アーキテクチャはますます複雑になっています。多くの場合、さまざまな技術的タイプのデータ ウェアハウスが同じ企業内に同時に存在します。したがって、データ ウェアハウスのアーキテクチャをどのように簡素化するかも重要な課題です。一般的に、複雑なデータ プラットフォームを管理するだけでなく、リソースの使用率が低い状況を管理および統制するには、専門チームが必要です。

5番目に、ビジネスニーズの拡張性、弾力性、柔軟性を満たす

事業が急成長している企業では、大規模なプロモーション活動やデータの補充、従来とは異なるイベントへの対応が必要になるケースが多くあります。データ ウェアハウスのパフォーマンスを迅速に拡張し、ビジネスの繁忙期と閑散期に応答時間を改善する方法にも、多くの課題が伴います。

テクノロジーとビジネスによって推進される新しいデータ ウェアハウスは、従来のデータ ウェアハウスが直面するこれらの課題にどのように対応するのでしょうか。ここでは 6 つの主な原動力が見られます。

まず、さまざまなデータを接続、保存、処理できる統合データ プラットフォームを実現したいと考えています。

2つ目はリアルタイムです。企業は、より高い適時性が求められるデータ駆動型情報に基づいて、ビジネスにリアルタイムのサポートと意思決定情報を提供できます。

3つ目は、データの量が非常に大きくなったことです。膨大なデータの中から目的のデータを見つけるには、データを管理・統制するためのマップが必要です。

4 番目に、従来のデータ ウェアハウスでは、データは集中的に保存され、同じストレージに集中させる必要があります。新たなビジネス ニーズにより、データは一緒に保存するのではなく、接続する必要があります。

第五に、データウェアハウス上で、よりインテリジェントなアプリケーション、情報ベースのビジネス、ビジネスの情報化をどのようにサポートするか。これが、インテリジェント データ ウェアハウスとインテリジェント データ ウェアハウスの需要の原動力です。

6 番目に、データ分野におけるさまざまな役割には、データ プラットフォームに対するさまざまな要件があります。例えば、データエンジニア、データアナリスト、データサイエンティストなどは、データプラットフォームの応答時間、処理速度、データ量、開発言語などに対して異なる要件を持っています。そのため、より優れた分析サービスを提供することが、データ管理プラットフォームの 6 番目の原動力となっています。

倉庫は進化を続けており、30 年前の概念よりも新しい意味合いが込められています。新たな意味合いとしては、データウェアハウス基盤、データアーキテクチャ、データ分析、サービスモデルという4つの視点から、クラウドネイティブ、レイクウェアハウス統合、オフラインリアルタイム統合、SAASベースのサービスモデルの進化傾向を明確に見ることができます。

クラウドネイティブ - データウェアハウスインフラストラクチャの進化

クラウド ネイティブは、データ ウェアハウス インフラストラクチャの基本的な進化方向です。従来のデータ ウェアハウスは、物理サーバーまたはクラウドでホストされるサーバーに基づいています。クラウド ネイティブの場合、ストレージ サービス、ネットワーク サービス、さらに多くの監視サービスなど、より基本的なクラウド サービスを適用できます。これは、クラウド上のネイティブ サービスを使用することで、クラウドのセルフサービス、弾力性などの機能を取得できることを意味します。また、クラウド データ ウェアハウスは、さまざまなデータ ソースからログ データをデータ ウェアハウスに抽出する方法、フルリンク データ管理と機械学習を実行する方法など、より多くのクラウド サービスをより適切に統合できます。したがって、クラウド ネイティブには、クラウド サービスの構築方法やネイティブに統合する方法が含まれることがよくあります。

図に示すように、クラウド ネイティブの場合、クラウドの柔軟なコンピューティング、ストレージ、セキュリティ機能が基盤レイヤーで最大限に活用されます。このことから、クラウドの複雑さがすべて遮断されていることがわかります。データ プラットフォームのユーザーは、サービスをアクティブ化し、Web 経由でプロジェクト スペースを作成し、5 分でデータ ウェアハウスをアクティブ化するだけで、データ ウェアハウスの背後にあるモデルを開発できます。これにより、サービス提供サイクルと、データ ウェアハウスの基盤となるアーキテクチャおよび技術アーキテクチャの構築プロセス全体が大幅に簡素化されます。一方、クラウドネイティブ データ ウェアハウスにはスケーラビリティがあります。 1CU のみを必要とするジョブを送信する場合でも、10,000CU を必要とする可能性があるジョブを送信する場合でも、プラットフォームはニーズに応じてデータを処理するためのリソースをスケジュールします。したがって、クラウド ネイティブはほぼ無制限のスケーラビリティをもたらします。

レイクウェアハウス統合 - データウェアハウスデータアーキテクチャの進化の方向

湖と倉庫の統合について話すとき、まずはその背後にある理由を見てみましょう。今日に至るまで、データ ウェアハウスは依然としてエンタープライズ データ管理に最適なソリューションであると言えます。ほとんどの企業は独自のデータ ウェアハウスを所有していますが、それらは異なる技術形式に基づいて構築されている場合があります。処理戦略、セマンティック サポート、シナリオ最適化、エンジニアリング エクスペリエンスの観点から、データ ウェアハウスは現在利用可能な最良のソリューションです。さらに、企業データの量も増加しており、より柔軟で俊敏なデータ探索機能が求められています。同時に、未知のデータをさらに調査する前に保存したいという要求もあります。したがって、企業はデータ分析の最適化と探索の利点を自社のアーキテクチャに統合する必要があります。処理戦略からセマンティック サポートやユース ケースまで、データ ウェアハウスとデータ レイクは企業にさまざまな利点をもたらします。データ ウェアハウスは管理が容易でデータ品質が高く、データ レイクは探索可能性と柔軟性の点で利点をもたらします。 2つの方法をどのように組み合わせて共有するかを考え、議論する必要があります。これが「湖と倉庫の融合」というコンセプトを提案した背景です。

MaxCompute が主にデータ ウェアハウスをベースにしているシナリオでは、データ管理におけるデータ ウェアハウスの最適なエンジニアリング経験と管理経験を、データ レイクのデータ管理とデータ処理の柔軟性とより適切に組み合わせることができます。 2019年、当社は「レイクとウェアハウスの統合」という新しいデータ管理アーキテクチャを世界に先駆けて提案しました。 MaxCompute データ ウェアハウスは、安全で信頼性が高く、構造化されたデータ管理方法を提供するために使用され、DataWorks はデータ リネージ、データ マップ、およびデータ ガバナンス機能を提供します。これらの機能はデータ レイクにどのように拡張されるのでしょうか?現在見られるデータ レイクには、クラウドベースのオブジェクト ストレージ OSS や Hadoop HDFS に基づくエンタープライズ ベースのデータ レイクなどがあります。これら 2 種類のデータ レイクを、既存の柔軟性に基づいてより簡単に探索できるようにし、データ処理のパフォーマンス、管理機能、セキュリティを向上させるにはどうすればよいでしょうか。

私たちが行っているのは、データ ウェアハウスとデータ レイクを接続し、データ レイクを通じて DLF を構築し、データ レイクのメタデータを検出し、構造化された統合管理を行い、レイクの柔軟性と利便性を統合することです。これは、ウェアハウス中心の、レイクウェアハウス統合型の新しいデータ管理アーキテクチャです。データ ウェアハウスは、エンタープライズ データの管理において新たな一歩を踏み出しました。

オフラインとリアルタイムの統合 - データ ウェアハウス データ分析の進化の方向

企業のデータ ウェアハウスでは、通常、SLS や Kafka などのサブスクリプション方式を通じてデータを収集するための 3 つのパスがあります。最初の可能性は、データの一部をデータ ウェアハウスにアーカイブし、その後データ全体を分析することです。 2 番目の方法は、リアルタイムのクエリ分析を実行することです。たとえば、リスク管理のシナリオで、電話番号の過去 3 年間の通話記録をすぐに確認したい場合は、リアルタイムの接続分析を実行する必要があります。 3 番目の方法は、関連する多次元クエリをいくつか実行することです。これらのリアルタイムデータの関連付けに基づいて、後でバッチ処理、リアルタイム処理、ポイントチェックが実行されます。リアルタイム データの取得、計算、適用は、オフラインからリアルタイムへのデータ ウェアハウス全体の発展における 3 つの中核的な意味を構成します。ここでの核となるのは計算です。コンピューティングの本質は、アクティブ コンピューティングとパッシブ コンピューティングの 2 つに他なりません。オフライン コンピューティングは多くの場合パッシブ コンピューティングであり、データ ウェアハウス エンジニアは新しい結果を計算するためにタスクを定義してジョブをスケジュールする必要があります。リアルタイムのオフライン統合では、パッシブ コンピューティングに加えて、アクティブ コンピューティング機能も必要です。データが流入すると、ジョブの挿入と再開によって、手動による介入なしに新しい結果または中間結果が自動的に計算されます。リアルタイム コンピューティングに参加すると、アクティブ コンピューティング プロセスが最大限に増加します。アクティブ結果の利点は、ジョブを再スケジュールすることなく、必要な結果データを取得できることです。

一部のビジネス上の問題はオフライン サービスとリアルタイム サービスを統合することで解決できますが、アーキテクチャは非常に複雑になります。そこで、Alibaba Cloud はオフラインのリアルタイム統合データ ウェアハウス アーキテクチャを提案しました。簡素化とは、オフラインとリアルタイムの統合アーキテクチャを実現するために必要なコア製品がわずかしかないことを意味します。データソースには、各サーバーによって生成されたトランザクションデータや人やオブジェクトの動作データが含まれます。これらは、ログ サービスを通じて定期的に Hologres にアーカイブされます。その後、リアルタイム データ ウェアハウスとストリーム コンピューティングを使用して、リアルタイム コンピューティングを実行します。次に、完全なデータ ウェアハウスが下に配置され、アクティブ コンピューティング、パッシブ コンピューティング、およびリアルタイム データ取得が完了します。結果データは移行することなく、Hologres を通じてリアルタイムで直接分析できます。リアルタイムデータ取得、リアルタイムデータ計算、リアルタイムデータ分析の各サービスが 1 つに統合され、アーキテクチャが最大限に簡素化されています。これは今日、オフラインのリアルタイム統合クラウド データ ウェアハウスと呼ばれているものです。

SaaS モデル - データ ウェアハウス サービス モデルの進化の方向

データ ウェアハウス インフラストラクチャ、データ管理アーキテクチャ、データ分析アーキテクチャの進化に基づいて、これらの製品のサービスはどのように提供されるのでしょうか?それは、データ ウェアハウスを SaaS 形式で顧客に提供し、顧客が最も簡単な方法でデータ ウェアハウス サービスを利用できるようにすることです。

データ ウェアハウスを構築する方法はいくつかあります。 1 つ目は、最もよく知られている方法である物理サーバーをベースにデータ ウェアハウスを構築することです。 2 つ目は、クラウド内の Hadoop またはさまざまな MPP データベースに基づいて、セミマネージド クラウド データ ウェアハウスを構築して確立することです。 3 番目と 4 番目のタイプは、比較的深いクラウド ネイティブ形式です。 3 番目のタイプは、典型的な Snowflake アプローチです。このアプローチでは、クラウド インフラストラクチャ サービスは実際にはデータ ウェアハウス マネージャーに公開されないため、組み込みと呼ばれます。 IaaS レイヤーは PaaS レイヤーに埋め込まれていますが、最終的にはデータ ウェアハウスは SaaS の完全な Web アプローチを通じて公開されます。 2021 年のグローバル Forrester 評価には 13 社のベンダーが参加しましたが、そのうち SaaS モデルでデータ ウェアハウス サービスを提供していたのは、Google の BigQuery、Snowflake、Alibaba Cloud MaxCompute の 3 社だけでした。

自社構築からクラウドネイティブまで、クラウド コンピューティングを介したデータ ウェアハウス サービスにより、データ ウェアハウスの管理の複雑さが最大限に軽減されていることがわかります。アーキテクチャ全体のレイヤーが少なくなり、クラスターやソフトウェアを管理する必要がなくなります。サービス指向のアプローチにより、管理が必要な基礎コンテンツをすべて削除し、自由な運用と保守を実現できます。バックエンドのアップグレードはクラウドベンダーによって提供されます。独自のデータとデータ モデルを管理し、Web 経由でデータ ウェアハウス サービスを使用するだけで済みます。データ ウェアハウスに保存されるデータはクラウド ストレージと同じであり、ストレージの量に応じて料金を支払います。計算についても同様です。計算しなければお金は使わない。 SaaS の利点を十分に実証します。同時に、ビジネスニーズに合わせて柔軟に対応できるという優れた特徴も備えています。当社のお客様の多くは、日常的には 10,000 コアのコンピューティング能力しか必要としませんが、ダブル イレブン デーには 30,000 コアのコンピューティング能力を必要とします。この SaaS サービス モデルでは、ユーザーが意識することなく、データ ウェアハウスのさまざまな作業ニーズを満たす十分な柔軟性を確保できます。

要約すると、データ ウェアハウスは、1990 年のデータベースからデータ ウェアハウス、MPP アーキテクチャ、ビッグ データ時代のデータ ウェアハウス、そして今日のクラウド ネイティブ データ ウェアハウスへと進化してきました。クラウドネイティブ インフラストラクチャ、データ アーキテクチャのレイク ウェアハウス統合、データ分析のオフライン リアルタイム統合、および SaaS ベースのデータ ウェアハウス サービス モデルは、4 つの主要な進化の方向と特徴です。 Alibaba Cloud は、新しいデータ ウェアハウス アーキテクチャを通じて、企業に優れたデータ管理エクスペリエンスを提供します。