開発日報

IT・WEB系備忘。日報は嘘です。

データマネジメントメモ

1. データストレージとオペレーション

データベースの保守管理。

データウェアハウス製品

DWHのせんていにあたって。

サーバの保守運用にリソースを費やしても、ビジネス面での課題解決には直接寄与せず、増え続けるデータやユースケースに対応するために、
優秀なエンジニアを駆り出すこと になり、機会損失が生じると考えたからです。
本当に守るべき制約、 達成したい目的は何か。
これらを踏まえた技術選定、 意思決定を大切にしました。

結果としてBigqueryに。

データ量が多くないならRDBMS・ELKスタックでも十分。
最近はスプレッドをデータベース代わりに活用できるツールもある。

SoEとしてのDWH、SoRとしてのRDBMS

DWHは探索的なデータ分析に向いている。

が、ミッションクリティカルな業務には向いていない。

そこで、「業務影響が大きくなったら技術要素を切り替える」

・ 開拓 フェーズ: 簡易システム( BigQuery + Python or Google App Script)を構築してデータ活用する
・ 検証 フェーズ: 1ヶ月ほど運用しながら、少しずつ業務に組み込む 
・ 装着 フェーズ: プロダクトのWebAPI・バッチ( MariaDB + SpringBoot)に移管する

2. データ統合と相互運用性

データの移動を効率的に管理すること。

統合ソリューションの設計、開発、監視

Jenkins + 各種ETLツール

DWHへのデータ繁栄にあたって、、Embulk + Fluentdは便利だよ。

Jenkinsでデータ流し込んでるよ。

Airflow(Cloud Composer) + Cloud Dataflow

こんなのもあるよ。

3. データモデリングとデザイン

データ同士の関係性を図示すること。

モデルストーミング

ホワイトボードや紙に書きだしながらブレインストーミングの要領で集計用のデータモデルを設計した。

ビジネス上のステークホルダやドメインエキスパートも巻き込もう。

アジャイルモデリング

  • データの網羅性にこだわらない

    • アジャイル的にデータモデルをスモールスタートさせる
  • データモデルを継続的に見直す

4. マスターデータ管理

一貫したデータを管理すること。

SLAと評価尺度を決める

データの鮮度の保証をSLAとして明記する。

独自ツールを構築(ケーススタディー)

基本的にはデータのCreate・Readのみ。 履歴を残す必要があるため、UPDATE・DELETEは行わず、バージョン管理する。