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

この記事には 7 つのサブセクションが含まれています: 1. データレイクとは; 2. データレイクの基本特性; 3. データレイクの基本アーキテクチャ; 4. さまざまなベンダーのデータレイクソリューション; 5. 一般的なデータレイクアプリケーションシナリオ; 6. データ湖建設の基本プロセス; 7. まとめ。個人のレベルに制限があるため、間違いは避けられませんが、学生は一緒に話し合ったり、批判したり修正したりすることを歓迎し、遠慮なく教えることができます。

1. データレイクとは何ですか

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

Wikipediaによると、データレイクとは、データを自然/元の形式で保存するシステムまたはストレージの一種であり、通常はオブジェクトブロックまたはファイルであり、元のシステムによって生成された生データのコピーや、関係からのものを含むさまざまなタスクのために変換されたデータが含まれます。データ (行と列)、半構造化データ (CSV、ログ、XML、JSON など)、非構造化データ (電子メール、ドキュメント、PDF など)、バイナリデータ (画像、音声、ビデオなど)。

AWS は、データレイクを、あらゆる規模のすべての構造化データと非構造化データを保存できる集中リポジトリとして定義します。

Microsoft の定義はさらに曖昧です。データレイクとは何かを明確に示していませんが、データレイクの機能を定義として取り上げています。データレイクには、開発者、データサイエンティスト、アナリストが保存しやすくするものすべてが含まれています。データの処理: これらの機能により、ユーザーはあらゆるサイズ、タイプ、速度のデータを保存し、プラットフォームや言語を超えてあらゆる種類の分析と処理を実行できます。

データレイクには実際には多くの定義がありますが、基本的には次の特性を中心に展開されます。

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

2. データレイクは、構造化データ、半構造化データ、非構造化データなど、あらゆる種類の大量のデータを保存できます。

3. データレイク内のデータは元のデータであり、ビジネスデータの完全なコピーです。データレイク内のデータは、ビジネスシステム内で元の外観を維持します。

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

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

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

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

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

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

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

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

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

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

2. データレイクの基本特性

データレイクの概念を基本的に理解した後、データレイクにどのような基本特性が必要か、特にビッグデータプラットフォームや従来のデータウェアハウスと比較してデータレイクがどのような特性を持っているかをさらに明確にする必要があります。具体的な分析の前に、AWS 公式 Web サイトの比較表を見てみましょう (表の引用元: https://aws.amazon.com/cn/big-data/datalakes-and-analytics/what-is-a) -データ -レイク/)

上の表はデータレイクと従来のデータウェアハウスの違いを比較したものですが、個人的にはデータとコンピューティングの2つのレベルからデータレイクの特徴をさらに分析できるのではないかと考えています。データに関しては:

1) 「忠実さ」。データレイクには、ビジネスシステム内のデータの「まったく同じ」完全なコピーが保存されます。データウェアハウスとの違いは、元のデータのコピーをデータレイクに保存する必要があり、データ形式、データモード、データコンテンツに関係なく変更する必要があることです。この点で、データレイクは「本物の」ビジネスデータの保存を重視しています。同時に、データレイクはあらゆる種類/形式のデータを保存できる必要があります。

2) 「柔軟性」: 上の表のポイントの 1 つは、「書き込みスキーマ」と「読み取りスキーマ」です。実際、これは本質的に、データスキーマの設計がどの段階で行われるかという問題です。あらゆるデータアプリケーションにとって、スキーマの設計は実際には不可欠であり、「スキーマレス」を重視する mongoDB などの一部のデータベースであっても、ベストプラクティスでは、レコードが可能な限り同じ/類似した構造を使用することが推奨されています。「書き込みスキーマ」の背後にあるロジックは、データを書き込む前に、ビジネスのアクセス方法に応じてデータのスキーマを決定し、確立されたスキーマに従ってデータのインポートを完了する必要があるというものですが、これは、データウェアハウスの初期所有コストが比較的高くなるということも意味します。特にビジネスモデルが明確でなく、ビジネスがまだ探索段階にある場合、データウェアハウスの柔軟性が十分ではありません。

