データおよび機械学習プラットフォームのアーキテクト

第7章. レイクハウスに集結する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

データレイクのパラダイムに従うか、DWHのパラダイムに従うかだ。どちらのアプローチにも長所と短所があるが、問題は、両方のテクノロジーを共存させて収束したアーキテクチャを実現することは可能なのかということだ。本章ではこのトピックについて、この考え方の簡単な動機付けから始め、レイクハウスアーキテクチャとして知られる収束型アーキテクチャの2つの大まかなバリエーションを分析し、そのどちらを選ぶべきかを決める手助けをする。

レイクハウスの概念は、構造化データ、半構造化データ、非構造化データをより柔軟かつスケーラブルに、大規模にストア・分析できるため、ますます普及している。レイクハウスは、構造化データと非構造化データのライフサイクル全体を扱うことができ、前の2章で学んだデータレイクとDWHアプローチの長所を統率された方法で組み合わせることができる。本章の最後では、レイクハウスアーキテクチャに向けて進化する方法を説明する。

ユニークなアーキテクチャの必要性

データレイクとDWHは、異なるユーザのニーズを満たすために登場した。両方のタイプのユーザを持つ組織は、魅力的でない選択を迫られている。

ユーザ・ペルソナ

前の章で学んだように、データレイクとDWHの主な違いは、取り込むことができるデータの種類と、未処理の（生の）データを共通の場所に陸揚げする機能に関連している。したがって、これら2つのパラダイムの典型的なユーザは異なる。

従来のDWH ユーザ はBIアナリスト であり、よりビジネスに近く、データから洞察を得ることに重点を置いている。データは従来、データアナリストの要求に基づいてETLツールによって準備される。これらのユーザは通常、質問に答えるためにデータを使用する。彼らはSQLに精通している傾向がある。

データレイク ユーザには、アナリストの他に、データエンジニア やデータサイエンティスト がいる。彼らは生データにより近く、データを探索し、マイニングするツールと機能を持つ。彼らはデータを変換してビジネスがアクセスできるようにするだけでなく（つまりDWHに転送できるデータ）、それを実験し、MLモデルの訓練やAI処理に使用する。このようなユーザは、データの中から答えを発見するだけでなく、ビジネスに関連する質問を見つけ、他のユーザにも役立つようにデータを準備する。彼らはPython、Java、Scalaなどのコーディング言語に習熟している傾向がある。

アンチパターン切断されたシステム

このようにニーズが異なる結果、 、DWHとデータレイクを別々のIT部門やチームが管理しているケースがよく見られる。しかし、このような分割アプローチには機会コストがかかる。演算子はビジネス洞察に集中するよりも、運用面にリソースを費やしてしまう。そのため、主要なビジネスドライバーや、競争優位を獲得するための課題にリソースを割くことができない。

さらに、データから実用的な洞察を提供するという同じ最終目標を持つ2つのシステムを別々に管理することは、データ品質と一貫性の問題を引き起こす可能性がある。片方のシステムから得たデータをもう片方のシステムから得たデータと一緒に使うためにデータを変換する余計な手間がかかるため、エンドユーザは完全に敬遠してしまうかもしれない。これはまた、 、企業全体のデータ溜まりにつながる可能性がある。データ溜まりとは、個人のマシン上に保存されたデータセットのことで、セキュリティリスクとデータの非効率的な利用の両方を引き起こす。 ...