Froglog

このポストについて データ基盤移行について書いていくシリーズです。 前回は戦略策定 (実際は戦術) までのところを書きました。 今回はそれを踏まえた技術選定、およびその後の予算獲得について書いていきます。 また、こちらは Databricks Advent Calendar 2024 シリーズ 2 の16日目の記事にもなっています。 はいそうです、出落ちですが技術選定として Databricks を選ぶことになります。 スコープ 前回 Part 1. 戦略策定編では概ねのロードマップが決まり、まずはデータ基盤のリアーキテクチャをやっていくことになりました。 リアーキテクチャにおいてはどのような技術スタックを使っていくかが重要な選択になります。 データ基盤においてはデータ処理のためのストレージとコンピュートの選択がとても重要です。 以降ではこの2つをあわせた DWH 製品の選定について書いていきます。 「DHW 製品」という言葉は適切ではないかもしれませんが、ここではストレージ + コンピュートが組み合わさったものぐらいに考えてください。 もちろんデータ基盤には他の技術要素もあり、それらも軽くない選択ですがこのポストでは割愛します。 (気が向いたら別記事で書くかも) 技術選定の目的 まず何のために技術スタックの置き換え、ひいては技術選定をするかの目的を明確にしておく必要があります。 旧データ基盤では次のような技術スタックになっていました。 ストレージ: S3 コンピュート: Glue Job, Athena この構成には次のような課題がありました。 主にこれらの課題を解決するために DWH 製品の乗り換えを検討することになりました。 dbt との親和性の低さ 一貫したガバナンスの欠如 dbt との親和性の低さ 前回作成したロードマップにおいて、dbt の導入が課題解決における重要なポイントになっています。 dbt の周辺エコシステムがデータ基盤の課題の解決に大きく貢献すると考えています。 また、データパイプラインの開発・運用の負荷も dbt 導入で軽減できそうです。 旧データ基盤では Glue Job と Athena クエリを組み合わせた複雑なパイプラインになっており、table を1つ追加するだけでもいろいろなコードに手をいれる必要があります。 ほぼ SQL で実装でき、かつ宣言的にパイプライン構築できる dbt は魅力的です。 仮に旧データ基盤に dbt を導入するとなると dbt-athena を使うことになります。 ただ dbt による Athena のサポートはやや弱く、dbt-athena はコミュニティ版から少し前に移管されたものですし、これを書いている2024年12月の時点で dbt Cloud の Athena のサポートはまだプレビューです。 反論がある方もいらっしゃるかもしれませんが、モダンなデータ基盤構築において Athena はやや影が薄い印象があり、dbt のサポートの弱さもこれが原因だと思います。 (ただし直近の re:Invent 2024 の内容からすると潮目が変わる可能性もありそうです) ...

