データレイク -- 概念、特徴、アーキテクチャ、事例の概要

1. データレイクとは

現在、データ レイクはホットなコンセプトであり、多くの企業が独自のデータ レイクを構築または構築する計画を立てています。ただし、データ レイクの構築を計画する前に、データ レイクとは何かを理解し、データ レイク プロジェクトの基本コンポーネントを明確にし、データの基本アーキテクチャを設計することがデータ レイクの構築にとって重要です。湖。データレイクとは何かについては、以下の定義があります。

ウィキペディアはそれを次のように定義しています。

データ レイクは、通常はオブジェクト ブロックまたはファイルである自然な/生の形式でデータを格納するシステムまたはストアの一種です。通常、データ レイクは、企業内の全量のデータを格納する単一のストアです。完全なデータには、元のシステムによって生成された元のデータのコピーと、レポート、視覚化、高度な分析、機械学習などのさまざまなタスク用に変換されたデータが含まれます。データ レイクには、構造化データ (行と列)、半構造化データ (CSV、ログ、XML、JSON など)、非構造化データ (電子メール、ドキュメント、PDF など)、およびリレーショナル データベースからのバイナリ データが含まれます。例: 画像、オーディオ、ビデオ)。データの沼地は、ユーザーがアクセスできないか、十分な価値を提供しない、劣化した管理が不十分なデータ レイクです。

AWS の定義は比較的簡潔です。

データ レイクは、すべての構造化データと非構造化データをあらゆる規模で保存できる集中型リポジトリです。データをそのまま (最初に構造化せずに) 保存し、ダッシュボードや視覚化からビッグデータ処理、リアルタイム分析、機械学習に至るまで、さまざまな種類の分析を実行して、より良い意思決定を導くことができます。

Microsoft の定義はさらに曖昧であり、データ レイクとは何かを明確に示していませんが、データ レイクの機能を定義として使用しています。

Azure のデータ レイクには、開発者、データ サイエンティスト、およびアナリストがデータを簡単に保存および処理できるようにするすべての機能が含まれています. これらの機能により、ユーザーはあらゆるサイズ、種類、速度のデータを保存でき、クロスプラットフォーム、クロスプラットフォームにすることができます.境界言語学は、あらゆる種類の分析と処理を行います。データ レイクは、データの収集と保存の複雑さを解消しながら、ユーザーがアプリケーション データを高速化するのに役立ち、バッチ処理、ストリーム コンピューティング、対話型分析などもサポートできます。データ レイクは、データの管理とガバナンスに対する既存の IT 投資と連携して、データの一貫性、管理性、安全性を維持できます。また、既存のビジネス データベースやデータ ウェアハウスとシームレスに統合して、既存のデータ アプリケーションを拡張することもできます。Azure Data Lake は、エンタープライズ レベルの多数のユーザーの経験を利用しており、Office 365、Xbox Live、Azure、Windows、Bing、Skype など、一部の Microsoft ビジネスでの大規模な処理と分析のシナリオをサポートしています。Azure は、ユーザーが現在および将来のニーズを満たすためにデータ資産の価値を最大化できるようにするサービスとして、多くの効率性とスケーラビリティの課題に対処します。


データレイクの定義は実際にはたくさんありますが、基本的には以下の特徴を中心に展開しています。

  1. データ レイクは、企業/組織内のすべてのデータを格納する十分なデータ ストレージ容量を提供する必要があります。

  2. データ レイクは、構造化データ、半構造化データ、非構造化データを含む、あらゆる種類の大量のデータを格納できます。

  3.  データ レイク内のデータは生データであり、ビジネス データの完全なコピーです。データ レイク内のデータは、ビジネス システム内のデータのまま保持されます。

  4. データ レイクには、データ ソース、データ形式、接続情報、データ スキーマ、権限管理など、さまざまなデータ関連要素を管理できる完全なデータ管理機能 (完全なメタデータ) が必要です。

  5. データ レイクには、バッチ処理、ストリーム コンピューティング、対話型分析、機械学習などのさまざまな分析機能が必要であると同時に、特定のタスク スケジューリングおよび管理機能も提供する必要があります。

  6. データ レイクには、完全なデータ ライフサイクル管理機能が必要です。元のデータを保存するだけでなく、さまざまな分析と処理の中間結果を保存し、データの分析と処理プロセスを完全に記録できる必要があり、ユーザーが生成プロセスを追跡するのに役立ちます。あらゆるデータの完全な詳細。

  7. データ レイクには、完全なデータ取得機能とデータ公開機能が必要です。データ レイクは、さまざまなデータ ソースをサポートし、関連するデータ ソースから完全/増分データを取得して、ストレージを標準化できる必要があります。データ レイクは、データ分析と処理の結果を適切なストレージ エンジンにプッシュして、さまざまなアプリケーション アクセス要件を満たすことができます。

  8. 超大規模ストレージやスケーラブルな大規模データ処理機能など​​、ビッグデータのサポート。

要約すると、個人的には、データ レイクは、ビッグ データのストレージ、処理、および分析のための進化するスケーラブルなインフラストラクチャであるべきだと考えています。データ レイクは、あらゆるソースから、あらゆる速度、あらゆる規模でデータを完全に取得できるデータ指向です。 、およびあらゆるタイプの、フル ストレージ、マルチモード処理、およびフル ライフ サイクル管理を提供し、さまざまな外部異種データ ソースとの相互作用および統合を通じて、さまざまなエンタープライズ レベルのアプリケーションをサポートします。


                                            図 1. データ レイクの基本機能

ここでさらに 2 つの点を指摘する必要があります。

  1. スケーラビリティとは、スケールのスケーラビリティと機能のスケーラビリティを指します。つまり、データ レイクは、データ量の増加に伴って「十分な」ストレージとコンピューティング パワーを提供するだけでなく、必要に応じて新しいデータ処理モードを継続的に提供する必要があります。たとえば、最初はバッチ処理機能のみが必要なビジネスでも、ビジネスが発展するにつれてインタラクティブなアドホック分析機能が必要になる場合があります。リアルタイム分析と機械学習として。

  2. データ指向とは、ユーザーが複雑な IT インフラストラクチャの運用と保守作業から解放され、ビジネス、モデル、アルゴリズム、およびデータに集中できるように、データ レイクが十分にシンプルで使いやすいものであることを意味します。データ レイクは、データ サイエンティストとアナリストを対象としています。現時点では、クラウド ネイティブはデータ レイクを構築するための理想的な方法であるはずです。これについては、「データ レイクの基本アーキテクチャ」セクションで詳しく説明します。

2. データレイクの基本機能

データ レイクの概念を基本的に理解したら、データ レイクの基本的な特性、特にビッグ データ プラットフォームや従来のデータ ウェアハウスと比較して、データ レイクの特性をさらに明確にする必要があります。具体的な分析の前に、AWS公式サイトの比較表を見てみましょう


上記の表は、データレイクと従来のデータウェアハウスの違いを比較したものですが、個人的には、データと計算の2つのレベルからデータレイクの特徴をさらに分析できると思います。データ側:

  • 「忠実」。ビジネス システム内のデータの完全なコピーがデータ レイクに保存されます。データ ウェアハウスとの違いは、元のデータのコピーをデータ レイクに格納する必要があり、データ形式、データ スキーマ、およびデータ コンテンツを変更してはならないことです。この点で、データ レイクは「本物の」ビジネス データの保存を重視しています。同時に、データ レイクはあらゆるタイプ/形式のデータを格納できる必要があります。

  • 「柔軟性」: 上記の表のポイントは、「スキーマの書き込み」と「スキーマの読み取り」です。これは、基本的に、データ スキーマ設計のどの段階が発生するかという問題です。For any data application, schema design is really essential. mongoDB などの「スキーマレス」を強調する一部のデータベースであっても、ベスト プラクティスでは、レコードで可能な限り同じ/類似の構造を使用することを推奨しています。「書き込みスキーマ」の背後にある暗黙のロジックは、データが書き込まれる前に、ビジネスのアクセス方法に従ってデータのスキーマを決定する必要があり、確立されたスキーマに従ってデータのインポートが完了するというものです。データとビジネスの間の優れた互換性の利点. ただし、これは、特にビジネス モデルが不明確で、ビジネスがまだ探索段階にある場合、データ ウェアハウスの初期所有コストが比較的高くなることも意味します。データウェアハウスの柔軟性は十分ではありません。データ レイクによって強調される「スキーマの読み取り」の背後にある基本的なロジックは、ビジネスの不確実性が標準であるということです。ビジネスの変化を予測することはできないため、ある程度の柔軟性を維持し、設計を遅らせ、インフラストラクチャ全体に能力を持たせます。ビジネスでデータを「オンデマンド」にします。したがって、個人的には「忠実度」と「柔軟性」は同じラインにあると考えています。ビジネスの変化を予測する方法がないため、データを最も原始的な状態に保ち、必要なときにデータを処理することができます。ニーズに。したがって、データレイクは、革新的な企業や急速に変化するビジネス開発を行う企業により適しています。同時に、データ レイクのユーザーにはそれに応じてより高い要件があり、データ サイエンティストとビジネス アナリスト (特定の視覚化ツールを使用) がデータ レイクのターゲット顧客です。

  • 「管理可能」: データ レイクは、包括的なデータ管理機能を提供する必要があります。データには「忠実度」と「柔軟性」が求められるため、データレイクには生データと処理済みデータの少なくとも 2 種類のデータが存在します。データレイク内のデータは蓄積され、進化し続けます。したがって、データ管理機能も非常に要求が厳しくなり、少なくとも次のデータ管理機能を含める必要があります: データ ソース、データ接続、データ形式、およびデータ スキーマ (ライブラリ/テーブル/列/行)。同時に、データ レイクは単一の企業/組織内の統合されたデータ ストレージの場所であるため、一定の権限管理機能も必要です。

  • 「トレーサビリティ」: データレイクとは、組織/企業内の全データの保管場所であり、データの定義、アクセス、保管、処理、分析の全プロセスを含む、データのライフサイクル全体を管理する必要があります。 、およびアプリケーション。強力なデータ レイクの実装では、その間にあるデータのアクセス、保存、処理、および消費プロセスを追跡でき、完全なデータ生成プロセスとフロー プロセスを明確に再現できる必要があります。