データレイクによって強調される「可読スキーマ」の背後にある根本的なロジックは、ビジネスの不確実性は正常であるということです。ビジネスの変化を予測することはできないため、ある程度の柔軟性を維持し、インフラストラクチャ全体がデータを「オンデマンド」でビジネスに適合させます。したがって、「忠実性」と「柔軟性」は同列にあると個人的には考えています。ビジネスの変化を予測する方法はないので、データを最もオリジナルの状態に保ち、必要に応じてデータを処理できるようにするだけです。ニーズに合わせて。したがって、データレイクは、革新的な企業やビジネスの変化や発展が急速な企業に適しています。同時に、データレイクのユーザーの要件も高く、データサイエンティストとビジネスアナリスト (特定の視覚化ツールを使用) がデータレイクのターゲット顧客です。

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

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

コンピューティングに関しては、データレイクにはコンピューティング機能に対する非常に広範な要件があり、それはすべてビジネスのコンピューティング要件に依存すると個人的に考えています。

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

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

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

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

１）第１段階：Hadoopに代表されるオフラインデータ処理インフラ。以下の図に示すように、Hadoop は、コアストレージとして HDFS、基本的なコンピューティングモデルとして MapReduce (略称 MR) を備えたバッチデータ処理インフラストラクチャです。HDFS と MR を中心に、オンライン KV 操作用の HBase、SQL 用の HIVE、ワークフロー用の PIG など、ビッグデータプラットフォーム全体のデータ処理機能を継続的に向上させるための一連のコンポーネントが作成されています。同時に、バッチ処理に対する各人のパフォーマンス要求がますます高くなるにつれて、新しいコンピューティングモデルが常に提案され、Tez、Spark、Presto などのコンピューティングエンジンが生み出され、MR モデルは徐々に進化してきました。 DAGモデル。一方では、DAG モデルは計算モデルの抽象的な同時実行能力を高めます: 各計算プロセスが分解され、タスクは計算プロセス内の集計操作ポイントに従って論理的に分割され、タスクは 1 つずつステージに分割されます。、各ステージは 1 つ以上のタスクで構成され、同時に実行できるため、計算プロセス全体の並列性が向上します。一方で、データ処理の中間結果をファイルに書き込む操作を減らすために、プロセスでは、Spark や Presto などの計算エンジンが可能な限り計算を使用し、ノードのメモリにデータがキャッシュされるため、データプロセス全体の効率とシステムスループットが向上します。

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

2) 第 2 段階: ラムダアーキテクチャ。データ処理機能と処理要件が継続的に変化するため、バッチ処理モードでパフォーマンスが向上しても、リアルタイム要件の高い一部の処理シナリオには対応できないことに気づくユーザーが増えています。時代の要求に応じてストリーミングコンピューティングエンジンが登場し、 Storm、Spark Streaming、Flink など。しかし、ますます多くのアプリケーションがオンラインになるにつれて、バッチ処理とストリームコンピューティングを組み合わせれば、ほとんどのアプリケーションのニーズを満たすことができることに誰もが気づき、ユーザーにとっては、実際には基礎となるコンピューティングモデルを気にする必要がなくなりました。バッチ処理やストリームコンピューティングは統一されたデータモデルに基づいて処理結果を返すことができるため、以下の図に示すようなLambdaアーキテクチャが提案されました。(トラブルを避けるために、ラムダアーキテクチャとカッパアーキテクチャ図の両方をインターネットから入手しました)

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

Lambda アーキテクチャの中心的な概念は「フローとバッチの統合」であり、上の図に示すように、データフロー全体が左から右にプラットフォームに流れ込みます。プラットフォームに入ると、2 つの部分に分かれており、1 つの部分はバッチ処理モードを採用し、もう 1 つの部分はストリーミングコンピューティングモードを採用します。コンピューティングモードに関係なく、最終的な処理結果はサービス層を通じてアプリケーションに提供され、アクセスの一貫性が保証されます。

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

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

