Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_4
Why Europe’s Largest Ad Targeting Platform Uses Hadoop_4
by Ed Albanese March 10, 2010
http://www.cloudera.com/blog/2010/03/why-europes-largest-ad-targeting-platform-uses-hadoop/
Older and a Little Wiser
The processing times for our most important events in December 2009 were:
2009年 12月時点における、私たちの最重要イベントの処理時間は以下のとおりです：
• 42 minutes to summarize all daily log files for all events
• 1 hour to create training data samples
• 1 hour to create weekly reports
• 3 hours to summarize data accessed via a customer web based interface
• 42分：ログ･イベントに関する日々のデータをサマライズ
• 1 時間：学習データのサンプルを生成
• 1 時間：週レポートの生成
• 3 時間：Web ベースのインターフェイスを介して顧客がアクセスしたデータのサマライズ
Hadoop has really helped us to reduce dramatically the time taken to process data. We can expand both our online and data processing platform in the same way by simply adding more machines.
るという、大きは変革をもたらしました。そして、シンプルにマシンの台数を増やしていくという共通の方式で、オンラインとデータ処理のプラットフォームの双方を、拡張することができます。
A recent interesting development in our market is to enable different customers to share their data with each other for variable time frames. Data shared by several willing customers involves finding and processing huge training sets for our prediction algorithms. If we had not migrated, we could have never made this possible.
私たちのマーケットで最近に行った興味深い開発は、可変的なタイムフレームの中で、別々の顧客のデータを、相互に共有させるというものです。 それを快諾した顧客でのデータ共有により、私たちの予測アルゴリズムのための巨大なトレーニングセットを見つけ出して、調整していくという作業が関連付けられました。 この、Hadoop への移行が行われたいなかったら、このようなチャンスはあり得なかったと思います。
Looking Ahead
A potential next step for us would be to use column-oriented stores with MapReduce integration. Some of the options in the Hadoop ecosystem include Zebra (Pig), RCFile (Hive), or HBase. If this proves to be successful I look forward to writing the follow-up post. Moving from one hour to one minute sounds good.
私たちの次のステップにおける可能性は、MapReduce インテグレーションに対応したカラム指向のストアを利用することでしょう。 Hadoop エコシステムにおける選択肢には、Zebra（Pig）、RCFile（Hive）、HBase が含まれます。それらが成功へと導いてくれるなら、次のポストで経緯を説明したいと思っています。 「1時間」を「1分」に短縮するのは、とてもステキなことです。
About nugg.ad
With its Predictive Behavioral Targeting solution nugg.ad operates Europe’s largest targeting platform. nugg.ad’s unique predictive algorithm reduces media loss, increases campaign efficiency and lowers target-group CPM. nugg.ad works with and assists its clients to increase turnover and win new advertising budgets as it delivers predicted values on socio-demographics, gender and product interests making it possible to target hard-to-reach target groups online.
nugg.ad は、Predictive Behavioral Targeting ソリューションを用いる、ヨーロッパで最大のターゲティング･プラットフォームを運用する企業です。nugg.ad のユニークな予測アルゴリズムは、メディアにおける非効率な運用を低減し、広告キャンペーンの効率を高め、より安価なターゲット･グループ CPM（Cost Per Mille）をもたらします。nugg.ad は、ターゲット･グループへのフォーカスという達成しにくい目標に対して、人口統計や、性別、製品への興味などをオンラインで調査することで、新しい広告予算を勝ち取るように誘導していきます。そして、クライアントと協調し支援していくことで、集客率を高めていきます。
About the author
Richard Hutton is the CTO of nugg.ad and has been working for the organization since October 2006.
＜おわり＞
ーーーーー
昨年の10月に開催された Hadoop World の Welcome レセプションで、あるスパム･フィルタにおける処理時間が 9時間から 1時間弱に短縮されたという話を聞きました。 また、以下のリファレンスを参照していただければ、Yahoo や VISA における Hadoop の効果は明白です。ただし、これまでに確認されている事例では、結果としての数値が紹介されているだけで、この nugg.ad のような途中経過までも説明するものは無かったと思います。その意味で、とても有益な資料になるはずです。 すばらしい情報を提供してくれた、Richard Hutton さんと Cloudera に拍手です。 ーーー A.C.
<関連>
Hadoop World Report：優良企業はなぜ Hadoop に走るのか
Hadoopが秘める可能性：オンプレミスでもクラウドでも使えるプラットフォームの魅力
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_1
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_2
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_3
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_4
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_3
Why Europe’s Largest Ad Targeting Platform Uses Hadoop_3
by Ed Albanese March 10, 2010
http://www.cloudera.com/blog/2010/03/why-europes-largest-ad-targeting-platform-uses-hadoop/
Development Begins
In June 2009 we started to develop a full solution. At this point certain external factors played a very helpful role in our development. One was the publication of the book “Hadoop: The Definitive Guide” by Tom White, which helped us to understand how we could use Hadoop. The other was the emergence of a dynamic programming language called Clojure, which compiles directly to JVM byte code.
そして、2009年 6月には、すべてのソリューションの再開発に着手しました。 そのとき、Tom White による “Hadoop: The Definitive Guide” が出版されるという、私たちの Hadoop への理解を推進する出来事がありました。また、JVM バイトコードへとダイレクトにコンパイルする、Clojure と呼ばれるダイナミック･プログラム言語も出現しました。
After one month of development we were able to create our reports using Hadoop with our processing times going from five days to one hour. This was great for building confidence in our decision. For the following four months we progressively turned features off in the old data warehouse as they became available in Hadoop. By October 2009 we had completed the migration and also additional new features previously impossible to run. In the next section I will briefly explain how it actually works.
1ヶ月の開発期間の後に、Hadoop を用いたレポート生成が可能になりましたが、その処理時間が 5日間から 1時間に短縮されたのです。それにより、私たちの判断に大きな自信が生まれてきました。それから 4ヶ月の間に、漸進的に Hadoop へと機能を移行し、古いデータウエア･ハウスを停止していきました。 そして 2009年10月には完全な移行を達成した上に、それまでは実現できなかった新しい機能を付け加えました。 次のセクションでは、私たちが行ってきたことを簡潔に説明していきます。
A Closer Look at our Hadoop Setup
Our cluster is located in one of our data centers and contains commodity machines with a total of 36 cores and 8 TB of disk space. The machines were provisioned using Chef from Opscode.com and we use the Cloudera CDH1 distribution.
私たちのデータセンターの１つに、このクラスタは配置されており、合計で 36コアの CUPと ８TB のディスク・スペースを有する、コモディティ･マシンで構成されています。それらのマシンでは、Cloudera CDH1 ディストリビューションを採用し、Opscode.com の Chef を用いたプロビジョニングを行っています。
The log files are now copied to the HDFS. In order to make sense of our data we need it summarized by hours, days and weeks. Therefore, we organize our HDFS directory structure hierarchically by date to reflect this requirement. The path for handling days and hours follows the structure /event/years/months/days/hours. This way we can use simple file globs for a MapReduce job input file configuration.
現時点において、ログ･ファイルは HDFS にコピーされています。 私たちのデータの意味を理解するためには、時間／日／週のレベルでの処理が必要になります。 したがって、こうした要件を反映するために、HDFS ディレクトリ階層構造を、日付を用いて構成するようにしました。｢日｣ や ｢時間｣ を取り扱うパスは、/event/years/months/days/hours という順に並びます。 そうすることで、MapReduce ジョブ入力ファイル･コンフィグレーションのための、シンプルで細かく分類されたファイルを利用できます。
We wrote our own simple scheduler querying the HDFS to see, if input is available to create missing output. When it cannot find the output a configuration is created containing input and output path which is sent to our MapReduce server.
また、出力を達成できないような入力が存在するのかどうか、その点を確認するために、HDFS に対するシンプルでスケジューリングされたクエリーを記述しました。 そして、出力が見つからない時には、MapReduce サーバーに送信する入出力パスを含んだ、コンフィグレーションを作成するようにしました。
The MapReduce server provides a JSON HTTP API for starting, querying and stopping jobs. It supports both scheduled and on-demand jobs. When the server receives a request to run a job, the event name is used to locate the associated chain of one or more Hadoop jobs to run. A unique identifier is returned which can be later used to query or stop the job.
私たちの MapReduce サーバーは、ジョブの始動／クエリー／停止のために、JSON HTTP API を提供します。そこでは、スケジュールされたジョブと、オンデマンドのジョブの双方がサポートされます。ジョブ実行のリクエストをサーバーが受信するときには、関連して実行される他の Hadoop ジョブを指し示すために、イベントの名称が用いられます。そして、後にジョブに対するクエリーや停止のための使用される、ユニークな ID が返されます。
An example is the chain of events to run one of our daily reports. Customer-wise it contains a summary of page impressions and unique clients for each socio-demographic and product interest prediction our online platform produces. Therefore, we first fetch information stored in our customer database and add this to the distributed cache. The MapReduce phase sums up the page impressions for each user and counts the number of client ids for each prediction and possible outcome e.g. age class 30-39. The final phase is to perform a reduce side join where the internal customer ids are translated to account manager readable information by accessing the data previously stored in the distributed cache.
例として、私たちのデイリー･レポートの、一部を実行するイベントの連鎖があります。 顧客の観点からすると、そこには、私たちのオンライン･プラットフォームが作り出す、それぞれの製品への興味と購買層の予測に関する、ページ･インプレッションと個々のクライアントのサマリーが含まれます。 したがって、顧客データベースにストアされた情報を最初にフェッチし、それを分散キャッシュに加えていきます。 MapReduce フェーズでは、それぞれのユーザーごとのページ･インプレッションを加算し、個々の予測と可能性の結果（age class 30-39 など）ごとに、クライアント ID の数を数えていきます。 最終フェーズとして、以前に分散キャッシュにストアされたデータにアクセスします。そして、内部情報である顧客 ID を、アカウント･マネージャーが読める情報に変換する、Reduce サイドの join を実行します。
At a later point we intend to use the MapReduce server API to build a web based interface fitting our purposes.
今後ですが、この目的に適してた Web ベースのインターフェイスを構築するために、MapReduce サーバー API を使うつもりです。
Frequently-run jobs are implemented in Clojure and Java using the Hadoop MapReduce API with a number of performance optimizations. These are:
頻繁に実行されるジョブは、Hadoop MapReduce API を用いて Clojure と Java で実装されますが、数多くのパフォーマンスの最適化をともないます。
• Compress map output to LZO, mainly to reduce disk IO during the shuffle phase
• Apply a Combiner to perform initial aggregation before the data arrives at the reducer
• Use our own developed Writable types which are written to be RawComparators
• Add type hints with Clojure code to avoid the overhead of reflection
• Map 出力を LZO に圧縮し、主として Shuffle フェーズのディスク I/O を低減。
• データが Reducer に到着する前に、最初のアグリゲーションを実行するために Combiner を適用。
• RawComparators になるように記述された、独自開発の Writable types を使用。
• リフレクションのオーバーヘッドを回避するために、Clojure を用いた type hints を追加。
Also we use tools like Pig to run ad hoc reports as well as streaming jobs e.g. to grep the contents of the web servers logs.
さらに、アドホックなレポートを実行するための、Pig のようなツールを使うだけではなく、たとえば、Web サーバー･ログのコンテンツを grep するための、ストリーミング･ジョブも利用します。
Spreadsheets are often used by our statisticians and account managers as a tool to analyze data. Therefore, we wrote an OutputFormat class which generates Excel work books with a number of sheets summarizing customer data.
統計学者とアカウント･マネージャーが実施する、データ分析のツールとして、スプレッドシートが頻繁に使用されます。 そのため、顧客データを要約する多数のシートを用いた、Excel ワークブックを生成するための、OutputFormat クラスを記述しました。
＜続く＞
ーーーーー
次は最終回で～～～す ーーー A.C.
＜関連＞
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_1
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_2
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_3
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_4
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_2
Why Europe’s Largest Ad Targeting Platform Uses Hadoop_2
by Ed Albanese March 10, 2010
http://www.cloudera.com/blog/2010/03/why-europes-largest-ad-targeting-platform-uses-hadoop/
Headache Turning Into a Migraine
One year later our situation had changed considerably. The graph below shows the amount of data we were logging from January 2009 until December 2009.
私たちの状況は、その１年後には大きく変化していました。 以下のグラフは、2009年 1月から 12月までに、収集していたログ･データ量を示します。
In March 2009 compared to the previous year we were logging more than double the amount of data per day as the online platform went from receiving 3200 to over 8500 requests per second. The good news was our business was growing nicely. Our online platform was straight-forward to scale in tandem, we just added more machines. The bad news was our data processing platform was not as simple to scale. In March 2009 the processing times for the same events mentioned early were:
2009年3月期の前年との比較では、オンライン･プラットフォームへのリクエストが毎秒 3200 から 8500 強へと増大したように、1日あたりのログ･データ量は２倍以上になりました。 ビジネスが上手く展開していることは、とても良いことでした。 それに応じてオンライン･プラットフォームも直線的にスケールを拡大し、さらに多くのマシンを加えるだけで済みました。 ただ、良くないことも起こってきました。データ処理プラットフォームのスケールが、簡単には拡大していかなかったのです。2009年 3月には、前述のイベント処理の時間が、以下のように増大してしまいました：
• 23 hours to summarize all daily log files for all events (almost a day to process a day)
• 18 hours to create training data samples (inhibiting our ability to refresh data mining models regularly)
• 5 days to create weekly reports (our weekly reports were almost one week behind)
• 4 days to summarize data accessed via a customer web based interface (prone to crash)
• 23 時間：ログ･イベントに関する日々のデータをサマライズ（ほぼ 1日を費やすようになった）
• 18 時間：学習データのサンプルを生成（データ･マイニング･モデルの通常運用が厳しくなった）
• 5日：週レポートの生成（週レポートの提供が、約 1週間遅れとなった）
• 4日：Web ベースのインターフェイスを介して顧客がアクセスしたデータのサマライズ（クラッシュに近い）
We could no longer process our data in the time scales needed for our business. The root cause of our problem was clear. A significant increase in data volume resulted in a significant increase in processing times. Initially we thought maybe we could just improve our classical data warehouse. After analyzing our current solution and problem it was pretty clear that we could not avoid hitting scaling and performance problems.
もはや、ビジネスが要求するタイムスケール内で、データを処理できなくなっていました。 その、根本的な問題は明確です。 つまり、データ量の大幅な増加が、処理時間の大幅な増大をもたらしていたのです。 そして当初は、従来からのデータウエア･ハウスを改善できると思っていました。その時点で用いていたソリューションと問題を解析した後に、スケールの壁とパフォーマンスの問題が避けられないことが明確になりました。
Searching for Relief, We Found Hadoop
In March 2009 we started our investigation of possible technologies. As part of it we setup a Hadoop test cluster with three machines. A selection of log files was copied into the HDFS. We started writing simple Pig scripts and later MapReduce jobs using the standard Hadoop API. It took some practice to go beyond the classical word count example to writing solutions for our problems using MapReduce.
2009年 3月に、私たちは利用可能なテクノロジーについて調査を始めました。 その一環として、Hadoop のテスト･クラスタを 3台のマシンに設定しました。一連のログ･ファイルは HDFS にコピーされます。 標準的な Hadoop API を使うために、最初はシンプルな Pig スクリプトを書き始め、その後には MapReduce ジョブにも取り組みました。 私たちの 問題のためのソリューションを MapReduce を用いて記述することは、これまでのワード数カウントの例を超える、いくつかのプラクティスとなりました。
Since our initial tests looked promising, we decided to try and build our solution on Hadoop. Besides scaling there were several additional reasons:
最初のテスト結果が好ましかったので、Hadoop への取り組みと、そこでのソリューション構築を決定しました。スケールの他にも、いくつかの理由がありました：
• Relatively easy to administrate and monitor
• Easy to use (when you are a small team everyone needs to be able to change anything at anytime)
• No software licensing costs
• Only expansion cost is hardware
• 相対的に見て、運用と監視が容易
• 利用が簡単 (小規模な開発チームにおいては、いつでも全員が、システムを変更できる状況が必要)
• ソフトウェア･ライセンスにコストがかからない
• 唯一の費用はハードウェアとなる
＜続く＞
ーーーーー
だんだん、面白くなってきましたねぇ ーーー A.C.
＜関連＞
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_1
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_2
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_3
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_4
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_1
Why Europe’s Largest Ad Targeting Platform Uses Hadoop
by Ed Albanese March 10, 2010
http://www.cloudera.com/blog/2010/03/why-europes-largest-ad-targeting-platform-uses-hadoop/
Richard Hutton, CTO of nugg.ad, authored the following post about how and why his company uses Hadoop.
nugg.ad operates Europe’s largest targeting platform. The company’s core business is to derive targeting recommendations from clicks and surveys. We measure these, store them in log files and later make sense of them all. In 2007 up until mid 2009 we used a classical data warehouse solution. As data volumes increased and performance suffered, we recognized that a new approach was needed. This post tells the story of how we arrived at using a Hadoop-based solution – and how we took jobs that required five days to process down to one hour.
nugg.ad は、ヨーロッパ最大のターゲティング･プラットフォームを運用しています。 当社のコア･ビジネスは、クリックとサーベイから、ターゲティング･リコメンデーションを得ることです。 それらを測定し、ログ･ファイルにストアし、意味のある情報にしていきます。 2007年から2009年の半ばまでは、従来のデータウエアハウス･ソリューションを使ってきました。 そして、データ量が増大してパフォーマンスが劣化したとき、新しいアプローチが必要だと認識しました。 このポストでは、Hadoop ベースのソリューションを用いるという結論に達した道筋と、5日間を必要とした作業を１時間まで短縮した方式について説明します。
Data Processing Platform Requirements
The nugg.ad service is split into two parts. The online targeting platform accessed by HTTP provides real-time targeting recommendations in response to a users clicking behavior. The off-line data processing platform performs the analytics to make this possible.
nugg.ad のサービスは、２つのパートに分かれています。HTTP でアクセスされるオンライン･ターゲティング･プラットフォームは、ユーザーのクリックに反応して、リアルタイムなターゲティング･リコメンデーションを提供します。 また、オフライン･データ処理プラットフォームは、そのリコメンデーションのための分析を行います。
Currently our online platform creates on a daily basis just over a 100 GB of log data per day. The majority of data is for website clicks, ad clicks and targeting predictions. These are split into different files for each category and rotated on an hourly basis. The data which needs to be logged is sent in UDP packets to a series of log nodes implemented in Erlang.
現時点において、私たちのオンライン･プラットフォームは、毎日 100GB 以上のログデータを生成します。 大半のデータは、Weｂサイトのクリックと、広告のクリック、そしてターゲティング予測に関するものです。 これらは、カテゴリごとに別のファイルに分けられ、時間単位でローテーションされます。ログに加えられるデータは、Erlang で実装された一連のログノードへ向けて、UDP パケットにより送信されます。
The logging of user interactions with our online platform creates considerable amounts of data. We need to use all of this data in order to:
このオンライン･プラットフォームを用いたユーザー･インタラクションは、相当な量のデータを生成します。 それらすべてのデータについて、以下の順序で利用していく必要があります:
• Monitor the performance of ad campaigns
• Track the precision of targeting predictions
• Create reports used by our account managers and statisticians for decision making
• Summarize the data for our customers to help sell ad space
• Run ad hoc reports over historical data
• Extract training data for our prediction algorithms
• Build machine learning models
• アド･キャンペーンにおける成果の確認
• ターゲティング予測における精度の追跡
• アカウント管理およびデジション･メーキングで用いるレポートの生成
• 広告スペースを顧客に販売するために必要な、要約したデータの生成
• 時間的なデータを参照するためのアドホック･レポートの実施
• 予測アルゴリズムのための学習データの抽出
• マシンによる学習モデルの構築
When We Were Young and Energetic
The initial solution for the data processing platform was built on the principles of classical data warehousing. The log files were collected from each of the log nodes and merged into one big file for each category. The contents were then aggregated. After that the results were used by the Pentaho Kettle ETL tool to populate the tables based on a star schema in PostgreSQL. At this point we could run SQL queries to use our data.
データ処理プラットフォームのための最初のソリューションは、従来からのデータウエア･ハウジングの原則を基盤として構築されました。 ログ･ファイルは個々のログ･ノードから集められ、それぞれのカテゴリーに対応する、１つの大きなファイルにマージされました。 続いて、コンテンツがアグリゲートされます。その結果は、Pentaho Kettle ETL ツールにより、PostgreSQL の star スキーマに基づくテーブルに代入されます。 この時点で、データを利用するための SQL クエリーの実行が可能になります。
In March 2008 we needed to process and use 30 GB of daily log data per day. The processing times for our most important events were:
2008年の 3月には、30GB のデイリー･ログを処理して利用する必要が出てきました。 私たちの重要なイベントを処理するための時間は、以下のとおりでした：
• 12 hours to summarize all daily log files for logged events
• 6 hours to create training data samples
• 2 days to create weekly reports
• 2 days to summarize data accessed via a customer web based interface
• 12 時間：ログ･イベントに関する日々のデータをサマライズ
• 6 時間：学習データのサンプルを生成
• 2 日：週レポートの生成
• 2 日：Web インターフェイスを介して顧客がアクセスしたデータのサマライズ
We were far from satisfied with these times. However, it was good enough in the early days and customer expectations of our service in 2008 were a lot lower than today.
このような時間の消費は、私たちが望むものではありませんでした。 それでも、会社が設立された当初は充分でしたし、2008年の私たちのビジネス予測は、現在よりもずっと低いところにあったのです。
＜続く＞
ーーーーーー
先週の半ばに、Cloudera のブログに掲載された事例紹介です。 今回を入れて、２～３回に分けてポストしていきます。とても面白い話が続きますので、ご期待下さい！ ーーー A.C.
＜関連＞
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_1
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_2
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_3
Hadoop による Web 広告システムの構築と運用 ：ヨーロッパでの事例_4
leave a comment