コンピューティングに関しては、個人的には、データ レイクのコンピューティング能力に対する要件は非常に広範囲に及び、ビジネスのコンピューティング要件に完全に依存していると思います。

  • リッチ コンピューティング エンジン。バッチ処理、ストリーミング コンピューティング、対話型分析から機械学習まで、あらゆる種類のコンピューティング エンジンは、データ レイクがカバーすべきカテゴリに属します。一般に、バッチ コンピューティング エンジンはデータの読み込み、変換、および処理に使用され、ストリーミング コンピューティング エンジンはリアルタイム コンピューティングが必要な部分に使用され、一部の探索的分析シナリオでは対話型分析エンジンの導入が必要になる場合があります。ビッグデータ技術と人工知能技術の組み合わせがますます近づいているため、さまざまな機械学習/深層学習アルゴリズムが導入されています.たとえば、TensorFlow/PyTorch フレームワークは、トレーニング用の HDFS/S3/OSS からのサンプル データの読み取りを既にサポートしています。したがって、認定されたデータ レイク プロジェクトでは、コンピューティング エンジンのスケーラビリティ/プラグ可能性が基本的な機能である必要があります。

  • マルチモーダル ストレージ エンジン。理論的には、データ レイク自体には、さまざまなアプリケーションのデータ アクセス要件を満たすマルチモーダル ストレージ エンジンが組み込まれている必要があります (応答時間/同時実行性/アクセス頻度/コストなどの要因を考慮して)。ただし、実際の使用プロセスでは、通常、データ レイク内のデータは頻繁にアクセスされることはなく、関連するアプリケーションはほとんどが探索的データ アプリケーションです.許容できるコスト パフォーマンスを達成するために、データ レイクの構築は通常、比較的安価な方法を選択します。ストレージ エンジン (S3/OSS/HDFS/OBS など) をサポートし、さまざまなアプリケーション要件を満たすために必要な場合は、外部ストレージ エンジンと連携します。

 3. データレイクの基本アーキテクチャ

データ レイクは、新世代のビッグ データ インフラストラクチャと見なすことができます。データ レイクの基本的なアーキテクチャをよりよく理解するために、ビッグ データ インフラストラクチャ アーキテクチャの進化を見てみましょう。

1) 第1段階:Hadoopに代表されるオフラインのデータ処理基盤。Hadoop は、下図に示すように、HDFS をコア ストレージとし、MapReduce (MR と呼ばれる) を基本的なコンピューティング モデルとするバッチ データ処理インフラストラクチャです。HDFS と MR を中心に、オンライン KV 操作用の HBase、SQL 用の HIVE、ワークフロー用の PIG など、ビッグ データ プラットフォーム全体のデータ処理機能を継続的に改善する一連のコンポーネントが生成されています。同時に、誰もがバッチ処理に対してますます高いパフォーマンス要件を持っているため、新しいコンピューティング モデルが常に提案されており、その結果、Tez、Spark、Presto などのコンピューティング エンジンが生まれ、MR モデルは徐々に DAG モデルに進化しました。

一方では、DAG モデルはコンピューティング モデルの抽象的な同時実行能力を高めます: 各コンピューティング プロセスは分解され、タスクはコンピューティング プロセスの集約操作ポイントに従って論理的に分割されます. タスクは段階に分割され、各タスクは段階に分割されます.ステージは1つ以上のタスクで構成され、タスクは同時に実行できるため、計算プロセス全体の並列性が向上します; 一方、データ処理プロセスでの中間結果書き込みファイル操作を減らすために、計算Spark や Presto などのエンジンは、コンピューティングを使用するために最善を尽くします。ノードのメモリはデータをキャッシュするため、データ プロセス全体の効率とシステム スループットが向上します。


                    図 2. Hadoop アーキテクチャーの概略図

2) 第 2 段階: ラムダ アーキテクチャ。データ処理能力と処理要件の絶え間ない変化により、多くのユーザーが、バッチ モードでパフォーマンスがどのように向上しても、高いリアルタイム要件を伴う一部の処理シナリオに対応できないことに気付きます. ストリーミング コンピューティング エンジンは、時代の要求に応じて出現します。 Storm 、Spark Streaming、Flink などとして。

しかし、ますます多くのアプリケーションが起動されるにつれて、バッチ処理とストリーム コンピューティングの組み合わせがほとんどのアプリケーションのニーズを満たすことができることに誰もが気付くようになります. ユーザーは、基礎となるコンピューティング モデルが何であるかをあまり気にしません.バッチ処理またはストリーム コンピューティングであり、統一されたデータ モデルに基づいて処理結果を返すことができるため、次の図に示すように Lambda アーキテクチャが提案されています。


                                  図 3. Lambda アーキテクチャの概略図

ラムダ アーキテクチャのコア コンセプトは「フロー バッチ統合」です. 上の図に示すように、データ フロー全体がプラットフォームに左から右に流れます。プラットフォームに入ると、2 つの部分に分割されます。1 つの部分はバッチ モードで、もう 1 つの部分はストリーム コンピューティング モードです。コンピューティング モードに関係なく、最終的な処理結果はサービス レイヤーを介してアプリケーションに提供され、一貫したアクセスが確保されます。

3) 第 3 段階: カッパ アーキテクチャ。Lambda アーキテクチャは、アプリケーションによって読み取られるデータの一貫性の問題を解決しますが、「ストリームとバッチの分離」処理チェーンにより、研究開発の複雑さが増します。そのため、1 つのシステムですべての問題を解決できるかどうかを尋ねる人もいます。現在、より一般的なアプローチは、ストリーム コンピューティングに基づいて行うことです。ストリーム コンピューティングの自然な分散特性により、スケーラビリティが向上します。ストリーム コンピューティングの同時実行性を高め、ストリーミング データの「時間枠」を増やすことで、バッチ処理とストリーム処理の 2 つのコンピューティング モードが統合されます。


                                      図 4. Kappa アーキテクチャの概略図

要約すると、従来の Hadoop アーキテクチャからラムダ アーキテクチャへ、ラムダ アーキテクチャから Kappa アーキテクチャへと、ビッグ データ プラットフォーム インフラストラクチャの進化には、アプリケーションに必要なさまざまなデータ処理機能が徐々に組み込まれ、ビッグ データ プラットフォームは徐々に進化して、企業。/組織の本格的なデータ処理プラットフォーム。現在の企業の慣行では、独立したビジネス システムに依存するリレーショナル データベースを除き、他のほとんどすべてのデータは、統合処理のためにビッグ データ プラットフォームに統合されていると見なされます。しかし、現在のビッグデータ プラットフォーム インフラストラクチャはストレージとコンピューティングに重点を置いており、データの資産管理は無視されています。これはまさに、新世代のビッグデータ インフラストラクチャとしてデータ レイクが注目する方向性の 1 つです。.

以前、非常に興味深い記事を読んで、次の質問をしました。なぜデータ レイクは、データ リバーやデータ シーではなく、データ レイクと呼ばれるのですか? 興味深い答えは次のとおりです。

  1. 「川」は流動性を重視し、「海には何百もの川が流れている」、川はやがて海に流れ込み、企業レベルのデータは長期間にわたって沈殿する必要があるため、「川」よりも「湖」と呼ぶ方が適切です。 "; 同時に、湖の水は自然に分割されます。これは、データを保存および管理するための統合データセンターを構築する企業のニーズと一致しています。「ホット」データは上位層にあり、アプリケーションが使用するのに便利です。いつでも; ウォーム データとコールド データは、データ センター内の異なるストレージに配置されます. メディアでは、データ ストレージ容量とコストのバランスが達成されます.

  2. なぜ「海」と呼ばないのかというと、海は果てしなく無限であり、「湖」には境界があるからです.この境界は企業/組織のビジネス境界であるため、データレイクにはより多くのデータ管理と権限が必要です.管理機能。

  3. 「レイク」という名前のもう 1 つの重要な理由は、データ レイクにはきめの細かいガバナンスが必要なことです。それは不可能です。価値を失います。

ビッグデータ インフラストラクチャの進化は、実際には次の点を反映しています: 企業/組織内では、データは重要な資産であるというコンセンサスになっています; データをより有効に活用するために、企業/組織は次のことを行う必要があります。

  1. そのまま長期保存

  2. 効果的な管理と集中管理

  3. 処理ニーズを満たすマルチモーダル コンピューティング パワーを提供

  4. ビジネス指向で、統一されたデータ ビュー、データ モデル、およびデータ処理結果を提供します。

こうした背景から、データレイクは、ビッグデータプラットフォームが持つさまざまな基本機能に加えて、データの管理、ガバナンス、活用機能に重点を置いています。具体的な実装に関しては、データ レイクには次のような一連のデータ管理コンポーネントを含める必要があります。

  1. データアクセス

  2. データ再配置

  3. データガバナンス

  4. 品質管理

  5. 資産カタログ

  6. アクセス制御

  7. タスク管理

  8. タスクのスケジューリング

  9. メタデータ管理など

