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


はじめに

ビッグデータ解析部でオーディエンスデータ解析基盤の開発、運用を担当している Mike です。
弊社ではインターネット広告配信ログをはじめとする「ビッグデータ」と呼ぶにふさわしいデータボリュームを扱うオーディエンスデータ解析基盤を構築しています。今秋、そのうちの1構成要素である、データサイズ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 電源供給工事待ちでした。
1つ下のクラスの 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個に分割されているためファイルハンドリングのオーバーヘッド込みの処理時間であることに起因すると考えています。

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

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

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

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

Netezza処理時間実測値2

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

終わりに

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


DACエンジニア採用情報

  関連記事

ディープラーニングで「顔が似ているAKB48のメンバーを教えてくれるbot」を構築

概要 こんにちは、システム開発部の中村です。 今回は、Facebook Messenger APIを利用して、 画像をアップロードすると、似ているAKB48のメンバーを教えてくれるbotを実装しました。 尚、ディープラーニングやTensorFlowそのものの解説というより、 「エンジンとしてディープ …

【超入門】Hivemallで機械学習 〜Treasure Dataでロジスティック回帰編〜

こんにちは。俺やで。 ビッグデータとかデータサイエンティストとかいう言葉が未だブームですね。 (「データサイエンティスト」は下火か。) ビッグデータ扱えるエンジニアも、 統計解析ができるアナリストも、 どっちもできるスーパーマンも世の中にはたくさんいますが、 ビッグデータも統計解析も扱えるインフラは …

Google BigQuery / Tableauを使ってみた

TableauからGoogle BigQueryへ接続してみました。 弊社で利用しているTreasureDataからデータ出力してBigQueryへロード、Tableauから接続まで実際に行った手順について記載します。 TreasureDataからAmazonS3へデータ出力 まず、データが蓄積され …

no image
Treasure Dataで長期間の集計

プラットフォーム・ワン T氏です。プラットフォーム・ワンでは、DSPのMarketOneとSSPのYIELD ONE提供しています。 MarketOneやYIELD ONEのログを調査する場合にTreasure Dataを使うことがあります。Treasure Dataでは大量のデータに対してHive …

Tableau 9.2で郵便番号の特性を地図で可視化してみる

Tableau 9.2から郵便番号地図が表示可能に 弊社ではデータ分析ツールのTableauを利用しています。オーディエンスデータの重複を分析したり、デモグラフィック属性を表示したりするなどデータの可視化に役立ちますTableauでは9.2から日本の郵便番号を用いて地図を可視化できるようになりました …

気象予報士とビッグデータ解析の意外な関係

DACから気象予報士が誕生しました ビッグデータ解析部のMikeです。 2015年1月の気象予報士試験に合格し、めでたく4月からアドテク業界ただ一人(本当?)の気象予報士となりました 。 そんなわけで、今回は気象予報士とビッグデータ解析の関係についてお話したいと思います。 なぜ気象予報士を目指したか …

トレジャーデータの新機能「Data Connector」でクライアントレスなビッグデータ連携を実現する

トレジャーデータは、スキーマレスな大量のデータ(ビッグデータ)をパブリッククラウド上に保管して集計や抽出をするためのサービスなのですが、他システムからの連携データをトレジャーデータのテーブルに格納するまでが一苦労でした。 他システムとの外部連携を行う場合、一般的にローカルサーバー内のストレージを外部 …

D3.jsとその活用事例について

D3.jsとは? D3とは「Data Driven Document」の略で、データに基づいてドキュメントを操作するための JavaScript ライブラリです。 ご存知の方も多いと思いますが、ちょっとだけD3.jsの基本的な使い方、そして弊社プラットフォームでの利用についてご紹介したいと思います。 …

【入門編】TreasureDataでWEBログ分析をしてみた

この記事は Treasure Data Advent Calendar 2015 – Qiita の24日目の記事です。 こんにちは。 今回はWEBログの集計や解析をする際によく使うHiveQLのクエリと、UDF(User Defined Functions)について実際の集計クエリを使 …

【Hivemall入門】RandomForestで毒キノコ推定モデルを作る

こんにちは。俺やで。 今回も前回から間が空いてしましたが、ビッグデータに対応したHiveで使える機械学習ライブラリ、 Hivemallの使い方について、書かせていただければと思います。 なお今回はQiitaのTreasure Data / Advent Calender 2015の12/3日分として …