分散処理時代の業務TXデータモデルについて

分散処理のでTXデータモデルについてちょっと思ったのでまとめておく。

基本的にクラウド系の分散システムでのTX系の業務データの扱いとしては、
大別して２種類の考え方があると感じている。
データストアの構造から言うと、
RDBMSとKVSの対比「のようなモノ」になることもおおいが
（個人的には正確な言い方ではないと思っている）
一般に構造化データと半構造化データといわれるものに近い。

まず話の前提として、
あくまで対象をTXデータに限定しているということを考慮しておきましょう。
（いわゆるマスターデータ系は基本的に構造化データが基本であり、
物理的にはともかく論理的には構造化されていなければ
メンテナンスはできない。まぁこれも議論はありますが・・・
とりあえずスコープ外で良いぐらい勝負はついてはいると思います）

その上で、ここでは今風の半構造化データという言い方
とはちょっと距離をとって、
むしろ従来の汎用機でのバッチの処理の
ファイルシステムの延長線上で
「クラウド時代のTXデータモデル」を捉えて見ます。
要は、このデータ構造が分散処理では
実は親和性が高いということを述べたい。

余談だけど、旧来の汎用機でのファイルシステムでの
データモデルがKVS上にうまくマッピングできることも次いでに指摘したい。
これは出自を考えれば親和性が高いのは当たり前で、
現行のKVS系がWeblogの収集を目的に作られたデータモデルであることと、
旧来の汎用機の入力フォーマットは
そもそも業務データのログデータであったことを考えれば、
論理的には整合性は理解しやすい。
（混乱しないようにお願いしたいのは、あくまでTXデータだけですよ。）

逆説的に言うと、汎用機のTXファイル構造の問題点も、
そのままKVSでは浮き彫りになるとも言える。

さらに後述するが、これはHadoopでも同じことがいえる。
HadoopIOでのデータモデルは通常は、
構造化されたデータモデルとそうではないモデルが使い分けられる。
（一般にPairs and Stripesといわれるデザインパターンに近い。）
ここでも同じ様相が観察できている。

まず構造化データとそうでないデータを例示しましょう。

・構造的なデータを持つ場合

class Summary{
 TxMaster_ID id;（割と有意キーがおおい）
 Summary sum;
 List<Data> data;
	class Data{
	 SID atmic_id;　（大抵は無為キー。これがユニークキー）
	 Obj member_1;
	 Obj member_2;
}
}

まぁ割と典型的な例ですね。
ネストはもっと深いこともおおい。
情報の冗長性を排した形での構造データになります。

データの冗長性が低いため、一覧性も高く、
更新処理やデータ自体のメンテナビリテリィは高い。
加えて、転送量は確実に減ります。
クラウドではかなり重要なポイントになります。

さらにデータ操作自体に関して言えば、構造処理が入るため、
比較的面倒なプログラムを書く必要があります。
キーの扱いについても、ユニークキーの取得が
ストレートにできないので、なんらかの工夫が普通はされます。

・・・なので、気持ちはわかりますが
まぁ複雑なJSONを書くと心が折れると同じです。
どちらかというと、モデルとしては
まずはファーストチョイスにはなりません。

分散処理から考慮すると、
「一定の上位構造で塊をつくって、その単位で処理を分散させる」
というスタイルになります。
HadoopでいうところのStripesパターンにあたりますが、
相当複雑なデータ構成を渡せるのと、なにより
データの冗長性を完全に排することができるため
パフォーマンスを優先する場合は選択の余地がなく、
この一択になります。
分散処理ではデータをネットワークでやりとりすることは
避けられないので、
オーバーヘッドを減らすには必要な手段になります。

ただし、ある程度の塊でないとデータの意味が
なくなるため、当然メモリー制約が発生し、
なんらかの対策を講じる必要があります。
加えて、キーの扱いはなんらかのセカンダリーソートの
実行が前提になるため、実行環境に依存して、
キー操作の実装を準備する必要が発生します。

一方、
・半構造的なデータで処理をする場合

class Data{
	SID atmic_id;　ユニーク・キー
	TxMasterID id;
 	Summary sum;
	Obj member_1;
	Obj member_2;
}

データ構造がフラットになるケース。
また、データが冗長的になるので、結合処理も必要ない。
必要なデータはフィールドを追加していくだけである。
フィールドが100以上なんてのはざらで
やたらめったら増えているものもある。
ただし、どのデータがどのデータに関するものなのか、
という情報が欠如するため、意味管理が面倒なのと
冗長性故に転送量が増えるということも起きる。

例でいえば、TxMasterIDは、
このDataインスタンスに対応するものではなく、
またSummaryフィールドの値は、
TxMasterIDが同一であるDataインスタンスに対しては、
常に同じ値が入る、ということになる。
要するに見ようによっては無駄ですね。

