ビッグデータシステムのLambdaアーキテクチャ

http://www.tuicool.com/articles/uiyYFf
Nathan Marzの大作Big Data:Principles and best practices of scalable real-time data systemsは、Labmda Architectureの概念を紹介し、ビッグデータアーキテクチャにおいてreal-timeとbatch jobをよりよく結合させ、ビッグデータのリアルタイム処理を達成するために使用されます.
従来のシステムの問題
従来のデータベースの設計では、システムの伸縮性をうまくサポートできません.ユーザー・アクセスが増加すると、データベースはますます増加するユーザー・リクエストの負荷を満たすことができず、データベース・サーバがユーザー・リクエストにタイムリーに応答できず、タイムアウト・エラーが発生します.
解決策は、Webサーバとデータベースの間に非同期処理のキューを追加することです.次の図に示します.

Webサーバがページ要求を受信すると、メッセージがキューに追加されます.DB側では、Workerを作成して定期的にキューからメッセージを取り出して処理します.たとえば、100個のメッセージを読み出すたびに処理します.これは両者の間にバッファを確立することに相当する.
しかし、このスキームはデータベースoverloadの問題を本質的に解決するものではなく、workerがwriterの要求に追いつかない場合、複数のworkerの同時実行を増やす必要があり、データベースは再び要求に応答するボトルネックになる.1つの解決策は、データベースをパーティション化することです.パーティション化の方法は、通常、Hash値をkeyとする.これにより、各keyが存在するパーティションを探す方法をアプリケーション側が知る必要があります.
問題は、ユーザーリクエストの増加に伴って発生します.以前のパーティションが負荷を満たすことができなかった場合、より多くのパーティションを追加する必要があります.この場合、データベースに対してreshardを行う必要があります.reshardingの作業は非常に時間がかかり、データの移行、クライアントアクセスのパーティションアドレスの更新、アプリケーションコードの更新など、多くの作業を調整する必要があるため、苦痛です.システム自体がオンライン・アクセス・サービスを提供している場合、メンテナンスに対する要求はさらに高くなります.誤ったパーティションにデータが書き込まれる可能性があるため、スクリプトを自動的に作成し、十分なテストが必要です.
パーティションがデータベース負荷の問題を解決できるとしても、フォールトトレランスの問題があります.解決策:

queue/workerの実装を変更します.メッセージが使用できないパーティションに送信されると、メッセージをpendingキューに配置し、pendingキュー内のメッセージを一定時間おきに処理します.

データベースのreplication機能を使用して、各パーティションにslaveを追加します.

問題は完璧に解決されなかった.システムに問題が発生したと仮定します.例えば、アプリケーションシステムのコード側で誤ってバグが導入され、ページのリクエストが1回繰り返しコミットされ、重複したリクエストデータが発生します.悪いことに、24時間後になってやっとこの問題が発見され、データの破壊が発生しました.毎週のデータバックアップでも、どのデータが破壊されたのか分からないため、この問題は解決できません.人為的なエラーは常に避けられないため、アーキテクチャ時にこの問題をどのように回避すればいいですか?
アーキテクチャはますます複雑になり、キュー、パーティション、レプリケーション、再パーティションスクリプト(resharding scripts)が追加されました.アプリケーションは、データベースのschemaを理解し、正しいパーティションにアクセスする必要があります.問題は、データベースがパーティションについて理解していないため、パーティション、レプリケーション、分散クエリーに対応するのに役立ちません.最悪の問題は、システムが人為的なエラーのためにエンジニアリング設計を行っていないことであり、バックアップだけでは治らないことです.結局,システムは人為的な誤りによる破壊を制限する必要がある.
データシステムの概念
ビッグデータ処理技術は、このような伸縮性と複雑性を解決する必要がある.まず、この分散の本質を認識し、パーティションとレプリケーションをうまく処理するには、エラーパーティションによるクエリーの失敗を招くのではなく、これらの論理をデータベースに組み込みます.システムを拡張する必要がある場合、ノードを非常に容易に追加することができ、システムは新しいノードに対してrebalanceを行うこともできる.
次に、データを可変にすることです.元のデータは永遠に修正されず、エラーを犯しても、エラーデータを書いても、元の良いデータは破壊されません.
「データシステム」とは?Nathan Marz氏は、
データ・システムが過去のデータを検索して質問に答える場合は、通常、データセット全体にアクセスする必要があります.
したがって、data systemの最も一般的な定義を与えることができます.

Query = function(all data)

次に、本書の著者は、Big Data Systemに必要な属性について説明します.

堅牢性とフォールトトレランス(RobustnessとFault Tolerance)