次の図に示すように、データ レイク システムのリファレンス アーキテクチャが示されています。典型的なデータレイクの場合、超大規模データの処理に必要なストレージとコンピューティング能力も備え、マルチモードのデータ処理機能を提供できるという点では、ビッグデータ プラットフォームと同じですが、拡張ポイントは、データ レイクはさらに多くのことを提供します。データ管理機能を向上させるために、以下に具体化されています。

  1. より強力なデータ アクセス機能。データ アクセス機能は、さまざまな外部異種データ ソースを定義および管理する機能、および外部データ ソースに関連するデータを抽出および移行する機能に反映されます. 抽出および移行されたデータには、外部データ ソースのメタデータと実際に格納されたデータが含まれます.

  2. より強力なデータ管理機能。管理機能は、基本管理機能と拡張管理機能に分けられます。基本的な管理機能には、データ レイク システムに必要な各種メタデータの管理、データ アクセス制御、データ資産管理などの管理機能がサポートされています。拡張管理機能には、タスク管理、プロセス オーケストレーション、およびデータ品質とデータ ガバナンスに関連する機能が含まれます。タスク管理とプロセス オーケストレーションは、主に、データ レイク システムでデータを処理するさまざまなタスクを管理、調整、スケジュール、および監視するために使用されます. 通常、データ レイク ビルダーは、カスタマイズされたデータ統合またはデータ開発サブシステムを購入/開発します. モジュールはそのような機能を提供します.また、カスタマイズされたシステム/モジュールは、データ レイクの関連するメタデータを読み取ることにより、データ レイク システムと統合できます。データ品質とデータ ガバナンスはより複雑な問題です. 一般に、データ レイク システムは関連する機能を直接提供しませんが、有能な企業/組織および既存のデータのためのさまざまなインターフェイスまたはメタデータを開きます. ガバナンス ソフトウェアの統合またはカスタム開発.

  3. 共有可能なメタデータ。データ レイク内のさまざまなコンピューティング エンジンは、データ レイク内のデータと深く統合されます。融合の基礎は、データ レイクのメタデータです。優れたデータ レイク システムでは、データを処理するときに、コンピューティング エンジンがデータ ストレージの場所、データ形式、データ モード、データ分布、およびその他の情報をメタデータから直接取得し、手動またはプログラミングの介入なしにデータを直接処理できます。さらに、優れたデータ レイク システムは、データ レイク内のデータに対してアクセス制御を実行することもでき、「ライブラリ テーブル列行」などのさまざまなレベルで制御強度を実現できます。


                                                      図 5. データ レイク コンポーネントのリファレンス アーキテクチャ

また、上図の「集中型ストレージ」は、よりビジネスコンセプトを集約したものであり、本質的には、企業/組織内のデータが明確で統一された場所に保管されることが望まれます. 実際には、データ レイクのストレージは、オンデマンドで拡張できる分散ファイル システムである必要があります. ほとんどのデータ レイクのプラクティスでは、S3/OSS/OBS/HDFS などの分散システムを、データ レイクの統合ストレージとして使用することをお勧めします。データレイク。

再びデータ ディメンションに切り替えて、データ レイクがデータを処理する方法をデータ ライフ サイクルの観点から見てみましょう. データ レイク内のデータのライフ サイクル全体を図 6 に示します. 理論的には、適切に管理されたデータ レイク内のデータは元のデータを永続的に保持しますが、プロセス データはビジネスのニーズを満たすために継続的に改善および進化します。


                                                 図 6. データ レイク内のデータ ライフ サイクルの図

4. 各種メーカーのデータレイクソリューション

データ レイクは現在のトレンドであり、主要なクラウド メーカーは独自のデータ レイク ソリューションと関連製品を発売しています。このセクションでは、さまざまな主流メーカーが立ち上げたデータ レイク ソリューションを分析し、それらをデータ レイク リファレンス アーキテクチャにマッピングして、さまざまなソリューションの長所と短所を理解できるようにします。

4.1 AWS データレイク ソリューション


                                                    図 7. AWS データレイク ソリューション

図 7 は、AWS が推奨するデータ レイク ソリューションです。ソリューション全体は AWS Lake Formation に基づいています。これは基本的に、他の AWS サービスと連携してエンタープライズレベルのデータレイク構築機能全体を完成させる管理コンポーネントです。上の図は、左から右に、データの流入、データの沈殿、データの計算、およびデータの適用の 4 つのステップを示しています。その重要なポイントを詳しく見てみましょう。

1) データ流入


データの流入は、メタデータの流入、ビジネスデータの流入など、データレイク全体の構築の始まりです。メタデータの流入には、データ ソースの作成とメタデータの取得の 2 つの手順が含まれます.最後に、データ リソース ディレクトリが形成され、対応するセキュリティ設定とアクセス制御ポリシーが生成されます。このソリューションは、外部データ ソースの関連メタデータを取得するための特殊なコンポーネントを提供します. このコンポーネントは、外部データ ソースに接続し、データ形式とスキーマを検出し、対応するデータ リソース ディレクトリ内のデータ レイクに属するメタデータを作成できます. ビジネス データの流入は ETL を介して行われます。

特定の製品形態、メタデータ キャプチャ、ETL、およびデータ準備に関して、AWS はそれらを個別に抽象化し、AWS GLUE と呼ばれる製品を形成します。AWS GLUE と AWS Lake Formation は同じデータ リソース カタログを共有します。これは、AWS GLUE 公式ウェブサイトのドキュメントに「各 AWS アカウントには、AWS リージョンごとに 1 つの AWS Glue データ カタログがあります」と明記されています。

異種データ ソースのサポート。AWS が提供するデータ レイク ソリューションは、S3、AWS リレーショナル データベース、AWS NoSQL データベースをサポートし、AWS は GLUE、EMR、Athena などのコンポーネントを使用してデータの自由な流れをサポートします。

2) データの降水量

Amazon S3 をデータ レイク全体の集中型ストレージとして使用し、オンデマンド/従量制でスケーリングします。

3) データ計算

ソリューション全体で、基本的なデータ処理に AWS GLUE を活用しています。GLUE の基本的な計算形式は、さまざまなバッチ モードの ETL タスクであり、タスクの開始方法は、手動トリガー、タイミング トリガー、およびイベント トリガーの 3 つのタイプに分けられます。AWS のさまざまなサービスは、生態学的に非常によく実装されていると言わざるを得ません. イベント トリガー モードでは、AWS Lambda を使用して拡張開発を行うことができ、1 つまたは複数のタスクを同時にトリガーすることができます。タスク トリガーのカスタマイズされた開発能力; 同時に、さまざまな ETL タスクは CloudWatch を介して適切に監視できます。

4) データ活用

AWS は、基本的なバッチ コンピューティング モードを提供するだけでなく、SQL ベースのインタラクティブなバッチ処理機能を提供する Athena/Redshift、ストリーム コンピューティング能力を含むさまざまな Spark のコンピューティング能力を提供する EMR など、さまざまな外部コンピューティング エンジンを通じて豊富なコンピューティング モードのサポートを提供します。 Spark が提供できる機械学習機能。

5) 権利管理

AWS のデータ レイク ソリューションは、"library-table-column" を含む粒度で、Lake Formation を通じて比較的完全な権限管理を提供します。ただし、例外が 1 つあります.GLUE が Lake Formation にアクセスする場合、粒度は「ライブラリ テーブル」の 2 レベルのみです.これは、GLUE と Lake Formation の間の統合がより緊密であることを別の側面から示しています.データはより多くのアクセスを持っています.

Lake Formation のアクセス許可は、データ リソース ディレクトリのアクセス権と基礎となるデータ アクセス権にさらに細分化できます。これらは、それぞれメタデータと実際に保存されたデータに対応します。実際にデータを格納するためのアクセス権限は、さらにデータアクセス権限とデータ格納アクセス権限に分けられます。データアクセス権限は、データベースにおけるデータベーステーブルへのアクセス権限と同様であり、データストレージ権限は、S3 内の特定のディレクトリへのアクセス権限をさらに絞り込みます (明示的および暗黙的に分けられます)。図 8 に示すように、ユーザー A は、データ アクセス許可のみでは、S3 の指定されたバケットの下にテーブルを作成できません。

個人的には、これはデータ レイクがさまざまなストレージ エンジンをサポートする必要性をさらに反映していると思います. 将来的には、データ レイクは S3/OSS/OBS/HDFS などのコア ストレージを含むだけでなく、必要に応じてより多くの種類のストレージ エンジンを組み込む可能性があります。アプリケーション アクセス要件. たとえば、S3 は生データを格納し、NoSQL は処理後に「キー値」モードでのアクセスに適したデータを格納し、OLAP エンジンはさまざまなレポート/アドホック クエリをリアルタイムで生成する必要があるデータを格納します。現在、さまざまな資料でデータレイクとデータウェアハウスの違いが強調されていますが、本質的には、データレイクは一種の統合データ管理のアイデアの具体的な実現であるべきであり、「レイクとウェアハウスの統合」が最も重要である可能性があります。未来. 開発動向.


             図 8. AWS データ レイク ソリューションの権限分離の概略図

要約すると、AWS データ レイク ソリューションは、特にメタデータ管理と権限管理の点で非常に成熟しており、異種データ ソースとさまざまなコンピューティング エンジンの間のアップストリームとダウンストリームの関係が開かれ、データを自由に「移動」できるようになりました。ストリーム コンピューティングと機械学習においても、AWS のソリューションは比較的完成度が高いです。ストリーム コンピューティングに関しては、AWS は特別なストリーム コンピューティング コンポーネント Kinesis を開始しました. Kinesis の Kinesis データ Firehose サービスは、完全に管理されたデータ配信サービスを作成できます. Kinesis データ ストリームを介してリアルタイムで処理されたデータは、S3 に簡単に書き込むことができますFirehose の助けを借りて、JSON を Parquet 形式に変換するなど、対応する形式変換をサポートします。