このポストについて データ基盤移行について書かれた各社の技術ブログなど見かけることがありますが、割とさらっと書かれていることが多いように思います。 本当はいろんな面で苦労があり、記事に表れていない辛さや工夫などがあるはず。 ということで今自分が経験している普通の会社の普通のデータ基盤移行について、詳しく記事にしてみようと考えました。 何回かに分けてデータ基盤移行のいろいろな側面を、うまくいったこともいかなかったことも含めて書いていきます。 とはいえ現在進行形なので、全編書き終わるのはかなり先になりそうです。 移行の背景 組織 まずイメージしやすいよう、どういった組織におけるデータ基盤移行なのかについて軽く触れておきます。 社員規模: 〜100名 web 系の B2C ビジネス データチームの構成 マネージャ: 1名 (データエンジニアリングの経験はほぼない) データエンジニア: 2 -> 3名 (途中で採用) 中小のベンチャー？企業ではありますが、意思決定プロセスは JTC 感があります。 私はデータエンジニアのポジションとなっており、その視点からの話であることにご留意ください。 小さい組織ということで私は移行の計画から設計、開発その他のあらゆるフェーズに中心的に関わっています。 どこもそうだと思いますが、人員的にはまあまあきびしい。 よくある中小 IT 企業のよくあるデータ基盤移行の話だと思っていただきたく。 大企業ではないのでそこまでちゃんとはしていません。 (ちなみに自分のブログで本件を記事にしていいかは上長に確認の上、OK をもらっています) 旧データ基盤 一連のポストでは移行前のデータ基盤のことを「旧データ基盤」と表記するものとします。 旧データ基盤は AWS 上で構築されており、アーキテクチャについて簡単に挙げると storage: S3 ETL: Glue Job, Athena SQL engine: Athena workflow orchestration: MWAA のようになっていました。 旧データ基盤の開発・運用側 (データエンジニア) としても、また社内の利用者側としてもいろいろと問題が挙がってきてはいました。 しかしそれをうまく集約・言語化できていないという状況でした。 そんな中でエライ人の鶴の一声で移行しようぜ！ということになり、データ基盤の移行を検討することに相成りました。 移行計画を考えるにあたり まず考えたこと データ基盤の移行は組織におけるデータマネジメントにおいて重要な位置づけとなるはず。 したがって単なる技術スタックの置き換えというスコープで考えるのはもったいないです。 組織のデータマネジメントの未来を想定して、戦略を持って開発・運用を進めるべきであると考えました。 そのためにはイシューを明確化しないといけません。 でもどの抽象度レベルで？ ボトムアップの戦術策定 まずは現場感覚、ボトムアップでの課題を明らかにすることを考えました。 本来は後述する戦略レベルから先に考えるべきですが、実際に目に見えている課題があり、取り組みやすかったというところで戦術のレベルから考え始めています。(良し悪しはある) 現状のアーキテクチャと運用では戦略策定への対応が難しいため、せめてそのための地ならしとして今見えている課題に対応できる状態にしたいというのもありました。 ...

このポストについて ​ DMBOK2 を読み進めていくシリーズ。 今回は第13章「データ品質」について。 これまで業務で「データ品質」という言葉が使われることがあったが、意味が限定的だったり人によって定義が違ったりしていた。 そのあたりクリアにできるとよい。 ​ 内容紹介 ​ データ品質の定義 ​ データ品質の簡潔な定義は「目的に適合している」。 データ品質管理の定義は「データを収集し扱うための技法を適用し、企業や地域のデータ利用者の、ニーズや利用に適したデータとすることを保証する活動を計画し、実施し、管理する」。 ​ データ基盤担当の仕事柄、データ品質というとどちらかというと上流であるデータソース側の定義が重要だと思っていたが、そうではなく下流であるデータ利用においての観点が起点になるというのが気づきだった。(でも考えてみれば当たり前) ​ ビジネス上の意義 ​ ステークホルダーの体験と組織の評判を高める ex. データが正しいことを顧客が信頼し、組織との取引に自信を持てる 組織がより有効な成果を出せるようにする ex. ビジネスチャンスの特定と効果的な請求により売上を獲得できる 低品質なデータによるリスクとコストを削減する ex. データが正しいかどうかをスタッフが見極める時間が減る ex. 誤ったデータによる誤った意思決定 組織の効率と生産性を向上する ex. カスタマーサービスにかかってくる電話が減り、問い合わせを解決できるようになる ​ 重要なデータ ​ データ品質管理における第一の原則は、組織とその顧客にとって最も重要なデータに改善努力を集中させること。 ​ ex. 顧客のメールアドレス欄のデータが不完全であれば、顧客にメールで商品情報を送ることができず、潜在的な売上を失う 1通のメールを送るごとに100円の収益が得られることが知られている → データ品質の改善に明確な価値があると言える ​ 重要なデータは組織や業界によって異なるが、以下のような用途で使用されることが多い。 ​ 規制、財務、経営報告 事業運営上のニーズ 製品の品質と顧客満足度の測定 事業戦略、特に競争上の差別化への取り組み ​ データ品質評価軸 ​ データ品質評価軸は、測定可能なデータの特徴または特性。 一般的な評価軸は次のとおり。 ​ No. 評価軸 説明 例 1 有効性Validity データの値が定義された領域の値と一致しているかどうか。 - 数値、日付などのデータ範囲- 電話番号などの書式 2 完全性Completeness 必要なデータがすべて存在するかどうか。カラム, レコード, データセットのレベルがある。 - カラム: 必須カラムにデータが入っているか？- データセット: 都道府県マスタに47都道府県の情報はあるか？ 3 一貫性Consistency データ値が同じアプローチ、評価、価値基準を用いてコード化されていることを保証すること。レコード内、レコード間、経時的な一貫性などがある。 - すべての顧客企業の住所は本社住所となっているか？- 生徒の成績評価は時を経ても同じか？ 4 整合性Integrity データに非一貫性や破綻した関係性がないこと。 - 顧客住所の国がカナダの場合、州としてカナダの州が記載されているか？ 5 適時性Timeliness データの取得または更新後、ユーザーがデータにアクセスできるようになるまでの時間を指す。 - 電力会社は電力需要データを数秒以内に利用して需給調整する必要がある- 政府機関が四半期末の2ヶ月後に GDP 報告書を作成 6 最新性Currency データが最後に更新されてから現在までの期間と、それがまだ正しいという可能性。データセットによって期待される最新性は異なる。 - 国コードは比較的静的- 銀行口座残高は変動的 7 妥当性Reasonableness データパターンが期待に合致しているかどうか。 - 先週のクリック数と比較して今日のクリック数は普通か否か？ 8 一意性/重複排除Uniqueness/Deduplication 現実世界の実体がデータセット内に2つ以上存在しないこと。 - ユーザー ID は重複していないか？- ユーザー ID は異なるが、同一の人物を表していないか？ 9 正確性Accuracy データが「現実の」実体を正しく表している程度。 - ユーザー名は現実世界の個人の名前なのか？- 顧客は実際にそのメールアドレスを使用しているのか？ ​ ここでようやく「データ品質」が具体的なものとして見えてきた。 測定が比較的容易なものもあれば困難なものもある。 ​ ...

