#突然ですが！今回は**「Equalum」**なるモノを弄ります。
これまで数回に亘って、”MemSQLとその周辺”に関して簡単な検証作業の状況を共有させて頂きましたが、今回は唐突に！極めて自己都合による検証作業を行う必要が発生し、その結果を皆さんと共有させて頂く事にします。
今までの作業は、基本的に高いMySQLとのSQL互換性と、ネイティブな「インメモリ」、また従来型のSQLデータベースでは、定期的な頭の痛い作業であった、初期サイジングを超えた場合や、一定期間を過ぎた際のデータ移行や性能強化への対応に対して**「スケール」可能といった部分で、昨今のBI、ML、AIといった「データマイニング系用途」に対して、非常に高く且つ持続発展可能な投資対効果が期待できる、Dx時代の新しい・・しかし従来型の経験や資源が活用可能なデータソースとしてMemSQL**の可能性を、各種の検証作業を通じて共有させて頂きました。
###最終アプリケーションへの高速＆柔軟対応が出来る事は判った・・・
MemSQLの柔軟性（今までのMySQL経験が活用出来たり、その周辺の構築してきた環境が「殆どそのまま転用可能」）や、ネイティブなインメモリ技術をフルに活かした高性能処理（I/O,SQLトランザクション）については、導入後シンプルに利用出来る事はご理解頂けたかと思います。また多くの方が、BIの性能問題やDWHの構築までは無理としても、出来るだけ時世に適合出来る速度・柔軟性で、データマイニングを活用したい！と考えられているかと思います（もちろん、IoTやソーシャルｘｘ、また今後発展が期待されている５G社会での新たな可能性への挑戦など・・・）
####でも！But！しかし・・・・####
流石のMemSQLもデータが流れてこなければ、単なる初期導入費用と維持管理や電気代等の金喰い虫になってしまう事は自明の理だと言えるでしょう。データを大量に且つ高速に処理するにはどうすれば良いか？従来型のアプローチで保守本流・王道のDWH構築をスクラッチから行うか？？・・・しかし、間違いなくデータを必要としている現場からのニーズは、
（１）スピード
（２）効率
（３）柔軟性
を全部実現してくれ！という状況になっているのではないかと思います。
出来上がった時には、市場も競合も自社も前提条件が変わってしまって・・・・では、Dxの重要アイテムであるデータドリブンを云々言っている場合では・・・そもそも無い！という状況になってしまいます。
###速さを活かす為の速さ###
速くSQL処理が出来るのであれば、その価値を最大化させる為には「必要なデータを」「必要なタイミングで」「出来るだけ高速・高効率で」収集・展開・処理しなければなりません。
####では、どうやってデータを流し込むか・・・####
MemSQLの検証を行っている際にkafka等のメッセージブローカーや、ネットワーク上に共有されているディレクトリ等を経由した、「パイプライン機能」を紹介させて頂いたかと思います。既存の幾つかのクラウドストレージ系や、前述のファイルシステムを介したデータ収集であれば、比較的簡単に活用モードに入る事は可能かと思いますが、現実的に考えた場合に**「何処にデータが存在しているか？？」**という大きな、しかし極めて現実的な問題に直面する事になります。もちろん、全く新規の仕組みをスクラッチから構築するのであれば、全ての構成要素に対してかなりの自由度が効きますが、何年もかけて運用ベースに至るまで作り上げてきた既存の仕組みを弄る・・・これは、正直かなり勇気が必要なチャレンジになるかと思いますし、この辺の現状が「あと一歩の所で、データドリブンを諦めるか・・Dxに踏み切れない理由」なのではないかと考えています。データを活かして、より良いデータ（結果）を創る・・・これが、データドリブンの基本だと思いますので、今回から数回に分けて、その辺の壁を突き崩せるかもしれない、新しい可能性について検証を進めて行く事にします。
#そこで、満を持してEqualumの登場・・・
Equalum社については、同社のホームページを一読して頂ければと思いますが、現在シリコンバレーに活動拠点を持ち、実際に多くの企業に採用が決まってきている、新進気鋭のベンチャー企業になります。日本国内の展開も開始され、StrategyCore社が国内市場開発を始めており、日本語での対応が必要であれば同社の問い合わせ窓口へメールを送って頂ければ幸いです。
###製品の特長###
Equalumの特徴は、大きく分けて以下の３つになります。
（１）複雑な処理をシンプルに
（２）必要なデータを必要な場所に必要な形で
（３）高速な処理と柔軟な展開
一般的には、この類の仕組みをスクラッチ状況から構築する場合、各種のOSSを熟知したうえで「適材適所」且つ「適宜適量」を自前で導入・構築して行かなければなりません。もちろん最近では、それぞれのOSS自体の進化や情報共有の拡大等により、以前に比べれば圧倒的に使いこなせる状況にはなってきましたが、それでも「それらを複数組み合わせて、それぞれの繋ぎ込みを最適化する・・等」は、それなりの覚悟と経験が必要な事も事実でしょう。
Equalumは「データ・インジェクション」を如何にシンプルに実現するか？そしてその処理に要求される機能（複雑化の要因）を同時に如何にシンプルに提供するか？に注力した製品になっています。従来型の同種の仕組みに見られるような、既存の各段階を順番に進めていって「半年～１年後に稼働」という事ではなく、**「導入後１-２週間で稼働（或いはそれ以下）」**が誰でも実現出来るように設計・開発が進められている点が大きな特徴になります。
現在の企業・団体におけるデータのサイロ化問題は、ある部分でデータドリブンによるDxを減速させる大きな要因になっています。多くの従来型データシステムは、基本的に期間を単位として（その理由の多くは、データサイズの制限や維持管理、特に拡張作業時のコスト・リスク問題によるかと思います）、一旦記録されると基本的には電子帳簿として機能しますので、検索・修正が殆どの機能であり、抽出とかテーブル再構築といった、まさにデータドリブンな用途は、そもそも想定外（それよりも安心・安全を重視）の部分が大きかったと思います。
良く、日本のエンタープライズにビッグデータが存在しているのか？という話を聞きますが、たぶん磁気テープまでを含めればその総量は十分ビッグデータなのだと思います。もちろん、最初から不特定多数でスケール必須のデータシステムとして想定される、ネット系の仕組みに関しては、そもそも従来型のサイジングが難しいという事もありますので、ここ数年で急速に進化してきている クラウド技術の展開として、ビッグデータ技術を前提とした実装が普通になっいる領域も多くなってきていますが、基本的に電子帳簿型（OAの黎明期からの基本コンセプト）の仕組みとしての、既存型データソースを如何に低リスクで活用出来るか？！が重要なポイントになってきているのも事実でしょう。
複雑でかつ広域に分散するデータをかき集めて、必要な処理を並行して行いながら、ストリーミングで最終的な活用テーブルに収める・・この一連の処理に必要な条件として、これらの処理を高速に行いながら同時に高い処理効率を維持出来るようにしなければなりません。大量のデータを処理する技術としては、ビッグデータ等の技術を転用すれば難易度は別にして実現する事は可能だと思いますが、その為に幾つかの異なる技術を、効率的かつ効果的に組み合わせる作業・・・これは、ある部分で機能（柔軟性）と性能の両立を難しくしている部分でもあります。Equalumの場合は、この難題について独自の技術を組み合わせる事により従来では出来ないか非常に困難であった、ストリーミングでデータを処理出来る機能も提供しています（複雑なプログラミング無しで...）。
#検証環境の構築について
現在、Equalum社ではホームページ等を通じた期間限定の仕様ライセンスの提供を公式に行っていません。基本的には実ビジネスを前提とした本格的なPoCを商談ベースで実施していく形になっていますので、以下の情報はあくまでも参考という事でご理解頂ければと思います。
（今回は、日本語データの動作検証も兼ねて特別に試用を許可して頂きました）
稼働するOS Linux CentOS7 64Bit（RHELの等価版でも対応可能）
インストール形式 ネットワーク・インストール（オフラインで持ち込む形式も応相談で可能）
構成H/W ３台のクラスター構成を推奨（最低１台から可能、但し機能評価レベルまで）
推奨：メモリ容量 64GB（デモ等であれば16GBから動作可能）
推奨：コア数 16 （デモ等であれば4-8コア程度から動作可能）
今回の検証環境は、32GBのメモリを搭載したCore i7(4コア：8スレッド）のデスクトップ機で実施しました。
基本的にEqualumのコンソールはWeb経由になりますので、サーバのIPアドレスとポート番号を入力して、ID/パスワードを設定すればOKです。
既に複数（評価版を使わせて頂き、接続確認を行いました）のデータソースと、幾つかのFlow処理手続き、また最終的にデータを受け取るターゲットの設定が行われていますが、正常に立ち上がるとこの様なコンソールが出てきます。
#全体の流れについて
まず初めに最上流側のデータソースの設定を行います。バッチ処理系であれば通常のJDBC接続と殆ど同じ設定で手続きは完了しますが、今回の検証における大本命のストリーミング処理については、幾つかの事前の設定が必用になりますので（今回はMySQLでの検証を行います）その詳細については、この後に背景等を含めて説明させて頂きます。
次にターゲットの設定を行います。標準でEqualumではHDFSベースのストアを用意していますが、今回はいつものMemSQLを使ってみることにします。導入にこちらも基本的には一般のデータベース情報の設定になりますので、正式なPoC等で作業される際も特に問題になる事は無いかと思います。
では取り急ぎ此処までの作業を行ってみます。
###データソースの設定
**[SOURCE]の右上にある[＋ADD]**ボタンを選択します。
今回検証した環境では、これらのデータソースを上流側に設定する事が出来る仕様になっていました。現在も継続的に開発は進行していますので、今後更に各種のデータソースから必要なデータを必要なタイミングで必要な処理を行って取り扱う事ができるようになると思います。
今回は、ストリーミング処理の検証を行いますので、この機能（実際にはデータソース側にこの機能を実現できる仕組みが必要ですので、全てのデータソースで可能という訳ではありません）をサポートしているMySQLを接続してみたいと思います。
（１）まず全体の名称としてSource Nameを指定します（ここではMySQL_Streaming）
（２）接続するデータソースが稼働しているホスト情報を設定します（ポート番号含め）
（３）データベースにDDLでアクセス可能なアカウントのユーザ名（今回は無条件で禁断のrootを指定しています）
（４）同様にパスワードも設定します。
基本的に
に関しては一番上のメニューでOKです（その他の詳細は別途共有させて頂きます）
（５）タイムゾーンを適宜選択します。
（６）[Capture Type]をバイナリ・ログにします（この前準備がMySQL側に必要になります）
（７）モニタリング間隔はとりあえず初期値で作業を行います（この数値は全体バランスを見て適切に設定します）
ここまできたら、下部左側にある**[TEST CONNECTION]を押してみます。設定に問題がなければコンソール上部に緑のメッセージが出ますので、[CREATE]**ボタンを選択して正式にソースを登録します。
###ターゲットの設定
**[TARGET]の右上にある[＋ADD]**ボタンを選択します。
今回検証した環境では、これらのソースから適宜ターゲットを選択する事が可能でした。もちろんこちら側の開発も順次進行していますので、今後さらにその選択肢は増えていくと思います。本検証では以前より別途検証を進めているMemSQLを受け皿側に使う事にします。
若干インターフェースは異なりますが、先ほどの上流側データソースの設定とほぼ同じ手順で作業を行えばOKです。（Database項目のみ、登録ユーザID/パスワードでDDLが効くデータベースを事前に作成して設定する必要が有ります）
基本的な事前の処理はこれで終了です。
###因みに・・・
前回までのMemSQL検証をお読みの方であれば、「あれっ？MemSQLのアカウントにパスワード・・・」という疑問が有るかと思います。そこで今回の検証では力技（といっても、基本的なデータベースのユーザ作成ですが。。。）で以下のコマンドをMemSQLで動かして検証用のアカウントを作成しました。
CREATE USER 'eqtest'@'%' IDENTIFIED BY 'eqpassword';
GRANT ALL PRIVILEGES ON *.* TO 'eqtest'@'%' IDENTIFIED BY 'eqpassword' WITH GRANT OPTION;
#ストリーミング処理の設定・・・
従来型の同種（・・と一般的に分類される）のソリューションと同じ様に、バッチ処理的な機能はより洗練された形で実装されていますので、その部分ではEqualum社が提唱する「ゼロコーディング」での環境構築を十二分に活用して頂く事は可能だと思います。ですので、今回の検証は「今起きている状況（データ）が上流側にどんどん展開される状況で、その状況を「ほぼリアルタイム」にターゲット側に向けて処理をしながらどんどんストリーミングして行く機能を動かして行きます。
一般的にこの類の処理・・・となると、基本的なイメージとしてはZookeeper,kafka,Sparkを上手く組み合わせて環境構築して、アプリ層側をJavaで作り込んでトピック、プロデューサ、コンシューマ・・・という苦行を容易に想像出来ると思いますが、Equalumはその辺のややこしい部分を上手に丸く収めて、必要な指示のみをGUIで要求してくる形になっています。
（１）Equalumにログインします。
（１）まずはデータソースにアクセスして必要事項を設定します。**[Streams]の右側にある[＋ADD]**ボタンを選択します。
（２）必要事項を埋めます。（**[Schema]と[Table]**項目の右上にあるアイコンをクリックすると、最新のデータソース状況が反映されます）
**[＋ADD TOPIC]**を選択します。
**[Event Stream Name]を適宜設定してく右下の[OK]**をクリックします。
右下にある**[CREATE]**ボタンをクリックして正常に登録されれば、とりあえず第1段階の設定はこれで完了です。
この辺の処理を、素の環境構成を行って個別に作り込んで行くと仮定した場合、それぞれの構成要素を熟知した上での作業が必要になりますし、立ち上げた後に追加や変更が発生した場合を考えると、そもそも手を付けない！という判断に致る可能性も有るかもしれません。Equalumはその辺を上手に隠蔽し、必要事項（より高度な設定選択も可能：[Advanced Settings]）の選択・設定のみで高度なストリーミング処理を活用する事が出来るように作られています。
#今回のまとめ
後は、上流側のデータソースとターゲット側のソースを選択し、その相互間の関係をマウスクリックと必要項目の設定でFlowの定義を行い、環境全体の稼働状況を確認して上流側の指定されたテーブルにデータを流し込んで行けば、此処までの設定に従って自動的にストリーミング処理が行われます。この部分は専用のGUIベースデザインツールが有りますので、次回の実践編で基本的な使い方を共有出来ればと考えています。
また、次回の実践編でのストリーミング検証では、Pythonを使って簡単た日本語データ捏造（？）ツールを作成し、そのツールで生成されたデータを上流側データベースに連続して挿入処理を行って、その更新情報を起点に下流側のターゲットソースへ自動処理される事を確認し、次回以降のタイミングで最終的には簡単な変換処理を幾つか試してみようと思います。
#謝辞
本検証は、Equalum社の特別の許可を得て実施しています。この貴重な機会を設定して頂いたEqualum社に対して感謝の意を表すると共に、本内容とEqualum社の公式ホームページで公開されている内容等が異なる場合は、Equalum社の情報が優先する事をご了解ください。