AWS のソリューション全体の最も優れた点は、Kinesis が GLUE のメタデータにアクセスできることです。これは、AWS データ レイク ソリューションの生態学的完全性を完全に反映しています。同様に、機械学習に関しては、AWS が SageMaker サービスを提供しており、SageMaker は S3 でトレーニング データを読み取り、トレーニング済みのモデルを S3 に書き戻すことができます。ただし、AWS のデータ レイク ソリューションでは、ストリーム コンピューティングと機械学習が固定的にバンドルされているのではなく、コンピューティング パワーの拡張としてのみ簡単に統合できることを指摘しておく必要があります。

最後に、図 6 のデータ レイク コンポーネント リファレンス アーキテクチャに戻り、AWS のデータ レイク ソリューションのコンポーネント カバレッジを確認しましょう (図 9 を参照)。


                                    図 9. リファレンス アーキテクチャでの AWS データ レイク ソリューションのマッピング

要約すると、AWS のデータ レイク ソリューションは、品質管理とデータ ガバナンスを除くすべての機能をカバーしています。実際、品質管理とデータ ガバナンスの作業は、企業の組織構造とビジネス タイプに強く関連しており、多くのカスタム開発作業を行う必要があるため、一般的なソリューションにこれが含まれていないことは理解できます。コンテンツ。実際、Apache Griffin など、このプロジェクトをサポートする優れたオープン ソース プロジェクトもあります. 品質管理とデータ ガバナンスに対する要求が高い場合は、自分でカスタマイズして開発することができます.

4.2 ファーウェイのデータレイクソリューション


                                                 図 10. ファーウェイのデータ レイク ソリューション

Huawei のデータ レイク ソリューションに関する情報は、Huawei の公式 Web サイトから入手できます。現在、公式 Web サイトに表示されている関連製品には、Data Lake Insight (DLI) と Intelligent Data Lake Operation Platform (DAYU) があります。DLI は、AWS の Lake Formation、GLUE、Athena、および EMR (Flink & Spark) のコレクションに相当します。公式サイトにDLIの全体構成図が見当たらなかったので、主にAWSソリューションとの比較を目的として、自分なりの理解で描いてみたので、形はなるべく統一した方がいいと思います。 Huawei DLIをよく知っている人も、遠慮なく教えてください。

Huawei のデータ レイク ソリューションは比較的完成度が高く、DLI はデータ レイクの構築、データ処理、データ管理、およびデータ アプリケーションのすべてのコア機能を引き受けます。DLIの最大の特徴は、SQLベースの対話型分析やSpark+Flinkベースのストリーム・バッチ統合処理エンジンなど、分析エンジンの充実です。コア ストレージ エンジンでは、DLI は引き続き組み込みの OBS によって提供されます。これは、基本的に AWS S3 の機能と一致します。ファーウェイのデータレイクソリューションは、アップストリームとダウンストリームのエコロジーの点で AWS よりも完全であり、外部データソースについては、現在ファーウェイクラウドで提供されているほぼすべてのデータソースサービスをサポートしています。

DLI は、Huawei の CDM (Cloud Data Migration Service) および DIS (Data Access Service) と連携できます。

  1. DIS を使用すると、DLI は、Flink ジョブでソースまたはシンクとして使用できるさまざまなデータ ポイントを定義できます。

  2. CDM の助けを借りて、DLI は IDC やサードパーティのクラウド サービスからのデータにもアクセスできます。

データ統合、データ開発、データ ガバナンス、品質管理などの高度なデータ レイク機能をより適切にサポートするために、HUAWEI CLOUD は DAYU プラットフォームを提供します。DAYU プラットフォームは、ファーウェイのデータ レイク ガバナンスと運用方法論を実装したものです。DAYU は、データ レイク ガバナンス全体のコア プロセスをカバーし、それに対応するツール サポートを提供します。ファーウェイの公式文書でも、データ ガバナンス組織を構築するための提案を提供しています。DAYU のデータ ガバナンス方法論の実装を図 11 に示します (HUAWEI CLOUD 公式 Web サイトから)。

                                            図 11 DAYU データ ガバナンス方法論プロセス

本質的に、DAYU データ ガバナンス方法論は、実際にはデータ レイク インフラストラクチャにおける従来のデータ ウェアハウス ガバナンス方法論の拡張であることがわかります。データ モデルの観点からは、ソース レイヤー、マルチソース統合が依然として含まれています。レイヤ、詳細データ レイヤ、データ ウェアハウスと完全に一致。データ モデルと指標モデルに従って、品質ルールと変換モデルが生成され、DAYU は DLI と接続し、DLI が提供する関連データ処理サービスを直接呼び出して、データ ガバナンスを完了します。

HUAWEI CLOUDのデータレイクソリューション全体は、データ処理のライフサイクルを完全にカバーし、データガバナンスを明示的にサポートし、モデルと指標に基づいたデータガバナンスプロセスツールを提供し、「レイクとウェアハウスの統合」の方向性が進化しました。

4.3 Alibaba Cloud データレイク ソリューション

私は現在データ BU に所属しているため、Alibaba Cloud には多くのデータ プロダクトがあります。このセクションでは、データベース BU プロダクトを使用してデータ レイクを構築する方法に焦点を当て、他のクラウド プロダクトも少し関与します。データベース製品に基づく Alibaba Cloud のデータ レイク ソリューションは、データ レイク分析とフェデレーション分析という 2 つのシナリオに重点を置いています。Alibaba Cloud データ レイク ソリューションを図 12 に示します。


                                             図 12. Alibaba Cloud データ レイク ソリューション

ソリューション全体では、データ レイクの集中ストレージとして OSS を使用しています。データ ソースのサポートに関しては、現在、OLTP、OLAP、および NoSQL データベースを含むすべての Alibaba Cloud データベースをサポートしています。主な要点は次のとおりです。

  1. データ アクセスと再配置。レイクを構築するプロセスでは、DLA の Formation コンポーネントには、メタデータの検出とワンクリックのレイク構築の機能があります.この記事の執筆時点では、「ワンクリックのレイク構築」は完全なレイク構築のみをサポートしていますが、インクリメンタル レイク構築をサポートしていますbinlog に基づくビルド 既に開発中であり、間もなくリリースされる予定です。漸進的なレイク構築機能により、データ レイク内のデータのリアルタイム性が大幅に向上し、ソースエンド ビジネス データベースへのプレッシャーが最小限に抑えられます。ここで、DLA Formation は内部コンポーネントであり、外部に公開されていないことに注意してください。

  2. データ リソース ディレクトリ。DLA は、データが「レイク内」にあるか「レイク外」にあるかに関係なく、データ レイク内のデータ資産を統合管理するためのメタ データ カタログ コンポーネントを提供します。メタ データ カタログは、連携分析用の統合されたメタデータ エントリでもあります。

  3. 組み込みのコンピューティング エンジンでは、DLA は SQL コンピューティング エンジンと Spark コンピューティング エンジンを提供します。SQL エンジンと Spark エンジンはどちらも、メタデータ情報を簡単に取得できるメタ データ カタログと深く統合されています。Spark の機能に基づいて、DLA ソリューションはバッチ処理、ストリーム コンピューティング、機械学習などのコンピューティング モードをサポートします。

  4. 外部エコロジーでは、データ アクセスと集計のためにさまざまな異種データ ソースをサポートすることに加えて、外部アクセス機能に関して、DLA はクラウド ネイティブ データ ウェアハウス (以前の ADB) と深く統合されています。一方では、DLA 処理の結果をいつでも ADB にプッシュして、リアルタイム、インタラクティブ、およびアドホックの複雑なクエリを満たすことができ、他方では、ADB のデータを OSS の助けを借りて簡単に OSS に返すこともできます。出現関数の。DLA に基づいて、Alibaba Cloud 上のさまざまな異種データ ソースを完全に接続でき、データが自由に流れます。

  5. データの統合と開発に関して、Alibaba Cloud のデータ レイク ソリューションには 2 つのオプションがあります。どちらを選択しても、ビジュアル プロセス オーケストレーション、タスク スケジューリング、およびタスク管理機能を外部に提供できます。データ ライフ サイクル管理に関しては、dataworks のデータ マップ機能は比較的成熟しています。

  6. データ管理とデータ セキュリティにおいて、DMS は強力な機能を提供します。DMS のデータ管理の粒度は「ライブラリ-テーブル-列-行」に分割され、エンタープライズ レベルのデータ セキュリティ管理および制御要件を完全にサポートします。権利管理に加えて、DMS のより洗練された側面は、元のデータベース ベースの DevOps コンセプトをデータ レイクに拡張し、データ レイクの運用、保守、および開発をより洗練されたものにすることです。

次の図に示すように、データ レイク ソリューション全体のデータ アプリケーション アーキテクチャはさらに洗練されています。

                                      図 13. Alibaba Cloud データレイクのデータ アプリケーション アーキテクチャ

左から右へ、データ フローの方向から、データ プロデューサーはさまざまな種類のデータ (オフクラウド/オンクラウド/その他のクラウド) を生成し、それらを OSS/HDFS/DB を含むさまざまな一般/標準データ ソースにアップロードします。ツール 待ってください。さまざまなデータ ソースについて、DLA は、データ検出、データ アクセス、データ移行、およびその他の機能を通じて、湖の建設操作を完了することができます。

