唐突ですが、今回はリアルタイム・ストリーミングで流れ作業の匿名化処理を検証してみます！
お陰様で個人的に幾つかEqualumに関する質問等を頂けるようになり、その中でデータの一部のカラム情報に関して、全自動で匿名化処理（アスタリスク列等に置き換える）は出来る？？・・・という内容がありました。
今回の検証では、極めてシンプルで単純な方法ですが、リアルタイムで連続挿入されてくるデータの「特定のカラム情報を全て自動的に」アスタリスク10個の文字列に置き換える作業を行ってみたいと思います。
イメージとしては、Equalumのエージェントが遠隔で稼働中のデータソースに加えられた操作を検出し、CDC＋kafka/Spark連携を駆使したリアルタイム・ストリーミング処理でそのメッセージをターゲット側に伝える際に、そのメッセージの一部（今回の匿名処理対象）を自動的に特定の情報（10個のアスタリスク）に置き換えて送る・・という感じになります。
ポイントは、纏めてドン！のバッチ系で処理をするのではなく、オリジナルに対象データが挿入されたタイミングで高速変換を自動的に実施し、ターゲット側のデータベースにリアルタイムで反映させる・・・という作業を、Equalum得意のプログラム無しで実現してみるという点になるかと思います。
では、一気に匿名化処理の検証を実施します！！
最初の作業は、今まで実施してきた検証と同じく上流側のデータソースに対して、ストリーミング処理を定義する事から始めます。ここでEqualum内部でのkafka/Spark処理連結が「プログラム無し」で行われ、以降の各種データ処理に対してCDCを最大活用したリアルタイム・ストリーミング処理を提供する事が出来るようになります。kafkaとの連携を実施する為に、ユニークな名称を設定するだけでOKです。
まず始めに、データが挿入される上流側のデータソースを設定します。先ほどの手続きで準備済みのデータソース（トピック）を選択します。
次に編集メニューからトランスフォームを選択します。
匿名化の設定は非常に簡単で、上流側のデータベースに入ってきたデータの「特定のカラム」を全てアスタリスク10個で置き換えるようにトランスフォームを設定するだけです。今回の検証では、識別しやすいように変換後のカラム名に対して「AN_」を頭に付ける事にしました。またその際の処理はシンプルにダブルクォーテーションで囲ったアスタリスク列でOKです。
今回の匿名化作業に必要な置き換え用のカラム情報の設定が完了しました。（表の下側に纏めておきました）
メニューからターゲット側のデータソースを選択して、着地側の必要情報を設定します。
以前の検証で行った様に、最終のターゲットテーブルに対する必要な設定を行います。今回の匿名化検証では最後の「マッピング」設定が肝になりますので、以下はその部分にフォーカスして手順を紹介します。
最後にターゲット側のテーブルに対する、流し込み対象のカラム情報のマッピングを行います。１：１の様なケースでは、何も確認せずにそのまま「OK」ボタンを選択すれば良いのですが、今回の匿名化処理では事前に定義した幾つかの項目に対しての、最終テーブル上の各カラムに向けたマッピング変更を行わなければなりません。
まずは、カード番号の情報を先ほど設定したカラムに置き換えます。
全てのマッピングを適切に匿名化側の情報に向けて設定変更します。この辻褄が合えばEqualum的にはリアルタイム・ストリーミング処理で匿名化を実行しながら、最終段に設定されているターゲットのデータベース上の所定のテーブルに、リアルタイムで順次着地させていきます。このマッピング作業は、Equalumを活用するうえで重要なチェック項目になりますので、他のケースも含めて確実に実施する必要があります。
今回設定したEqualumのFLOWはこのような感じになります。（間に匿名化の為のTransformを1段挟んだだけの、非常に簡潔明瞭な形です）
今回検証に使用したスクリプトが、上流側のMySQLに挿入した結果がこちら側になります。形式的には今までの検証で使用している内容になりますので、個人情報（実際はFakerが作りだしている内容になりますが・・・）がそのまま各カラムに入ってきています。
こちらがEqualumでストリーミング処理を行いながら匿名化を実施した結果になります。綺麗にアスタリスクに置き換わっている事が確認できます。
Equalumのリアルタイム・ストリーミング処理により、ターゲットデータベース上のテーブルは自動的に必要情報がアスタリスク列に置き換わり、実質的に上流部のオリジナル情報（こちら側はエビデンス側として保全対象）の処理とほぼ同時に、下流側のターゲットデータベース上に対して、必要な情報項目の匿名化が実施済みの形で処理されるようになります。
今回のまとめ
昨今の情報利活用や広域情報共有等の際には、この種の情報匿名化作業が必要になるケースが出てくると思います。Equalumを活用する事で、データを流しながら必要処理を完了させて、ターゲット側に着地させたと同時に利活用や、その後に必要な処理（この場合は複数のテーブル（サイロ化されたデータベースから引き抜かれてくる情報）を跨いだケースが多くなるので、その処理の高速化の為に「インメモリ＆スケールアウト型のデータベース」を使う事が増えてきています。これは、Equalumで高速化しても、その後の処理が遅いと投資対効果が極端に悪化するとか、IoT系の仕組みが既存系のデータ待ち状態になって、同じ様に投資対効果を下げる事を避ける意味での採用事例になります。
利活用系のターゲットデータは、今後の活用形態や規模の変化が読みにくいケースが多いので、前述のスケールアウトが可能な物や、クラウド提供されるサービスを活用するケースが増えてくると思います。
既存の現業系データシステムに無用のトランザクション・ロードを追加せずに、Equalumとその着地側のデータソースの柔軟な組み合わせで、「同じ時間帯」で、「同じデータ」に対して「創造的なアプローチを気兼ねなく行える」環境を構築できるのが、Equalumの強みの一つなのではないかと感じました。
謝辞
本検証は、Equalum社の特別の許可を得て実施しています。この貴重な機会を設定して頂いたEqualum社に対して感謝の意を表すると共に、本内容とEqualum社の公式ホームページで公開されている内容等が異なる場合は、Equalum社の情報が優先する事をご了解ください。