Equalumがやって来た！（展開編２）

#今回は各機能の検証と少し複雑な(?)FLOWを作ってみる！
前回の検証で、Equalumを使うと複雑なコーディングを実施しないで、データベースを含むSQL周辺の基本が抑えられていれば、誰でもリアルタイム・ストリーミングをデータ処理のプロセスに活用出来る事が確認出来ました。そこで今回はこのデータ処理を便利に行う為に、標準で提供されている幾つかのオペレーターに関する基本的な検証を行ってみたいと思います。

##まずはJOINから・・
JOINはデータベースを取り扱った経験をお持ちの方であれば、その概要や留意点についての基本的な情報は理解されていると思いますので、この場ではそれらの詳細についての解説は割愛させて頂き、Equalumではどう使うのか？について検証して行きます。
まずは、前回同様にEvent Stream形式のソース側を2個用意します。
![j1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/aca39ee9-6780-4baa-d089-615a2db797d3.jpeg)

![j2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/9cb01d7b-16e4-e125-8b05-886dc7ec5f4a.jpeg)

次にOperatorメニューからJOINを選択します。

![j3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/8529680e-ed04-7c6a-58df-26acc03f3062.jpeg)
![j4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/66f2a1d7-e9f5-0e8d-ef2c-4e94172ff56f.jpeg)

先ほど設置したEvent Streamを接続します。

![j5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/9bc2785c-ea63-8cce-5b20-2f7d58c4a093.jpeg)

JoinにあるEditボタンを選択して必要事項を設定します。

![j6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/08c49361-fd81-774f-a9cb-46d3c872d6e7.jpeg)
修正が必要な個所が赤字で指示されますので、適宜それらを修正して行きます。今回はidとtsが衝突していますので、この場所で編集作業を行います。編集は、各項目の右端にある編集アイコンを選択して行います。
![j7.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/c72cf52e-c599-612b-7bd4-81f2eeb64247.jpeg)
![j8.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/71dce8c0-2b64-a694-f7f0-40d3e7f4e057.jpeg)

JOINのタイプはプルダウンメニューで選択できます。今回はInnerで検証してみます。
次にConditionの項目にJOINの条件を設定します。今回はデータのIDで強制的に突合させてしまいます。

![j9.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/282b12e8-fe39-0bb7-8920-5155be8535dd.jpeg)

最後に、ストリーミング処理ならでは（？）の条件を忘れずに設定しておきます。

![j10.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/8cf5e0c2-cb42-62fa-f5f4-c0f2cb699813.jpeg)
Time Windowについては調整項目になる様ですが、今回の小規模環境では１を設定して検証しました。

次にターゲットのデータソースを定義します。

![j11.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/3d7238e5-b0cf-4457-f5d5-6eab9f5b651e.jpeg)

ここまでくれば、Joinとターゲットを接族してターゲット側のEditボタンを選択して、前回同様の設定を行って行けばOKです。テーブル定義もこの場所で自動的にSQL文を生成してくれますので、問題が無ければ確認してそのまま利用できますが、今回の検証では事前定義したテーブルに着地させる事にします。
![j12.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/b6a44651-3b9a-2851-cec9-2314ca1590ab.jpeg)

この状態で、前回の検証同様に上流側のデータソースにPythonで自動的にデータを連続挿入し（2つのテーブルにそれぞれ1秒間隔で）、その結果をストリーミング処理しながら下流側のデータソースのテーブルに反映させます。（シンプル＆力技でのJOINですので、出来上がりは美しくないかもしれませんが・・・そこは基本機能の検証という事でご容赦の程。。）
![j13.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/e5099353-bdb8-6f65-96b0-ec3dbd1c8685.jpeg)

まずは、下流側のターゲットソース上のテーブルを確認します。
![j14.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/ec3619f8-d308-933c-545c-93d28c89e509.jpeg)

上流側のテーブルを確認します。
![j15.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/a15e0275-d2ca-14d6-aace-f8ecc9a3a707.jpeg)