このポストについて 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 でインストールすることができる。 この記事を書いている時点では v0.10.3 が最新であり、この記事の内容はこのバージョンに基づいている。 Data Contract CLI で扱う data contracts は YAML で定義される前提となっており、その仕様は datacontract/datacontract-specification で決められている。 この data contracts に対して Data Contract CLI では次のようなことが行える。 lint によるフォーマットチェック データソースに接続した上での schema やデータ品質のテスト data contracts の破壊的な変更の検出 JSON Schema や dbt など、他の形式からの／へのインポートとエクスポート 以下の図がイメージしやすい。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第8章「データ統合と相互運用性」について。 業務で扱っているデータ基盤はデータ統合が不完全であるため、なんとかしたいと考えている。 以降、特に注釈のない引用は DMBOK2 第8章からの引用とする。 データストレージと相互運用性とは データ統合と相互運用性 (DII: Data Integration and Interoperability) は次のように定義されている。 アプリケーションや組織内および相互間におけるデータの移動と統合を管理する データの移動を効率的に管理することがそのビジネス上の意義となる。 ほとんどの組織には数多くのデータストアがあり、組織内・組織間でデータを移動させることは IT 組織の重要な任務となっている。 複雑さとそれに伴うコストを管理するために、全社的な視点からデータ統合を設計しなければならない。 データウェアハウスなどのデータハブによりアプリケーション間のインターフェースの数を削減することができる。 DII のゴールは以下 法令を遵守しながら、必要とするフォーマットと時間枠でデータを安全に提供する。 共有のモデルとインターフェースを開発することでソリューションを管理するコストと複雑さを軽減する。 重要なイベントを特定し、アラートとアクションを自動的に起動する。 ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする。 概念・用語など 抽出、変換、取込 DII の中心にあるのが、抽出 (Extract)、変換 (Transform)、取込 (Load) のいわゆる ETL という基本プロセス。 抽出 ソースから必要なデータを選択し、抽出する 抽出されたデータはディスク上やメモリ上にステージングされる 業務システムで実行される場合は、少ないリソースを利用するように設計する 変換 ソースデータを変換してターゲットデータストアの構造と互換性を持つようにする フォーマット変更、構造の変更、意味的変換、重複排除、並べ替えなどがある 取込 ターゲットシステムに物理的に格納されるか、提供される ELT ターゲットシステムにより多くの変化機能がある場合は、プロセスの順序を ELT にすることができる データレイクへの取込を行うビッグデータ環境では一般的 レイテンシ ソースシステムでデータが生成されてから、ターゲットシステムでそのデータが利用可能になるまでの時間差。 アプローチによってレイテンシの高低が異なる。 バッチ 利用者や自動的な要求に応えて、定期的にアプリケーションや組織間を一定量まとまって移動させる レイテンシは高いが大量データを処理するときのパフォーマンスがいい 低レイテンシを実現するためのマイクロバッチもある 変更データキャプチャ データの変更 (挿入・変更・削除) のデータセットを監視し、その差分をターゲットのシステムに渡す DBMS のアクティビティログをコピーし、処理する形で行われることもある 準リアルタイムとイベント駆動 設定された予定により1日を通して分割された少量のデータセットで処理されたり、データ更新などのイベントが発生したときに処理されたりする 一般的にエンタープライズ・サービス・バスを利用して実装される 非同期 データ提供側は受信側の更新確認を待たずに処理を続行する リアルタイム、同期 次のトランザクションを実行する前に、他のアプリケーションからの確認を受け取るまで実行プロセスが待機する 非同期と比べて状態管理の負担が少ないが、他のトランザクションをブロックしたり遅延させたりすることもある 低レイテンシまたはストリーミング イベントが発生したときにシステムからリアルタイムで連続して流れる リプリケーション 分析やクエリによるパフォーマンス低下を防ぐために、トランザクション処理環境にリプリケーション (複製) を使用することがある。 多くの DBMS にはリプリケーションを作るためのユーティリティ機能がある。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データストレージとオペレーション」について。 主にデータベースの運用に関する内容となっており、いわゆるデータベースエンジニアの人には当たり前の話？が書かれている。 以降、特に注釈のない引用は DMBOK2 第6章からの引用とする。 データストレージとオペレーションとは 以下のように定義されている。 データの価値を最大化するために、永続化されるデータを設計し、実装し、サポートすること 主にデータベース管理者 (DBA: Database Administrators) が行うことになる。 次の2つのアクティビティが含まれる。 データベースサポート: データベース環境の初期実装からデータの取得、バックアップ、廃棄までのデータライフサイクル関連アクティビティ データベース技術サポート: 技術要件を決め、技術的なアーキテクチャを定義し、技術を実装・管理する 事業がデータに依存する企業においてはデータストレージとオペレーションのアクティビティは事業の継続性のために必要不可欠である。 ゴールは次のとおり データライフサイクル全体にわたるデータの可用性を管理する データ資産の完全性を保証する データ処理の性能を管理する 概念・用語など データベースアーキテクチャの種類 集中型データベース: 単一システム内で使うデータを一箇所にまとている 分散型データベース: 多数のノードにデータが配置される 連邦型データベース: 自立した複数のデータベースシステムを単一の連邦型データベースに割り当てる 仮想化／クラウドプラットフォーム: クラウド上のデータベースを実装 データベース処理のタイプ ACID: トランザクションの信頼性のための制約 原子性 (Atomicity): 操作はすべて実行されるかまったく実行されないかのどちらか 一貫性 (Consistency): トランザクションはシステムが定義するすべてのルールを常に満たさなければならない 独立性 (Isolation): 各トランザクションは実行中の他のトランザクションの影響を受けない 永続性 (Durability): トランザクションは完了すると元に戻せない BASE: データの量と多様性を受けた、ACID とは異なる考え 基本的に利用可能 (Basically Available): ノードの障害発生時もあるレベル以上の可用性を保証する ソフトステート (Soft State): データは一定の変動状態にある 最終的な一貫性の確保 (Eventual Consistency): データは最終的にすべてのノードで一貫性を保つが、各トランザクションの一貫性が常に確保されているわけではない CAP: 分散システムでは以下のどれか2つしか満たせない 一貫性 (Consistency): システムは常に想定どおり動作できなければならない 可用性 (Availability): システムは要求時に利用可能でなければならに 分断耐性 (Partition Tolerance): システムは部分的な障害の発生時に運用を続行できなければならない データベース構成 上から順により制御された構造であり、かつ古くからあるものとなっている。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データモデリングとデザイン」について。 第4章でデータモデリングについて言及されていたが、ここで詳しく見ていく。 以降、特に注釈のない引用は DMBOK2 第5章からの引用とする。 データモデリングとは データモデリングとは、データ要件を洗い出し、分析し、取扱スコープを決めるプロセスであり、データ要件を記述し伝えるために、明確に定義されたデータモデルと呼ばれる様式が用いられる。このプロセスは反復的であり、概念、論理、物理モデルが含まれる。 第4章 データアーキテクチャ ではエンタープライズ・データモデルという言葉が登場したが、この第5章ではそのデータモデルがより具体的に解説されている。 データモデルは効果的なデータマネジメントを行うにあたり必要なものとされている。 次のような意義がある。 データに関する共通語彙を提供する 組織のデータや情報システムに関しての明示的な知識を捉え文書化する プロジェクトにおいて主なコミュニケーションツールとして使われる アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる データモデルは組織が把握した現状、またはあるべき姿として組織のデータを記述する。 カテゴリー情報、リソース情報、業務イベント情報、詳細取引情報がその対象となる。 データモデルの構成要素 ほとんどのデータモデルはエンティティ、リレーションシップ、属性、ドメインにより構成される。 エンティティ エンティティとはある組織が情報を収集する対象のこと。 組織が使う名詞。 以下は Marmaid の Entity Relationship Diagrams でエンティティを表現した例。 学校を例にしており、学生、コース、インストラクタがエンティティとして表されている。 --- title: Entity --- erDiagram Student Course Instructor リレーションシップ リレーションシップはエンティティ間の関連性を表す。 以下の例は学生はコースを “履修する”、インストラクタはコースを “教える” ことを表している。 --- title: Relationship --- erDiagram Student }|--|{ Course : take Instructor }|--|{ Course : teach 線の両端の形はリレーションシップの cardinality (多重度) を表している。 この場合ではそれぞれカラスの足状になっているが、それぞれ「1またはそれ以上」という意味で、「学生は1つ以上のコースを履修する」「コースは1人以上の学生に履修される」ということを表している。 リレーションシップの arity (項数) は一般的には二項型 (バイナリリレーションシップ) であることが多く、2つのエンティティ間の関係を表す。 一方で線の両端が同じエンティティにつながっている単項型、3のエンティティが関連する三項型もある。 以下は単項型の例で、前提となるコースの履修が必要であることを示す。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第4章「データアーキテクチャ」について。 やや抽象度が高い内容となっており、理解が難しいと感じた。 以降、特に注釈のない引用は DMBOK2 第4章からの引用とする。 データアーキテクチャとは データアーキテクチャの定義は以下のとおり。 企業の (組織構造に関係なく) データニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持する。マスターとなる青写真を使ってデータ統合を手引し、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う。 業務戦略と技術実装の間を橋渡しすることがデータアーキテクチャの目的。 以下が成果物、つまり前述の定義の「マスターとなる青写真」となる。 データの保存と処理の要件 企業の現在のデータ要件と長期のデータ要件を満たす構造や計画の立案 これらを記述するためにエンタープライズ・データモデル (EDM) とデータフロー設計が必要となる。(後述) エンタープライズアーキテクチャ データアーキテクチャとビジネス、アプリケーション、テクニカルなど他の領域のアーキテクチャとの違いは下表のようになる。 それぞれが影響を及ぼし合う関係となっており、データアーキテクチャはビジネスアーキテクチャによって決められる。 ドメイン エンタープライズ・ビジネスアーキテクチャ エンタープライズ・データアーキテクチャ エンタープライズ・アプリケーションアーキテクチャ エンタープライズ・テクニカルアーキテクチャ 目的 企業が顧客や他のステークホルダに どのように価値提供しているかを 明らかにする データがどのように整理・管理されるべきか記述する 企業内アプリケーションの 構造と機能を記述する システムを稼働して価値を 提供するために必要な 物理実装技術を記述する 要素 ビジネスモデル、業務プロセス、業務能力、サービス、イベント、戦略、語彙集 データモデル、データ定義、データマッピング仕様、データフロー、構造化データの API ビジネスシステム、ソフトウェアパッケージ、データベース テクニカルプラットフォーム、ネットワーク、セキュリティ、統合ツール 依存関係 他のドメインに対する要件を設定する ビジネスアーキテクチャによって作られ、要求されるデータを管理する ビジネス要件に基づいて特定されたデータに対応する アプリケーションアーキテクチャを提供し実行する 役割 ビジネスアーキテクトとアナリスト、ビジネス・データスチュワード データアーキテクトとモデラー、データスチュワード アプリケーションアーキテクト インフラストラクチャアーキテクト DMBOK2 表6 アーキテクチャ領域 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第15章「データマネジメント成熟度アセスメント」について。 データマネジメントの導入において重要な役割を果たしそうなので早めに確認しておきたかった。 以降、特に注釈のない引用は DMBOK2 第15章からの引用とする。 データマネジメント成熟度アセスメントとは データマネジメント成熟度アセスメント (DMMA: Data Management Maturity Assessment) はその名の通り、組織のデータマネジメントのレベルの評価に基づくプロセス改善の取り組みのこと。 能力成熟度アセスメント (CMA: Capability Maturity Assessment) というものがあり、それのデータマネジメント版が DMMA。 CMA では 成熟度モデルは進化の観点から定義され、それにはプロセスの特性を表すレベルが使用される。組織がプロセスの特性を理解すると、組織は成熟度を測り、その能力を向上させるための計画を立てることができる。(中略) 新しいレベルに上がる度にプロセスの実行はより一貫性を増し、予測可能な状態となり、信頼性が高くなる。 レベルは通常0~5の6段階で表される。 DMMA は 全体的なデータマネジメントを評価するために使用したり、単一の知識領域や、単一のプロセスに焦点を当てて使用したりできる。どのような点に焦点を当てたとしても、DMMA はデータマネジメント業務の健全性と有効性について、業務と IT の視点のギャップを埋めるために役立つ。 組織が DMMA を実施する理由は、規制への対応、データガバナンス、プロセス改善、etc. DMMA の第一のゴールはデータマネジメント活動の現状を評価することであり、それにより改善計画を立てることができるようになる。 アセスメントレベル 以下はアセスメントレベルの概要。 データマネジメントの各知識領域 (ex. データガバナンス、メタデータ管理、etc.) ごとにレベルが評価される。 level 0: 能力が欠如した状態 データマネジメントの取り組みがない level 1: 初期／場当たり的な状態 限られたツールセットを用いた一般的なデータマネジメント ガバナンスは低レベル データ処理は一部の専門家に依存し、役割や責任は部門別に定義されている level 2: 反復可能な状態 組織は一元化された共通ツールを使い始める 役割は明確化されており、一部の専門家のみに依存しない level 3: 定義された状態 拡張可能なプロセスの導入と制度化 組織全体である程度統制されたデータの複製 データ品質全体の総体的な向上 組織的なポリシー定義と統制 level 4: 管理された状態 新しいプロジェクトやタスクから得られる結果が予測され、リスクの管理が始まる データマネジメントに成果に対する評価尺度が含まれる データマネジメント用の標準ツールが集中管理計画とガバナンス機能に組み合わされている level 5: 最適化された状態 活動の成果は十分予測可能に 組織は継続的な改善に重点を置く 十分理解された評価尺度を使ってデータ品質とプロセスが管理・測定される 次のように各知識領域ごとに可視化することができる。 現状ランクと求められるランクの乖離が大きいところが組織にとってのリスクとなる。 ...

このポストについて 前回の記事 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 であることに注意。 ID の列があるので、行の識別に使えそう。 ...