ただし、処理から見ると実は簡単になる。
プログラムそれ自体は設計も実装も相対的に簡易にはなる。
構造処理を行うことがないため、
バグの混入も少なく、品質自体は高い。
キーの操作も非常に簡潔にできる。

ただし、関連データを保持できないため、
データ間の不整合が発生する場合は非常に操作がコスト高になる。
また、変更処理のコストが膨大になることは周知の通りです。

この構造は、いわゆる基幹バッチでは、
ほぼデファクトと言ってよいでしょう。
基幹バッチでの処理は
基本的に「最小構成のデータをself-contained」
に生成することがおおいですね。
他システムへ渡すデータを生成したり、
帳票データや伝票イメージデータはことが多いが、
これは用途として必然的にself-containedになります。
例えば、典型的な決済処理のバッチで生成される請求データは、
最終のアトミックな状態で
ほぼ完全に全部の情報をもっていなくてはいけない。
冗長であってもかまわないこともおおいです。

要は、これが分散処理と相性がいいですよ、と、こうなる。

最小構成がself-containedなフラットデータモデルは
細切れでばらまく取り扱いが楽だからです。
このモデルは分散処理として最小構成にいつでも分解できるために、
メモリー制約には対処しやすいのも特徴です。
取り回しも楽。キーもダイレクトに扱えます。
おぉスバラシイ。

おそらく処理がただでさえ複雑になりがちな分散環境では
このデザインが、まずは最初の選択になるでしょう。
そして、ごらんのとおりKVSとの相性もいいです。

じゃー、半構造モデルで行きますか？
・・・なので、そのままホイホイいきたい気分ですが、
それはそれでハマる部分はありますよと。

何か？というと、
端的にいうと前掲のようにこのデータモデルは、
冗長性故に運用性が低いということです。
少なくとも結合していたマスターデータ変更に関しては、
非常にもろいし、一定のレンジでの変更にも弱い。
例で言えば、あるTxMasterIDに所属する明細が
一カ所修正になった、という場合でも
変更するのは一苦労なのはすぐわかる。
（というか、最初からデータを
作り直したくなるぐらいな気分になることもある）
その結果、
業務的なプログラムとしては
データ変更処理のプログラムは必要以上に複雑になる
ということになります。

同じことは、基幹系でも当然にあるので、
手は打っていて、というか・・・
要は打つ手がないので、RDBにいったりDOAの方に行きました、
ということになっている。

では移行できない汎用機ではどうしたかっていうと・・
おもいっきり再実装時のコストをさげるように「仕組み」を振っておくしかない
という結論になっていますね。
ソースの解析やら、RTやリリースの厳守とか
可能な限りのドキュメンテーションとか、
とにかく仕組みでカバーというのが
現時点の結論。

なにがいいたいかっつーと、
現状では、TXのデータモデルは概ね二つに分類できますが
優勢なのは半構造データで、これは業務系とも相性は
悪くはないです、ということと、
そして、その分、変更耐性が強くないということです。

また、設計上はある程度ポリシーを事前に決めておかないと確実に死ねます。
しかも、これはわりと実装モデルの話だったりして、
適当な設計だとスルーして終わることが可能です。
んであとで困る。

これは昔から基幹TXでは問題になっていたということで、
同じことが多分これから普通に起きるのですが、
これは昔の知恵で対処済みなので、
車輪は二度も開発するな、ということもあります。

閑話休題えっと、ここまで来てアレですが、基幹の人はすぐ気づいたと思いますが、
実は第三の道がありまして・・・・・

例のヘッダーと明細をわけて流すというやつです。
基幹の人はこれだけでわかると思いますが、
StructuredとSemi-Structuredの混成。

最終的には、フラットデータには押し込めるのですが、その結合のタイミングを
最終処理まで持ち込む（すなわち転送量を減らす、かつ、
データ・ハンドルをさせやすくする）という手法です。

まぁこれがですね。トリッキーなんですが、バンド幅に制限のあった
古代ジュラ紀あたりには、流行ってですね・・・
おそらくその手法は分散でも使えます。
・・・ただまぁ、おすすめはしませんねぇ〜
ご存じの通り、ある程度データの流量と
スキーマの性格とメンテナンスの度合を天秤にかけた手法で
経験知＋設計がモノをいう手法なので、
経験のないアジャイル万歳な方には、とてもとても無理ですねぇ〜。
無理してやっても異常系で死ぬのと、
あとからの運用メンテの担当者に氏ねって言われるのがオチです。

コロンボ風味のベテランのおっさんが職場にいるようなら
聞いてみるといいですよ。「必ず」知ってますと思います。
これはこれで、まぁノウハウがあるのですが、
それはまたの機会で。

まぁそんな話です。分散処理のTXは
従来の最小単位でのself-containedなデータモデルが
向いてますが、メンテがきついので、適当作ると
死ぬよ、（自戒も込めて）というのがこのメモの趣旨。

ヤレヤレだぜ的なアレです。