データ仮想化
データ活用
皆様ご存じの通り、データ活用が企業の将来を左右する時代が到来していることは言うまでもありません。
しかし、活用対象のデータは、様々な形式で、様々な場所に分散して格納されているのが実情です。更には、クラウドへの資産移行などの動きに伴い、活用対象のデータがオンプレミスとクラウドのハイブリッド環境に分散している環境をよく目にします。
分散するデータの統合
このように分散するデータを一元的に統合して活用する際、統合データベースを構築し、物理的にデータを集約するアプローチが一般的です。特に、Snowflake などのサービスを活用して、クラウド上に統合データベースを構築している企業が多いように感じます。
統合データベースの構築には以下のような課題が伴います。
- 大容量のストレージを準備する必要があり、その運用コストが高止まりしがち
- データソースからデータを抽出し、ETL などでデータを加工し、最後にデータを書き込むまでのバッチ処理が、データ量や複雑さ次第では負荷の高い処理になり得る
- 太古の昔から続く、リアルタイムデータを参照したいという要望
データ仮想化
そこで登場するのがデータ仮想化です。
分散するデータに対して、仮想的に統合されたデータ層を介してアクセスすることができます。複数のデータソースに対して、統合ビューを介してアクセスすることをイメージすると分かりやすいかもしれません。
データ仮想化の特長
データ仮想化がもたらす一般的な特長は以下の通りです。
- リアルタイムデータ
データソースから直接データを取得するため、リアルタイムで更新がかかるデータを参照対象とすることができる - コスト削減
統合データベースにデータをコピーしないため、データを二重持ちする必要がなく、結果としてコストの削減につながり得る - アジリティー
データ加工や物理コピーにかかる負担が軽減されるため、データスキーマの修正が比較的容易になり、アジリティー開発に適する
環境構築
Denodo
データ仮想化の市場でシェアの高い Denodo を使って、実際に環境を構築し、機能性を確認してみたいと思います。
非常に機能性に長けたアプリケーションなので、すべての機能を盛り込むことは当然不可能です。そのため、Yellowfin でデータ分析するためのスキーマを構築するために必要な機能を中心に試してみようと思います。
なお、本項の内容では、必要なビューを作成するまでの大まかな手順が把握できることを目的とし、詳細な設定手順は省略します。
本記事で扱う内容をもう少し詳細に知りたい方は、以下のチュートリアルを実施することをお勧めします。
処理全容
全体的な流れのイメージは以下の通りです。
3 種類のデータソースから取得したデータを結合、集約して、店舗ごとで月次のデータにまとめた予実比較のビューを作成します。
データソース
データ形式や格納先、粒度などが異なるデータを準備しました。
これらを統合して、店舗単位に月次で予実管理ができるビューを作成します。
| 種類 | データソース | 備考 |
|---|---|---|
| 売上明細 | PostgreSQL | オーダー単位の受注状況のデータ (約 30 万行) |
| 店舗マスター | PostgreSQL | 売上明細と連結させる情報 |
| 予算 | Excel ファイル | 月次の店舗単位の予算データ |
| 住所録 | MongoDB | 店舗の住所データ |
データソース接続とベースビュー
まずはデータソースに接続し、そこからベースビューを作成します。ベースビューとは、元のスキーマがそのまま反映されたビューです。全体の流れの中では、下記の赤枠で記されている部分が該当します。
今回は PostgreSQL、MongoDB、Excel がデータソースとなるため、それぞれに対する接続を定義します。
-
PostgreSQL
-
MongoDB
-
Excel
接続が確認出来たらベースビューを作成します。
-
PostgreSQL
-
MongoDB
-
Excel
売上明細を月次に集約
次に、日次のオーダーを管理する売上明細と店舗マスターを JOINします。その後、予算と粒度を合わせるために、JOIN したビューを月次に集約します。
全体の流れでいうと、下記の赤枠内の処理が該当します。
JOIN する列を選択します。
続いて、Group by で集約する列を選択します。店舗単位の月次で集約するため、year、month、store_cd を選択します。
結果をビューで確認すると、売上明細が店舗単位の月次の売上結果に集約されました。
SQL 文で記述する内容を GUI から操作する感じです。
予実比較
売上の集約の粒度が合ったところで、予算と売り上げ実績を JOIN し、予算達成率を計算した新たな列を追加します（下記赤枠内）。
予算と実績を JOIN します。店舗単位で月次の予算が決められているため、year, month, store_cd を条件に指定します。
続いて、予算達成率を計算します。
結果、以下のビューが作成されました。
住所録
最後に、住所録を JOIN します（下記赤枠内）。
住所録を JOIN し、最終的なビューが完成しました。
キャッシュ
ここまでの手順で作成したものはビューなので、Denodo にはデータの実態は存在しません。ただ、キャッシュの機能を使って、Denodo にデータを持ってくることが可能です。
最終的に作成したビューで、キャッシュがパフォーマンスに及ぼす影響を測定してみようと思います。
-
キャッシュしない場合
ここまでの手順で示した処理を一通りキャッシュなしで実施した場合、195 ms を要しました。
-
キャッシュする場合
最終的なビューをキャッシュした場合、28 ms となり、処理時間が約 7 倍異なります。
Yellowfin のような BI ツールとの連携では、リアルタイム性よりもデータの整合性やパフォーマンスが重視のされるため、分析対象のデータはキャッシュすることが現実的と思われます。
カタログ
準備したビューは、カタログ化して利用者に公開することができます。
カテゴリやタグを使って、用途を明確にしておくことで、管理部門の工数削減にもつながり得ます。
タグやカテゴリを使って、用途が分かり易いように整備しておくことが重要です。
業務部門のユーザーにも使い易くするためには、ファクトとマスタを区分しないで、大福帳の形で準備しておくなどの考慮も必要かと思います。
Yellowfin からのアクセス
Denodo で作成したビューに Yellowfin から接続してみます。
JDBC ドライバー
Yellowfin から Denodo には JDBCで接続します。そのために必要なドライバーは下記から入手可能です。
プラグイン追加
denodo-vdp-jdbcdriver-9.3.0.jar を入手したら、Yellowfin のプラグイン管理からプラグインの追加を行います。
データ接続
プラグインを登録できたら、データ接続を作成します。
| 項目 | 設定内容 |
|---|---|
| 接続方法 | 一般 JDBC |
| 認証アダプター | 標準認証 |
| 名前 | denodo |
| JDBC ドライバー | com.denodo.vdb.jdbcdriver(denodo) |
| 接続文字 | jdbc:vdb://localhost:9999/ |
| ユーザー名 | admin |
| パスワード | admin |
以上の設定で、Yellowfin から JDBC を介して Denodo のビューへアクセスできるようになりました。
Yellofin コンテンツの作成
あとは、Yellowfin側で、ビュー、レポート、ダッシュボードを作成します。
課題
冒頭で述べた通り、リアルタイムデータの扱い、アジリティー開発との相性の良さ、コスト削減など、データ仮想化がもたらす利点は多くあります。
一方で、いくつか課題もあるように感じています。特に自分が重要だと思う課題を以下に列挙します。
リアルタイム性
仮想データベースの利点の一つに、リアルタイム性が挙げられます。しかし、実際にオンラインでトランザクションが走るデータベースからデータを取得することは、現実的ではありません。あるいは、レポートや分析にはある程度まとまったデータを用いることが一般的で、リアルタイム性が求められる場面は限られます。
データ形式の不一致
今回の手順の中では、PostgreSQL、MongoDB、Excel に分散したデータ間で、共通した店舗コード (store_cd) で連結できることを前提としています。しかし、現実世界では、仕組みが異なれば、コード体系が異なることは当然です。体系の異なるコードの取り扱いに関しては、別途対応が必要なことに変わりはありません。
データ加工
物理的な統合データベースを構築する場合、ETL などでデータをバッチ加工することが一般的です。ビジュアル的にデータの流れを追うことができる ETL と比較すると、データベース言語で処理する仮想データソリューションの操作性やメンテナンス性は劣る部分があります。
On-the-fly
On-the-fly による処理は、クエリ実行時にデータ変換やデータクレンジングを行います。そのため、複雑な処理や、複数のデータソースにまたがる処理を実行する場合など、特にパフォーマンスのオーバーヘッドが大きくなりがちです。
総括
統合データベース構築とデータ仮想化にはそれぞれの利点があり、適材適所で使い分けられるべきであると感じました。
何より、これまで、データ分析には DWH の構築が必須と考えていましたが、代替となる手段が存在することを知れたことが大きかったです。
では皆様、良いデータ分析を！乾杯！！