要約すると、従来の Hadoop アーキテクチャからラムダアーキテクチャへ、ラムダアーキテクチャから Kappa アーキテクチャの進化へと、ビッグデータプラットフォームインフラストラクチャの進化には、アプリケーションに必要なあらゆる種類のデータ処理機能が徐々に含まれ、ビッグデータプラットフォームは、企業/組織の完全なデータ処理プラットフォームに徐々に進化しました。現在の企業実務では、さまざまな独立したビジネスシステムに依存するリレーショナルデータベースを除き、残りのデータはほぼすべてビッグデータプラットフォームに組み込まれ、統合処理されると考えられています。しかし、現在のビッグデータ基盤インフラはストレージとコンピューティングに重点が置かれ、データの資産管理は無視されており、これこそが新世代のビッグデータ基盤であるデータレイクが注力する方向の1つです。

実は、ビッグデータインフラの進化には、企業・組織内でデータが重要な資産であるという認識が定着しており、データをより有効に活用するためには、データ資産をそのまま保管しておく必要があるという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 は、Athena/Redshift を介した SQL ベースのインタラクティブなバッチ処理機能の提供など、さまざまな外部コンピューティングエンジンを通じて豊富なコンピューティングモードのサポートを提供します。Spark のコンピューティング機能には、Spark が提供するストリームコンピューティング機能と機械学習機能が含まれます。提供することができます。

5) 権限管理。

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

Lake Formation の権限は、データリソースディレクトリのアクセス権限と基礎となるデータアクセス権限にさらに分割でき、それぞれメタデータと実際に保存されているデータに対応します。実際に保存されているデータへのアクセス権は、データアクセス権とデータストレージアクセス権にさらに分類されます。データアクセス権限は、データベース内のデータベーステーブルに対するアクセス権限に似ていますが、データストレージ権限は、S3 の特定のディレクトリに対するアクセス権限をさらに調整します (明示的と暗黙的な 2 つのタイプに分けられます)。図8に示すように、ユーザーAはデータアクセスのみの権限ではS3の指定バケット配下にテーブルを作成できません。

個人的には、これはデータレイクがさまざまなストレージエンジンをサポートする必要があることをさらに反映していると思います. 将来のデータレイクは、S3/OSS/OBS/HDFS などのコアストレージだけでなく、アクセスに応じてさらに多くの種類のストレージエンジンを組み込む可能性がありますたとえば、S3 は生データを保存し、NoSQL は「キー/値」モードでのアクセスに適した処理済みデータを保存し、OLAP エンジンはさまざまなレポート/アドホッククエリをリアルタイムで生成する必要があるデータを保存します。現在、あらゆる種類の資料がデータレイクとデータウェアハウスの違いを強調していますが、本質的には、データレイクはある種の統合データ管理アイデアを具体的に実現したものであるはずであり、「レイクとウェアハウスの統合」はおそらくそうなるでしょう。今後の発展傾向。

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

要約すると、AWS データレイクソリューションは、特にメタデータ管理と権限管理の点で非常に成熟しており、異種データソースとさまざまなコンピューティングエンジンの間の上流と下流の関係をオープンにし、データを自由に「移動」できるようにしています。フローコンピューティングと機械学習の点でも、AWS のソリューションは比較的完成度が高いです。フローコンピューティングの観点から、AWS は特別なフローコンピューティングコンポーネントである Kinesis を開始しました。Kinesis の Kinesis data Firehose サービスは、フルマネージドのデータ配信サービスを作成できます。Kinesis data Stream を通じてリアルタイムで処理されたデータは、次の方法で S3 に簡単に書き込むことができます。 Firehose の助けを借りて、JSON から Parquet 形式への変換など、対応する形式変換をサポートします。AWS ソリューション全体の最も優れた点は、Kinesis が GLUE のメタデータにアクセスできることです。これは、AWS データレイクソリューションの生態学的完全性を完全に反映しています。同様に、機械学習に関しては、AWS が SageMaker サービスを提供しており、SageMaker は S3 のトレーニングデータを読み取り、トレーニングされたモデルを S3 に書き戻すことができます。ただし、AWS のデータレイクソリューションでは、フローコンピューティングと機械学習が固定的にバンドルされているわけではなく、簡単に統合できるコンピューティング機能の拡張にすぎないことを 1 つ指摘しておく必要があります。

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

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