「レイクへ」のデータについては、DLA は SQL と Spark に基づくデータ処理機能を提供し、Dataworks/DMS に基づく外部視覚化データ統合とデータ開発機能を提供できます。外部アプリケーション サービス機能に関して、DLA は標準化された JDBC インターフェイスを提供します。 、各種通報ツールや大画面表示機能などに直接接続できます。Alibaba Cloud の DLA の特徴は、OLTP、OLAP、NoSQL などのデータベースを含む Alibaba Cloud データベース エコシステム全体に支えられており、SQL ベースのデータ処理機能を提供することです.従来のエンタープライズ データベース ベースの開発技術スタックの場合、コスト変換の割合が比較的高く、低いほど、学習曲線は比較的平坦です。

Alibaba Cloud の DLA ソリューションのもう 1 つの特徴は、「レイクとウェアハウスのクラウドネイティブな統合」です。従来のエンタープライズ レベルのデータ ウェアハウスは、ビッグ データの時代のさまざまなレポート アプリケーションでは依然としてかけがえのないものですが、データ ウェアハウスは、ビッグ データの時代におけるデータ分析と処理の柔軟性要件を満たすことができません。

したがって、データ ウェアハウスはデータ レイクの上位層アプリケーションとして存在することをお勧めします: つまり、データ レイクは、企業/組織内の元のビジネス データの唯一の正式なデータ ストレージの場所です。さまざまなビジネス アプリケーションのニーズに応じて元のデータを作成し、再利用可能な中間結果を形成します。中間結果のデータ スキーマ (Schema) が比較的固定されている場合、DLA は中間結果を企業/組織のデータ ウェアハウスにプッシュして、データ ウェアハウスを実行できます。に基づくビジネス アプリケーション。Alibaba Cloud は DLA を提供する一方で、クラウドネイティブのデータ ウェアハウス (旧 ADB) も提供します.DLA とクラウドネイティブのデータウェアハウスは、次の 2 つの点で深く統合されています。

  • 同一生成元の SQL 解析エンジンを使用します。DLA の SQL は ADB の SQL と文法的に完全に互換性があるため、開発者は一連のテクノロジ スタックを使用して、データ レイク アプリケーションとデータ ウェアハウス アプリケーションを同時に開発できます。

  • どちらも OSS の組み込みアクセス サポートを備えています。OSS は DLA のネイティブ ストレージとして直接存在しますが、ADB の場合、OSS 上の構造化データは、外部テーブルの機能を通じて簡単にアクセスできます。外部テーブルの助けを借りて、DLA と ADB の間でデータを自由に転送して、レイクとウェアハウスの真の統合を実現できます。

DLA と ADB の組み合わせにより、クラウド ネイティブのレイクとウェアハウスの統合が真に実現されます (クラウド ネイティブとは何かについては、この記事の範囲を超えています)。本質的に、DLA は、拡張機能を備えたデータ ウェアハウスの貼り付けソース レイヤーと見なすことができます。従来のデータ ウェアハウスと比較して、ソース レイヤーは次のようになります。

  1. あらゆる種類の構造化データ、半構造化データ、および非構造化データを保存できます。

  2. さまざまな異種データ ソースを接続できます。

  3. メタデータを検出、管理、および同期する機能。

  4. 組み込みの SQL/Spark コンピューティング エンジンは、さまざまなデータ処理のニーズを満たす強力なデータ処理機能を備えています。

  5. 完全なデータの完全なライフサイクルを管理する機能があります。DLA+ADBに基づくレイクとウェアハウスの統合ソリューションは、「ビッグデータプラットフォーム+データウェアハウス」の処理能力を同時にカバーします。

DLA のもう 1 つの重要な機能は、「全方向に拡張する」データ フロー システムを構築し、データがクラウド上にあるかクラウド外にあるかに関係なく、データが内部にあるかどうかに関係なく、データベースのエクスペリエンスを備えた外部機能を提供することです。または組織の外; データレイク、さまざまなシステムの助けを借りて、それらの間のデータには障壁がなくなり、自由に出入りできます; さらに重要なことに、このフローは規制されており、データレイクはデータの流れを完全に記録します.

4.4 Azure データ レイク ソリューション

Azure のデータ レイク ソリューションには、図 15 (Azure 公式 Web サイトから) に示すように、データ レイク ストレージ、インターフェイス レイヤー、リソース スケジューリング、およびコンピューティング エンジン レイヤーが含まれます。ストレージ レイヤーは Azure Object Storage 上に構築されており、構造化データ、半構造化データ、および非構造化データを引き続きサポートします。

インターフェイス レイヤーは WebHDFS. 特に、HDFS のインターフェイスは Azure オブジェクト ストレージに実装されています. Azure はこの機能を「データ レイク ストレージのマルチプロトコル アクセス」と呼んでいます. リソースのスケジューリングに関しては、Azure は YARN に基づいて実装されています。コンピューティング エンジンに関しては、Azure は U-SQL、hadoop、Spark などのさまざまな処理エンジンを提供します。


                       図 15. Azure データ レイク分析アーキテクチャ

Azure の特徴は、Visual Studio をベースにお客様の開発をサポートすることです。

  1. 開発ツールのサポートと Visual Studio との緊密な統合。Azure では、データ レイク分析アプリケーションの開発言語として U-SQL を推奨しています。Visual Studio は U-SQL の完全な開発環境を提供します。同時に、分散データ レイク システム開発の複雑さを軽減するために、Visual Studio はプロジェクトに基づいてプロジェクトをカプセル化します。U-SQL を開発するときは、"U 「SQL データベース プロジェクト」では、このようなプロジェクトで Visual Studio を使用すると、コーディングとデバッグが非常に便利になると同時に、開発した U-SQL スクリプトを生成環境に公開するためのウィザードも提供されます。U-SQL では、Python と R を拡張して、カスタム開発のニーズを満たすことができます。

  2. 複数のコンピューティング エンジンの適応: SQL、Apache Hadoop、および Apache Spark。ここでの Hadoop には Azure が提供する HDInsight (Azure でホストされる Hadoop サービス) が含まれ、Spark には Azure Databricks が含まれます。

  3. 多くの異なるエンジン タスクを自動的に切り替える機能。Microsoft は、データ レイクの既定の開発ツールとして U-SQL を推奨しており、U-SQL スクリプトと Hive、Spark (HDSight および databricks)、および Azure Data Factory データ フローとの間の変換をサポートするさまざまな変換ツールを提供しています。

4.5 まとめ

この記事では、データ レイク ソリューションについて説明します。クラウド ベンダーの単一の製品は含まれません。データ アクセス、データ ストレージ、データ コンピューティング、データ管理、およびアプリケーション エコロジーの側面から、次の表のように簡単にまとめました。

実際、スペースの制約により、有名なクラウド ベンダーのデータ レイク ソリューションには Google や Tencent が含まれています。公式ウェブサイトによると、データレイクのソリューションは比較的単純で、概念的な詳細にすぎません. 推奨される実装プランは「oss + hadoop (EMR)」です.

実際、データレイクは単純な技術プラットフォームの観点から見る必要はありません. データレイクを実現する方法もさまざまです. データレイクソリューションの成熟度を評価するには、それが提供するデータ管理機能が重要です.これには、メタデータ、データ資産カタログ、データ ソース、データ処理タスク、データ ライフ サイクル、データ ガバナンス、権限管理などが含まれますが、これらに限定されません。また、周辺エコシステムと接続する機能も含まれます。

5. 代表的なデータレイクの適用事例

5.1 広告データ分析

近年、トラフィック獲得のコストはますます高くなり、オンライン チャネルを介した顧客獲得コストの指数関数的な増加は、あらゆる分野に深刻な課題をもたらしています。インターネット広告のコストが上昇する中で、トラフィックを購入して新しいトラフィックを獲得するためにお金を使うという主要なビジネス戦略は、確実に機能しなくなります。フロントエンドトラフィックの最適化は戦いの終わりになりました. データツールを使用して、サイトに到着した後のトラフィックのターゲットコンバージョンを改善し、広告の各リンクの操作を改善することは、変更するためのより直接的かつ効果的な方法です.現状。結局のところ、広告トラフィックのコンバージョン率を改善するには、ビッグデータ分析に頼る必要があります。

より多くの意思決定支援を提供するためには、チャネル、配信時間、および配信人口を含むがこれらに限定されない、より多くの埋め込みデータを収集および分析し、クリック率データ指標に基づいてデータ分析を行う必要があります。より良い結果を提供し、高効率と高出力を達成するためのより迅速なソリューションと推奨事項を提供します。したがって、広告の分野における多次元、マルチメディア、マルチ広告、およびその他の構造化、半構造化、および非構造化データの収集、保存、分析、および意思決定に関する推奨事項に直面して、データ レイク分析製品ソリューションは非常に重要です。広告主またはパブリッシャー向け. 新世代のテクノロジーの選択は非常に好意的です.

DG は、世界をリードするエンタープライズ向けの国際的なインテリジェント マーケティング サービス プロバイダーであり、高度な広告技術、ビッグ データ、および運用能力に基づいて、グローバルで高品質のユーザー獲得およびトラフィック収益化サービスを顧客に提供しています。DG は当初からパブリック クラウドに基づいて IT インフラストラクチャを構築することを決定しており、当初、DG は AWS クラウド プラットフォームを選択して、広告データを S3 のデータ レイクの形式で保存し、Athena を介してインタラクティブな分析を実行しました。しかし、インターネット広告の急速な発展に伴い、広告業界はいくつかの課題を抱えており、モバイル広告の公開および追跡システムはいくつかの重要な問題を解決する必要があります。

  1. 並行性とピークの問題。広告業界では、トラフィックのピークが頻繁に発生し、インスタント クリックが数万または数十万に達することもあるため、システムには、迅速に応答してすべてのクリックを処理するための非常に優れたスケーラビリティが必要です。

  2. 大量データのリアルタイム分析をいかに実現するか。広告配信の効果を監視するために、システムはすべてのクリックとユーザーのアクティブ化データをリアルタイムで分析し、同時に関連データを下流のメディアに送信する必要があります。

  3. プラットフォーム上のデータ量は急速に増加しており、毎日のビジネス ログ データが継続的に生成およびアップロードされ、公開され、クリックされ、プッシュされたデータが継続的に処理されます. 毎日新しく追加されるデータの量は、すでに約 10 ~ 50TB です. . 広告データのオフライン/ほぼリアルタイムの統計を効率的に完了し、広告主のディメンション要件に従って集計分析を実行する方法。

