データマネジメントメモ

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は行わず、バージョン管理する。