要約すると、AWS のデータレイクソリューションは、品質管理とデータガバナンスを除くすべての機能をカバーします。実際、品質管理やデータガバナンスの業務は企業の組織構造や業態と密接に関係しており、多くのカスタム開発作業が必要となるため、一般的なソリューションにこの内容が含まれていないのは当然です。実際、Apache Griffin など、このプロジェクトをサポートするオープンソースプロジェクトは比較的優れており、品質管理やデータガバナンスに対する要求が強い場合は、自分でカスタマイズして開発することもできます。

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

図 10. Huawei データレイクソリューション

Huawei のデータレイクソリューションに関する情報は、Huawei の公式 Web サイトから入手できます。現在公式 Web サイトで公開されている関連製品には、Data Lake Insight (DLI) および Intelligent Data Lake Operation Platform (DAYU) などがあります。このうち DLI は、AWS の Lake Formation、GLUE、Athena、EMR (Flink & Spark) をまとめたものに相当します。DLI の全体的なアーキテクチャ図は公式 Web サイトで見つけることができませんでした。主に AWS のソリューションとの比較を目的として、私自身の理解に基づいて描いてみました。形式は可能な限り一貫している必要があります。 Huawei DLI についても詳しく教えてください。

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

DLI は、Huawei の CDM (クラウドデータ移行サービス) および DIS (データアクセスサービス) に接続できます。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のデータレイクソリューション全体は、データ処理のライフサイクルを完全にカバーし、データガバナンスを明確にサポートし、モデルと指標に基づいたデータガバナンスプロセスツールを提供します。HUAWEI CLOUDのデータレイクソリューションでは、徐々に「統合」の方向が始まります。湖と倉庫の「」が進化しています。

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

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

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

ソリューション全体では、依然として OSS をデータレイクの一元化ストレージとして使用しています。データソースのサポートに関しては、OLTP、OLAP、NoSQL データベースを含むすべての Alibaba Cloud データベースが現在サポートされています。主要なキーポイントは次のとおりです。

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

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

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

4) 周辺環境では、データアクセスと集約のためのさまざまな異種データソースのサポートに加えて、外部アクセス機能の点で、DLA はクラウドネイティブデータウェアハウス (旧称 ADB) と緊密に統合されています。一方で、DLA 処理の結果をオンザフライで ADB にプッシュして、リアルタイム、インタラクティブ、アドホックな複雑なクエリを満たすことができ、他方では、ADB 内のデータは、次の方法で簡単に OSS に返すこともできます。外観機能。DLA に基づいて、Alibaba Cloud 上のさまざまな異種データソースを完全に接続し、データを自由に流すことができます。

5) データの統合と開発に関して、Alibaba Cloud のデータレイクソリューションは 2 つのオプションを提供します: 1 つはデータワークスを使用して完了する方法、もう 1 つは DMS を使用して完了する方法です。どちらを選択しても、視覚的なプロセスの配置、タスクのスケジュール設定、およびタスク管理機能を外部に提供できます。データライフサイクル管理の観点から見ると、Dataworks のデータマップ機能は比較的成熟しています。

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

以下の図に示すように、データレイクソリューション全体のデータアプリケーションアーキテクチャをさらに改良します。

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

