はてなブックマーク

最近よく聞かれるようになった「データレイク」という概念にあまりついていけていなかったため、いまさらながらざっと調べてみた。 データレイクとは#Wikipedia によると最初にこの言葉を使ったのは Pentaho 社の CTO である James Dixon らしい。 その時の彼のブログ (10年前…) を読むと、既にあったデータマートに対して Only a subset of the attributes are examined, so only pre-determined questions can be answered.The data is aggregated so visibility into the lowest levels is lost –Pentaho, Hadoop, and Data Lakes - James Dixon’s Blogというような問題意識

このポストについて#Data Contract CLI を触ってみたところ、面白かったのとこれからのデータパイプライン開発について思うところがあったので書いてみる。 Data Contract CLI とは？#datacontract/datacontract-cli Data Contract CLI は data contracts を運用するためのオープンソースのコマンドラインツールである。 data contracts の概念については以前の記事で詳しく書いているのでそちらをご参考いただければと。 ただしこちらの記事は1年前のものであり、今回取り上げる Data Contract CLI の登場などを含めて現在では data contracts を取り巻く状況も変わっている可能性があることに注意。 Data Contract CLI は Python で開発されており、pip でイ

インストールされたバージョンを確認。 $ dlt --version dlt 0.3.25 また、gsfs, pandas, streamlit, google-cloud-bigquery-storage も必要になるのでインストールしておく。 2. pipeline project を作成#次のコマンドで pipeline project を用意する。 これは verified source として Filesystem、destination として DuckDB を指定して pipeline project を作るという意味。 Filesystem はローカルのファイルシステムや S3, GCS のようなクラウドストレージからファイルを読むことが可能。 このコマンドが成功すると次のようなディレクトリ構造が作られる。 . ├── .dlt │ ├── .sources │ ├── c

このポストについて#このポストは datatech-jp Advent Calendar 2023 の18日目の投稿です。 web の記事で見かけた dlt というツールが気になったので調べてみた。 dlt の概要について書いていく。 What is dlt?#https://dlthub.com/ dlt とは “data load tool” の略。 雑に言うとデータパイプラインにおける ELT の Extract と Load を行う ものとなっている。 主にベルリンとニューヨークに拠点を持つ dltHub 社によって開発されており、OSS の Python ライブラリとして提供されている。 次のような特徴を持つ。 プラットフォームではなくあくまでライブラリであることが強調されているつまり Airflow, GitHub Actions, Google Cloud Functions

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 evo

データエンジニアリングの領域で少し前から目にするようになった “data contract” という言葉。 なんとなく今の業務で困っている課題の解決になりそうな気がしつつもよくわかっていなかったので調べてみた。 data contract について語られているいくつかのブログ記事などを参考にしている。 Data Contract とは#データの schema というのはナマモノで、いろいろな理由で変更されることがある。 schema を変更する場合、その schema のデータ (table や log) が所属する単一のビジネス機能や application のドメインで行われることになる。 そのドメインの閉じた世界で考える分にはこれで問題ないのだが、DWH や data lake など組織レベルのデータ基盤でデータを流通していた場合はその先のことも考えないといけなくなる。 このようにチ

業務で 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 の概要 - ConfluentAWS の Glue Schema Registry はこれより後のリリースであり、同等のものの AWS マネージド版といったところだろうか。 schema registry で何ができるかは Confl

ほとんどバッチ処理しか書いたことのない者だがストリーム処理のシステムを開発することになった。 それにあたって独学で調べたことなどまとめておく。 ストリーム処理とは#そもそも “ストリーム処理” とは何を指しているのか。 以下の引用が簡潔に示している。 a type of data processing engine that is designed with infinite data sets in mind. Nothing more. – Streaming 101: The world beyond batch こちらは “streaming system” について述べたものだが、つまり終わりのないデータを扱うのがストリーム処理ということである。 例えば web サービスから生まれ続けるユーザ行動ログを逐次的に処理するというのがストリーム処理。 web サービスが終了しないかぎり

はじめに#前回のポストではデータレイクとはどういうものかというのを調べた。 今回はデータレイクの文脈でどのような OSS が注目されているのかを見ていきたい。 以下は NTT データさんによる講演資料であり、その中で「近年登場してきた、リアルタイム分析に利用可能なOSSストレージレイヤソフト」というのが3つ挙げられている。 Delta LakeApache HudiApache Kuduこれらはすべて論理的なストレージレイヤーを担う。 こちらの講演資料に付け足すようなこともないかもしれないが、このポストではデータレイクという文脈から自分で調べて理解した内容をまとめるということを目的にする。 当然 Hadoop, Hive, Spark 等もデータレイクの文脈において超重要だが、「データレイク」という言葉がよく聞かれるようになる前から普及していたのでこのポストでは触れないことにする。 Del

ちょっと昔話#かつて参画したプロジェクトの話。 そのプロジェクトでは他社から受注した受託開発として機械学習系のシステムを開発していた。 当時としては新しいフレームワークを使い、かなり頑張ってなんとか納期内で完成させた。 その中の1つの機能として A/B テストができるようにしていた。 パラメータチューニングによりパフォーマンスを改善することを想定していた。 しかし結局その機能は使われることがなかった。 なぜか。 A/B テストを実施するためのクライアントの追加の予算がつかなかったためである。 受託なのでなおさらなのだが、売上にならなければ工数をかけるこはできない。 工数を使ってパフォーマンス改善することはできなかった。 手はあるのに。 機械学習の精度は必ずしも利益に結びつかない#この昔話で何が言いたいかというと、機械学習の精度改善は必ずしも利益に結びつかないということである。 そのことを示

はじめに#このポストではストリーム処理の survay 論文の話題に対して Apache Flink における例を挙げて紹介する。 論文概要#Fragkoulis, M., Carbone, P., Kalavri, V., & Katsifodimos, A. (2020). A Survey on the Evolution of Stream Processing Systems. 2020年の論文。 過去30年ぐらいのストリーム処理のフレームワークを調査し、その発展を論じている。 ストリーム処理に特徴的に求められるいくつかの機能性 (functionality) についてその実現方法をいくつか挙げ、比較的古いフレームワークと最近のフレームワークでの対比を行っている。 このポストのスコープ#このポストでは前述のストリーム処理システムに求められる機能性とそれがなぜ必要となるかについて簡