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


はじめに

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

  関連記事

Amazon Redshiftのパフォーマンスチューニング #1 アーキテクチャ概要

ご挨拶 こんにちは。システム開発部の中村です。 現在新卒入社2年目で、普段は受託開発の要件定義等の業務が主担当だったりします。 このブログの発起人というか、まあ言い出しっぺという事で初稿を上げさせて頂きます。 今回はAmazon Web ServiceのDWHサービス、Redshiftのパフォーマン …

HyperLoglogでcount distinctを速くする

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

Treasure Dataの新機能(Data Tank)をAudienceOneのレポート機能で利用した話

Data Tankとは? Treasure Dataの新機能でTreasure Dataのプラットフォーム上に構築されたデータマートです。 Tableau等のBIツールとの接続を想定されており、AWSでいうところのRedshift的なものだと考えるとわかりやすいかと。 Data TankはPostg …

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

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

PyStanによるはじめてのマルコフ連鎖モンテカルロ法

はじめに こんにちは。システム開発部の中村です。 社内で行っている『データ解析のための統計モデリング入門』(所謂緑本)の輪読会に参加した所、 大変わかりやすい本だったものの、Macユーザには悲しい事に実装サンプルがWinBUGSだったため、 9章の一般化線形モデルのベイズ推定によるアプローチをPyt …

Google BigQuery / Tableauを使ってみた

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

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

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

Treasure Dataで大規模なマスタデータを扱う際にはtimeカラムインデックスを活用しよう

DACではTreasure Dataを利用して各種データの蓄積や集計を行っています。Treasure Dataは時系列のデータを扱うのに特にすぐれたアーキテクチャなのですが、セグメントIDとユーザーIDの組み合わせといった大量のマスタデータを利用した計算にも利用することもできます。そのような場合にt …

no image
Treasure Dataで長期間の集計

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

GoogleAppsScriptとTreasureData REST APIを使ってサーバレスにTwitterのデータを取得

またまたTreasureDataネタです。 ただ、今回はクエリ系のネタではなく、GoogleAppsScriptとTreasureDataのREST APIを使ってTwitterのデータをTreasureDataに入れてみたので、その方法を紹介したいと思います。 はじめに ログデータだけではなく、公 …