上記の 3 つのビジネス上の課題に対応すると同時に、顧客である DG の毎日の増分データは急速に増加しています (現在の毎日のデータ スキャン量は 100+TB に達しています) AWS プラットフォームで Athena を使い続けるとボトルネックに直面しますAthena の読書では、S3 データ帯域幅とデータ分析のラグ タイム. 慎重かつ慎重なテストと分析の後、AWS クラウド プラットフォームから Alibaba クラウド プラットフォームに移行することが最終的に決定されました. 新しいアーキテクチャ図は次のとおりです:


                                     図 16. 改良された広告データ レイク ソリューション アーキテクチャ

AWS から Alibaba Cloud に移行した後、このお客様がビジネスの山と谷に対応できるように、「Data Lake Analytics + OSS を使用する」という究極の分析機能を設計しました。一方では、ブランドの顧客からのアドホックな分析に対処するのは簡単です。一方、Data Lake Analytics の強力なコンピューティング パワーを使用して、月次および四半期ごとの広告を分析し、ブランドの下でどれだけの活動が行われるかを正確に計算します.各活動は、メディア、市場、チャネル、および DMP に分割されます.ブランド マーケティングのための Jiahe インテリジェント トラフィック プラットフォームによってもたらされるコンバージョン率がさらに向上しました。

また、広告の掲載と分析の総所有コストの観点から、Data Lake Analytics が提供するサーバーレス エラスティック サービスは、オンデマンドで課金され、固定リソースの購入を必要とせず、運用と保守のコストと使用コストを大幅に削減します。


                                          図 17 データ レイク展開の概略図

一般的に、DG が AWS から Alibaba Cloud に切り替えた後、ハードウェア コスト、人件費、および開発コストが大幅に節約されました。DLA のサーバーレス クラウド サービスを利用することで、DG はサーバーやストレージなどのハードウェア機器を事前に購入するために多額の投資を行う必要がなく、一度に多数のクラウド サービスを購入する必要もありません。インフラの完全オンデマンド展開:需要が多いときはサービスを増やす 需要が減ると、サービスの数を減らし、資金の利用率を向上させます。

Alibaba Cloud プラットフォームを使用することの 2 つ目の大きな利点は、パフォーマンスの向上です。DG のビジネスが急速に成長し、その後複数の事業部門がアクセスする時期に、モバイル広告システムへの DG のアクセスが爆発的に増加することがよくありました.しかし、元の AWS ソリューションとプラットフォームは、Athena で S3 データを読み取り、データ読み取り帯域幅に遭遇しました.は巨大なボトルネックであり、データ分析時間はますます長くなります. Alibaba Cloud DLA と OSS チームは、優れた最適化と変換を実行しました. 同時に、DLA データベース分析はコンピューティング エンジン上にあります (TPC-DS を使用)世界第 1 位) AnalyticDB 共有コンピューティング エンジン) は、Presto のネイティブ コンピューティング エンジンよりも数十倍高速であり、DG の分析パフォーマンスも大幅に向上します。

5.2 ゲーム操作分析

データ レイクは、優れた TCO パフォーマンスを備えた一種のビッグ データ インフラストラクチャです。多くの急成長中のゲーム会社にとって、爆発的なゲームの関連データは短期間で非常に急速に増加することが多く、同時に、会社の研究開発担当者の技術スタックがその増加と成長率に対応することは困難です。短期的なデータの増加; 現時点では、データの爆発的な増加を有効に活用することは困難です。データレイクは、このような問題を解決するためのテクノロジーの選択肢です。

YJ は急速に成長しているゲーム会社であり、関連するユーザーの行動データに基づいて詳細な分析を行い、ゲームの開発と運用を導きたいと考えています。データ分析の背後にあるコア ロジックは、ゲーム業界での市場競争の拡大に伴い、プレイヤーの品質に対する要求がますます高くなり、ゲーム プロジェクトのライフ サイクルがますます短くなり、プロジェクトの入出力比率に直接影響するというものです。プロジェクトのライフ サイクルを効果的に延長し、各段階のビジネス トレンドを正確に制御できます。

トラフィックのコストが増加するにつれて、ビジネス開発をより適切にサポートするために、経済的で効率的な洗練されたデータ操作システムを構築する方法がますます重要になっています。データ操作システムには、それを支えるインフラが必要であり、そのようなインフラをどのように選択するかは、会社の技術的な意思決定者が考える必要がある問題です。思考の出発点は次のとおりです。

  1. 十分な柔軟性を持ってください。ゲームの場合、それはしばしば短期間のバーストであり、データ量が急増します。したがって、データの爆発的な増加に適応し、弾力的な要件を満たすことができるかどうかが重要な考慮事項です。コンピューティングであろうとストレージであろうと、十分な柔軟性を持つこと。

  2. お金に見合うだけの価値がなければなりません。ユーザーの行動データについては、継続率などの分析と比較のために長期間にわたってデータを引き出す必要があることがよくあります. 多くの場合、90 日または 180 日間の顧客維持率を考慮する必要があります; したがって、どのように最も費用対効果の高い方法で長期間保存する 大量のデータは重要な考慮事項です。

  3. 十分な分析機能とスケーラビリティが必要です。多くの場合、ユーザーの行動は埋もれたポイントデータに反映されており、ユーザー登録情報やログイン情報、請求書などの構造化データと関連付けて分析する必要があるため、データ分析では、少なくともビッグデータの ETL 機能、アクセス異種データ ソースの機能と複雑な分析のモデリング機能。

  4. これは、会社の既存の技術スタックと一致し、将来の採用を容易にする必要があります。YJ にとって、技術を選択する際の重要なポイントは、技術者の技術スタックです.YJ の技術チームのほとんどは、MySQL という従来のデータベース開発に精通しており、マンパワーはタイトであり、データ操作分析を行う技術者は 1 人しかいません。しかし、短期間でビッグデータ分析のためのインフラを独自に構築する能力はまったくありません。YJ の観点からは、ほとんどの分析が SQL で実行できることが最善であり、求人市場では SQL 開発者の数がビッグデータ開発エンジニアの数よりもはるかに多くなっています。お客様の状況に応じて、既存プログラムの変革をお手伝いします。


                                      図 18. 改造前のスキーム

変換前は、顧客の構造化データはすべて高水準の MySQL に保存されていましたが、プレイヤーの行動データは LogTail を介してログ サービス (SLS) に収集され、ログ サービスから OSS と ES にそれぞれ配信されていました。 . このアーキテクチャの問題点は次のとおりです。

  1. 行動データと構造化データは完全に分離されており、一緒に分析することはできません。

  2. 行動データの検索機能をインテリジェントに提供し、詳細なマイニング分析を行うことはできません。

  3. OSS はデータ ストレージ リソースとしてのみ使用され、十分なデータ価値をマイニングしません。

実際、お客様の既存のアーキテクチャを分析したところ、データ レイクのプロトタイプがすでに存在していました。データの全量が OSS に保存されており、OSS でデータを分析するお客様の能力をさらに補完する必要があります。 . さらに、データ レイクの SQL ベースのデータ処理モードは、テクノロジ スタックを開発する顧客のニーズにも対応します。要約すると、お客様がデータ レイクを構築できるように、お客様のアーキテクチャに次の調整を加えました。


                              図 19. 変換されたデータ レイク ソリューション

一般的に、顧客のデータリンクの流れは変更しませんでしたが、OSS データの 2 次処理を実行するために、OSS ベースの DLA コンポーネントを追加しました。DLA は、標準の SQL コンピューティング エンジンを提供し、さまざまな異種データ ソースへのアクセスをサポートします。DLA に基づいて OSS データを処理した後、ビジネスで直接使用できるデータを生成します。ただし、DLA の問題点は、低遅延が要求される対話型分析シナリオをサポートできないことです.この問題を解決するために、クラウドネイティブのデータ ウェアハウスである ADB を導入して、対話型分析の遅延の問題を解決しました.同時に、では、お客様向けの可視化分析ツールとして、フロントエンドにQuickBIを導入しました。YJ ソリューションは、図 14 に示す統合レイクおよびウェアハウス ソリューションのゲーム業界での典型的な実装例です。

YM は、さまざまな中小企業向けに一連のデータ分析および運用サービスを提供するデータ インテリジェンス サービス プロバイダーです。特定の実装の技術的なロジックを次の図に示します。


                                                   図 20. YM インテリジェント データ サービス SaaS モデルの概略図

プラットフォーム側は、ユーザー(企業がWebページ、APP、アプレットなどのアクセスフォームを提供する)がさまざまな埋もれたデータにアクセスするためのマルチエンドSDKを提供し、プラットフォーム側は統合されたデータアクセスサービスとデータ分析サービスをSaaSの形で提供します。加盟店は、さまざまなデータ分析サービスにアクセスして、より詳細なデータ分析を実行し、行動統計、顧客ポートレート、顧客サークルの選択、広告配置の監視などの基本的な分析機能を完了することができます。ただし、この SaaS モデルにはいくつかの問題があります。

  1. 加盟店の種類やニーズの多様化により、販売を重視する加盟店もあれば、顧客業務を重視する加盟店もあるなど、あらゆる加盟店をカバーし、加盟店のカスタマイズされたニーズを満たすSaaS分析機能をプラットフォームで提供することは困難です。 、および満たすのが難しいコストの最適化に重点を置いているものもあります。

  2. カスタムタグに依存するカスタマーサークルの選択、顧客定義の拡張機能、およびその他の機能など、一部の高度な分析機能については、統合データ分析サービスではそれらを満たすことができません; 特に、一部のカスタムタグは、マーチャントによってカスタマイズされたアルゴリズムに依存しているため、満足することはできません。 . クライアントの高度な分析ニーズ。

  3. データ資産管理のニーズ。ビッグデータ時代において、データは企業・組織の資産であることは誰もが認めるところですが、加盟店に属するデータをいかに合理的かつ長期的に定着させるかは、SaaSサービスにおいても考えなければならないことです。 .

