書評: ビッグデータを支える技術

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)で著名な西田さんの著書である。とても先見性のある本で、当時は仕事でもあったからとてもお世話になった。その西田さんの新作だというし、最近はもういろいろビッグデータのソフトウェアとミドルウェアがありすぎてワケの分からないことになっていると思ったので、知識を整理するためにサクッと購入。

ビッグデータを支える技術―刻々とデータが脈打つ自動化の世界 (WEB+DB PRESS plus)

ビッグデータを支える技術―刻々とデータが脈打つ自動化の世界 (WEB+DB PRESS plus)

本書の冒頭でも触れられているが、昨今ではありとあらゆるソフトウェアがオープンソースで公開されているし、詳しい情報はほぼすべてインターネットで公開されているから、この本はカタログ的にさまざまな概念や製品を紹介していき、個別に深く解説することはしないと注意されている。まさにそれこそが本書の価値で、元エンジニアで昨今のビッグデータの潮流を知りたい課長、部長級の管理職や、現場でビッグデータを前に呆然としているエース級のフルスタックエンジニアが知識の補完を行う用途にピッタリである。次点で向いている用途としては、これからビッグデータの赤い荒波に乗り出していこうと考えているエンジニアや営業職にとっても、業界を俯瞰して全体図を把握するにはよい(当然コレだけではダメで、そこから自分の得意分野を深掘りしていかなければならないだろう)。ビッグデータのことが分からない、という人は必読の一冊だ。

私自身はこの業界にもう10年近くいることになるので、おおよその概観を脳内に持っているつもりだったが、思った以上にビジネスインテリジェンスとかETLとかバッチとかに多様な世界があって、いろいろあるらしいなあということをざっと確認できたのでよかった。以下は、自分の専門分野で気になったところの指摘をささやかながらしておこうと思う。ちょっと忌々しい指摘ではあるが、これで本書の価値が損なわれるわけではないのでお間違いのなきよう。

10/6追記: YARNとLXCに関して - 「ビッグデータを支える技術」補足 にて捕捉いただいた。この捕捉を読んでから、以下のコメントは割り引いて読んでいただきたい。

Apache Mesos について @ P119

119ページのカラムで「Mesosによるリソース管理」と題してApache Mesosの紹介をしているのだが、2017年の本にしては情報が古い。まず出だしの「MesosはOSレベルの仮想化技術を用いており、YARNと比べると…」という話からしてアレでして、YARNもMesosもリソース制限は基本的にcgroupを使っているわけなのでそんなに変わらない。Namespacesの利用があるかどうかは異なるかもしれないが、それはリソース制御ではなくIsolationなのでちょっと違う。また「Dockerと同じくLinuxコンテナ(LXC)が用いられ」というのは明らかに誤り。遅くても1.0の時点でサポートされているコンテナエンジンはDockerかMesos独自のエンジンであり、LXCは一年以上前から利用していない。DockerもLXCは既に利用しておらず、LinuxのNamespacesを利用している。

またその後の解説でMesosにData localityがなく、一方でYARNにはあるのでYARNの方が優れていると解説されている。確かにMapReduceなどのLocality機能と親和性が高い機能がYARNだとスムーズに動作するらしいが、Mesosの2 level scheduler という思想に基づけば入力データのHDFS上の位置をみつつLocality awareに作るのはフレームワーク側の仕事である。テクニカルには、多数のOfferを抱えておけばIPアドレスは分かるので、フレームワーク側でデータの位置と割り当てられたリソースをマッチングしてスケジュールすることが可能。むしろYARNみたいに中央集権的にスケジューリングするよりも、Mesos用にスケジューリングアルゴリズムを自律的に使い分ける方が便利なケースもあるだろうから、Data localityがあるから優れていると一方的に評するべきではない。それでも、On the flyですぐLocalityを考慮してジョブを動かせるのは便利だけど、それは計算フレームワーク側が対応してるかどうかの問題じゃないかと思う。もちろんYARNの方が対応してるソフトウェアは多いと思うが、それは個別のソフトウェアの話だろう。

分散システムという言葉について

また、本書の全体を通して「分散システム」という言葉が定義なしに使われていて、都度どのような故障モデルや通信モデルを備えているのか、合意の基準は何なのかが引っかかる。

特にP150では「TCPではメッセージにシーケンス番号を付けますが、分散システムではシーケンス番号はあまり使われません」と表記していて、続く文章で欠番のないシーケンス番号の発行は(いわゆる故障あり非同期通信モデルでは)現実的に難しいためと解説している。たしかにトランザクションIDやTCPのシーケンス番号、REDOログなど欠番があったときに途中のメッセージを待つ必要がある場合には、要件を満たすシーケンス番号を発行することが技術的に難しい(Twitter の Snowflake などはあったが、それだけでクラスタを一つ組まなければならない)ので「使われません」という表現になる。なる、が、非常にこれはミスリーディングで、我々がシステムで依存しているPaxos, Zab, Raft といった分散合意プロトコルは欠番を許容するシーケンス番号を順につけていって、プロトコルの正しさはその順序性に依存しているのである。Raftはシーケンス番号の欠番を許さないが、欠けたデータを復元する手順を持っている。

この言い回しが紛らわしいのは「分散システムでは」の主語が大きいことに由来しているので、もっと限定的に書くべきであった。そもそもこの文章はストリーム処理における "at least once" の解説に含まれている場面であって、冗送排除の文脈であって欠損メッセージの検出ではない。したがって同じメッセージには同じIDがついているだけで十分で、送信側が受信側からAckを確認するまで再送し続ければ at least once は達成できる。つまり欠損の検出が不要なわけで、シーケンス番号じゃなくてもいい…シーケンス番号はよく使うんだよ…という主張だ。「あまり使いません」というミスリードは不要だったのではないかという話。