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


はじめに

ビッグデータ解析部でオーディエンスデータ解析基盤の開発、運用を担当している 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エンジニア採用情報

  関連記事

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

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

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

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

Google BigQuery / Tableauを使ってみた

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

no image
いま必要なのは「アナリティクスアプローチ」

こんにちは。 ビッグデータ解析部のakiです。 解析部で、Markezineでの連載をはじめましたのでご紹介です。 いま必要なのは「アナリティクスアプローチ」、ビッグデータ活用の課題とこれから (http://markezine.jp/article/detail/21293) マーケターのかた向け …

no image
Treasure Dataで長期間の集計

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

HyperLoglogでcount distinctを速くする

こんにちは。俺やで。 HyperLoglogについて書きます。おもしろいです。名前が。 ■1. HyperLoglogとは? count distinctを速くするアルゴリズム 以前、Minhashについて書きました。 (Treasure Dataさんのブログにも載せていただきました。ありがとうござ …

GoogleスプレッドシートからTreasureDataへデータを取り込む

AudienceOneの開発を担当しています。skryoです。 またまたTreasureDataネタですが、今回はGoogleスプレッドシートからGoogleAppsScriptを使ってTreasureDataへデータを取り込む手順を紹介したいと思います。 なぜ? Googleスプレッドシート上でマ …

【入門編】TreasureDataでサイトのアクセス解析をしてみた~第2弾!~

今回もやります、集計クエリ解説シリーズ第2弾!! 前回は、Webログからセッション単位のデータを作成するだけでした。 第2弾では作成したテーブルを元に、より実践的なアクセス解析、サイト分析で使えるHiveQLについて、実際に使用したクエリとともに解説していきたいと思います。 今回やったこと 利用した …

Amazon ElastiCache/Redisのパフォーマンス確認

はじめに こんにちは、AudienceOne開発部です。AudienceOne開発部ではいわゆるビッグデータと呼ばれる大量のデータをアドホックあるいは定常的に日々ETLだの集合演算だのをする一方で、様々な大規模データ処理ソリューションを継続的に検証しております。 本記事は、その中でもユーザが保持して …

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

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