今回は、多段構成の後半部分をノーコードで作成し、全体を完成させた後に実際の動作検証を行います。

前回は、実際にストリーミング処理を行う部分のFLOW定義をGUIベースの専用環境で行い、そのノーコード作業の流れを簡単に紹介させて頂きました。
Equalumの処理的には、前回までの完成部分だけでも世間一般で言われている様な「サイロの壁問題」を、圧倒的にシンプルに解消出来る「誰でも作れる統合テーブル」を処理する事は可能です。
しかし、第1回目に掲げた多段構成を含めて「目標1時間以内」という事ですので、引き続き頑張って行きたいと思います。

今回の構成概要を少し現実的な状況にすると・・

1回目に今回のEqualum構成概要を説明させて頂きましたが、今回は最終回ということですので「少しリアルな感じ」に書き直してみました。

このデータフローをリアルタイム・ストリーミング＆ExactlyOnceと、勿論ノーコードでサクッと実現出来るのがEqualumの強みであり、是非！今までのやり方での構築と比べて頂ければと思います。

まずは後半部分の作成

前回の作業で、分散サイロ想定の店舗側DBが更新されると、即時に高度なCDC技術とKafka・SPARKを組み合わせた処理で、指定された手続きをストリーミングしながら実行し、その結果を指定されたDBのテーブルに格納する流れを作成しました。
今回は、後半戦に向けて統合DBテーブルの内容を「さらにCDC処理対象」とし、最終的には3種類の目的別データベースと、統合データベースの複製を自動的に行う処理をノーコードで実現させて行きます。

統合DBテーブルを上流側に登録

1回目に行った、Kafka系の処理をバックボーンに配備する為の、ノーコード設定を統合テーブルに対して行います。
手順的には全く同じですので、あっという間に完了すると思います。完了するとGUIメニューで選択可能になります（一番上の項目が該当）

オリジナルの統合テーブルを指定されたDB上のテーブルに即時複製させる

まずは、オリジナル側の統合テーブルに加えられている操作を、CDC技術を使って即時にターゲット側に完全複製する処理をノーコードで作成します。手順的には非常に簡単で、予め用意してある対抗側のテーブルとGUI上で連結させて、前回の手順と同様にMAPPINGの確認を行います。

ここで唯一のポイントは、MAPPINGを行う際に必ずWrite Behaviourの項目をUPSERTにする事だけです。

余談ですが・・・・
じゃあ、全部初めから何でも許容出来るAPPLY CHANGE TYPEにしておかないの？と聞かれるのですが、これはそれぞれの利点を的確に活用出来る選択肢として設定項目になっています。
勿論、一番軽い作業が単に来たモノを挿入するだけ・・の作業になり、当然処理速度も期待出来ますが（IoT系等では必須みたいです）、ケースによってはその部分を少し妥協して、機能の利用を優先させる選択が出来る仕組みの方が、より最適化という意味では現実的だという判断であえて明確に分離させています（リアルDBやBIやAIでかき混ぜる前提のDB等で使い分ける）。

上流側で処理の殆どが完了していますので、もの凄いシンプルなFLOW設定で完了します。

ポイントは、対抗側（ターゲット側）のテーブルをちゃんと用意しておけば、複雑なFLOW設定は不要・・・という事になります。

用途ごとの自動仕分けデータテーブルを作成する

以降は、基本的に前述の作業を繰り返すだけで完了します。
予め用意してあるターゲットDB上のテーブルを選択して統合テーブルと直結し、MAPPINGを確認して、Write Behaviourの項目をUPSERTに設定する・・・・だけです。
後半戦の4本のデータ・パイプラインは「アッと！」いう間も無く出来上がるかと思います。

また、名前を付けて登録・配備・起動の手順・操作もこれまでと全く同じです。

無事に作業が完了すると、今回は合計で9本のデータ・パイプラインが完成しました。

さて、データを流し込んでみよう・・・・

今回はPythonベースで作成した、GUI型のデータ生成＆状況可視化（簡単なクエリを投げて状況を可視化しています）ツールを使って、合計9本のノーコード・・でも後ろでExactlyOnceなKafka＆SPARKが動く、リアルタイム・データ・パイプラインの動作検証を行ってみます。
これが、今回使用したツールになります。

上の部分で必要なパラメータを設定し、中断のボタンでそれぞれに定義された処理を実行、後半の横棒がプログレスバーになっていて、上から順に

（1）SQLデータの生成状況

（2）~（6）　商材別の仮想店舗の受注（データ割り振られ）状況

（7）全ての店舗のデータを自動統合しているテーブル状況（基本的にSQLの状況に同期します）

（8）~（10）自動統合されているテーブルからCDCで自動的に目的別DBを作成している状況（基本的にSQLの状況に同期します）

（11）オリジナルの統合テーブルをCDCで自動的に別DBのテーブルに複製している状況（基本的にSQLの状況に同期します）

となっています。

Equalum上で作成した環境の稼働を確認後、店舗テーブル、統合DBテーブル、分類DBテーブルを初期化（カラムのみの状態にする）し、その後SQLデータの自動連続生成と所定の店舗テーブルへの挿入を開始します。

作業を始めるとSQL状況が変化を開始し、同時に対応するデータテーブル（緑色と赤色はEqualumのCDC技術でリアルタイム同期していきます）が変化を始めます。作業を開始してしばらくした状況と作業完了後の状況が以下の通りです。

