DACエンジニアブログ：アドテクゑびす界

DACのエンジニアやマーケター、アナリストが執筆するアドテクの技術系ブログです。

巨大データベースのスケールアップと引越作業

Netezza データベース ビッグデータ

はじめに

ビッグデータ解析部でオーディエンスデータ解析基盤の開発、運用を担当している Mike です。 弊社ではインターネット広告配信ログをはじめとする「ビッグデータ」と呼ぶにふさわしいデータボリュームを扱うオーディエンスデータ解析基盤を構築しています。今秋、そのうちの１構成要素である、データサイズ16TBの巨大データベースをスケールアップするリプレイスを実施しました。このような巨大データベースのリプレイスはそうそうあることでもないので、新旧データベースの性能比較に加え、引越作業の工夫や注意点についても書いてみたいと思います。

データベーススケールアップの内容

対象となるデータベースは、IBM PureData System for Analytics （製品情報ページ） という超高速・大容量データベースです。以前 Netezza と呼ばれていたので、"IBM PureData System for Analytics" より "Netezza"（ネティーザ） のほうがピンとくる人が多いかもしれませんね。IBMの資料にも「Netezzaテクノロジーを活用した PureData System for Analytics」と謳われており、我々も社内で "Netezza" と呼んでいますので、ここでも親しみを込めて "Netezza" と書かせていただきます。

さて、新旧Netezzaのスペック概要は以下のとおりです。「DB処理性能」の値からはざっくり7倍の処理性能向上が期待できます。実際にどうであったかは後述の実測結果をご確認ください！ 旧Netezza　＝IBM PureData System for Analytics N1001-005 新Netezza　＝IBM PureData System for Analytics N2002-010

Netezzaスペック概要 ※2014/12/10修正： ユーザーデータ容量の単位をGBからTBへ修正しました。

引越作業の注意点｜　引越期間

発注からデータ移行完了まで1ヶ月を当初目標としましたが、結果的にはトータル2ヶ月かかりました。プラス1ヶ月は何かというと、データセンターでの 200V-60A 電源供給工事待ちでした。 １つ下のクラスの N2002-050（＝旧Netezzaと同ランク）に必要な 200V-30A はデータセンターが一般的に供給している電源仕様に収まるのですが、弊社が導入した N2002-010 に必要な 200V-60A の電源は日本のデータセンターで標準メニュー化されているところは少ないようで、今回設置したデータセンターさんには新Netezzaのための電源ラインを新設いただきました。電源ライン敷設工事作業そのものは1,2日でできるのですが、必要となる「電線」が受注生産でその調達に1ヶ月弱かかり、新Netezzaの「火入れ」まで約1ヶ月待つ必要がありました。

引越作業の工夫｜　データベース利用停止時間の短縮

データベースを丸ごと引っ越す場合、一般的には旧データベースのフルバックアップを新データベースへ展開する手順で進めることが多いと思います。この場合、データベースフルバックアップ取得中はデータベースへ変更がかけられず、データベースは利用停止となります。Netezzaにおいても同様です。 今回の移行対象データは約15TB、3,000テーブル弱で、フルバックアップ取得時間を試算したところ2日以上となりました。我々のNetezzaは24時間常に処理が実行されており、うまく調整しても6時間以上連続したメンテナンスウィンドウは設けられません。そこで手間は増えますが、テーブル単位に新Netezzaへデータ転送する方式としました。具体的には、変更のかからないテーブルから順次移動を行い、最後にデータベースを利用停止にして少量の直近差分を反映させることとしました。これにより、約15TB、3,000テーブル弱のデータ移行を1時間弱の利用停止で完了させることができました。

実際の処理性能

さて本題の、新Netezzaと旧Netezzaの処理性能比ですが、単純な処理の処理時間実測値で比較してみます。

Netezza処理時間実測値

単純な検索処理ではスペック上のDB内部処理性能比約7倍で実行されるのが確認できました。一方、ロード処理の性能比が悪く見えるのは、実は元ファイルが約6,000個に分割されているためファイルハンドリングのオーバーヘッド込みの処理時間であることに起因すると考えています。

もう１つ、少しアドテクっぽいクエリ処理時間も載せておきます。 我々は解析活動のアウトプットとしてオーディエンスのセグメント分類データを多数保持しており、そのデータとログと掛けあわせる分析をよく行います。SELECT文の構造は２テーブルの内部結合というだけですが、数億行ｘ数億行の巨大テーブル同士の結合になることも日常茶飯事で、処理速度は解析処理業務効率に大きく影響します。 一例として、10億の広告配信ログテーブル IMPRESSION_LOG と、4億のオーディエンスを8つのセグメントに分類したセグメントグループテーブル SEGMENT_GROUP777 を取り上げ、時間帯別・セグメント別インプレッション数集計をクロス表形式に出力してみます。 共通フィールド COOKIE_ID が結合キーとなります。オーディエンスは 1から8 までのセグメントに分類されています。

【テーブル定義】
　IMPRESSION_LOG   ( TIME, COOKIE_ID, ... )
　SEGMENT_GROUP777 ( COOKIE_ID, SEGMENT_ID, ... )

時間帯別・セグメント別インプレッション数を求めるSELECT文は以下のようになります。

SELECT
   HOUR( A.TIME )                                       AS HOUR
  ,SUM( CASE WHEN B.SEGMENT_ID = 1 THEN 1 ELSE 0 END )  AS SEGMENT1
  ,SUM( CASE WHEN B.SEGMENT_ID = 2 THEN 1 ELSE 0 END )  AS SEGMENT2
  ,SUM( CASE WHEN B.SEGMENT_ID = 3 THEN 1 ELSE 0 END )  AS SEGMENT3
  ,SUM( CASE WHEN B.SEGMENT_ID = 4 THEN 1 ELSE 0 END )  AS SEGMENT4
  ,SUM( CASE WHEN B.SEGMENT_ID = 5 THEN 1 ELSE 0 END )  AS SEGMENT5
  ,SUM( CASE WHEN B.SEGMENT_ID = 6 THEN 1 ELSE 0 END )  AS SEGMENT6
  ,SUM( CASE WHEN B.SEGMENT_ID = 7 THEN 1 ELSE 0 END )  AS SEGMENT7
  ,SUM( CASE WHEN B.SEGMENT_ID = 8 THEN 1 ELSE 0 END )  AS SEGMENT8
FROM
  IMPRESSION_LOG    A
 ,SEGMENT_GROUP777  B
WHERE A.COOKIE_ID = B.COOKIE_ID
GROUP BY
   HOUR( A.TIME )
ORDER BY
  1
;

得られたクロス表をセグメントごとの全体に対する割合に変換してヒートマップにしたものが以下の表です。（割合変換とヒートマップはExcelでの作業です。）早朝、昼間、夕方、深夜の時間帯などにセグメント間のアクセス傾向の違いを見て取れます。 heatmap

さて肝心のクエリ処理時間ですが

Netezza処理時間実測値2

と計測されました。10億×4億 のデータ量であることを考えれば旧Netezzaでも十分高速ですが、新Netezzaでは「DB処理性能比」に匹敵する処理時間短縮が実現されています。我々はこのようなクエリを日常的に実行しており、このような素晴らしくよいDBレスポンスに対し、今では何の驚きも感じなくなってしまいました。。。

終わりに

巨大データベース(Netezza)のリプレイスに関して、新旧データベースの性能比較と引越作業の注意点や工夫について書かせていただきました。別の機会に、Netezzaをパフォーマンス良く利用するためのコツなどご紹介できればと思います。