2015年1月6日火曜日

移行データの正当性

新年、明けましておめでとうございます。

大須賀です
今年もよろしくお願いいたします。




私はオープンシステム全盛期からデータウェアハウス興隆の時期にかけて、お客様の基幹系のデータをUnixやWindowsに移行する業務を多くお手伝いしてきました。
その成果がWaha! Transformerという製品なのですが、データ移行にはRDBベースで開発をしている方々には想像できないような問題があります。

メインフレームは、いまよりもっとマシンが遅い時代から、1台で数百人のアクセスをこなしていました。必然的にデータベースシステムにかけられるCPUパワーは限定されており、RDBでは常識である参照整合性やテーブルジョインはRDBに実装されていても使えませんでした。
そのため、データ整合性はアプリケーションが保証していたのです。(「いるのです」と言った方が良いかもしれません。レガシーシステムではいまでも当時のアプリが稼働している例が多いです)

たとえば、あるカラムに投入されるべきコードが、マスタテーブルになければならない場合、RDBでは通常、Foreign Keyを使用すれば、コードカラムに、マスタに存在しないコードが入ると、レコードの挿入時にRDBが参照整合性エラーではじいてくれます。
このような構造のデータベースなら、異常データはそもそもデータベース内に存在しないことになります。

一方、レガシーシステムでは、アプリケーション内に、投入可能なコードをインコーディングすることで、適切なコード以外は書き込めなくしています。マスタを参照して投入可能なコードを獲得する場合もありますが、オンラインのレスポンス保証のためには省略する場合が多いのです。

そうなると、データの正当性はアプリケーションの信頼性次第と言うことになります。
アプリケーションに障害がなくても、長い運用のなかで仕様変更により設計書に記されていないコードや、もう使われていないシステム稼働当初のデータ、アプリケーションの障害で混入したデータ、はては開発時のデバッグ用コードが残っている場合もあります。

これがそのまま抽出され、移行チームに渡されます。

始末が悪いことに、こういった「ダーティーな」データは、データ移行時ではなく、データロード後にデータ検証するときに初めて見つかります。特にデータウェアハウスでその傾向が強いです。
データウェアハウスは確定された正確なデータが来ることが前提ですので、Foreign
Key等の参照整合性はあまり使われません。データが正確なら、検索や集計時には参照整合性チェックは必要ないからです。
そのため、データロード時ではなく、フロントエンドのBIツールのデバッグ時に発覚することになります。

データ移行をプログラムで実施する場合、データ量にもよりますが、ホスト側のCOBOLで抽出時に加工するか、サーバー側でやるならC言語等の高速な言語が使われることが多いでしょう。
データウェアハウスの構築にはC言語プログラマは必要ないですし、COBOLプログラマもいないので、移行作業のみ別のチームから人間を連れてきたり、基幹システム側に依頼したりします。
しかし、移行フェーズが終わって、いざデータの突き合わせを行うと、数字が合わない。データの調査を依頼すると、工程上、移行チームは既に解散済みで、直す人がいない。
BIツールでの検証は工程の最終フェーズですから、ここで手戻りが発生すると、高い確率で納期遅延を起こします。

データ移行にETLツールを使用するのは、単にロジックを高速に構築できると言うことではなく、このような手戻りに素早く対応できるという意味もあるのです。


このような経験から、データ移行は次のような点に留意して計画することをお勧めします。

  • データ移行は手戻りがある物として計画する。
  • ETLツール等を利用し、移行フェーズの工期短縮と手戻り時の工数削減をするか、または、移行チームを最後まで解放しない

0 件のコメント:

コメントを投稿