Posts

このポストについて このポストは Distributed computing Advent Calendar 2023 の3日目の記事になります。 1日目、2日目に続いて Apache Iceberg について書きますが、このポストでは Iceberg の実用例を書きます。 AWS DMS による CDC の結果を Apache Iceberg 形式にして Amazon Athena でクエリできるようにするという内容になります。 やっていることとしては Perform upserts in a data lake using Amazon Athena and Apache Iceberg | AWS Big Data Blog で紹介されている内容と近いですが、実務としての背景や工夫したところなどを書いていきます。 背景 私の所属する事業会社では日々プロダクトから様々なデータが発生しており、プロダクトの分析やレポーティング、ML など様々な用途で利用されている。 それを支える基盤としてデータ基盤が存在している。 データ基盤ではクエリエンジンとして Amazon Athena を使っている。 ストレージとしては S3 を使用しており、主に分析用として Parquet 形式でデータが置かれる。 ここに業務用の operational な database から日次でデータを取り込んでいる。 データソースは RDS (Aurora MySQL) であり、比較的大きなデータとなっている。 これまではこの RDS -> S3 のデータ取り込みには RDS の S3 snapshot export という機能を利用していた。 この機能では比較的簡単な設定により、バックアップ用のスナップショットの内容を S3 に export することができる。 ちなみに対象 database のスナップショットのサイズは数十 TB ある。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第3章「データガバナンス」について。 DAMA ホイール図において中心に置かれているので先に読んでおこうと思った次第。 以降、特に注釈のない引用は DMBOK2 第3章からの引用とする。 データガバナンスとは データガバナンス (DG) の定義は、データ資産の管理 (マネジメント) に対して職務権限を通し統制 (コントロール) することである。統制とは計画を立て、実行を監視し、徹底させることを指す。 この定義からデータガバナンスがなぜ DAMA ホイール図の中心に位置しているかがわかる。 データガバナンスにより周囲の各知識領域の計画や実施を統制するという建付けになる。 データガバナンス (DG) のゴールは組織がデータを資産として管理できるようにすることである。DG はデータを資産として管理するための原則、ポリシー、プロセス、フレームワーク、評価指標を提供し、組織の各階層レベルでデータマネジメントアクティビティを牽引する。 これを可能にするためにデータガバナンスは持続可能であり、業務プロセスに組み込まれており、測定可能になっている必要がある。 データガバナンス組織 次の組織構成が一般的なデータガバナンスモデルであるとのこと。 DMBOK2 データガバナンス組織構成 右側がデータマネジメントを実施するロールになっており、左側がデータガバナンスによりデータマネジメントさせるロールになっている。 データガバナンス運営委員会が組織のデータガバナンスの頂点となっており、最も権限が強い。 各部門にはデータガバナンス評議会 (DGC) が置かれており、これらがポリシー・評価指標の開発などのデータガバナンスの取り組みや課題、報告を管理する。 データガバナンスオフィス (DGO) はデータスチュワード (後述) などで構成され、企業レベルのデータ定義とデータマネジメントにフォーカスする。 大規模、かつデータマネジメントの意識が高い組織でないとこういった組織構成はなかなか作れないのではと思った。 ライト版の図も欲しいところ。 DMBOK2 データ問題の報告経路 ポリシーやステークホルダー利害の不一致、権限、データ品質などなど、データに関する問題は上記のような報告経路をたどる。 データスチュワード制 データスチュワード制はデータとプロセスの実行責任と結果責任を表す最も一般的な呼び名であり、データ資産の効率的な統制と利用を確かなものとする。 ちょっとこの説明ではイメージしにくいかもしれない。 データガバナンスの文脈において、データスチュワードは現場を含む組織の各レベルでデータガバナンスを効かせるための活動を行う実務者だと理解した。 データスチュワードという職務名があってもいいが、そうでなくてもよいらしい。 次のようなことをやる。 核となるメタデータの作成と管理 ルールと標準の文書化 データ品質の問題管理 データガバナンス運営アクティビティの実施 データスチュワードについては以下も参考。 参考: データスチュワードとは？役割やメリット、育成方法、選定基準について解説！ | trocco®(トロッコ) データポリシー データポリシーとは、データとインフォーメーションを生成し、取得し、健全性を保ち、セキュリティを守り、品質を維持し、利用することを統制する基本的なルールに、原則と管理糸を盛り込む指示である。 ポリシーはデータガバナンスの “What” を説明する。 通常はデータマネジメント・プロフェッショナルか業務ポリシー担当者が起草し、最終的に DGC により承認される。 組織に対して効果的に伝達、実施される必要があり、そのためには簡潔で直感的な表現であるべき。 社内ポータルなどオンラインで閲覧できるようになっているのがよい。 ...