以上をまとめると、上図の基本モデルにデータレイクモデルを導入することで、加盟店がデータを蓄積し、モデルを出力し、分析・運用するための基本的な支援施設としてデータレイクを利用できるようになります。データレイク導入後のSaaSデータインテリジェンスサービスモデルは以下の通りです。


                                                        図 21. データレイクベースのデータ インテリジェンス サービス

図 21 に示すように、プラットフォームは各ユーザーにワンクリック レイク構築サービスを提供し、マーチャントはこの機能を使用して独自のデータ レイクを構築します。データレイクに完全に同期され、毎日の増分データが「T+1」モードに基づいてレイクにアーカイブされます。従来のデータ分析サービスに基づいて、データ レイク ベースのサービス モデルは、データ資産化、分析モデリング、およびサービスのカスタマイズという 3 つの主要な機能をユーザーに提供します。

  1. データの大文字化機能。データレイクを使用して、マーチャントは独自のデータを引き続き預けることができ、データの保存期間と費用は完全にマーチャントが決定します。データ レイクはデータ資産管理機能も提供します. マーチャントは、生データの管理に加えて、処理されたプロセス データと結果データをさまざまなカテゴリに保存することもできます。これにより、埋もれたデータの価値が大幅に向上します.

  2. 分析モデリング機能。データレイクには生データだけでなく、埋もれたデータのモデル (スキーマ) もあります。埋没点データ モデルは、グローバル データ インテリジェンス サービス プラットフォームのビジネス ロジックの抽象化を反映しています.データ レイクを介して、元のデータを資産として出力するだけでなく、データ モデルも出力します.埋没点データの助けを借りてモデル、マーチャントはより深い理解を持つことができます埋もれたポイントデータの背後にあるユーザーの行動ロジックは、マーチャントが顧客の行動をよりよく理解し、ユーザーのニーズを得るのに役立ちます.

  3. サービスのカスタマイズ機能。データ レイクが提供するデータ統合およびデータ開発機能を使用して、埋もれたポイント データ モデルの理解に基づいて、マーチャントはデータ処理プロセスをカスタマイズし、元のデータを継続的に反復処理し、データから貴重な情報を抽出し、最終的にデータを取得することができます。元のデータを超えるデータ分析サービスの価値。

 6. データレイク構築の基本プロセス

個人的には、データレイクは従来のビッグデータプラットフォームよりも完成度の高いビッグデータ処理基盤支援施設であり、完璧なデータレイクとはお客様のビジネスにより近い技術的存在であると考えています。すべてのデータ レイクには、メタデータ、データ資産カタログ、権利管理、データ ライフサイクル管理、データ統合とデータ開発、データ ガバナンスと品質管理など、ビッグ データ プラットフォームの存在を超える機能が含まれています。使用する顧客。弾力性、ストレージとコンピューティングの独立した拡張、統合ストレージ エンジン、マルチモード コンピューティング エンジンなど、データ レイクによって強調されるいくつかの基本的な技術的機能も、ビジネス ニーズを満たし、ビジネス パーティに最も費用対効果の高いものを提供します。 TCO。

データ レイクの構築プロセスは、ビジネスと密接に統合する必要がありますが、データ レイクの構築プロセスは、従来のデータ ウェアハウスや一般的なデータ センターとは異なる必要があります。違いは、データ レイクをよりアジャイルな方法で構築する必要があることです。「構築しながら使用し、使用しながら管理する」ということです。データ レイク構築の俊敏性をよりよく理解するために、まず従来のデータ ウェアハウスの構築プロセスを見てみましょう。業界では、従来のデータ ウェアハウスの構築に「ボトムアップ」と「トップダウン」の 2 つのモードが提案されており、それぞれ Inmon と KimBall によって提案されました。具体的なプロセスについては詳しく説明しません。それ以外の場合は数百ページを超える可能性があるため、ここでは基本的なアイデアのみを簡単に説明します。

  • Inmon は、ボトムアップ (EDW-DM) データ ウェアハウス構築モデルを提案します。つまり、運用システムまたはトランザクション システムのデータ ソースが抽出され、変換され、ETL を介してデータ ウェアハウスの ODS レイヤーにロードされます。ODS レイヤーのデータは、事前に設計された EDW (エンタープライズ データ ウェアハウス) パラダイムに従って処理され、EDW に入ります。EDW は一般に、企業/組織向けの一般的なデータ モデルであり、上位層のアプリケーションが直接データ分析を行うのは不便です。したがって、各ビジネス ユニットは、それぞれのニーズに応じて、EDW からのデータ マート レイヤー (DM) を再度処理します。

    長所:メンテナンスが容易で統合性が高い 短所:一度体制が決まると柔軟性に欠ける、業務に適応するための導入サイクルが長い。このように構築されたデータ ウェアハウスは、金融などの比較的成熟した安定したビジネスに適しています。

  • KimBall は、データ ソースを運用システムまたはトランザクション システムから ODS レイヤーに抽出またはロードすることにより、トップダウン (DM-DW) データ アーキテクチャを提案します。次に、ODS のデータを介して、次元モデリング手法を使用して多次元サブジェクト データ マート (DM) を構築します。さまざまな DM が一貫したディメンションを通じてリンクされ、最終的に企業/組織の共通のデータ ウェアハウスを形成します。

    長所: 迅速な構築、最速の投資収益率、敏捷性と柔軟性; 短所: エンタープライズ リソースとして、維持が容易ではなく、構造が複雑で、データ マートの統合が困難です。中小企業やインターネット業界でよく使われます。

実は上記はあくまで理論上のプロセスであり、EDWを構築するにしてもDMを構築するにしても、データを徹底的に理解し、データウェアハウスを構築する前にデータモデルを設計することと切り離すことはできません。今話題の「データインデータ台湾」では、下図に示す基本的な構築プロセスから逃れることはできません。


                                      Figure 22. データウェアハウス・データセンター構築の基本プロセス

  1. データ掘り。企業/組織にとって、データ レイクを構築するための最初の作業は、データ ソース、データ タイプ、データ フォーム、データ パターン、合計データ、およびデータを含む、企業/組織内のデータに関する包括的な調査と研究を実施することです。成長量等 この段階での暗黙的かつ重要な作業は、データを使用して企業の組織構造をさらに整理し、データと組織構造の関係を明らかにすることです。これは、将来のユーザーの役割、権限の設計、およびデータ レイクのサービス方法を明確にするための基礎を築きます。

  2. モデルの抽象化。企業・組織の業務特性に応じて、さまざまな種類のデータを分類・分類し、フィールドに分割してデータ管理のためのメタデータを形成すると同時に、メタデータに基づいて一般的なデータモデルを構築します。

  3. データアクセス。最初の手順の結果に従って、アクセスするデータ ソースを決定します。データ ソースに応じて、必要なデータ アクセス技術の機能を決定し、データ アクセス技術の選択を完了します。アクセスするデータには、少なくともデータ ソース メタデータ、元のデータ メタデータ、および元のデータが含まれます。あらゆる種類のデータは、第 2 段階で形成された結果に従って分類され、保存されます。

  4. 統合されたガバナンス。簡単に言えば、データレイクが提供するさまざまなコンピューティングエンジンを使用してデータを処理し、さまざまな中間データ/結果データを作成し、適切に管理および保存します。データ レイクには、完全なデータ開発、タスク管理、タスク スケジューリング機能があり、データ処理プロセスを詳細に記録する必要があります。ガバナンスの過程で、より多くのデータ モデルと指標モデルが必要になります。

  5. ビジネス支援。一般的なモデルに基づいて、各ビジネス部門は独自の詳細なデータ モデル、データ使用プロセス、およびデータ アクセス サービスをカスタマイズします。

上記のプロセスは、急成長しているインターネット企業にとっては重すぎて、多くの場合、実装できません. 最も現実的な問題は、モデルの抽象化の第 2 段階です. 多くの場合、ビジネスは試行錯誤と探索です.将来の方向性を知らずに一般的なデータ モデルを抽出することは不可能です. データ モデルがなければ、その後のすべての操作が不可能になります. これは、多くの急成長企業がデータ ウェアハウス/データ ミドル プラットフォームを実装できないと感じている理由でもあります.需要に応えられない重要な理由。

A data lake should be a more "agile" way to build a data lake. データ レイクを構築するには、次の手順をお勧めします。


                                              図 23. データレイク構築の基本プロセス

