​ ​

あなたの知らないファームノート 第2回 Data Management について

こんにちは。
ファームノートクラウド開発グループの谷内です。

前回に続き、「通常の WEB サービス開発ではあまり触れる機会のない技術かもしれないが、ファームノートでは積極利用している」技術についてご紹介します。

以前は CQRS + Event Sourcing という文脈から、「参照専用テーブルを作成します」という説明を行いました。

ファームノート個体/群管理システムは、家畜に対する従業員、獣医師、授精師のあらゆる行為を Event Sourcing におけるイベントとして記録しています。
発生した過去の事実と、未来の予定としての双方のイベントが入力されます。
それらのイベントを時系列に並べて計算し、イミュータブルなテーブルを生成します。
そのテーブルには、「家畜が現在どのような状態にあるか」を数百種類に及ぶ計算済みのプロパティとして保存します。
それらは例えば、1頭単位の牛の生理状態などを表しますが、集約することで群の繁殖状況や農場全体の経営状態についても算出します。

実はこのテーブルは、CQRS でいうところの普通の参照専用テーブルではありません。

temporal dbevent sourcing というと、すべての活動履歴を追跡可能であるため、Data Management におけるセキュリティの話とつながりやすいところではないかと思いますが、別の側面も持っています。
それは DWH や BI といったデータ分析用途です。

以下、図をもとに作業フローを追いながらデータの説明をします。

database_management.png

1. まず作業担当者が、各人の作業履歴をスマートデバイスから入力します。

この作業ログは RDB に正規化された状態で保存されます。

2. 分析用データの抽出にはいくつかの方法がありますが、採用データベースが PostgreSQL だったこともあり、トリガーで変更データをキャプチャしています。
これは、設計が複雑になることやパフォーマンスの問題につながることから、一般にはあまり採用されない方式であると思います。
我々は、アプリケーション構築段階からデータのキャプチャリングコストを見込んで計測しておくことで、これらの問題をクリアしました。
当時は PostgreSQL のバージョンも 9.3 であり不可能でしたが、いまでは Logical Decording によって変更をストリーミングする方がよい設計となりそうです。

3. キャプチャされたデータは、Accumulating Snapshot として保存されます。
この時に、前回ご説明した、Event Sourcing による参照用テーブルの再構築が行われます。
さらにここには temporal db の特徴があり、時系列情報が加味されています。
このようなテーブルを Timespan Accumulating Snapshot といいます。
これに、マスタ等の各種情報をリレーションして Fact テーブルを構成しています。

4. この Fact テーブルは時系列を持っているため、任意の時点での在庫などが即時に確認できます。
それにより、PCから在庫管理等の日常業務を行えます。
さらには、ユーザーが自由にクエリを組み立てられ、その結果が常に瞬時に返ってくることから業務オペレーションの効率化が実現されています。

5. CQRS の参照用テーブルは事前に値を計算して、場合によっては多JOIN を回避したりすることによって参照性能を上げています。
これに時系列情報を加えることで、計算済みの項目を時系列にまたがって処理し、MOLAP と ROLAP のいいとこ取りを目指しています。
現在はキャッシュにすべき項目の選定に改善の余地があり、速度的にはまだ満足のいくレベルではないのですが、この Cube を利用することで、妊娠率の計算をリアルタイムで行っています。
現状は OLAP Client としての機能を Farmnote が持っていないため柔軟性がないのですが、将来的には farmnote 上でユーザーが自由に分析可能な BI ツールとしての側面も持たせる計画があります。経営者がタブレット端末から経営情報にアクセスし、お手軽にセルフBIを可能にするのが目的です。

ファームノートでは、データ分析に強いエンジニアを募集しています。
農業分野におけるデータアーキテクトというのは、今、とても大きなニーズのあるチャレンジングな分野です。
我こそはという方は是非ご応募ください!

このエントリーをはてなブックマークに追加