データフローの観点から左から右に、データプロデューサーはさまざまな種類のデータ (オフクラウド/オンクラウド/その他のクラウド) を生成し、さまざまなツールを使用して、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 点で緊密に統合されています。
1) 同じソース SQL 解析エンジンを使用します。DLA の SQL は ADB の SQL 構文と完全な互換性があるため、開発者は一連のテクノロジースタックを使用してデータレイクアプリケーションとデータウェアハウスアプリケーションを同時に開発できます。
2) どちらにも 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」を作成できます。 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 のデータレイクソリューションを提供しています。公式 Web サイトによると、データレイクソリューションは比較的シンプルで概念的な説明にすぎず、推奨される実装ソリューションは「oss+hadoop (EMR)」です。実際, データレイクは単純な技術プラットフォームの観点から見るべきではありません. データレイクを実装するにはさまざまな方法もあります. データレイクソリューションが成熟しているかどうかを評価するには, 重要なのはデータレイクソリューションのデータ管理機能に注目することですメタデータ、データ資産カタログ、データソース、データ処理タスク、データライフサイクル、データガバナンス、権限管理などを含むがこれらに限定されない、および周辺エコロジーと接続する機能を提供します。

5. 典型的なデータレイクのアプリケーションケース

5.1 広告データ分析

近年、トラフィック獲得のコストはますます高くなり、オンラインチャネルを通じて顧客を獲得するコストが急激に増加したため、あらゆる分野が深刻な課題に直面しています。インターネット広告費の高騰を背景に、お金をかけてトラフィックを買い、新規ユーザーを呼び込むという主要なビジネス戦略は失敗するのは必至だ。交通フロントエンドの最適化は戦いの終着点であり、データツールを使用して駅到着後の交通のターゲットコンバージョンを改善し、運用広告のさまざまなリンクを洗練することが、交通状況を変えるための最も直接的かつ効果的な方法です。現状。結局のところ、広告トラフィックのコンバージョン率を向上させるには、ビッグデータ分析に頼らなければなりません。

意思決定をより支援するためには、チャネル、配達時間、配達人数、クリックスルー率データ指標に基づくデータ分析など、より多くの埋もれたポイントデータを収集して分析する必要があります。高効率と高出力を達成するための、より効率的かつ迅速なソリューションと提案。したがって、広告分野における多次元、マルチメディア、マルチ広告スペースやその他の構造化、半構造化、非構造化データの収集、保存、分析、意思決定の要件に直面して、データレイク分析製品はソリューションは広告主またはパブリッシャーの手に委ねられており、新世代のテクノロジーの選択は非常に熱心に支持されています。

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

1) 同時実行性とピーク時の問題。広告業界では、トラフィックのピークが頻繁に発生し、瞬間的なクリック量が数万、さらには数十万に達することがあります。そのため、各クリックに迅速に応答して処理するには、システムに非常に優れたスケーラビリティが必要です。

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

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

上記 3 つのビジネス課題に対応するため、同時に顧客である DG の毎日の増分データが急速に増加しています (現在、1 日のデータスキャン量は 100 TB 以上に達しています)。AWS プラットフォームでの継続使用は Athena の課題に直面します。 S3 データの読み取りにおける帯域幅のボトルネックとデータ分析の遅延時間慎重かつ慎重なテストと分析の結果、すべてのステーションを AWS クラウドプラットフォームから Alibaba Cloud プラットフォームに再配置することが決定されました。新しいアーキテクチャ図は次のとおりです。

図 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 ソリューションとプラットフォームでは、S3 データを読み取る際のデータ読み取り帯域幅の制限に遭遇しました。 Athena。大きなボトルネックがあり、データ分析の時間がますます長くなっています。Alibaba Cloud DLA と OSS チームは、大幅な最適化と変革を実行しました。同時に、DLA データベース分析はコンピューティングエンジン (ランク付けされています) 上で行われています。世界初の TPC-DS AnalyticDB 共有コンピューティングエンジン) は、Presto のネイティブコンピューティングエンジンよりも数十倍高速であり、DG の分析パフォーマンスも大幅に向上します。

5.2 ゲーム運営分析

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

