このポストについて 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 というプロジェクトマネジメントについて書かれた本をご存知かもしれないが、あれのデータマネジメント版だと思っていい。 私としてはデータマネジメントの教科書的なものだと考えている。 2023年現在における最新版は2018年の第2版となっている。 以降では DMBOK2 とする。 5年前なのでやや古いと思うかもしれないが、内容的には特定技術について書かれているわけではなく、ある程度抽象度が高い話になっているので陳腐化はしにくい。 データマネジメントとは 以降、特に注釈のない引用は DMBOK2 第1章からの引用とする。 データマネジメントとは、データとインフォメーションという資産の価値を提供し、管理し、守り、高めるために、それらのライフサイクルを通して計画、方針、スケジュール、手順などを開発、実施、監督することである。 この一文にいろいろと集約されているので見ていこう。 データとインフォーメーション ここでいう「データ」と「インフォメーション」は DIKW モデルにもとづく解釈でよい。 データはインフォメーションの原材料であり、インフォメーションは意味と目的、つまりコンテキストを付与されたデータと言える。 ex. 前四半期の売上レポートは「インフォメーション」、それの元になっている DWH のデータが「データ」 データマネジメントにおいては特にこのデータとインフォーメションを扱う。...

前回のポストでは 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つだと言えそう。...

データエンジニアリングの領域で少し前から目にするようになった “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....