図 22 と比較すると、まだ 5 つのステップがありますが、これらの 5 つのステップは包括的な単純化と「着陸可能」な改善です。

  1. データ掘り。データソース、データ型、データ形式、データモード、データの総量、データの増分など、データの基本的な状況を把握する必要があります。ただし、それは実行する必要があることです。データレイクは元のデータをすべて保存するためのものであるため、事前に詳細な設計を行う必要はありません。

  2. 技術選択。データの状況に応じて、データレイク構築の技術的な選択を決定します。実際、このステップも非常にシンプルで、データレイク技術の選択に関して業界では多くの一般的な慣行があるため、個人的には、「コンピューティングとストレージの分離」、「弾力性」、および「独立した拡張」の 3 つの基本原則をお勧めします。 "。推奨されるストレージの選択は、分散オブジェクト ストレージ システム (S3/OSS/OBS など) です。実際には、これら 2 種類の機能がコンピューティング エンジンの鍵となるため、バッチ処理要件とコンピューティング エンジンの SQL 処理機能に焦点を当てることをお勧めします。データ処理 ストリーム コンピューティング エンジンについては後で説明します。コンピューティングでもストレージでも、サーバーレスの形を優先することをお勧めしますが、将来的には、アプリケーションで徐々に進化させることができ、独立したリソース プールが本当に必要であり、専用のクラスターを構築することを検討してください。

  3. データアクセス。アクセスするデータ ソースを決定し、完全なデータ抽出と増分アクセスを完了します。

  4. アプリケーション ガバナンス。このステップがデータレイクの鍵であり、私は個人的に「統合ガバナンス」を「アプリケーションガバナンス」に変更しました。データ レイクの観点からは、データ アプリケーションとデータ ガバナンスは統合され、不可分である必要があります。データの適用に着手し、アプリケーションの要件を明確にし、データ ETL のプロセスでビジネスで使用できるデータを徐々に形成すると同時に、データ モデル、指標システム、および対応する品質基準を形成します。データレイクは、生データの保存とデータの探索的分析と応用を重視していますが、これはデータレイクにデータモデルが必要ないという意味ではなく、逆にビジネスの理解と抽象化が開発を大きく促進します。データ レイクおよびアプリケーションのデータ レイク テクノロジーは、データの処理とモデリングを可能にし、優れた俊敏性を維持し、ビジネスの発展と変化に迅速に適応することができます。

技術的な観点から見ると、データ レイクはビッグ データ プラットフォームとは異なり、完全なライフ サイクル管理とデータの適用をサポートするために、データ レイクには比較的完全なデータ管理、カテゴリ管理、プロセス オーケストレーション、タスク スケジューリング、データ トレーサビリティ、データ ガバナンス、品質管理、権限管理、およびその他の機能。コンピューティング能力に関しては、現在の主流のデータ レイク ソリューションは、SQL とプログラム可能なバッチ処理モードの両方をサポートしています (機械学習のサポートには、Spark または Flink の組み込み機能を使用できます)。処理パラダイムに関しては、ほとんどすべてが Towards を使用します。非巡回グラフのワークフローパターンに対応し、対応する統合開発環境を提供します。ストリーム コンピューティングのサポートについては、現在、さまざまなデータ レイク ソリューションがさまざまなアプローチを採用しています。具体的な方法について説明する前に、フロー コンピューティングを分類してみましょう。

  1. モード 1: リアルタイム モード。このストリーム コンピューティング モードは、「1 つずつ」または「マイクロ バッチ」方式でデータを処理することと同等であり、リスク管理、推奨、早期警告などのオンライン ビジネスでより一般的です。

  2. モード 2: クラス ストリーミング。このモードは、指定された時点以降に変更されたデータを取得する/特定のバージョンのデータを読み取る/現在の最新データを読み取るなどの必要があります。これはストリームのようなモードであり、分析などのデータ探索アプリケーションでより一般的です。一定期間 日々の活動、保持、転換など

この 2 つの基本的な違いは、モード 1 がデータを処理する場合、データは多くの場合データ レイクに保存されず、ネットワーク/メモリ内を流れるだけであるということです。モード 2 がデータを処理する場合、データはすでにデータ レイクに保存されています。要約すると、個人的には次のパターンをお勧めします。


                                                         図 24 データ レイク内のデータ フローの概略図


図 24 に示すように、データ レイクにモード 1 の処理能力が必要な場合でも、データ転送用のインフラストラクチャとして Kafka のようなミドルウェアを導入する必要があります。完全なデータ レイク ソリューションは、生データを Kafka にストリーミングする機能を提供する必要があります。ストリーミング エンジンには、Kafka のようなコンポーネントからデータを読み取る機能があります。データを処理した後、ストリーミング コンピューティング エンジンは、必要に応じてアプリケーション アクセス用に結果を OSS/RDBMS/NoSQL/DW に書き込むことができます。ある意味では、モード 1 のストリーム コンピューティング エンジンは、必ずしもデータ レイクの不可分な部分として存在する必要はなく、アプリケーションが必要とするときに簡単に導入する必要があるだけです。ただし、ここで指摘する必要があります。

  1. ストリーミング エンジンは、データ レイクのメタデータを簡単に読み取れる必要があります。

  2. ストリーミング エンジンのタスクも、データ レイクのタスク管理に統合する必要があります。

  3. ストリーミング タスクは、統合された権限管理に組み込む必要があります。

モード 2 の場合、本質的にバッチ処理に近くなります。現在、多くの古典的なビッグ データ コンポーネントは、HUDI/IceBerg/Delta などのサポート メソッドを提供しており、すべてが Spark や Presto などの古典的なコンピューティング エンジンをサポートしています。HUDI を例にとると、特殊なタイプのテーブル (COW/MOR) をサポートすることで、スナップショット データ (指定されたバージョン)、増分データ、および準リアルタイム データにアクセスする機能が提供されます。現在、AWS、Tencent などは HUDI を EMR サービスに統合しており、Alibaba Cloud の DLA も HUDI で DLA の機能を開始する予定です。

この記事の最初の章に戻りましょう、データ レイクの主なユーザーはデータ サイエンティストとデータ アナリストであり、探索的分析と機械学習はこのグループの人々にとって一般的な操作であると述べました。モード) 主にオンライン ビジネスに使用されます. 厳密に言えば、データ レイクのターゲット ユーザーにとって厳密に必要なものではありません. ただし、ストリーム コンピューティング (リアルタイム モード) は現在、ほとんどのインターネット企業のオンライン ビジネスの重要な部分であり、データ レイクは、企業/組織内の集中型データ ストレージの場所として、一定のスケーラビリティを維持する必要があります。ストリーミング コンピューティング機能を組み込むように拡張できます。

ビジネス支援。ほとんどのデータ レイク ソリューションは、JDBC などの標準的なアクセス インターフェイスを提供しますが、市販されているさまざまな一般的な BI レポート ツールや大画面ツールも、データ レイク内のデータに直接アクセスできます。ただし、実際のアプリケーションでは、処理されたデータをデータ レイクからオンライン サービスをサポートする対応するデータ エンジンにプッシュすることをお勧めします。これにより、アプリケーションのエクスペリエンスが向上します。

7. まとめ

新世代のビッグデータ分析および処理のインフラストラクチャとして、データ レイクは従来のビッグデータ プラットフォームを超える必要があります。個人的には、次の側面が将来のデータレイク ソリューションの可能な開発方向であると考えています。

1. クラウド ネイティブ アーキテクチャ。クラウド ネイティブ アーキテクチャとは何かについてはさまざまな意見があり、統一された定義を見つけるのは困難です。しかし、データレイクのシナリオになると、個人的には次の3つの特徴だと思います。

(1) ストレージとコンピューティングを分離し、コンピューティング能力とストレージ容量を独立して拡張できます。

(2) マルチモーダル コンピューティング エンジンのサポート、SQL、バッチ処理、ストリーミング コンピューティング、機械学習など。

(3) 十分な弾力性を確保し、従量制をサポートするサーバーレス サービスを提供します。

2. 十分なデータ管理機能。データ レイクは、データ ソース管理、データ カテゴリ管理、処理フロー オーケストレーション、タスク スケジューリング、データ トレーサビリティ、データ ガバナンス、品質管理、権限管理などを含むがこれらに限定されない、より強力なデータ管理機能を提供する必要があります。

3. ビッグデータの能力、データベースの経験。現在、大多数のデータ分析者はデータベースの使用経験しかありません.ビッグデータプラットフォームの機能は強力ですが、ユーザーフレンドリーではありません.データサイエンティストとデータ分析者は、データ、アルゴリズム、モデル、およびそれらの関係に注意を払う必要があります.ビッグ データ プラットフォームの開発を学ぶために多くの時間とエネルギーを費やす代わりに、データレイクが急速に発展するためには、いかにユーザーに良い体験を提供できるかが鍵となります。SQL ベースのデータベース アプリケーション開発は、人々の心に深く根付いており、SQL の形でデータ レイクの機能をどのように解放するかは、今後の主要な方向性です。

4. 完全なデータ統合とデータ開発機能。さまざまな異種データ ソースの管理とサポート、異種データの完全/増分移行のサポート、およびさまざまなデータ形式のサポートは、継続的に改善する必要がある方向性です。同時に、完全で視覚的で拡張可能な統合開発環境が必要です。

5. ビジネスとの深い統合と統合。典型的なデータ レイク アーキテクチャの構成は、基本的に業界のコンセンサスになっています。分散オブジェクト ストレージ + マルチモーダル コンピューティング エンジン + データ管理です。データ レイク ソリューションの成功の鍵はデータ管理にあります. 生データの管理、データ カテゴリの管理、データ モデルの管理、データ権限の管理、または処理タスクの管理のいずれであっても、ビジネスへの適応および統合と切り離すことはできません。将来的には、データ サイエンティストやデータ アナリストとの健全な開発と相互作用を形成するために、ますます多くの業界データ レイク ソリューションが登場するでしょう。業界データ モデル、ETL プロセス、分析モデル、およびカスタマイズされたアルゴリズムをデータ レイク ソリューションにどのように事前設定するかは、将来のデータ レイク分野での差別化された競争の重要なポイントになる可能性があります。

おすすめ

転載: blog.csdn.net/ytp552200ytp/article/details/125987504