YJ は急成長しているゲーム会社であり、関連するユーザー行動データに基づいて詳細な分析を行い、ゲームの開発と運営を指導したいと考えています。データ分析の背後にある中心的なロジックは、ゲーム業界における市場競争の拡大に伴い、プレーヤーの品質に対する要求がますます高くなり、ゲームプロジェクトのライフサイクルがますます短くなり、それがゲームの入出力比に直接影響を与えるというものです。プロジェクトのライフサイクルを効果的に延長し、各段階のビジネストレンドを正確に制御できます。トラフィックコストの増加に伴い、ビジネス開発をより適切にサポートするために、経済的かつ効率的に洗練されたデータ運用システムを構築する方法がますます重要になっています。データ操作システムにはそれをサポートするインフラストラクチャが必要ですが、そのようなインフラストラクチャをどのように選択するかは、企業の技術的な意思決定者が考慮する必要がある問題です。思考の出発点は次のとおりです。

1) 十分な柔軟性を持ってください。ゲームの場合は短期的なバーストが多く、データ量が急激に増加するため、コンピューティングでもストレージでも、データの爆発的な増加に適応し、弾力的な需要に対応できるかが重要な検討ポイントとなります。、十分な柔軟性が必要です。

２）十分なコストパフォーマンスがあること。ユーザー行動データの場合、継続率など長期にわたって分析・比較する必要がある場合が多く、90日、場合によっては180日の顧客維持率も考慮する必要があるため、最もコスト効率の高い方法で長期保存する方法大量のデータは考慮する必要がある問題です。

3) 十分な分析能力と拡張性がなければなりません。埋設ポイントデータにはユーザーの行動が反映される場合が多く、分析にはユーザーの登録情報、ログイン情報、請求書などの構造化データを紐付ける必要があるため、データ分析においては少なくともETL機能が必要となるビッグデータの場合、異種データソースへのアクセス機能と複雑な分析のモデリング機能。

4) 企業の既存のテクノロジースタックと一致し、将来の採用を促進する必要があります。YJにとって、技術選定の重要なポイントは技術者の技術スタックだが、YJの技術チームのほとんどは従来のデータベース開発、つまりMySQLにしか精通しておらず、データ操作分析を行う技術者は1名のみとマンパワーが逼迫している。 1 つは、ビッグデータ分析のためのインフラを短期間で独自に構築する能力がないことです。YJ の観点からは、ほとんどの分析が SQL で実行できることが最善であり、人材採用市場では、SQL 開発者の数がビッグデータ開発エンジニアの数よりもはるかに多くなっています。お客様の状況に応じて、既存のスキームの変更をお手伝いします。

図 18. 変換前のスキーム

変換前は、顧客のすべての構造化データは高標準の MySQL に保存されていましたが、プレーヤーの行動データは LogTail を通じてログサービス (SLS) に収集され、ログサービスからそれぞれ OSS と ES に配信されました。このアーキテクチャの問題点は、1) 行動データと構造データが完全に分離されており、連鎖解析ができない、2) 行動データにはインテリジェントな検索機能があり、詳細なマイニングや分析ができない、3) OSS が存在しない、という点である。データストレージリソースとしてのみ使用されており、十分なデータ値がマイニングされていません。

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

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

基本的に、お客様のデータリンクフローは変更せず、OSS データの二次処理を実行するために OSS をベースにした DLA コンポーネントを追加しました。DLA は、標準 SQL コンピューティングエンジンを提供し、さまざまな異種データソースへのアクセスをサポートします。OSS データが DLA に基づいて処理された後、ビジネスで直接利用できるデータが生成されます。しかし、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 と Kim Ball が提案しました。特定のプロセスについては詳しく説明しません。詳しく説明しないと何百ページも書ける可能性があるため、ここでは基本的な考え方のみを簡単に説明します。

1) Inmon は、ボトムアップ (EDW-DM) データウェアハウス構築モデルを提案しています。つまり、運用システムまたはトランザクションシステムのデータソースが抽出、変換され、ETL を通じてデータウェアハウスの ODS 層にロードされます。 ODS 層は、事前に設計された EDW (Enterprise Data Warehouse) パラダイムに基づいて処理され、EDW に入力されます。EDWは一般に企業・組織の共通データモデルであり、上位層のアプリケーションが直接データ分析を行うのは不便であるため、各事業部門が必要に応じてEDWからデータマート層（DM）を再処理することになります。

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

