Facebookのデータウェアハウス

HDFS: Data warehousing at Facebook
のリンク先にある論文

http://borthakur.com/ftp/sigmodwarehouse2010.pdf

ではFacebookがどのようにデータウェアハウスを構築しているかが書かれています。

興味深い論文なのですが気になった点を書きます。

全体のシステム構成はこちら

特長的なのはHive-Hadoopクラスタが２つあることです。
その意味で象本や他のFacebookのプレゼンスライドに出てきた絵とちょっと違います。

以下のように書かれています。

As shown in Figure 1, there are two different Hive-Hadoop
clusters where the data becomes available for consumption by the
down stream processes. One of these clusters – the production
Hive-Hadoop cluster - is used to execute jobs that need to adhere
to very strict delivery deadlines, where as the other cluster – the
ad hoc Hive-Hadoop cluster is used to execute lower priority
batch jobs as well as any ad hoc analysis that the users want to do
on historical data sets. The ad hoc nature of user queries makes it
dangerous to run production jobs in the same cluster. A badly
written ad hoc job can hog the resources in the cluster, thereby
starving the production jobs and in the absence of sophisticated
sandboxing techniques, the separation of the clusters for ad hoc
and production jobs has become the practical choice for us in
order to avoid such scenarios.

この２つのユースケースについて詳細には書かれていないですがProductionの方がSLAが厳しいようです。
SLAが違うのでクラスタを分けており、これによりAdhocのジョブがProductionに悪影響を及ぼさないようにしているようです。

この辺のジョブ管理というかリソース管理は必要でしょうねえ。あと権限管理もか。

それはともかく、ユースケースとしてはおそらくProductionはScribeやMySQLからデータを取得してアナリストが使いやすい形のデータ（データマート）を作り、Adhocの方はアナリストが好きなようにクエリを発行して解析するものでしょう。

ProductionからAdhocへのレプリケーション方法については以下のように書かれています。

The replication process relies on
the logging of all the Hive commands submitted to the production
cluster. This is achieved by implementing a “command logger” as
a pre-execution hook in Hive – the pre-execution hook API
enables Hive users to plug in any kind of programming logic that
gets executed before the execution of the Hive command.

どうやらHiveコマンドをフックするAPIがあるようで、それをトリガーにしてレプリケーションしているようです。これはドキュメントに書いてない気もしますがw　まあHiveはFacebookが作ったので中身もよくわかっているんでしょう。