青い部分は、全ての長さを総計すると生成されたSQL全体の数に相当します。
制止画像ではありますが、Pythonが生成するランダムなSQL処理に即時同期して、各データテーブルが更新されているイメージは掴んで頂けるかと思います（アプリケーションの観点から見れば、極めてシンプルなPythonのシーケンシャル処理でも、プログレスバーの処理順番が回ってきた時には、EqualumのCDC機能によるデータ処理済みの状況になっているので、アプリの粗を隠してくれるような動作をしています）

フォルダーの整理をしていたら、プログレスバーが地味だったバージョンでの、スタートから全データストリーミング終了までの動画が有りましたので、取り急ぎ共有させて頂きます。アプリの作りを十二分に補ってくれるEqualumのノーコード・リアルタイム・ストリーミングの感じは掴んで頂けるかと思います。

良く聞く「あるある」な話になりますが、GUIを含むこのデータ生成ツールの作成が「一番時間が、圧倒的かつ、大部分を浪費」した一連の検証作業になりました。

念のためにDBeaverでテーブル状況を確認

店舗側のテーブルから、無作為で1個選んでPythonのFaker機能を使って生成されたデータ挿入状況を確認します。

きれいに商材が揃って入っている事が確認できました。（ツールからランダムに11個割り振られた様です）
次に、統合データベース（オリジナル側）を確認します。

統合出来ている事を確認できました。（id_CDC,ts_CDCはオリジナル側の情報になります）
ついでにこの統合テーブルの複製側も確認してみます。

データの即時複製も出来ている様です。
この機能については、今回はFLOWの中で設定利用しましたが、単純に関連する全てのテーブルを遠隔地のDBにレプリケーションして欲しい・・という要求も有るかと思います。この用は場合はEqualumのレプリケーション専用機能を使って、より柔軟かつ効率的に同期複製を実現する事が可能ですので、これは是非別の機会に検証してみたいと思います。

最後に、用途別自動仕分けDBテーブルの状況を見てみます。此処では顧客情報を自動抽出したテーブルを確認しています。

きれいに目的別自動仕分けDBもCDC即時生成されていることが確認出来ました。

今回のまとめ

3回に渡り、Equalumのノーコード機能を活用した多段データシステムの「アジャイル的」作成を行ってきました。ExactlyOnce機能込みでの即時ストリーミング・データ同期の仕組みを、GUIベースの選択・設定だけで実現出来る事は、真のオンタイム・データドリブンによるDxをIT的な知識や経験を持たなくても、むしろ現場のデータ状況を理解している「真にデータのサポートをジャストインタイムで必要としている人自身」が実現出来る事を意味しています。

また、旧来・従来型のデータシステムのミドルウエア的なソリューションにおける、バッチETL,ストリーミング処理、CDCレプリケーションの3種類を個別に取り扱う必要なく、1個の仕組みでデータに関わる中間処理を全て賄える可能性も、この一連の検証を通じて確認する事が出来ました。

高度な、殆どの人が諦めていたようなデータシステム・データ流通の仕組みを、ノーコードで即時処理・同期を実現するEqualumの性能・機能は、今までの発想とは全く異なる視点から新たな可能性をDｘの世界にもたらす事でしょう。

Equalumで多段のデータパイプラインを1時間以内でノーコード作成する！（その1）はこちら

Equalumで多段のデータパイプラインを1時間以内でノーコード作成する！（その２）はこちら

最後に・・・・・###

3回に分けて検証記事を紹介させて頂きましたが、ノーコードで此処まで出来る・・・・という時代になったという（それも、CDC対応出来るDBや基盤をサポート出来るデータシステムであれば、誰でもExactlyOnceなリアルタイム・ストリーミング・データ・パイプラインが作れる）事を、ぜひ頭の片隅に置いて頂けると「きっと何かの役に立つ」かと思います。

今回の一連の作業では、Equalumの環境をPythonで関係するデータベースも含めて、１個のGUIでコントロールする・・・という目的が有りましたので、敢えて時短部分はEqualumのノーコード機能に任せる形で、素人ながらの処理状況可視化機能付きGUIツールが完成しました。

但し、現実的に考えた場合は「既存のBI群や、その他の新進気鋭なデータ・コンピューテイング系ソリューションとの連携が殆どだと思います。
そこで、市販のEqualumの処理性能に追従出来る能力を有する、LogiCOMPOSER（以前に紹介済みですが・・）を使った同期速度の例を共有させて頂き、今回の締めとさせて頂きます。

左側のデータベースに処理が行われると同時に、右側のデータベースにEqualumによる処理が実行されて、それらの結果（LogiCOMPOSERの場合は、マイクロクエリ技術を使っていますので、EqualumのCDCよりも後の処理層での情報を利用しています）が即時可視化されている様子が確認頂けるかと思います。

この世界を支える裏方のデータ・パイプライン（kafkaベースでExactlyOnce対応）は、勿論「ノーコード」でサクッと！作られています。

国内での正式取り扱い関連については、国内での販売代理店による試用環境提供を始め。かなり具体的な準備が整ってきていると聞いておりますので、改めて別の機会にこれらの試用環境等に関する利用報告や、Equalum社の内部情報等（公開可能な・・）も共有させて頂ければと考えております。

謝辞

本検証は、Equalum社の公式バージョン（V2.27)を利用して実施しています。
この貴重な機会を提供して頂いたEqualum社に対して感謝の意を表すると共に、本内容とEqualum社の公式ホームページで公開されている内容等が異なる場合は、Equalum社の情報が優先する事をご了解ください。