データレイクとデータウェアハウス

みなさん、こんにちは。今回は、ジェシーが TSDB 分野から離れて、データ レイクとデータ ウェアハウスのトピックについて話したいと思います。部外者として、ジェシーはこの 2 つについて一般的な紹介もしたいと考えています。 

この記事はあくまで個人的な意見ですので、偏見がある場合はご容赦ください〜

20 年前、データ ウェアハウジングは業界で最も人気のあるテクノロジーではありませんでした。長い間、データ間には障壁があり、分離されたデータ ワークフローが一般的でしたが、ほとんどの企業はローカル コンピューティング クラスターであり、企業間のタスクは限定的にしか関連付けられていません。現在、データドリブン分析、部門横断的なデータ チーム、クラウドの台頭により、「最新のデータ ウェアハウス」やデータ レイクという用語が生まれています。クラウドにより、さまざまな点でデータの管理が容易になり、より幅広いユーザーがアクセスできるようになり、処理が高速化されます。データレイクとデータウェアハウスの議論がなければ、企業はデータを有意義な方法で使用することはできません。ただし、データ レイクとデータ ウェアハウスのどちらを選択するかになると、答えは簡単ではありません。2013 年に Amazon Redshift がリリースされ、その後数年で Snowflake や Google BigQuery などがリリースされ、市場の人気はますます高まりました。S3 や Databricks などのデータ レイクをミックスに追加すると、データ レイクとデータ ウェアハウスのどちらを選択するかの決定がさらに難しくなります。 

データ ウェアハウスとデータ レイクとは何ですか

データ ウェアハウスは、データの保存と計算を提供するデータ リポジトリであり、通常はデータ分析のユースケースに SQL クエリを利用します。データ レイクは、通常はストリーミング、機械学習、またはデータ サイエンスのユースケース向けに、構造化データと非構造化データのストレージと計算を提供するデータ リポジトリです。

データレイクとデータウェアハウスの類似点と相違点

データ レイクとデータ ウェアハウスはどちらもデータ リポジトリです。データ ウェアハウスとデータ レイクの 3 つの主な違いは、ストレージ、メタデータ、およびコンピューティング能力を提供する方法です。 

ストレージ: ストレージとは、データ ウェアハウスとデータ レイクがすべてのテーブルに存在するすべてのレコードを保存する方法を指します。さまざまなストレージ テクノロジーとデータ形式を利用することで、データ ウェアハウスとデータ レイクは、必要なコストとパフォーマンス特性を備えた幅広いユースケースに対応できます。従来、データ レイクは生の構造化データ、半構造化データ、および非構造化データを無期限に保存しますが、データ ウェアハウスはデータとそれに対応するメタデータを整然と保存します。Databricks ではユーザーが Unity Catalog と Delta Lake を通じて構造とメタデータを追加できるようになったのに対し、Snowflake では Apache Iceberg テーブルを導入して SQL テーブルの信頼性とシンプルさを実現し、同時に Spark、Trino、Apache Flink などの Apache エンジンを有効にしたため、これらの違いは時間の経過とともに収束しました。 、Presto、および Hive は、同じテーブルを同時に安全に使用できます。

メタデータ: データ ウェアハウスとデータ レイクは、多くの場合、作成したすべてのデータベース、スキーマ、テーブルを管理および追跡する方法を提供します。これらのオブジェクトには、スキーマ、データ型、ユーザー生成の説明、さらにはデータの鮮度やその他の統計などの追加情報が伴うことがよくあります。 

コンピューティング: コンピューティングとは、データ ウェアハウスまたはデータ レイクが、保存されているデータ レコードに対して計算を実行する方法を指します。このエンジンにより、ユーザーはデータの「クエリ」、データの取り込み、およびデータの変換を行うことができます。通常、これらの計算は SQL によって表現されます。これは、データ レイクがデータ ウェアハウスと重複するもう 1 つの領域です。Snowflake の Snowpark は、Java、Python、Scala などの複数のプログラミング言語をサポートしており、これらは SQL 関数として実行されます。その後、パンダを使用したネイティブ Python エクスペリエンスと、長い SQL を書かずにデータ操作を行うための PySpark のような API である Snowpark Python もリリースしました。一方、Spark SQL は、Python、R、Scala などの言語を SQL コマンドに変換するのに役立ちます。

データウェアハウスが必要な理由

データ ウェアハウスは完全に統合および管理されたソリューションであるため、すぐに構築して使用することが簡単です。データ ウェアハウスを使用する場合、企業は通常、単一のベンダーが構築および運用する単一のソリューションでメタデータ、ストレージ、コンピューティングを使用します。データ レイクとデータ ウェアハウスの議論では、データ ウェアハウスでは一般に、より多くの構造とスキーマが必要であり、多くの場合、データの読み取りと使用時のデータ衛生性の向上と複雑さの軽減が求められることを考慮してください。データ ウェアハウスは、事前にパッケージ化された機能と SQL の強力なサポートにより、高速で実用的なクエリを容易にし、データ分析チームにとって理想的なものとなっています。 

データレイクが必要な理由

