このポストについて 前回の記事 dlt 入門 - ELT の Extract と Load を担う data load tool では dlt の概要を説明した。 この記事ではそれを踏まえ、dlt を使って CSV ファイルを BigQuery に load するという一連の開発作業をやってみる。 現実の CSV はそのまま使えなかったりするので、BigQuery に入れるまでに泥臭い前処理のような作業があることが多い。 そのへんもまとめて dlt でやってみるとこんな感じ、というのが示せるとよい。 やりたいこと 個人で管理しているお金の情報を個人用の BigQuery に置きたい、という要件を想定。 データ概要 具体的には MoneyForward のデータを load していく。 個人では API を利用できないので、web UI から export できる CSV のデータで収入・支出詳細と資産推移月次を対象とする。 CSV の export 方法は以下を参照。 入出金履歴はダウンロードできますか – マネーフォワード MEサポートサイト データの内容は次のようになっている。 収入・支出詳細_2023-11-01_2023-11-30.csv "計算対象","日付","内容","金額（円）","保有金融機関","大項目","中項目","メモ","振替","ID" "1","2023/11/30","AMAZON.CO.JP","-2830","楽天カード","食費","食料品","","0","EPv92ZjQcOxgWQx_cLbhD1" "1","2023/11/24","東京ガス","-4321","楽天カード","水道・光熱費","ガス・灯油代","","0","r6wuQPfrIRS6aFpNYZE5Eh" "1","2023/11/24","給与 カ) フロッグログ","700000","みずほ銀行","収入","給与","","0","doettKpYyNp0Tml9KQQXm1" ヘッダーがあり、各列に名前が付いている。 encoding が CP932 であることに注意。...

このポストについて このポストは 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, ローカル環境などどこでも動かすことができる スケールアウト可能な分散処理ではない extract と load にまつわる反復的で平凡な作業をなくすことを目指している schema 推論や schema evolution をサポート 宣言的なコードでメンテナンスを楽にする incremental loading をサポート 豊富な source GA, Salesforce, Kinesis などいろいろ例が挙げられている 要は API からの取得も含めて JSON-like な形式で Python で読めるものなら何でも 豊富な destination BigQuery, Snowflake など主要なクラウド DWH DuckDB はローカルでの動作確認に便利 Airflow, dbt などとの連携がある CLI の提供もある その他、Glossary を見ておくとドキュメントが読みやすくなる。...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第12章「メタデータ管理」について。 仕事でメタデータを扱い始めたので読んでおきたかった。 以降、特に注釈のない引用は DMBOK2 第12章からの引用とする。 メタデータとは 一般的な説明としては「データに関するデータ」とよく言われている。 データに関するデータはすべてメタデータなので、メタデータはとても幅広い内容となっている。 DMBOK2 ではメタデータの説明として図書館の例を挙げている。 そこには数十万の書籍と雑誌があるのに、図書目録がない。図書目録がなければ、読者は特定の本や特定のトピックの検索を開始する方法さえ分からないかもしれない。図書目録は、必要な情報 (図書館が所有する本と資料、保管場所) を提供するだけでなく、利用者が様々な着眼点 (対象分野、著者、タイトル) から資料を見つけることを可能にする。 (中略) メタデータを持たない組織は、図書目録のない図書館のようなものである。 データという資産を管理するためにも、データを利用するためにも、リスクマネジメントのためにもメタデータは必要となる。 メタデータの種類 メタデータはビジネス、テクニカル、オペレーショナルの3つに分類することができる。 ビジネスメタデータ 主にデータの内容と状態に重点を置く。 IT からは独立している。 dataset, table, column の定義と説明 業務ルール、変換ルール、計算方法、導出方法 データモデル etc. テクニカルメタデータ 技術的詳細やシステムに関する情報。 主に IT に関連している。 物理 database の table, column の名称 column のプロパティ アクセス権 etc. オペレーショナルメタデータ データの処理とアクセスの詳細を示す。 運用で得られる情報とも言える。 バッチプログラムのジョブ実行ログ データの抽出とその結果などの履歴 運用スケジュールの以上 etc. 以上、各種のメタデータで例に挙げたのはあくまで一部であり、現実にはもっと多くのメタデータが存在する。 メタデータを管理する意義 図書館の例からもわかるとおり、メタデータなしではデータを管理することはできない。 信頼性が高く管理されたメタデータにより、次のようなことができるようになる。 データのコンテキストを提供し、それによりデータ品質を測定可能にして信頼性を向上させる 業務効率の向上、および古いデータや誤ったデータの利用防止 データ利用者とエンジニアの間のコミュニケーションの改善 法令遵守の支援 etc. メタデータの管理が不十分だと次のようなことが起こる。 一貫性のないデータ利用と誤った定義によるリスク メタデータは複製されて保管されることによる冗長性 利用者の信頼性低下 etc. メタデータアーキテクチャ メタデータの内容は幅広いがしたがってその取得元も幅広く、ビジネス用語集、BI ツール、モデリングツール、等々が挙げられる。...

このポストについて このポストは 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 という機能を利用していた。...

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