【ビッグデータ】データレイク：次世代ビッグデータの開発動向

1. データレイク技術の背景

国内の大手インターネット企業は、毎日数十、数百テラバイト、さらには数ペタバイトの生データを生成しています。これらの企業は通常、オープンソースのビッグデータ コンポーネントを使用してビッグ データ プラットフォームを構築します。ビッグデータ プラットフォームは、Hadoop に代表されるオフライン データ プラットフォーム、Lambda アーキテクチャ プラットフォーム、Kappa アーキテクチャ プラットフォームの 3 つの段階を経てきました。

データ レイクは、最新世代のビッグ データ テクノロジ プラットフォームと見なすことができます。データ レイクの基本アーキテクチャをより深く理解するために、ビッグ データ プラットフォームの進化プロセスを見て、データを学習する必要がある理由を理解しましょう。湖のテクノロジー。

1.1 オフラインビッグデータプラットフォーム（第一世代）

第 1 段階: Hadoop に代表されるオフライン データ処理コンポーネント。Hadoop は、コア ストレージとして HDFS、基本コンピューティング モデルとして MapReduce を使用したバッチ データ処理の基本コンポーネントです。HDFS と MR を中心に、ビッグ データ プラットフォームのデータ処理能力を継続的に向上させるために、リアルタイム KV 操作用の HBase、SQL 用の Hive、ワークフロー用の Pig など、一連のビッグ データ コンポーネントが誕生しました。同時に、バッチ処理に対する各人のパフォーマンス要求がますます高くなるにつれて、新しいコンピューティング モデルが常に提案され、Tez、Spark、Presto などのコンピューティング エンジンが生み出され、MR モデルは徐々に進化してきました。 DAGモデル。

データ処理プロセスにおける中間結果の書き込み操作を減らすために、Spark や Presto などのコンピューティング エンジンはコンピューティング ノードのメモリを使用して可能な限りデータをキャッシュし、それによってデータ プロセス全体の効率とシステム スループットを向上させます。

1.2 ラムダアーキテクチャ

データ処理機能と処理要件が継続的に変化するため、バッチ処理モードでパフォーマンスがいかに向上しても、高いリアルタイム要件を伴う処理シナリオに対応できないことに気づくユーザーが増えています。時代の要求に応じて、ストリーミング コンピューティング エンジンが登場しました。 、Storm、Spark Streaming、Flink など。

しかし、ますます多くのアプリケーションがオンラインになるにつれて、バッチ処理とストリーム コンピューティングを併用して、ほとんどのアプリケーションのニーズを満たすことができることに誰もが気づきました。高いリアルタイム要件を持つシナリオの場合、リアルタイム ストリーム処理プラットフォームは、Flink + Kafkaユーザーのリアルタイムのニーズを満たすため。そこで、次の図に示すような Lambda アーキテクチャが提案されました。

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

この種のデータ アーキテクチャには多くのビッグ データ コンポーネントが含まれており、アーキテクチャ全体の複雑さとメンテナンス コストが大幅に増加します。

1.3 Lambda アーキテクチャの問題点

長年の開発を経て、Lambda アーキテクチャは比較的安定しており、過去のアプリケーション シナリオを満たすことができます。しかし、これには多くの致命的な弱点があります。

• データ ガバナンスの高コスト: リアルタイム コンピューティング プロセスでは、オフライン データ ウェアハウスのデータ リネージおよびデータ品質管理システムを再利用できません。リアルタイム コンピューティング用のデータ リネージュとデータ品質管理システムを再実装する必要があります。
• 開発コストと保守コストが高い: 2 セットのオフライン データ ウェアハウス システムとリアルタイム データ ウェアハウス システムを同時に保守する必要があり、同じコンピューティング ロジック セットで 2 セットのデータを保存する必要があります。たとえば、1 つまたは複数の元データを更新するには、オフライン データ ウェアハウスを再度実行する必要があり、データ更新コストが非常に高くなります。
• データ口径の不一致: オフライン計算とリアルタイム計算では 2 つのまったく異なるコードが使用されるため、データの到着遅延と 2 種類のコードの実行時間の違いにより、計算結果が不一致になります。

それでは、Lambda アーキテクチャの問題を解決できるアーキテクチャはあるのでしょうか?

1.4 カッパのアーキテクチャ