低遅延の読み取りと更新(Low Latency reads and updates)

伸縮性(Scalability)

汎用性(Generalization)

拡張性(Extensibility)

内蔵クエリー(Ad hoc queries)

メンテナンス最小(Minimal maintenance)

デバッグ可能(Debuggability)

Lambdaアーキテクチャ
Lambdaアーキテクチャの主な考え方は、次の図に示すように、ビッグデータシステムを複数の階層に構築することです.

理想的には、式Query = function(all data)から任意のデータアクセスが開始されるが、PBなどのかなりのレベルに達し、リアルタイムクエリをサポートする必要がある場合、非常に膨大なリソースがかかる.
1つの解決策は、クエリー関数(precomputed query funciton)を事前に演算することである.本書では、このような事前演算クエリー関数をBatch Viewと呼び、クエリーを実行する必要がある場合にBatch Viewから結果を読み取ることができます.このような予め演算されたViewはインデックスを確立することができ、ランダム読み出しをサポートすることができる.システムは次のようになります.

batch view = function(all data)
query = function(batch view)

Batch Layer
Lambdaアーキテクチャでは、batch view = function(all data)を実装する部分をbatch layerと呼ぶ.2つの役割を果たしています.

はMaster Data setを格納し、これは不変の持続的な成長のデータセット

である.

は、このMaster Data setについての事前演算

を行う.
明らかに、Batch Layerは、HadoopまたはSparkがサポートするMap-Reduce方式のようなバッチ処理を実行する.その実行方法は、疑似コードで表すことができます.

function runBatchLayer():
  while (true):
    recomputeBatchViews()

たとえば、次のようなコードがあります.

Api.execute(Api.hfsSeqfile("/tmp/pageview-counts"),
     new Subquery("?url", "?count")
         .predicate(Api.hfsSeqfile("/data/pageviews"),
             "?url", "?user", "?timestamp")
         .predicate(new Count(), "?count");

コードはhdfsフォルダの下のpage viewsを並列に統計し、結果を集計し、最終結果をpageview-countsフォルダの下に保存します.
Batch Layerによる事前演算の役割は,実際にはビッグデータを小さくし,リソースを効率的に利用し,リアルタイムクエリのパフォーマンスを改善することである.しかし、ここでは、Batch Layerで実行計画を手配し、定期的にデータを一括処理するために、クエリーに必要なデータを事前に知る必要があるという前提があります.また,これらのプリ演算を求める統計データはマージ(merge)をサポートする.
Serving Layer
Batch Layerは、master datasetに対してクエリーを実行することによってbatch viewを取得し、サービングLayerはbatch viewの操作を担当し、最終的なリアルタイムクエリーをサポートします.したがって、サービスレイヤーの役割は次のとおりです.

batch viewへのランダムアクセス

batch view

を更新
ServiceLayerは、Elephant DBなどの専用分散データベースであり、batch viewのロード、ランダム読み出し、更新をサポートする必要があります.ランダム書き込みはデータベースに多くの複雑さをもたらすため、batch viewのランダム書き込みはサポートされていません.シンプルな特性により、システムがより堅牢になり、予測可能になり、構成が容易になり、メンテナンスも容易になります.
Speed Layer
batch layerがbatch viewの推定を完了すると、serving layerが更新されます.これは、推定演算を実行するときに入力されるデータがすぐにbatch viewに表示されないことを意味します.これは、完全なリアルタイムを必要とするデータシステムには受け入れられない.この問題を解決するにはspeed layerを通過しなければならない.データの処理から見ると、speed layerとbatch layerは非常に似ており、それらの最大の違いは前者が最近のデータのみを処理し、後者がすべてのデータを処理することである.もう1つの違いは、最小の遅延を満たすために、speed layerは同じ時間にすべての新しいデータを読み取ることはありません.逆に、batch layerのようにview全体を再演算することなく、新しいデータを受信したときにrealtime viewを更新します.speed layerは再演算(recomputation)ではなく増分計算である.
したがって、Speed Layerの役割は、

serving layerに更新された高遅延の補完

高速増分アルゴリズム

最終Batch Layerはspeed layer

を上書きします.
Speed Layerの式表現は以下の通りです.

realtime view = function(realtime view, new data)

realtime viewは、新しいデータと既存のrealtime viewに基づいていることに注意してください.
まとめると、Lambdaアーキテクチャは次の3つの式です.

batch view = function(all data)
realtime view = function(realtime view, new data)
query = function(batch view . realtime view)

Lambdaアーキテクチャ全体を下図に示します.

Lambdaアーキテクチャに基づいて、batch layerを介してserving layerにデータが入ると、realtime viewでの対応する結果は不要になります.