Data Lake

前回のポストでは merge on read で Apache Iceberg の table を near real time で更新するということを行った。 このポストではそのメンテナンスについて触れて、かつそれを実行してみる。 merge on read の課題 merge on read で table を更新する場合、copy on write の場合と違い table 全体を洗い替えする必要はなく差分のみを追記することになる。 したがって更新にかかる時間は copy on write よりも短くなる。 一方で merge on read の名のとおり読み出し時に積み重なった差分とベースを merge して最新の snapshot とするため、読み出しの速度は copy on write より遅くなる。 長時間更新され差分がたくさん存在しているとなおさら遅い。 なので 更新頻度が低く、参照頻度が高いユースケース -> copy on write 更新頻度が高く、参照頻度が低いユースケース -> merge on write という使い分けがよいとされている。 前回ポストの例では一晩更新を続けた後の merge on read の table に対して簡単な select 文を実行したところ、6分程度かかってしまった。...

Apache Iceberg の table を near real time に、つまり高頻度で更新するということをやってみた。 Apache Iceberg とは Apache Iceberg (以下 Iceberg) は分散ファイルシステムやクラウドストレージ上の table format であり、Apache Hudi や Delta Lake と並んで data lake や lakehouse architecture で用いられる。 特徴的なのは table とデータ実体 (Parquet, Avro など) の間に metadata file, manifest list, manifest file の抽象的なレイヤーがあり、ファイル単位で table の状態を track できること。 これにより強い isolation level、パフォーマンス、schema evolution など様々な機能・性能を実現できるようになっている。 Apache Iceberg Iceberg Table Spec 詳しくは公式ドキュメントを参照のこと。 最近では SmartNews 社が Iceberg で data lake を構築したことを記事にしていた。 Flink-based Iceberg Real-Time Data Lake in SmartNews (Part I) | by SmartNews | SmartNews, Inc | Apr, 2023 | Medium ベンダー提供の DWH 中心ではなく Lakehouse Architecture を目指すのであれば最有力の table format の1つだと言えそう。...

業務で AWS Glue Schema Registry を使おうとしたけど、やっぱりやめたというお話。 Glue Schema Registry What’s Schema Registry? AWS Glue Schema Registry は2020年に発表された AWS の機能だ。 Control the evolution of data streams using the AWS Glue Schema Registry 一方、私が最初に schema registry 的なものを見たのは Confluent の例。 Schema Registry の概要 - Confluent AWS の Glue Schema Registry はこれより後のリリースであり、同等のものの AWS マネージド版といったところだろうか。 schema registry で何ができるかは Confluent のリンク先の図がとてもわかりやすいので参考にしていただきたい。 Glue Schema Registry もだいたい同じで、ストリーム処理のための機能である。 Glue Schema Registry で解決したい課題とその機能 データ基盤上のストリーム処理における schema 管理はバッチ処理のそれとは異なる難しさがある。 これは schema evolution と呼ばれる問題で以前のポストでも述べている。...

「データレイク」という言葉は使う人によって異なった意味があるように感じており、気になっていた。 このポストではアーキテクチャ目線でのデータレイクと内容物目線でのデータレイクの違いについて書いてみる。 便宜上前者を「データレイク」、後者を「データレイク層」と呼ぶことにする。 アーキテクチャ目線の「データレイク」 「データレイク」については以前こちらのポストで書いたのでここでは詳しく触れない。 詳細はリンク先を見ていただきたい。 ここでキーとなるのが、 加工前データや非構造化データを含むあらゆるデータを保存 一元的なデータ管理 という部分だ。 あらゆるデータを一元的に管理するという思想であり、これができるアーキテクチャがデータレイクということだ。 例えば AWS や Azure のドキュメントを見るとデータレイクの中が zone に分けられており、生データを保持する raw zone や加工されたデータを置いておく curated zone などがある。 (zone の命名にもいくつかの流派があるようだ…) Reference architecture - Data Analytics Lens Data lake zones and containers - Cloud Adoption Framework | Microsoft Docs 次の Robinhood 社の例でもデータレイク中に生データとその派生データが存在している。 Fresher Data Lake on AWS S3 | by Balaji Varadarajan | Robinhood 内容物目線の「データレイク層」 一方でデータレイクには生データのみを置くべき、という考えもある。 本書におけるデータレイク（DataLake）層とは、元のデータをコピーして、1つのシステムに集約したものを指します。 データソース（＝水源）から流れてきたデータを蓄える場所なのでレイク（湖）と呼びます。 ECサイトの注文履歴データを、分析用DBにコピーしている場合、それがデータレイクと言えます。データレイクのデータは、データソースと一対一の関係にあります。何も加工していない、ただのコピーだからです。 何も加工していない、ただのコピーであることが重要です。仮にデータの中身に誤りがあったとしても、修正や加工をせず、そのまま集約しましょう。 – ゆずたそ,渡部 徹太郎,伊藤 徹郎. 実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ (Japanese Edition) (pp....

はじめに 前回のポストではデータレイクとはどういうものかというのを調べた。 今回はデータレイクの文脈でどのような OSS が注目されているのかを見ていきたい。 以下は NTT データさんによる講演資料であり、その中で「近年登場してきた、リアルタイム分析に利用可能なOSSストレージレイヤソフト」というのが3つ挙げられている。 大規模データ活用向けストレージレイヤソフトのこれまでとこれから（NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05） from NTT DATA Technology & Innovation Delta Lake Apache Hudi Apache Kudu これらはすべて論理的なストレージレイヤーを担う。 こちらの講演資料に付け足すようなこともないかもしれないが、このポストではデータレイクという文脈から自分で調べて理解した内容をまとめるということを目的にする。 当然 Hadoop, Hive, Spark 等もデータレイクの文脈において超重要だが、「データレイク」という言葉がよく聞かれるようになる前から普及していたのでこのポストでは触れないことにする。 Delta Lake https://delta.io/ Delta Lake is an open-source storage layer that brings ACID transactions to Apache Spark™ and big data workloads. Delta Lake Delta Lake は Apache Spark の読み書きに ACID な transaction を提供するストレージレイヤーの OSS である。 Databricks が作り、2019年4月に v0.1.0 がリリースされたのが最初だ。...