Lambda アーキテクチャの「ストリームとバッチの分離」処理リンクにより、研究開発の複雑さが増大します。したがって、1 つのシステムですべての問題を解決できるのではないかという疑問を持つ人もいます。現在、より一般的な方法は、フロー コンピューティングに基づいて実行することです。Flink + Kafka次に、リンク全体を直列に接続して、Kappa アーキテクチャを紹介します。Kappa アーキテクチャは、Lambda アーキテクチャのオフライン処理層とリアルタイム処理層の間のコンピューティング エンジンの一貫性のなさ、高い開発コスト、運用保守コスト、一貫性のないコンピューティング結果の問題を解決します。

Kappa アーキテクチャの方式は、ストリーム-バッチ統合方式とも呼ばれます。これを借用してFlink + Kafkaフロー バッチ統合シナリオを構築しますが、ODS レイヤーのデータをさらに分析する必要がある場合は、Flink コンピューティング エンジンにアクセスして DWD レイヤーの Kafka にデータを書き込む必要があります。また、結果データを DWS レイヤーで Kafka に送信します。Kappa アーキテクチャは完璧ではなく、多くの問題点もあります。

1.5 Kappa アーキテクチャの問題点

• データのバックトラッキング能力が弱い: Kafka は複雑な需要分析をサポートする能力が弱く、より複雑なデータ分析に直面した場合、DWD および DWS レイヤーのデータを ClickHouse、ES、MySQL、または Hive に書き込んでさらに分析する必要があります。リンクの複雑さ。さらに大きな問題は、データのバックトラッキングを行う場合、リンクの複雑さによりデータのバックトラッキング能力が非常に弱いことです。
• 弱い OLAP 分析能力: Kafka はシーケンシャル ストレージ システムであるため、シーケンシャル ストレージ システムが OLAP 分析を直接実行する方法はありません。たとえば、述語プッシュダウンなどの最適化戦略をシーケンシャル ストレージ プラットフォームで実装するのは比較的困難です (カフカ）難しいこと。
• データのタイミングが課題です: Kappa アーキテクチャはメッセージ キューに大きく依存しています。メッセージ キューの精度がアップストリーム データの順序に厳密に依存していることはわかっています。ただし、メッセージ キュー内のデータの層が増えるほど、メッセージ キューの精度が向上する可能性が高くなります。故障することはあります。通常、ODS 層のデータは絶対に正確ですが、ODS 層のデータを計算後に DWD 層に書き込むと順序が狂います、DWD から DWS へのデータの順序が狂う可能性が高くなります。データの不整合の問題は非常に深刻です。

1.6 ビッグデータ アーキテクチャの問題点の概要

従来の Hadoop アーキテクチャから Lambda アーキテクチャへ、そして Lambda アーキテクチャから Kappa アーキテクチャへ、ビッグ データ プラットフォーム インフラストラクチャの進化により、アプリケーションに必要なあらゆる種類のデータ処理機能が徐々に組み込まれていますが、これらのプラットフォームには依然として多くの問題点があります。

効率的なデータバックトラッキングをサポートし、データ更新をサポートするだけでなく、データのバッチストリーム読み取りおよび書き込みを実現し、さらには数分から数秒レベルのデータアクセスを実現できるストレージテクノロジーはありますか?

1.7 リアルタイム データ ウェアハウスの構築要件

これは、リアルタイム データ ウェアハウスの構築にとっても急務です。実際、Kappa アーキテクチャで発生するいくつかの問題は、Kappa アーキテクチャをアップグレードすることで解決できます。次に、主に現在のホット データ レイク テクノロジについて説明します。

それでは、リアルタイム要件を満たすだけでなく、オフライン コンピューティングの要件も満たし、開発と運用保守のコストを削減し、構築された Kappa アーキテクチャで遭遇する問題点を解決できるようなアーキテクチャはあるのでしょうか。メッセージキューによって? 答えは「はい」です。これについては、この記事の後半で詳しく説明します。

2. データレイクはデータウェアハウスの問題点の解決に役立ちます

2.1 データレイクコンセプトの継続的改善

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

2.1.1 オリジナルデータの保存

• データ レイクには、会社のすべてのデータを保存するのに十分なストレージ容量が必要です。
• データ レイクには、構造化データ、半構造化データ (XML、Json など)、非構造化データ (写真、ビデオ、オーディオ) など、さまざまな種類のデータを保存できます。
• データ レイク内のデータは元のビジネス データの完全なコピーであり、これらのデータはビジネス システム内で元の外観を維持します。

2.1.2 柔軟な基盤ストレージ機能

実際の使用では、データ レイク内のデータは頻繁にアクセスされることは通常ありませんが、許容できるコスト パフォーマンスを実現するために、通常、データ レイクの構築にはコスト効率の高いストレージ エンジンが選択されます。

• ビッグデータ用の超大規模ストレージと、スケーラブルな大規模データ処理機能を提供します。
• S3//などの分散ストレージ プラットフォームをストレージ エンジンとして使用OSSできます。HDFS
• Parquet、Avro、ORC などのデータ構造形式をサポートします。
• データキャッシュ高速化機能を提供できます。

2.1.3 リッチコンピューティングエンジン

データ バッチ コンピューティング、ストリーミング コンピューティング、対話型クエリ分析から機械学習まで、あらゆる種類のコンピューティング エンジンが、データ レイクがカバーすべきカテゴリに属します。ビッグデータと人工知能技術の組み合わせにより、さまざまな機械学習/深層学習アルゴリズムが継続的に導入されており、たとえば、TensorFlow/フレームワークは、機械学習トレーニングのために/ /からのサンプルデータの読み取りをPyTorchサポートしています。したがって、適格なデータ レイク プロジェクトの場合、コンピューティング エンジンとストレージ エンジンのプラグ可能性は、データ レイクが持つ必要のある基本的な機能です。S3OSSHDFS

2.1.4 完璧なデータ管理

• データ レイクには、包括的なメタデータ管理機能が必要です。データ ソース、データ形式、接続情報、データ スキーマ、権限管理、その他の機能が含まれます。
• データ レイクには、包括的なデータ ライフサイクル管理機能が必要です。元のデータを保存するだけでなく、さまざまな分析や処理の中間結果データも保存できる必要があり、データの分析や処理の過程を完全に記録して、ユーザーが任意のデータの生成過程を追跡できるようにする必要があります。完全にデータの一部です。
• データ レイクには、包括的なデータ取得機能とデータ リリース機能が必要です。データ レイクは、さまざまなデータ ソースをサポートし、関連するデータ ソースから完全/増分データを取得し、ストレージを標準化できる必要があります。データ レイクは、さまざまなアプリケーション アクセス要件を満たすために、データを適切なストレージ エンジンにプッシュできます。

2.2 オープンソース データ レイクのアーキテクチャ

LakeHouse アーキテクチャは、現在のアーキテクチャの進化において最も注目されているトレンドとなっており、保存されたデータ管理システムに直接アクセスでき、データ ウェアハウスの主な利点を組み合わせています。LakeHouse は、ストレージとコンピューティングの分離アーキテクチャに基づいて構築されています。ストレージとコンピューティングの分離に関する最大の問題はネットワークにあり、特にアクセス頻度が高いデータ ウェアハウスの場合、ネットワーク パフォーマンスが非常に重要です。DeltaLakehouse を実装するには、 、Hudi、など、多くのオプションがありますIceberg。3 つの焦点は異なりますが、これらはすべて、統合メタデータ管理、複数のコンピューティングおよび分析エンジンのサポート、高レベルの分析とコンピューティングとストレージの分離のサポートなど、データ レイクの一般的な機能を備えています。

では、オープンソース データ レイク アーキテクチャは一般的にどのようなものなのでしょうか? ここでアーキテクチャ図を描きました。主に 4 つの層に分かれています。

2.2.1 分散ファイルシステム

最初の層は分散ファイル システムで、クラウド テクノロジーを選択するユーザーは通常、データの保存に S3 と Alibaba Cloud を選択しますが、オープン ソース テクノロジーを好むユーザーは通常、独自の HDFS を使用してデータを保存します。

2.2.2 データアクセラレーション層

2 番目の層はデータ アクセラレーション層です。データ レイク アーキテクチャは、典型的なストレージとコンピューティングの分離アーキテクチャであり、リモートでの読み取りと書き込みのパフォーマンス損失は非常に大きくなります。私たちの一般的な方法は、ホット データとコールド データの分離を実現するために、頻繁にアクセスされるデータ (ホット データ) をコンピューティング ノード上でローカルにキャッシュすることです。これを行う利点は、データの読み取りおよび書き込みパフォーマンスが向上し、ネットワーク帯域幅が節約されることです。Alluxioオープンソースか Alibaba Cloudを選択できますJindofs。

2.2.3 テーブルフォーマットレイヤー

3 番目の層はテーブル形式層で、データ ファイルをビジネス上の意味を持つテーブルにカプセル化します。データ自体はACID、、、、などのテーブル レベルのセマンティクスを提供しますSnapshot。このレイヤーは、オープンソース データ レイクの三銃士の 1 つを選択できます。、、はデータ レイクを構築するためのテクノロジーであり、それ自体はデータ レイクではありません。schemapartitionDeltaHudiIcebergDeltaHudiIceberg

2.2.4 計算エンジン

4層目は各種データ計算エンジンです。Spark、Flink、Hive、Presto などを含むこれらのコンピューティング エンジンはすべて、データ レイク内の同じテーブルにアクセスできます。

3. データレイクとデータウェアハウスの概念の比較

3.1 データレイクとデータウェアハウスの比較

私が理解しているデータ レイクの本質について話させてください。新しいことの本質を理解していなければ、それを制御することは困難です。下の図はすべてを示しています。

データ レイクの概念を基本的に理解した後、データ レイクにどのような基本特性が必要か、特にデータ ウェアハウスと比較してデータ レイクがどのような特性を持っているかをさらに明確にする必要があります。AWSデータウェアハウスとデータレイク比較の公式比較表を参考にしてみましょう。

どの企業も、さまざまなニーズやユースケースに対応できるため、データ ウェアハウスとデータ レイクを必要としています。

• データ ウェアハウスは、トランザクション システムや基幹業務アプリケーション システムからのリレーショナル データを分析するために最適化されたデータベースです。高速な SQL クエリを提供するために、データ構造とスキーマを事前に定義します。生データは一連の ETL 変換を受けて、信頼できる「単一データ結果」をユーザーに提供します。
• データ レイクは、基幹業務アプリケーション システムからのリレーショナル データだけでなく、モバイル アプリケーション、IoT デバイス、ソーシャル メディアからの非リレーショナル データも保存するため、異なります。データを取得するときに、事前にデータ構造やスキーマを定義する必要はありません。これは、データ レイクには、複雑なデータ構造を必要とせずに、あらゆる種類のデータを保存できることを意味します。データに対してさまざまな種類の分析 (SQL クエリ、ビッグ データ分析、全文検索、リアルタイム分析、機械学習など) を使用できます。

特性	データベース	データレイク
データ	トランザクション システム、運用データベース、基幹業務アプリケーションからのリレーショナル データ	IoT デバイス、Web サイト、モバイル アプリ、ソーシャル メディア、エンタープライズ アプリケーションからの非リレーショナル データとリレーショナル データ
スキーマ	データウェアハウス実装前の設計（スキーマ書き込み）	分析時の書き込み (スキーマの読み取り)
お金に見合った価値	クエリ結果が高速になるとストレージ コストが高くなります	クエリ結果の高速化に必要なストレージ コストの削減
データ品質	重要な事実の根拠として使用できる、厳しく規制されたデータ	規制されるかどうかにかかわらず、あらゆるデータ (生データなど)
ユーザー	ビジネスアナリスト	データサイエンティスト、データ開発者、ビジネスアナリスト（規制データを使用）
分析する	バッチレポート、BI、視覚化	機械学習、予測分析、データの発見と分析

上の表ではデータ レイクと従来のデータ ウェアハウスの違いを紹介しましたが、次に、データ ストレージとコンピューティングの 2 つのレベルからデータ レイクの特徴をさらに分析します。

3.2 書き込みモードと読み取りモード

3.2.1 書き込みモード

データ ウェアハウスの「書き込みスキーマ」の背後にある隠されたロジックは、データを書き込む前にデータのスキーマを確認し、その後データをインポートするというものです。この利点は、ビジネスとデータを相互に連携できることです。、欠点

3.2.2 読み取りモード

データレイクは「可読性の高いスキーマ」を重視しており、その背後にある論理は、ビジネスの不確実性は正常である、つまりビジネスの発展や変化を予測できないため、ある程度の柔軟性を維持するというものです。構造設計を延期することで、インフラストラクチャ全体がデータを「オンデマンド」でビジネスに適合させることができるようになります。したがって、データレイクは開発および革新的な企業により適しています。

3.3 データ ウェアハウスの開発プロセス

データレイクは柔軟で高速な「時間読み取りモード」を採用しており、デジタル変革の波の下で、企業が技術変革を完了し、データを完全に蓄積し、企業の急速な発展の下で無限のデータ需要の問題に対処するのに非常に役立ちます。

3.4 データレイクのアーキテクチャスキーム

データ レイクは、新世代のビッグ データ インフラストラクチャと考えることができます。このアーキテクチャでは、データ ストリーム処理であってもバッチ処理であっても、データ ストレージはデータ レイクIceberg上で。明らかに、このアーキテクチャは Lambda アーキテクチャと Kappa アーキテクチャの問題点を解決できます。

3.4.1 Kafka に保存されるデータ量が少ないという問題を解決する

現時点では、すべてのデータ レイクの基本的な考え方は HDFS に基づくファイル管理システムであるため、データ量が非常に大きくなる可能性があります。

3.4.2 OLAP クエリのサポート

同様に、データ レイクは HDFS に基づいて実装されており、中間層データに対して OLAP クエリを実行するには、現在の OLAP クエリ エンジンのみがいくつかの調整を必要とします。

3.4.3 データガバナンスの統合

バッチ ストリーム データが HDFS、S3、およびその他のメディアに保存された後は、同じデータ系統とデータ品質管理システムを再利用できます。

3.4.4 ストリームバッチアーキテクチャの統合

Lambda アーキテクチャと比較して、データ レイク アーキテクチャには統一されたスキーマと統一されたデータ処理ロジックがあり、ユーザーはデータの 2 つのコピーを維持する必要がなくなりました。

3.4.5 一貫したデータ統計

統一されたストリームバッチ統合コンピューティングおよびストレージ方式の採用により、データの一貫性が保証されます。

3.5 どちらが良いか

データ レイクとデータ ウェアハウスは、どちらが優れているか劣っているとは言えません。それぞれに利点があり、互いの利点を補うことができます。理解のためにここに図を描きます。

• レイクとウェアハウスのメタデータはシームレスに接続され、相互に補完されます。データ ウェアハウスのモデルはデータ レイクにフィードバックされ (元のデータの一部となり)、レイクの構造化されたアプリケーションがデータにデポジットされます。倉庫。
• レイクとウェアハウスを統合開発し、異なるシステムに保存されているデータをプラットフォームを通じて一元管理できます。
• データレイクとデータウェアハウスのデータについては、ビジネス開発のニーズに応じて、どのデータをデータウェアハウスに保存し、どのデータをデータレイクに保存するかを決定し、それによってレイクとデータウェアハウスの統合を形成します。倉庫。
• データはレイクにあり、モデルはウェアハウスにあり、変換が繰り返されます。

4. データ レイクはデータ ウェアハウス アーキテクチャのアップグレードに役立ちます

4.1 データレイク構築の目標

Data Lake Technology はIceberg現在Parquet、 、Avro、の 3 つのファイル形式をサポートしていますORC。以下の図に示すように、Icebergそれが持つ機能は次のように要約され、これらの機能はレイクとウェアハウスの統合を構築するために重要です。

• データ ストレージ層は、標準的で統一されたデータ ストレージ モデルを採用しています。
• 準リアルタイムのデータ構築を構築して、T + 1データの適時性を確保します。
• データのトレーサビリティがより便利になり、運用と保守のコストが削減されます。

4.2 準リアルタイムのデータアクセス

データレイク技術はIceberg、読み取りと書き込みの分離をサポートするだけでなく、同時読み取り、増分読み取り、小さなファイルのマージをサポートし、秒レベルから分単位の遅延にも対応できます。Icebergバッチフロー統合を備えた Flink リアルタイム データ ウェアハウス アーキテクチャに基づくリアルタイム フル リンク。

下図に示すように、操作を行うIcebergたびにcommit、不可視から可視にデータが変化するなど、データの可視性が変化し、ほぼリアルタイムのデータ記録が実現されます。

4.3 リアルタイム データ ウェアハウス - データ レイク分析システム

オフライン データ ウェアハウスを構築する場合、まずオフライン スケジューリング システムを使用して定期的にデータを抽出するなどのデータ アクセス操作を実行し、次に一連の ETL 操作を経て、最後にデータを Hive テーブルに書き込む必要があります。比較的大きいです。したがって、Iceberg のテーブル構造の助けを借りて、Flink または Spark Streaming を使用してほぼリアルタイムのデータ アクセスを実現し、データ レイテンシーを短縮できます。

上記の機能に基づいて、上で説明した Kappa アーキテクチャを確認してみましょう。Kappa アーキテクチャの問題点はすでにわかっています。Iceberg は優れたテーブル形式として使用できるため、Streaming Reader と Streaming Sink もサポートできます。それでは、Kafka を Iceberg に置き換えることを検討することは可能でしょうか?

Iceberg の基盤となるストレージは HDFS や S3 などの安価なストレージであり、Parquet、ORC、Avro などのストレージ構造をサポートしています。中間層の結果データに対してOLAP分析を行うことができます。Iceberg Snapshot のストリーミング リーダー機能に基づいて、オフライン タスクの遅延を日レベルから時間レベルまで大幅に削減し、ほぼリアルタイムのデータ レイク分析システムに変換できます。

中間処理層では、Presto を使用していくつかの単純な SQL クエリを実行できます。Iceberg はストリーミング読み取りをサポートしているため、システムの中間層で Flink に直接アクセスしたり、中間層で Flink を直接使用してバッチ処理を実行したりすることもできます。またはストリーミング コンピューティング タスク。さらに計算した後、中間結果をダウンストリームに出力します。

4.4 Kafka を Iceberg に置き換えることの長所と短所

一般に、Kafka を Iceberg に置き換えることの利点は主に次のとおりです。

• ストレージ層でストリームとバッチの統合を実現
• 中間層はOLAP分析をサポートします
• 効率的なバックトラッキングのための完璧なサポート
• ストレージコストの削減

もちろん、次のような欠点もあります。

• データ遅延はリアルタイムからほぼリアルタイムに移行します
• 他のデータ システムとのインターフェースには追加の開発作業が必要です

4.5 Flink CDC による MySQL データ同期の問題の解決

Iceberg は、統一されたデータ レイク ストレージ テーブル形式を提供し、データ分析用に複数のコンピューティング エンジン (Spark、Presto、Hive など) をサポートしています。純粋な列形式のデータ ファイルを生成でき、列形式のファイルは OLAP 操作に非常に適しています。Iceberg は、The Snapshot に基づいています。デザイン モードはデータの増分読み取りをサポートします。Iceberg インターフェイスは高度な抽象化と優れた互換性を備え、上位レベルのコンピューティング エンジンと下位レベルのストレージ エンジンの両方から独立しているため、ユーザーが独自の定義を行うのに便利です。ビジネスの論理。

データを CDC フラグとともにappendIceberg に直接アップロードし、mergeの時点で、特定の組織形式および特定の効率的な計算方法に従って、これらの増分データと最後のデータの全量を 1 回だけ比較しますmerge。この利点は、ほぼリアルタイムのインポートとリアルタイムのデータ読み取りをサポートしていることです。このコンピューティング ソリューションの Flink SQL は、CDC 取り込みをネイティブにサポートしており、追加のビジネス フィールド設計を必要としません。

5. データレイク技術の発展展望

データ レイクは、次のビッグ データ テクノロジ革命の明るい点になる可能性があります。私たちはチャンスを掴み、チャンスを掴み、データ レイクについて一緒に学ぶ必要があります。しかし、私の提案は依然として「使わずに学ぶ」です、なぜそう言うのですか？例: $2018\; 年$の初めに、私たちは Flink を一斉に立ち上げ、その後毎月バージョンをアップグレードしました。それはただのお尻の痛みです。したがって、大手インターネット企業が穴を埋めるのを待ち、その後、短期間、フラットかつ高速な方法でデータレイクを直接立ち上げますが、私たちは学ばなければなりません。

6. まとめ

この記事を通じて、データ レイクとは何か、データ レイクについて学ぶ必要がある理由、データ レイクによって解決できる実際的な問題について基本的に理解しました。後ほど、Iceberg がデータ レイク ソリューションとして選ばれる理由に引き続き焦点を当てていきます。