データレイクソリューション
essentia
機能概要
2016.07.15開催
[ db tech showcase 2016 ]
Antuit株式会社
テクニカルソリューショングループ 中村 應 の講演から
essentia
（エッセンシア）アウトライン
―――――――――――――――――
ファイルベースのデータを高速に加工・集計 を得意とするツールです。
データベース以外にも下図のように多様な 形式のデータを、圧縮されたそのままでロー ド・加工することが可能です。特にタイムシ リーズデータ（ログ）の処理に長けていま す。
Linux上で動作するコマンドラインコマンドで構成
されており、Shell Scriptで処理を記述するだけ
のシンプルな構成です。
クラスターの起動、停止からデータロード、オンメモ リデータ処理まで全てコマンドライン。
標準関数でカバーできない加工や集計は、C言
語で記述可能です。
Public Cloud（AWS、Microsoft Azure）での
利用を推奨。
必要なときに即座に環境を構築し、処理が終 了すれば実行環境はターミネートされますので、
低コストで運用できます。特定のデータベースや 環境に囚われない、データ処理環境です。
次図はAWSでの利用イメージです。必要な時にインスタンスを立ち上げて処理を流し、終了したら実行環境はTerminateし
ビッグデータの統合やクレンジング・集計は、多様でかつ試行錯誤となる場合がほとんどのため、大量データをオンメモリで分散処理す る構造が必須です。
大規模データの分散処理をオンメモリで実現します。
データセットに対して一連の処理を行う際に、逐一HDDに書き出す方式よりも高速に処理できます。処理の記述はShell Script (bash)だけで行えます。
オンメモリの分散処理ではSparkが有名ですが…
環境の構築や処理の実装は、比較的essentiaの方が簡単です。
essentiaのオブジェクトには、table（データのプール）、vector（データの集計）があり、ソースデータをロードしながら加工・集
計します。
既存のRDBなどを置き換えるものではなく、データを読み込み・処理・出力するというシンプルな機能です。RDBやHadoop
その他にあるソースデータを、それらで処理ができない、または処理が難しい大量データ（非構造データやタイムシリーズデータ） の処理を高速に行います。
WEBアクセスログ、顧客行動履歴（カスタマージャーニーなど）、POSログ、広告ログ、
◆
大量データ処理の
I/O
コストは無視できない
大量データを加工する場合、まずファイルを配置場所から作業用スペースにコピーします。次にファイルは圧縮されていることが多いの で、解凍しデータを展開します。
ここでやっと本来のデータ処理に入りますが、殆どのケースで集計・加工処理は一度で完結せず、繰り返しが続きます。集計やクレ ンジングのステップが進むごとに、データストレージに書き込む、またそれを読み込む、処理してまた書き込むという繰り返しです。
Hadoopなどではこのような手順を踏んで、最終的にアウトプットを出力します。
例えば上図の処理では3回ディスクに負荷をかけています。特に1回目コピー、2回目解凍は大きな負荷になりますし、本来のデ
ータ処理に入る前にとても時間がかかります。パイロットシステムから本番データに移行する際に、トラブルになりやすいポイントでもあ ります。
essentiaの場合、まずファイルをある程度グルーピングします。次にファイルをどこかにコピーすることなく、圧縮されていても展開するこ
となくそのまま読み込みます。ストリーミングロードをしながら、必要な前処理（不要なデータ削除、フィルタリング、文字列加工な ど）をします。前処理をしたデータはそのままメモリにロードします。前処理の部分からクラスター分散して、データはメモリにロードし、 加工集計はメモリ上で繰り返し処理され、最後に結果をファイルやデータベースに出力します。原則としてディスクI/Oは、データソー
◆
スピード比較（RedShift）
対象データはバナー広告の配信ログ（どこのサイトにどのように配信されたか）です。圧縮状態で約1.55TB、展開すると9TB、 40000File,230億レコードの規模です。
集計処理は全部で4種類を実施、essentiaは100nodeのクラスター作成、RedShiftは8nodeになります。essentiaは4つの
集計を同時に実行できるので、ロード・集計・出力全ての処理を55分で終了しました。一方RedShiftは、各集計が1時間以
上、合計で6時間かかっています。しかしそれ以前に、データロードで24時間もかかりました。圧倒的な処理スピードの差が出てい
ます。
◆
利用例
実店舗とECの両方でビジネスをしており、TVCMも出しています企業の利用例をご紹介します。
ECサイトに訪問したお客様とTVCMから流入したお客様、店舗で購入したお客様、このうちの同一人物を抽出
する作業です。顧客IDで名寄せし、様々なログデータを収集し時系列順に組み合わせることで、複数のデバイスを持つCさんの
essentia
（エッセンシア）アーキテクチャ
―――――――――――――――――
essentiaに必要な環境やコマンドは、以下のようにシンプルな構成です。
◆
データロードの問題とは
一般的には大量データを処理する場合には、まず以下のようなロードの準備が必要です。 ・処理したい範囲を決める（期間やエリアなど）
・該当するファイルを作業領域にコピーする この段階でよく発生する問題ですが・・
① 同一日付のファイルが複数ある
例えばシステムログなどの場合、複数のサーバーがあれば同じ日付のファイルが存在します。これを作業領域にコピーしてフォルダ 構成などを構築することになります。
② ファイルが読み込みやすい形で配置されていない
階層がバラバラ、フォルダ別に分かれているが配置ルールが徹底していないなど探すのに手間がかかる。 ③ 圧縮形式やフォーマットが統一されていない
◆
カテゴライズ・ロード
ストレージ上のファイル群をあらかじめカテゴライズしてからロードする機能を装備しています。
ファイル名のパターン、パスのパターン、圧縮形式などからファイルのカテゴリを作成し、名前を付けます。 「カテゴリ名」＋「処理対象日付」を指定するだけで、目的のファイルを取り出すことができます。
Zipやtar形式では複数ファイルが含まれている場合も、目的のファイルだけを取り出すことが可能です。
◆
ロードしながら前処理
RDBに入っている美しいデータとは違い、ログなどのファイルベースのソースデータは、不要なレコードやフィールドがあったり、1つのフィー
ルドを複数に分割したり、複数のフィールドを連結する必要があることが往々にしてあります。これらの処理を、いちいちプログラム言 語で記述するのは非常に大変です。しかもソースデータが大きければ大きいほど、この処理には非常に時間がかかります。
これらの問題を解決するために、essentiaではロードしたデータのフィルタリングやマッピングを行うためのツール（aq_pp）を用意し、
前処理の負荷をできる限り小さくしています。場合によっては、前処理だけで必要なことが全てできてしまうこともあります。
aq_ppツールの主な処理
先頭行からの指定行数の読み飛ばし（ヘッダ行の読み飛ばしなど）
マスターデータとつきあわせて特定フィールドの変換（商品コードを商品名に変換するなど）
四則演算（同一レコード内で完結する計算は前処理で行える）
フィルター（特定条件のレコードのみに絞る）
指定ルールによるマッピング変換（フィールド中の特定ルールによる一部分の切り出し、正規表現の置換）
時刻変換（Unix Timeから日次フォーマットへ、またはその逆）
WEBアクセスログの処理に便利な機能
カテゴライズ・ロードのサンプルスクリプト
◆オンメモリデータ処理
処理単位としたいデータ中のフィールドを主キー（PrimaryKey）として設定します。例えばWEBアクセスログで言えば、トラッキング
クッキーなどですが、複数のフィールドの組み合わせで主キーとする場合は、前処理で連結します。データはその主キーのhash値で、
各ワーカーノードへ分散されます。主キーの発散度合いが小さいと、特定ノードにデータが集中して処理効率が落ちます。データセット は主キー毎に作られ、処理の単位も主キー毎に行われます。
essentiaのオンメモリ処理では、4つのオブジェクトを定義します。
1. database 同一主キーのtable、vectorをグルーピングし、グループ内のtable、vectorのデータを主キーでリンクさせる。 2. table インポートされた全てのデータを保持するためのオブジェクトで、1つの主キーに対して複数レコードのデータを保持する。 3. vector 集計用のオブジェクトで、1つの主キーに対して1レコードのみ保持する。インポートと同時に各種集計を行う。 4. variable 同一database内の各オブジェクト間で値のやりとりを行うための変数オブジェクトで、オブジェクト間での値のコピー
や、複数のオブジェクトにそれぞれ存在する値の計算などに利用する。
◆主キーの役割
主キーとは、処理対象のデータの格納単位であり、RDBのようにユニークである必要はありません。 1つの主キーが複数のレコードを持っていても問題はなく、udbdコマンドは、主キーを軸にして行われます。
主キー毎に日次でソートなど、処理自体はレコード単位で行われます。 ワーカーノードへのデータ分散は、主キーのハッシュ値によって行われます。
◆
データベースとは
同一の主キーを持つtable、vectorをグルーピングして、主キーで各オブジェクトのデータをリンクさせる機能です。同一のdatabaseに
所属するtable、vectoreは主キーを共有します。
◆
Vector
とは
Essentia最大の特徴となるオブジェクトです。主キーに対して1レコードのみ保持されるため、同一主キーに対して複数レコードの入
力があった場合は、各フィールドの集計設定に基づき置換、合算などの集計処理が行われます。インポートしながら各集計処理を 行う、高速処理のキモとなります。
主キーでgroup byして行う集計を、データをインポートしながら行うイメージになります。
各フィールド事態に、以下のような集計処理を定義することができます。 ・定義できる集計
+add：インポートされた数値データを加算する +first：最初にインポートされた値を保持する +last：最後にインポートされた値を保持する
+min：インポートされた数値のうち最小のものを保持する +max：インポートされた数値のうち最大のものを保持する
上記はVectorの動作例になります。
入力ログデータは、日付と訪問者とその人が何回ページを閲覧したかという内容です。Vectorオブジェクトで４つのカラムを作成し、
それぞれに定義を設定します。入力ログデータを、Vectorオブジェクトにインポートすると、集計しながらデータが読み込みまれます。
◆
レコード処理
Udbdコマンドの処理は、バケット（主キー）単位のループで行います。database単位で、主キー毎に複数table/vectorをスキャ
ンしてループをしながら加工・集計処理を行っていきます。
例えばCookieと会員IDの対応テーブルを見ながら、アクセスログの中に会員IDを埋め込む処理をみてみましょう。
Cookieを主キーにしてループしていきます、左側のデータをスキャンして順番に会員IDをVariableオブジェクトに格納します。次に右
側のアクセスログファイルうち、「AAA」のレコードを集めて、該当のカラムにVariableをコピーして会員IDを埋め込みます。このほかに
◆
レコード処理
ビッグデータ解析の最大の問題は、形式がバラバラの非構造化データや圧縮解凍処理です。従来はETLツールなどで対応できまし
たが、データ量と種類が爆発的に増大し、時間とコストがかかり過ぎる大きな問題になっており、ビッグデータ解析では 80％が前処
理にかかるとも言われています。
