「データレイク」という言葉は使う人によって異なった意味があるように感じており、気になっていた。
このポストではアーキテクチャ目線でのデータレイクと内容物目線でのデータレイクの違いについて書いてみる。
便宜上前者を「データレイク」、後者を「データレイク層」と呼ぶことにする。
アーキテクチャ目線の「データレイク」
「データレイク」については以前こちらのポストで書いたのでここでは詳しく触れない。
詳細はリンク先を見ていただきたい。
ここでキーとなるのが、
- 加工前データや非構造化データを含むあらゆるデータを保存
- 一元的なデータ管理
という部分だ。
あらゆるデータを一元的に管理するという思想であり、これができるアーキテクチャがデータレイクということだ。
例えば AWS や Azure のドキュメントを見るとデータレイクの中が zone に分けられており、生データを保持する raw zone や加工されたデータを置いておく curated zone などがある。
(zone の命名にもいくつかの流派があるようだ…)
- Reference architecture - Data Analytics Lens
- Data lake zones and containers - Cloud Adoption Framework | Microsoft Docs
次の Robinhood 社の例でもデータレイク中に生データとその派生データが存在している。
内容物目線の「データレイク層」
一方でデータレイクには生データのみを置くべき、という考えもある。
本書におけるデータレイク（DataLake）層とは、元のデータをコピーして、1つのシステムに集約したものを指します。 データソース（＝水源）から流れてきたデータを蓄える場所なのでレイク（湖）と呼びます。
ECサイトの注文履歴データを、分析用DBにコピーしている場合、それがデータレイクと言えます。データレイクのデータは、データソースと一対一の関係にあります。何も加工していない、ただのコピーだからです。
何も加工していない、ただのコピーであることが重要です。仮にデータの中身に誤りがあったとしても、修正や加工をせず、そのまま集約しましょう。
こちらの書籍にならってこのポストではこれを「データレイク層」と呼ぶことにする。
この考え方では生データの「データレイク層」の他に加工されたデータを置くための「DWH 層」「データマート層」がある。
本書においてはアーキテクチャというよりは中に何を入れるかで「データレイク層」が規定される。
この「データレイク層」の考えは日本企業でよく見かける気がしている。(が、私が知らないだけで海外事例もあるかもしれない)
以下はその例。
2024-02-04 追記
海外でも「データレイク層」の意味で data lake という言葉が使われているケースがある模様。
「データレイク」と「データレイク層」の比較
「データレイク」も「データレイク層」もやっていることは同じで、ただ何を「データレイク (層)」と呼んでいるかが違っている。
どちらも生データ、加工データ等を zone や層として分けて管理する。
以下のようなニュアンスの違いがあると認識している。
| データレイク | データレイク層 | |
|---|---|---|
| 内容物 | 生データ、加工データ | 生データのみ |
| アーキテクチャ | オブジェクトストレージ等で一元的 | データレイク層と DWH 層は別でもよい |
| 使われている場所 | 海外 | 国内？ |
個人的には「データレイク層」は「raw data 層」というような命名の方が混乱を避けつつ実を表しておりいいのではという感じがする。
(つまり raw zone ですね…)
一方で「データレイク層」と呼びたい気持ちもわかる。
まとめ
誰かが「データレイク」についてしゃべっているときはどちらの「データレイク」のことを言っているのか、気をつけた方がよい。
もっと言うと世の中にはまた別の定義もあるかもしれない。
私がこれまで一緒に仕事をしたエンジニアの中でも優秀な人たちは言葉の定義に敏感な人が多かった。
こういったところ気をつけていきたい。