このポストについて なんか個人的にデータマネジメントの機運が高まってきたので、ずっと積ん読していた DAMA-DMBOK を読んでいこうかなと。 で、せっかくなのでデータ関係の皆さんがよくやっているように自分としても読書メモをまとめてみようと思った。 内容を網羅するのではなく、現場のデータエンジニアとして活動した経験を踏まえて自分なりの観点でまとめてみたい。 今回は第1章「データマネジメント」で、それ以降は関心がある章をつまみ食い的に読んでいく。 DAMA-DMBOK とは DAMA とは DAta Management Association の略であり、 世界各地に80の支部を持ち、8,000名を越える会員を擁する全世界のデータ専門家のための国際的な非営利団体です。 特定のベンダーや技術、手法に依存しないことを前提として、データや情報、知識をエンタープライズの重要な資産として管理する必要性の理解を促し、この分野の成長を推進しております。 – 一般社団法人 データマネジメント協会 日本支部(DAMA Japan) とのこと。 この DAMA が刊行しているのがデータマネジメント知識体系ガイド (The DAMA Guide to Data Management Body of Knowledge) であり、その略称が DMBOK である。 ＤＡＭＡ ＤＭＢＯＫは、データマネジメントプロフェッショナルにとって有益な資料かつ指針となることを目指し、データ管理のもっとも信頼できる入門書となるよう編集されています – 一般社団法人 データマネジメント協会 日本支部(DAMA Japan) IT 業界歴の長い人なら PMBOK というプロジェクトマネジメントについて書かれた本をご存知かもしれないが、あれのデータマネジメント版だと思っていい。 私としてはデータマネジメントの教科書的なものだと考えている。 ...

前回のポストでは 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分程度かかってしまった。 レコード数はたかだか128件程度であることを考えるとかなり遅いと言える。 このままでは使い物にならない。 ...

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つだと言えそう。 ...

データエンジニアリングの領域で少し前から目にするようになった “data contract” という言葉。 なんとなく今の業務で困っている課題の解決になりそうな気がしつつもよくわかっていなかったので調べてみた。 data contract について語られているいくつかのブログ記事などを参考にしている。 Data Contract とは データの schema というのはナマモノで、いろいろな理由で変更されることがある。 schema を変更する場合、その schema のデータ (table や log) が所属する単一のビジネス機能や application のドメインで行われることになる。 そのドメインの閉じた世界で考える分にはこれで問題ないのだが、DWH や data lake など組織レベルのデータ基盤でデータを流通していた場合はその先のことも考えないといけなくなる。 このようにチームを超える影響というのは、ビジネス機能に責任を持っているチームからは見えにくくなっていることが多い。 上流の application 側で schema を変更したら下流のデータ基盤の ETL 処理がぶっ壊れてしまった、というのはデータ基盤運用あるあるではないだろうか。 というところを解決して平和に過ごせるようにすることが data contract の主なモチベーションだと思われる。 “contract” は日本語で言うところの「契約」。 組織におけるデータ流通において、データの送り手である producer 側と受け手である consumer 側との間で合意した契約を遵守することにより、前述のような問題を避けることができるというのが data contract である。 組織内のデータの見通しがよくなったり、パイプラインを宣言的に開発することができるようになるというメリットもある。 エンジニアにとっては Datafold のブログ記事の例を読むとイメージしやすいかもしれない。 To provide another analogy, data contracts are what API is for the web services. Say we want to get data from Twitter. One way is to scrape it by downloading and parsing the HTML of Twitter’s webpage. This may work, but our scraper will likely break occasionally, if Twitter, for instance, changes a name of a CSS class or HTML structure. There is no contract between Twitter’s web page and our scraper. However, if we access the same data via Twitter’s API, we know exactly the structure of the response we’re going to get. An API has required inputs, predictable outputs, error codes, SLAs (service level agreements – e.g. uptime), and terms of use, and other important properties. Importantly, API is also versioned which helps ensure that changes to the API won’t break end user’s applications, and to take advantage of those changes users would graciously migrate to the new version. ...

業務で 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.57-58). Kindle 版. ...

