BIツールを使うにあたって、データの準備が必要です。
この記事は
- データマートの作り方
- データマートを作る時に検討すべき点
について解説します。
１つ目として、この記事はデータマートにデータを連携する６つの方法についてメリットとデメリットを解説しています。
データマートを作るにあたって、軽視されやすいところです。
データ連携は後でトラブルになる事が多いので、ぜひ読んでください。
部門用のデータベースです。
データウェアハウスより小規模で、目的を絞ったものをいう事が多いです。
データマート作成までの流れ
大きく考える点はこの３つです。
- データ連携方法
- データマート
- BIツール
最適な方法は
- どのようなBIツールを使うか？
- データの規模はどのぐらいか？
- 利用者と情報システム部のスキルはどのぐらいか？
などのバランスによって決まります。
そのため全員にとっての最適解はないです。
ですが、できる限りいろいろな種類の方法とメリット/デメリットをあげますので、参考にしてください。
データ連携方法について
データ連携の方法について、考えられる方法をリストアップしました。
この中から自社にあった方法を選びます。
| 番号 | 内容 | 連携頻度 | 価格 |
|---|---|---|---|
| 1 | ファイル連携 業務システムで連携ファイルを作成し、データマートがファイルを取り込む | 日に数回 | 低 |
| 2 | DB間で直接データを連携する DB LINK(リンクサーバ)を使い、データマートが直接業務システムからデータをとる | 日に数回 | 低 |
| 3 | DBのリストア 業務システムのバックアップをデータマートに戻す | 夜間や週末 | 低 |
| 4 | ETLツール（データ連携用のソフト）を使用する 連携作成処理やスケジュールなど一通り機能がそろっているツールです | 日に数回 | 高 |
| 5 | データレプリケーションのソフトを使う データをほぼリアルタイムでデータマートに連携します | リアルタイム | 非常に高 |
| 6 | ESBツールを利用する |
ファイル連携
最近はファイル連携は少なくなってきています。
デメリットはこちらです
- 作成する処理が多い。
ファイル作成 -> ファイル転送 -> ファイル取り込み
の３処理は作成が必要 - 処理時間がかかり、大容量のデータ転送には向かない
ファイル連携が使われるのは、業務システムが非常に堅牢な場合です。
- 業務システムのパフォーマンスを維持するため、システム外からの処理実行を禁止している
- セキュリティ上の理由から他システムが直接データ参照するのを許可しない。
といった理由です。
社内のシステム同士の連携であれば、避けられるのでしたらできる限りファイル連携はしない方がいいです。
作成工数とサポート工数がかかり、また処理時間がかかるのでメリットは少ないです。
DB間で直接データを連携する
この方法が一番おすすめです。
メリット
- 開発が簡単で、必要な技術スキルもDB技術だけで開発できる。
- パフォーマンスがいい。
連携処理の仕組みはこちらの３つです。
- 全件データを毎回連携
- データの更新日を使用して、更新のあったデータのみ連携
- マテリアライズViewを利用して、データ連携
80%ぐらいの確率で発生する王道の問題パターンです。
- 全件データで連携を作成
- 日次で夜間に１回など連携していたが、利用者の要望に応じて数時間ごとに連携するように変更
- 数年後に処理時間が増えて、連携処理時間が長くなりすぎて問題となる
- 多くの処理で使われているため、変更が困難となり対応が難しくなる
データの更新日を使用して、更新のあったデータのみ連携するように作成。
- データが変更されたのに更新日が変わっていない。
そのためデータ連携がされなかった - レコードの削除はないはずだったのに、削除が実施された。
そのためデータマートに削除データが残った。
こういった事故が発生して、全データの更新に変更。
そして「よくある失敗１」が発生する。
マテリアライズViewを使うのが開発上一番確実です。
マテリアライズViewですと、業務システムのデータ知識も必要なく、確実にデータの変更をとれます。
機械的に連携処理を作れるので、一番開発が行いやすいです。
デメリットは業務システムの変更が必要な点です。
マテリアライズViewはDBの更新時にログを作成します。
そのため業務システム上のパフォーマンスが落ちます。
問題はマテリアライズViewによってどのぐらい業務システムのパフォーマンスが落ちているかわからない事です。
夜間にデータ連携している場合は、日中の業務システムのパフォーマンスを落とさないために、全件データ連携の方がいいという事もあります。
DBのリストア
この方法は業務システムのバックアップを他のサーバに戻して、それをデータマートとして利用する事です。
似た方法として、本番機の災害用に備えているホットスタンバイのDBを使うという事も考えられます。
データマート用に設計したテーブルを作成しなければ、使える方法です。
デメリットは更新頻度を上げにくいので、一般的には１日１回か週単位でのデータ更新となります。
ETLツールを使用する
データ連携をする時に、ETLツールの話がよくでます。
ETLツールはかなり高い商品です。
開発者の立場としてはETLツールはあまりおすすめしません。
- ツールによって使い方が違うために、開発するまでの習得工数がかかる。
- 「DB間で直接データを連携する」で作成するプログラムより、プログラムが結果的に複雑になる。
- GUIで作成するツールが多いですが、直接プログラムを書いた方が簡単。
- データ連携のプログラムは単純なので、ツールを使うメリットが薄い。
ETLは高いツールなので、それでしたら技術力の高いエンジニアをアサインした方が効率がいいという理由です。
メリットはこちらです。
- Indexはデータ挿入前に外して処理後に作成すると早くなるなど、細かいところまでパフォーマンスをあげる機能はそろっている。
- スケジュール、処理時間、エラーの状態を確認できる機能がある。
データレプリケーションのソフトを使う
OracleですとGolden Gateなどの製品です。
信じられないほど高いです。
パフォーマンスがよくリアルタイム性があるので、仕組み的に一番よくできているのはこのデータレプリケーションです。
障害時にREDOログ(リアルタイムのバックアップのログみたいなもの)を利用して、データ連携するので、業務システムのパフォーマンスが落ちません。
業務システムが24時間高負荷で動いている時などは、候補として考える事もあると思います。
ESBツールを利用する
エンタープライズ・サービス・バスというものを利用してデータを連携する方法です。
敷居が高いのですでに導入済み以外の場合は候補にならないと思います。
業務システムにデータが登録されたら、それをサービス・バスに流し、データマートが拾ってデータ連携するというものです。
業務システムからの連携先システムが大量にある場合は検討する価値があるものです。
データ連携のまとめ
長くなってしまったので、データマートは次の記事で説明します。
データ連携の候補は下記となります
- ファイル連携
- DB間で直接データを連携する
- DBのリストア
- ETLツールを使用する
- データレプリケーションのソフトを使う
- ESBツールを利用する
データマートは中小規模のDBをターゲットにしている事が多いので、1,2,3が候補になります。
大規模データベースの場合、4,5,6の検討も考える事になります。
