これは何?
この記事は、 FOLIO Advent calendar 2020 の12日目の記事です。
11日目は、paulxllさんのデータマートを一から作り直した話でした。
13日目は、Yuki Ishikawaさんです。
先日、@j5ik2oさんからお誘いいただいたので、@MinoDrivenさんと一緒にいろいろ話して来ました。
今回は、その時に紹介した内容の補足や話し足りなかったことを書いていこうかと思います。
話してきたこと
私が主に話したのは以下の2つについてでした。
- データ基盤から見たときのアプリケーション側の技術的負債の見え方
- データ基盤から考えるドメインオブジェクトとモデリングについて
詳細については割愛しますが、主に以下のキーワードにまつわる話と、データマネジメントの営みを疎かにすると如何に大変かを話してました。
キーワード
イミュータブルデータモデル
@kawasimaさんの以下の2つのスライドを紹介しつつ、単なるCRUDで実装してしまうとデータ分析の時に何が困るのか等を話してました。
詳細については、kawasimaさんのscrapboxにあるイミュータブルデータモデル に記載されていますので、
ドメインオブジェクトを考えた後にドメインイベントも含めどうやって記録していくか考えていくのが良いかと思います。
イベントが終わった後に、@t_wadaさんが#textafmでイミュータブルデータモデルについて分かりやすく話されていたのでこちらも参考にすると良いかと思います。
#textafm の新しいエピソードを公開しました。我ながら今回も（主に和田さんのおかげで）なかなか面白い内容に仕上がった感じがしてます。特に「サービスオブジェクトとイミュータブルデータモデルに何の関連があるの？」と思われた方にぜひ聴いていただきたいです。 https://t.co/lWSlLFvWO3
— (やさいち|yasaichi) (@_yasaichi) November 30, 2020
bi-temporal data model
弊社ではbi-temporal data modelを利用して履歴を残しつつ記録することが多いため、エンジニアは理解をしていることが求められます。
下記の記事やスライドを参考にすると良いかと思います。
スタースキーマ
データ基盤を構築する際にデータの持ち方を考える時のセオリーとして採用しています。マイクロソフトに分かりやすい記事があったので参考になると思います。
ドメインイベントやドメインオブジェクトからファクトテーブルに変換するには何が必要なのか、ディメンジョンテーブルは分析等に必要な物が揃えられるか、ドメインオブジェクトから変換できるのか等、ドメインモデルとデータモデルのどちらの知識も必要になるのでモデリングの経験はこういう場合に活躍します。
ショットとフロー
前職のマネージャーの方に教わったのですが、データ分析の際以下の2つのデータがあることが要求されます。
- ある時点での全体を俯瞰出来るデータ。いわゆるスナップショット。
- 任意の対象の履歴データ。時系列に並べられていて状態遷移等がいつ発生したのかが分かる。
ドメインイベントが追記で記録されていくことで、いつどんなイベントが発生してその後どう遷移していったかがデータとして残るようになります。
また、ある時点でのドメインオブジェクトの最新状況を記録しておくことでスナップショットとして残るようになります。
Event Sourcingの考え方に基づいてデータを残しておくことで、データ分析に求められるデータを作りやすくなります。
データマネジメントが30分でわかる本
この本は、データマネジメント知識体系ガイド 第二版を読む前にザクッと知れる本です。
著者の経験に基づいた実践的な内容なので、自分に置き換えた時に想像しやすいかと思います。
データモデリングについてだけでなく、アプリケーションを開発する際にどういったデータを残す必要があるか等、アプリケーション開発者にとっても役に立つ内容が盛り込まれてます。
話足りなかったこと
個人情報との分離
データ分析の際に個人を特定できないようにする必要がありますが、アプリケーションのデータに含まれてしまっていると前処理としてマスキングや変換(例えば年齢 -> 世代に変換等)が必要になってきます。
アプリケーション側では記録する際に機微な属性などを含めないようにする、あるいは個人に関するデータは別のサービスとして管理し、アプリケーション内では個人を特定出来ないようにする等の対応を予め盛り込んでおくことが求められます。
こうすることで、個人にまつわる属性の責任の所在を明確にし、分析する際のセグメントの粒度との調整をしやすくなります。
データモデルとドメインモデル
出来れば ドメインモデル === データモデル となっているシステムが理想だとは思いますが現実では難しいので何らかの手段で変換する必要が出てくると思います。
どちらが素晴らしいとか優位だとかは無く、どちらも必要で違いを理解した上で設計の際に利用していく物だと考えています。
個人的には、ドメインモデルから考えていく方が合っているので、データ構造とかは実際に永続化する必要になるまで決めないことが多いです。
永続先はRDBが使われることが多いですが、NoSQLであったり、Kafkaのようなキューに入れることも増えてきたと思います。
普段バッチ処理の設計や実装をしていると、データからドメインモデルに変換する必要が本当にあるのかはよく考えたりします。
ドメイン知識を理解した上で本当に必要なのはバリューオブジェクトなのか、エンティティなのかを考えて実装していくのが面白いと思うことがあります。
アプリケーションが生成したデータを利用する側から見る視点を持つことで、ドメインモデルがいかに大切で、それが反映されていないデータがいかに分析に使いにくいのか、
使えるようにするまでにコストがどれくらいかかるのかが理解出来るようになったと思います。
最後に
@j5ik2oさん、@MinoDrivenさん、スタッフをされていた@yoshiyoshifujiiさん、@crossroad0201さん、匠真堂に参加している皆さん、ありがとうございました。