![j16.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/8b307993-8409-d15f-4c9d-8401da183ff6.jpeg)

データ数が少なかったので、上流側のテーブルに挿入が始まってから終わるまでの時間が一瞬で終了し、ほぼ同時に下流側のストリーミングJOIN処理も出来上がってしまいましたので呆気なく検証は終了です。


##たぶん一番使いそうなTransformを検証
次にTransformを検証してみます。
この検証では、シナリオとして消費税のカラムを現状のデータフローに対して「後付け」で設定して下流側のテーブルに反映させてみる事にします（その位の準備は事前に・・・という話もありますが・・・）
まずは、最上流のデータソースの準備をいつも通りに行い、OperatorからTransformを選択してFlowを接続します。
![T1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/996faf96-59d4-72b0-9aea-a058d7a33936.jpeg)
次に「＋」ボタンを選択し
![T2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/7a3befc8-e849-bcef-b09b-5fa588d7386c.jpeg)
取り扱うフィールドを追加します。
![T3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/c3f75b4a-0cdb-8cd2-a9e5-21d0c8f3c7ac.jpeg)
![T4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/c18f638b-3a7c-b04f-b3a0-d5a3b8c11c46.jpeg)
基本的にこの設定で新たなカラムが「この段階で設定される」事になります。
![T5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/284b4c00-0f13-0c31-93d7-a4b05b111b4a.jpeg)
カラムの順番は右側の上下ボタンで調整が可能です。
![T6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/e5464075-fd61-76fc-ec5a-6d11b9d6f825.jpeg)
![T7.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/1e2f2b09-f879-0c53-8c14-04ec3919e7ac.jpeg)
これで右下のOKボタンを選択し、ターゲットのデータソース（この場合もFlow設定すると上流側である今回のTransform情報をベースにプロトタイプを作成してくれますので、その情報を活用してテーブルを生成する事が可能です）を設定し、今まで同様に1秒毎にデータを自動生成して上流側に挿入すれば、そのアクションを自動検知して今回設定した手順の処理を行い、下流側のターゲットテーブルを即時生成していく形になります。
上流側に自動挿入されたデータはこんな感じになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/97a1d680-a539-d8c5-2e63-787af0bd4e54.png)

Tax項目を途中追加して生成された下流側のテーブルはこんな感じになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197589/5cc4e240-a0b7-5740-e110-49d018ce7f3e.png)

#今回のまとめ
駆け足になりましたが、今回はJOINとTRANSFORMの検証を行いました。
複雑なkafka系コーディングや、Spark連携等の作業を考える必要なく、かなり高度なリアルタイム・データストリーミングをデザイン出来る可能性は感じて頂けたかと思いますが、次回の検証では

###さらに複雑（？）な流れ

の作成に挑戦してみたいと思います。

###ゼロコーディングで高度なkafka/Spark連携のストリーミング環境を構築！

専用の最適化・専用実装を行ったDeepなkafkaの世界には負けるかもしれませんが、誰でもかなり早いkafkaストリーミングでのデータ連携・活用環境が作れる！という点においては、非常に可能性を秘めた環境であると言えるでしょう。

バッチ処理しか選択肢が無い時代は過去の話になりました。
今をデータ活用で変えるのであれば、その選択肢は必然的にリアルタイム・ストリーミングになると思います。
データで今を変えて未来を創る！！
これがDxにおけるデータ・ドリブンの真骨頂なのだと思います・・・

[**Equalumがやって来た！（前半完結編１）**](https://qiita.com/wadaken1961/items/03bb783e284e67275e84)に続く

#謝辞
本検証は、Equalum社の特別の許可を得て実施しています。この貴重な機会を設定して頂いたEqualum社に対して感謝の意を表すると共に、本内容とEqualum社の公式ホームページで公開されている内容等が異なる場合は、Equalum社の情報が優先する事をご了解ください。