2) KimBall は、運用システムまたはトランザクションシステムのデータソースを抽出または ODS 層にロードし、次元モデリング手法を使用して ODS データデータマートを通じて多次元テーマを構築するトップダウン (DM-DW) データアーキテクチャを提案します。 (DM)。各 DM は一貫したディメンションを通じて相互にリンクされ、最終的に企業/組織の共通のデータウェアハウスを形成します。

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

実際、上記は理論的なプロセスにすぎず、実際には、EDW を構築する場合でも DM を構築する場合でも、データウェアハウスを構築する前にデータを徹底的に理解し、データモデルを設計することが不可欠です。「台湾」の現在注目の「データ」は、下図に示す基本的な構築プロセスから逃れることはできません。

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

1) データを調べます。企業/組織の場合、データレイクを構築する最初の作業は、データソース、データタイプ、データ形式、データパターン、データボリューム、データ増分など、企業/組織内のデータに関する包括的な調査と研究を行うことです。金額などこの段階で暗黙的に重要なタスクは、データ調査作業の助けを借りて企業の組織構造をさらに整理し、データと組織構造の関係を明らかにすることです。これは、その後のユーザーの役割、権限の設計、データレイクのサービス方法を明確にするための基礎を築きます。

2) モデルの抽象化。企業・組織のビジネス特性に応じて、各種データを整理・分類し、ドメインに分割し、データ管理のためのメタデータを形成し、メタデータに基づいて一般的なデータモデルを構築します。

3) データアクセス。最初のステップの結果に従って、接続するデータソースを決定します。データソースに応じて、必要なデータアクセステクノロジ機能を決定し、データアクセステクノロジの選択を完了します。アクセスされるデータには、少なくともデータソースメタデータ、オリジナルデータメタデータ、およびオリジナルデータが含まれます。あらゆる種類のデータは、第 2 ステップで形成された結果に従って分類され、保管されます。

4) 統合されたガバナンス。簡単に言うと、データレイクが提供するさまざまなコンピューティングエンジンを利用してデータを処理し、さまざまな中間データ・結果データを形成し、それらを適切に管理・保存することです。データレイクには、包括的なデータ開発、タスク管理、タスクスケジュール機能が備わっており、データ処理プロセスを詳細に記録する必要があります。ガバナンスのプロセスでは、より多くのデータモデルと指標モデルが必要になります。

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

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

データレイクは、より「アジャイル」な構築方法である必要があるため、データレイクを構築するには次の手順をお勧めします。

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

図 22 と比較すると、まだ 5 つのステップがありますが、これらの 5 つのステップは包括的に簡略化され、「実現可能な」改善となっています。

1) データを調べます。データソース、データタイプ、データ形式、データモード、データ量、データ増分などのデータの基本的な状況を把握する必要があります。しかし、それだけです。データレイクは元データを丸ごと保存するため、事前の綿密な設計は必要ありません。

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

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

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

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

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 などが自社の EMR サービスに HUDI を統合しており、Alibaba Cloud の DLA も HUDI 上で DLA の機能を開始する予定です。

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

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

7. まとめ

次世代のビッグデータ分析と処理のインフラストラクチャとして、データレイクは従来のビッグデータプラットフォームを超える必要があります。私個人としては、データレイクソリューションの今後の発展の方向性としては次のような側面があると考えています。

1) クラウドネイティブアーキテクチャ。クラウドネイティブアーキテクチャとは何かについてはさまざまな意見があり、統一された定義を見つけるのは困難です。しかし、データレイクシナリオに関しては、(1) ストレージとコンピューティングが分離されており、コンピューティングパワーとストレージ容量を独立して拡張できる、(2) マルチモーダルコンピューティングエンジンのサポート、という 3 つの特徴があると個人的に考えています。、SQL、バッチ処理、ストリーミング (3) 十分な柔軟性を確保し、従量課金制をサポートするためにサーバーレスサービスを提供します。

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

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

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

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