ポエムです。 事業フェーズごとのデータサイエンティストの役割 まずはこちらの発表。 事業立ち上げにデータサイエンティストは必要なのか？ | CA BASE NEXT とても納得できる内容だった。 一部抜き出して要約すると 事業の立ち上げフェーズ データがまだなかったり、整備されていない状態 データサイエンスによる改善がしにくい 事業のグロースフェーズ 大規模なデータが使える状態 データサイエンスによる改善がやりやすい とのこと。異論はない。 では事業が立ち上がり、グロースが落ち着いたその後の成熟フェーズではどうなのだろうかという話。 成熟フェーズにおける改善の難しさ 端的に言うと成熟フェーズでは ML によるさらなる改善は困難になってくると思う。 ここで言う成熟フェーズにおいてはプロダクトの進化とともに機械学習もそれなりに適用されてきたものとする。 成熟フェーズということで既存の ML モデル、特にビジネスインパクトが大きい箇所はこれまでいろいろな改善が重ねられてきている。 そのモデルの精度をさらに上げるとなると、より高度なアルゴリズム、より複雑なデータ等を扱う必要がある。 しかし技術的によっぽど大きなブレークスルーがない限りは精度の改善幅はグロースフェーズよりもかなり小さいものとなるだろう。 精度が上がれば上がるほど、次の1%を上げるためのコストは大きくなっていく。 改善が進むほどに次の改善業務は困難になっていく。 (蛇足だがある程度大きな組織でなければ高度で state-of-the-art な ML アルゴリズムは運用しない方がいいと考えている) では既存ではない新しい適用箇所に ML を使えばいいのではとなるかもしれない。 しかしやはりそれも難しい。 ビジネスインパクトが大きく、かつわかりやすい適用箇所にはおそらくすでに ML が適用されているからだ。 その状態から更によい適用箇所を見つけるには深いドメイン知識が必要になったりする。 という感じでいわゆるキラキラした「ML でビジネスをドライブ！」みたいなことは成熟フェーズでは難しいことが多いのではないか。 しかしデータサイエンティストにやることがないわけではない。 成熟フェーズで何ができるか ぱっと思いつくのは次のような仕事。 データドリブンな施策の立案・評価 これは事業フェーズ問わずあるべき ドメイン知識が必要 ML エンジニアリング パイプラインの改善や属人性をなくすお仕事 ML モデルの受動的なメンテナンス 精度が変化したときの調査 内部的・外部的要因によるデータの変化への対応 やっぱり ML モデルの精度改善 成熟フェーズということでビジネスもスケールしていれば 0.1% の精度改善でも売上的なインパクトは大きいかもしれない いわゆる狭義のデータサイエンスではなく、ドメイン知識であったりアナリストやエンジニア的な視点が絡んだ仕事が増えてくる。 よくある「ML だけじゃなく◯◯もできると強いよね」みたいな話になってしまった。 おわりに …という話が少し前に Twitter で知人との話題に上がった。 若者が歴史的にいろんな人が改善に取り組んできた ML モデルの改善にアサインされている、というのが近いところで観測されたのでたいへんそうだなあと思いつつこの件を思い出したので書いてみた。 ...

ストリーム処理のフレームワークが備える backpressure という機能がある。 このポストでは Apache Flink の backpressure について調べたことを記載する。 Backpressure の目的 backpressure はストリーム処理システムにおける負荷管理の仕組みの一つ。 一時的な入力データ量の増大に対応する。 インターネットユーザの行動履歴やセンサーデータなどは常に一定量のデータが流れているわけではなく、単位時間あたりのデータ量は常に変動している。 一時的にスパイクしてデータ量が増大するようなことも起こりうる。 複数の operator からなる dataflow graph により構成されるストリーム処理システムにおいては、処理スピードのボトルネックとなる operator が存在する。 一時的に入力データ量が増えてボトルネックの operator の処理速度を上回ってしまった場合に、データの取りこぼしが発生するのを防ぐのが backpressure の目的となる。 Backpressure の仕組み Buffer-based ここでは以前のブログでも紹介した、ストリーム処理で必要とされる機能について書かれた Fragkoulis et al. 1 を引用して一般論としての backpressure について述べたい。 上流／下流の operator をそれぞれ producer, consumer とする。 producer, consumer (それらの subtask と言ってもいいかも) がそれぞれ異なる物理マシンに deploy されているケースが Figure 12b となる。 各 subtask は input と output の buffer を持っており、 producer は処理結果を output buffer に書き出す TCP 等の物理的な接続でデータを送信 consumer 側の output buffer にデータを格納 consumer がそれを読み込んで処理する というような流れになる。 buffer はマシンごとの buffer pool で管理されており、input/output で buffer が必要となった場合はこの buffer pool に buffer が要求される。 ...