16. Twin Graph 更新の履歴蓄積

前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

Azure Digital Twins が保持する Twin Graph が保持する情報は、”今”の状態に関するものです。例えば、IoT 機器でどこかの部屋の温度を測っていて、その温度を Twin Graph 上の対応する Twin の 温度 Property に反映しているとすると、その温度 Property は IoT 機器が送ってきた最新の温度だという事です。温度は当然、刻一刻と変化していきます。IoT ソリューションの基本的なアーキテクチャパターンであるラムダアーキテクチャの”リアルタイムデータストリーム”のパスによる、今どうなっているかを表示するダッシュボードや、Stream Analytics 等を活用した部屋の快適な状態からの逸脱や機器の異常状態の検出をトリガーにしたワークロードの開始等のシナリオは、Twin Graph の今のデータの保持と、更新の通知の機能だけで十分構成可能ですが、任意の時点での、状態更新履歴の参照や、IoT 機器の最適な制御を編み出すための、過去のデータを使った機械学習等、ラムダアーキテクチャの”コールドパス”の実現は、Azure Digital Twins の機能だけでは実現できません。
Twin Graph の更新履歴の保持は、Azure Data Explorer との連携で行うようになっています。

ちょっと前までは、Time Series Insights という、ある意味癖の強いサービスが用意されていて、それと連携するようにという事になっていました。
私的には、このサービス、時系列データの保持に特化していて、蓄積の際、時系列データ専用の Apache Parquet を使っていたり、通常のデータベースでは意外と難しい過去の期間のデータの高速の取り出しが出来たりと、結構面白いなと思っていて好きなサービスだったのですが、あえなくターミネートされることになってしまいました。まぁね…過去のデータを入れられるのが90日前とか、ちょっと出所が謎なツリー構造のみの限定的なモデルの定義とか、判り難いこと甚だしいサービスだったので、しょうがないですね。
データを専門に取り扱う Azure Data Explorer が進化して、時系列データの扱いもそれに統合されるのは、時間の問題だったんでしょうね。
マイクロソフトのサービスに限らず、クラウド系のサービスは、サービスイン後に別のサービスに吸収されたりなくなったりは日常茶飯事です。不幸にも（？）そのサービスを使って構築した IT ソリューションが、サービスインした後でも、使っているサービスがオワコンになってしまったら、代替サービスに素直に乗り換えましょう。そのためには、”利用するサービスの本質は何か”と”それを使ってやりたいことは何か”を明確にしておくことが重要です。
最も、そのサービスのヘビーユーザーになって、提供側にそのサービスをオワコンにさせない、という別の方法もありますが…

補足コメント

今回の記事では、Azure Data Explorer を使って、Azure Digital Twins の Twin Graph の更新履歴を保持する事を試みます。