アトムとビット〜Hadoopでバッチが速くなって何がうれしいか？

まず、社内のオープニングで説明した内容だったりするのですが、一回まとめておきたいので。

断っておくとこの言い方はニコラス・ネグロポンティから取っています。彼の主張は明確でいままでアトム（物質）的な存在だったものが、ビット（電子情報）的な存在に凌駕される、いや大きく姿を変えてるという指摘でございますね。Being digitalが出版されたのが95年なので、もう15年以上になるわけですね。ま、ざっくりすぎてアレですが。・・ワーディングとして便利なので利用させてもらいます。

まず、主題は何かというと、「バッチが速くなって何がうれしいのか？」という問題の背景をちゃんと説明しておきたい。もともとHadoopで何がしたかったのかというと、そもそもバッチのスピードを上げたかった。そもそもRDBMSではまぁ限界があったというのが事の起こり。んで分散処理を行うとIOが分散されるので、スピードがあがりますね。CPUも使い切れますね。ということでAsakusaというものを作りました。というのが今に至る道筋になっています。別にビックデータというのは考えていませんでした。

実はずっと追求していたことがあって、それはもう１０年来変わっていないのですが、要は「アトムとビットのずれ」をなくす、ということがやりたかった。というか、できていないのでこれからも追求します、ということです。この「一つの手段」がバッチの高速化です。自分らのサイトを見てもらえばわかる通り、EDIなんてのもやってまして、これとHadoopは関係ないだろ、という指摘もあるかと思いますが、実は達成すべき目標は同じだったりしてます。（達成てきているかどうか、別の議論で・・）

つまり、「アトムとビットのずれ」をなくしましょう、ということです。

まず、基本的に企業活動や一般の日常生活において、アトム（物理情報）とビット（電子情報）はかならず、ズレます。例えば、受発注である商品を売買します。届くタイミングと納品データの発生は一致しません。もし、仮にアトムとビットが完全に一致しているのであれば、物流拠点に商品がついたその瞬間に検収データが「ビットとして」生成されるべきです。が、そうではないですね。検収して、検収の元データが作られて、クレンジング・在庫処理・その他の後方処理がバッチで処理されて、初めてちゃんとビットになるわけです。この間、アトム（モノが届いて納品先の手元にあるという状態）とビット（その情報が電子空間で認識されている）は、絶対にずれています。要はアトムとビットの同期を取るタイムラグが発生する。上記の例のようなラグが、企業内はもちろん、とくに企業間ではものすごく拡大しています。例えば、商品の仕入や物流とその検収・受領のデータの流れのタイミングはまったく一致しません。「流通在庫」なんてのは、ほぼ正確なビットはないと思っていいです。こういった例は枚挙に暇がなく、流通・サービス・製造・運輸・インフラといった実際にモノをハンドリングする業務ではほぼ確実に発生しています。

このラグが実は非常に問題です。

アトムとビットが常に一致している場合は、物事の判断や処理は大抵の場合迅速に行えます。意思決定がおそかったり、処理がつまるのは、このアトムとビットの不一致が原因として大きい。特にこの同期の処理に時間がかかればかかるほど、判断が遅れます。なぜなら一般にアトム的な判断は往々にして、ビットに依存するからです。さらに、同期処理に時間がかかっている間に、アトムの情報はどんどん更新されますし、また、変更があった場合の遡及処理に時間がかかります。要するにどうでもよいコストがかかります。

修正伝票や基幹処理されたデータの修正処理がおそろしく手間なのは周知の通りです。そして、大抵の場合は、これは人件費であり、時間的なコストです。もっとも貴重な資源ですね。時間の代替性はコストとして高くつく、というのはご存知とおりです。総じて、大抵の無駄は「アトムとビットの不一致」により発生している、と思っています。さらに言うと、データの更新はビットの方が速いというイメージがありますが、実際はビットの方が遅いというのが実体です。

そして、その無駄を許容できる余裕は今の日本や日本の企業にはありません。んで、さらに「アトムとビットの不一致」をなくすことことに大きく寄与できるのがITです。なので、やるべき価値があるし、ITでやることの意義がある、と思っています。

（ついでにいうとBMSってのが、EDIの規格なんですが、これはTA伝票(＝アトム情報の物理コピー)を電子化(＝ビット化)したものです。基本的には業務効率化のインフラミドルを提供していく、というのが方向性なので、Hadoopによるバッチ高速化もそういった大きな考え方の延長にあります。）

なお、余談ですが、個人的には実はレイテンシーとスループットの関係がエンタープライズでは、この「アトムとビットのずれ」でそれぞれ活躍する場面が異なるな、と思っています。すなわちレイテンシーやスループットの向上は、このズレをなくすためには必要な「コンセプト」ですが、それぞれ役割が違います。

スループットは、データ処理の全体的なスピードを上げて、比較的な大きな基幹系のシステムで、極力アトムとビットを合わせましょう、という方向に利用されます。バッチ処理やオンライン処理にあたるところでのコンセプトだと思っています。
次に、レイテンシーですが、これは組み込みの分野、とくにデバイスとデータ生成の部分で必要とされるコンセプトだと思っています。これは限りなく小さく、そして論理的にはゼロ・レイテンシーが要求されます。ビットとアトムの同期のその瞬間のレイテンシーですね。RtOSと言ってもいいかと。

スループットを要求される仕組みとレイテンシーが要求される場面はそれぞれ異なり、それらがうまく組み合わさって、アトムとビットのズレはなくなるだろうと思っています。Hadoopでのバッチ短縮はその一部分でしかないですが、割と明確な目標をもっているつもりです。バッチが速くなってうれしいか？という話にもどりますが、上記の理由でうれしいですね。はい。