データ レイクとデータ ウェアハウスの議論では、データ レイクはデータ ウェアハウスの DIY バージョンであり、データ エンジニアリング チームがシステムで使用するさまざまなメタデータ、ストレージ、コンピューティング テクノロジを選択できるようになります。データ レイクは、少数 (またはそれ以上) のデータ エンジニアによってサポートされる、よりカスタムのプラットフォームを構築したいデータ チームやデータ サイエンティストに最適です。

データ レイクの一般的な特徴には次のようなものがあります。

(1) ストレージと計算の分離: この機能はコストを大幅に節約するだけでなく、リアルタイムのストリーミングとクエリのためのデータの解析と強化にも役立ちます。

(2) 分散コンピューティングのサポート: 分散コンピューティングは、セグメント化されたクエリのパフォーマンスの向上、耐障害性の高い設計、および優れた並列データ処理を可能にするため、大規模なデータ処理のパフォーマンスのサポートに役立ちます。

(3) カスタマイズと相互運用性: 「プラグ アンド プレイ」の性質により、データ レイクはデータ プラットフォームの拡張性をサポートし、企業のデータ ニーズの発展と成熟に応じてスタックのさまざまな要素が簡単に連携できます。

(4) 主にオープン ソース テクノロジに基づいています。これにより、ベンダー ロックインが軽減され、優れたカスタマイズが可能になります。これは、大規模なデータ エンジニアリング チームを持つ企業にとって非常に効果的です。

(5) 非構造化データまたは構造の弱いデータを処理する機能: データ レイクは生データをサポートできるため、データを処理する際の柔軟性が向上し、データ サイエンティストやデータ エンジニアに非常に適しています。生データを操作すると、集計と計算をより詳細に制御できるようになります。

(6) 複雑な非 SQL プログラミング モデルのサポート: これは、データ レイクとデータ ウェアハウスの違いです。ほとんどのデータ ウェアハウスとは異なり、データ レイクは、Apache Hadoop、Apache Spark、PySpark、および高度なデータ サイエンスと機械学習のためのその他のフレームワークをサポートしています。

湖と倉庫の統合とは

データ レイクとデータ ウェアハウスのどちらを選択するかを決定するのは非常に難しいですが、特にデータ エンジニアリング チームの間では代替案が登場しています。これは、データ ウェアハウスとデータ レイクの機能を組み合わせたソリューションであり、従来のデータ分析手法と、機械学習などのより高度なコンピューティング用に構築された手法を組み合わせたものです。レイクとウェアハウスの統合は、クラウド ウェアハウス プロバイダーが Redshift Spectrum や Delta Lake などのレイク スタイルの利点を提供する機能を追加し始めたときに初めて登場しました。同様に、データ レイクには、SQL 関数やスキーマなどのウェアハウスのような機能を提供するテクノロジが追加されています。現在、データレイクとウェアハウスの違いは狭まりつつあります。

選び方

データレイクとデータウェアハウスの選択は簡単な答えではありません。データ レイクまたはデータ ウェアハウスの決定で何を選択するかに関係なく、従うべきルールがいくつかあります。

(1) 企業のデータ目標に応じて適切なソリューションを選択します。企業が少数のワークフローで 1 つまたは 2 つの主要なデータ ソースしか定期的に使用していない場合、データ レイクを最初から構築することは、時間とリソースの点で意味がありません。ただし、企業がデータを使用してあらゆる情報を提供しようとしている場合、オールインワン ソリューションは、さまざまな役割のユーザーに迅速で実用的なノウハウを提供する可能性があります。

(2) コアユーザーが誰なのかを理解する。会社のデータ プラットフォームの主なユーザーは、いくつかの異なる部門にまたがるビジネス インテリジェンス チームですか? データ エンジニアの専任チームはどうでしょうか? それとも、さまざまなデータセットに対して A/B テストを行うデータ サイエンティストのグループでしょうか?

(3) データの可観測性。データ ウェアハウス、データ レイク、ウェアハウス レイク: 3 つのソリューションすべて (およびそれらの組み合わせ) には、データ ガバナンスとデータ品質に対する総合的なアプローチが必要です。結局のところ、データが破損したり失われたり不正確であれば、パイプラインがどれほど高度であっても関係ありません。優秀なデータ チームの一部は、データ オブザーバビリティ、つまりデータ パイプラインの問題を監視し、警告するためのエンドツーエンドのアプローチを活用しています。要約すると、データ ウェアハウスとデータ レイクの選択は、どちらかのツールを選択するというよりも、ジョブに適したツールを選択することが重要です。

ここまで述べたところで、時系列データベースのシナリオに戻りましょう。将来、時系列データがデータ レイクに入力され、その後、さまざまなデータ レイクがデータ ウェアハウスでクエリのために集約され、関連付けられるようになるのでしょうか? 例: 「マルチシステムの共存は、データ レイク、複数のデータ ウェアハウス、ストリーミング、時系列、グラフや画像のデータベースなどのその他の特殊なシステムなど、企業で比較的一般的なアーキテクチャです。」答えを出す時間。

CnosDB の概要

CnosDB は、正式にリリースされ、完全にオープンソース化された、高性能で使いやすさの高いオープンソースの分散時系列データベースです。

コード ウェアハウスに注目してください。3 つのリンクをワンクリックしてください: https://github.com/cnosdb/cnosdb