データレイクとデータウェアハウスの存在は、対立するものでも、代替する関係でもなく、相互に融合する関係にあります。
データ レイクは、過去 2 年間の比較的新しいテクノロジーです。ビッグ データの分野では、実際のデータ レイクはどのようなものであるべきですか? 現在、データ レイクの理解はまだ探索段階にあります。現在代表されているオープン ソース製品には次のものがあります。氷山、フーディ、デルタ湖。
それでは、データ レイクはどのようなものであるべきでしょうか? まず、データ レイクが何であるかを説明するために、データ レイクの作成者である AWS を見てみましょう。たとえば、次の図:
画像出典: データについて語る - AWS データレイクの探索
データを理解していない人は、データ レイクが非常に強力であると考えるかもしれませんが、データを理解している人は、データ レイクが単なるデータ ウェアハウス テクノロジの積み重ねであると考えるかもしれません。上のフレーム図を見てください。データの専門家が理解できない語彙はどれですか? データレイクが新しい概念として宣伝されているのはなぜですか?
データレイクの定義は次のとおりです。
データ レイクは、あらゆる規模のすべての構造化データと非構造化データを保存できる集中リポジトリです。データを（最初に構造化せずに）そのまま保存し、ダッシュボードや視覚化からビッグデータ処理、リアルタイム分析、機械学習に至るまで、さまざまな種類の分析を実行して、より適切な意思決定を導くことができます。
では、データ レイクと以前のデータ ウェアハウスの違いは何でしょうか。
データ ウェアハウスは、トランザクション システムや基幹業務アプリケーションからのリレーショナル データを分析するために最適化されたデータベースです。データ構造とスキーマは高速 SQL クエリを最適化するために事前に定義されており、その結果は運用レポートや分析によく使用されます。データは、ユーザーにとって信頼できる「唯一の信頼できる情報源」として機能できるように、クリーニング、強化、変換されます。
データ レイクは、基幹業務アプリケーションからのリレーショナル データだけでなく、モバイル アプリケーション、IoT デバイス、ソーシャル メディアからの非リレーショナル データも保存するため、異なります。データがキャプチャされたとき、データ構造やスキーマは定義されていませんでした。これは、綿密な設計を行わずに、また将来どのような質問に回答する必要があるのかを知らなくても、すべてのデータを保存できることを意味します。SQL クエリ、ビッグ データ分析、全文検索、リアルタイム分析、機械学習など、データに対してさまざまな種類の分析を使用して洞察を得ることができます。
冒頭から、データ ウェアハウスとデータ レイクの主な違いは構造化データと非構造化データのストレージであるように見えますが、本当にそれだけでしょうか?
実際、この種の比較には大きな論理的な抜け穴があります。まず結果から違いを確認し、次にその違いを使用して違いを説明し、原因と結果を逆転させます。例えば、AWS のデータレイクは非構造化データを扱うことができますが、データ ウェアハウスは非構造化データを扱うことができません。これがデータレイクとデータ ウェアハウスの本質的な違いの 1 つであると考えられます。
次の記事では、今後のデータ レイクとデータ ウェアハウスの違いについて説明します。新しいことを学ぶには、その本質を段階的に発見する必要があります。
データ ウェアハウスとデータ レイクの処理フローは次の図で示すことができます。この図では、5 つのベンチマーク プロセス ノードが赤い丸でマークされています。
この図から、データ レイクには処理プロセスにおけるデータ ウェアハウス以上のコンテンツはなく、データ ストレージ、モデル設計、処理ツール、開発者、消費者という 5 つの側面の構造変化が見られることがわかります。比較のための側面。
データストレージ。
1
データ ウェアハウスの収集および処理に保存されるデータは、一般に構造化された形式で存在します。元のデータが非構造化であっても、これらの非構造化データはソースに一時的に保存されるだけです。データ ウェアハウスへの入力は、データ ウェアハウスの基本的な保存形式となっています。データ ウェアハウス: これは、データ ウェアハウス モデル (ディメンションまたはリレーショナル モデリング) がリレーショナル データに基づいているという特性に関連しています。
実際、データ ウェアハウスが構造化データのみを処理するのは、従来のデータ モデリングの負担のためであり、データ ウェアハウスが構造化データのみを処理および保存することを規定している人はいません。
データ レイクは包括的かつ軽量であり、構造化データと非構造化データの両方がデータ レイク自体の一部となっており、データ レイクにおける「レイク」の概念が反映されています。データ ウェアハウス モデリングには制限がないため、もちろん何でも投入できますが、これによりデータの沼地になる道が開かれます。
モデルデザイン
2
データ ウェアハウス内のすべてのスキーマ (テーブル構造など) は事前に設計され、生成されます。データ ウェアハウス構築で最も重要なタスクはモデリングであり、カプセル化された安定したモデルを通じて、限定的かつ標準化されたデータ サービスを外部に提供します。モデルが設計可能かどうかデータセンターがデータサービスの再利用性を重視するのと同様に、高い凝集性と疎結合性がデータウェアハウスの品質を評価する基準になっています。
データ ウェアハウスはデータ分野の計画経済に非常に似ていることがわかります。すべての製品 (モデル) は事前に生成されており、モデルは変更できますが、その変更には非常に時間がかかります。
データ レイクのモデルは事前に生成されるのではなく、各アプリケーションのニーズに応じて設計および生成されます。これは市場経済の産物に似ており、再利用性は犠牲になりますが、柔軟性がもたらされます。そのため、データ レイクはさらに適用されます。分析の理由を探ることに重点を置きます。
加工ツール
3
データ ウェアハウスの収集および処理ツールは一般に比較的閉鎖的であり、その多くはコードによって暴力的に実装されており、そのほとんどは集中した専門の開発者のみに公開されています。主な目的は、データの統一的な収集とモデリングを実現することです。消費者向け（アプリケーション側）のサービスではないため、その必要はありません。
ポイント (2) で述べたように、データ レイクの収集および処理ツールは完全にオープンです。データ レイクのモデルはアプリケーションのアドホック設計によって生成されます。つまり、アプリケーションには直接 ETL 機能が必要であり、データレイクデータの処理能力 カスタマイズされたモデルの構築を完了するには、そうでなければ柔軟性はおろか、着陸の可能性もありません。
ツールがオープンであり、エクスペリエンスが十分に優れているかどうかは、データ レイクの成功の前提条件です。明らかに、従来のデータ ウェアハウスの一部の収集および開発ツールは受け入れられず、一般に公開することは不可能であることがよくあります。
開発者
4
データ ウェアハウスの一元的な開発者は、データの収集、保存、処理などのすべての段階をカバーするデータを処理して、データ フローを管理するだけでなく、ツール フローも作成します。
データ フローは最終的にアプリケーションにサービスを提供するため、データ モデルの品質には特別な注意が払われ、ツール フローには基本的な機能があり、パフォーマンス要件を満たすだけで済みます。いずれにせよ、データ ウェアハウス チームはそれを自分たちで使用し、結果は損害です。運営スタッフ。
データ レイクはまったく異なります。集中管理された開発者は、データ フローの段階で生データをデータ レイクに投入することのみを担当し、ツール フローの変換により多くのエネルギーが費やされます。これは、これらのツールがエンド ユーザーを直接指向しているためです。使用されている場合、データ レイクは使用できません。
申請スタッフ
5
データ ウェアハウスがアプリケーション担当者に公開するのは構築されたデータ モデルだけであり、アプリケーション側のすべての役割はデータ ウェアハウスによって定義されたデータ モデルの範囲内でのみ実行できるため、アプリケーション側のイノベーション能力が制限されます。ある程度まで。たとえば、元のデータには貴重なフィールドがありますが、データ ウェアハウスの中央開発者がそれをフィルタリングしました。
この種の問題はデータ ウェアハウスで非常に一般的です。多くのデータ フェッチャーは広いテーブルのみを取得し、ソース データについてはまったく不明です。いわゆる成功もデータ ウェアハウスであり、失敗もデータ ウェアハウスです。
データ レイクのアプリケーション側は、データ レイクによって提供されるツール フローを使用して、データの収集、抽出、保存、処理のすべての段階をカバーする最新の生データにアクセスできます。ビジネスの最大値。
データ ウェアハウスとデータ レイクは、データ テクノロジの分野における 2 つのデータ処理モードとサービス モードを表していることがわかります。
ORACLE の DBLINK 時代にはすでに第 1 世代のデータ レイクがありました。当時 ORACLE が世界を支配しており、ORALCE の DBLINK によって生データを直接探索できるようになったからです。
データ量の増加とデータの種類の継続的な充実に伴い、さまざまなデータを統合するための新しい「データベース」を作成する必要があります。
しかし当時、なぜデータレイクではなくデータウェアハウスだったのでしょうか?
それは主にアプリケーションドライバーの問題です。
なぜなら、当時は誰もがレポートに関心があり、レポートの中心的な要件は正確さと一貫性だったからです。標準化および正規化されたディメンションとリレーショナル モデリングは、これに適応しただけです。一元化されたデータ ウェアハウスのサポート モデルは、姿を変えた計画です。経済性です。
ビッグデータ時代の到来とデジタル化の発展に伴い、多くの企業は、非構造化生データの割合がますます高くなり、フロントエンドアプリケーションの応答要件がますます高くなり、大規模なデータ マイニングはますます正確になり、データ駆動型ビジネスの要件を満たすことができなくなりました。
企業はさまざまなデータを深く掘り下げ、データベースの表示（レポート）からデータのマイニング（調査や予測）に段階的に移行する必要がある一方で、企業は段階的なデータの表示から段階的に変化する必要もあります。ステップ サポート モデルを高速かつ柔軟な方向に移行し、アプリケーション側の柔軟性をさらに高めると、現時点ではデータ ウェアハウスは少し持続可能ではありません。
データレイクが誕生したのはこのような背景があります。
実際、データ レイクが登場するずっと前から、多くの企業がデータ レイクと同様の作業を行っていましたが、それは単に、誰もがデータ ウェアハウスの構造化データ処理により重点を置き、非構造化データ ログなどに集中していただけです。それを保存し、必要なときにアプリケーション プログラムで処理して望ましい結果を得るというものですが、体系的な処理はありません。
ETL がオープンになっていない主な理由は、推進力が十分ではないことですが、実際、カスタマイズして抽出するデータの種類がそれほど多くないためです。
多くの企業がビジュアル開発プラットフォームに取り組んでいないことは容易に理解できますが、企業はレポートで十分に対応できますが、なぜビジネス担当者が自分で開発やマイニングを行うのでしょうか。今ではデータレイクが人気ですが、そのほとんどがAmazonなどのインターネット企業であるのが普通です。
そして、最近の湖と倉庫の統合という比較的新しい概念、アリによって提案された概念、下の写真を見てみましょう
湖と倉庫の統合とは何ですか?
レイクとウェアハウスの統合は、データ ウェアハウスとデータ レイクの違いを統合し、データ レイク上にデータ ウェアハウスを構築する新しいデータ管理モデルです。これにより、エンタープライズ データのインフラストラクチャが効果的に簡素化され、データ ストレージの弾力性が向上します。品質と品質を向上させると同時に、コストを削減し、データの冗長性を減らすこともできます。
レイクとウェアハウスのデータ/メタデータはシームレスに接続され、相互に補完されます。データ ウェアハウスのモデルはデータ レイクにフィードバックされ（元のデータの一部となり）、レイクの構造化されたアプリケーション ナレッジが蓄積されます。データウェアハウスに。
レイクとウェアハウスの統合アーキテクチャの主なポイントは、「レイク」と「ウェアハウス」のデータのシームレスな接続を実現し、データ ウェアハウスの柔軟性とデータ レイクの柔軟性を効果的に統合することです。データ レイクは主に次のように使用されます。中央リポジトリは機械学習、データ ウェアハウス、ログ分析、ビッグ データ、その他のテクノロジーを統合してデータ サービス リングを形成し、データをより適切に分析および統合し、データ ウェアハウスとデータ レイク内のデータが自由に流れることができるようにします。 、およびユーザー その中のデータをより便利に取得できるようになり、データの「湖への出入り」がより便利になります。
レイクとウェアハウスの統合は、データ ウェアハウスとデータ レイクの価値を重ね合わせ、データの重力を克服し、サービス間でデータをフローさせ、冗長な構築を削減し、レイク内のデータをデータ ウェアハウスに「フロー」させ、直接データを呼び出し、データ ウェアハウス内のデータを将来のデータ マイニングのためにデータ レイクに保存することもできます。レイクとウェアハウスの統合により、データ ウェアハウスのホット データとデータ レイクの履歴データを迅速に処理でき、実行中にデータ移動操作を行わずに豊富なデータ セットを生成できます。
データ レイクがどのようなものであるべきかについては、次の開発で解決する必要がありますが、現時点では、さまざまなニーズや使用需要を満たすことができるため、一般的な組織はデータ ウェアハウスとデータ レイクを必要としています。したがって、データレイクとデータウェアハウスの存在は対立するものではなく、代替関係でもなく、相互に融合する関係にあります。
ERP データをデータ ウェアハウスやデータ レイクに統合するにはどうすればよいですか?
今では誰もがデータ レイクとデータ ウェアハウスの違い、およびレイクとウェアハウスを統合する新しいデータ管理モデルを理解しています。では、ビジネス分析のために ERP システム データをリアルタイムかつ大量にデータ レイクやデータ ウェアハウスにエクスポートするにはどうすればよいでしょうか? SNP Glue ソフトウェアは、高度な SAP データ統合を実装することで、顧客のデータ プラットフォームを次のレベルに引き上げることを目的としています。
Glue を使用すると、ERP (ECC、S4/HANA)、BW、CRM/SCM、顧客の ABAP アプリケーション、HANA データなどの SAP データをデータ ウェアハウスにインポートでき、リアルタイム レプリケーションの実現、SAP データの抽出、データベース、データ レイク、BI データ分析ツール、クラウド ソリューションなど、目的のターゲット環境にそれを配置します。ユースケースをサポートするには、データをデータ レイクにリアルタイムでストリーミングして、データ製品を提供したり、イベントベースの顧客アプリケーションをサポートしたりします。SNP Glue はベンダー ロックインのリスクを回避します。SAP、Google、Amazon、Microsoft、Snowflake、Cloudera によって認定されています。
Glue がどのようにデータをデータ プラットフォームのデモに統合するかを確認したい場合は、SNP にお問い合わせください。