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

2016/09/13 - データベース, ビッグデータ Presto, Treasure Data, ビッグデータ

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

Treasure Dataでは時系列のデータを効率よくあつかうため、timeカラムが固定インデックスとなっており、3600秒（1時間）ごとのパーティショニングに分けてインポートされます。この性質を利用して、時系列で格納する必要のないデータについては「セグメントID * 3600」「カテゴリID * 3600」のようにマスタのキー値を元に作成した時間を設定することで値が高速に取得できるようになります。

検証のためにtimeカラムをセグメントIDとして設定したテーブルを作成します。テーブル作成の元ネタはセグメントとユーザーのM：N対応を縦持ちで持つテストデータで、総行数は約8億行あります。

-- timeカラムをセグメントID * 3600の設定
INSERT INTO TABLE tmp_segment_time_test
SELECT
segment_id * 3600 time,
segment_id,
tuuid
FROM
segment_data

-- timeカラムをセグメントID * 3600の設定

INSERT INTO TABLE tmp_segment_time_test

SELECT

segment_id * 3600 time,

segment_id,

tuuid

FROM

segment_data

指定したふたつのセグメント同士の重複ユーザー数を抽出してみましょう。

-- segment_idでセグメントを指定
SELECT
COUNT(distinct t1.tuuid)
FROM
(SELECT tuuid FROM tmp_segment_time_test t1 WHERE segment_id = 61306) t1
INNER JOIN (SELECT tuuid FROM tmp_segment_time_test t1 WHERE segment_id = 51486) t2
ON t1.tuuid = t2.tuuid

-- segment_idでセグメントを指定

SELECT

COUNT(distinct t1.tuuid)

FROM

(SELECT tuuid FROM tmp_segment_time_test t1 WHERE segment_id = 61306) t1

INNER JOIN (SELECT tuuid FROM tmp_segment_time_test t1 WHERE segment_id = 51486) t2

ON t1.tuuid = t2.tuuid

Presto計算ログ（1分36秒）

-- memory:1.02GB, peak memory:10.22GB, queued time:1.24ms
20160816_145600_04229_uspws                                                                                                        1.60m           rows  bytes bytes/sec done   total             
[0] output &lt;- aggregation &lt;- [1]                                                                                                   FINISHED          10    90B  15.0KB/s    1 /     1             
 [1] aggregation &lt;- aggregation &lt;- [2]                                                                                             FINISHED      36,657  1.8MB  23.5MB/s   60 /    60             
  [2] aggregation &lt;- project &lt;- innerjoin &lt;- left:project &lt;- filter &lt;- aone_odessa_dev.tmp_segment_time_test &lt;- right:remoteSource FINISHED 951,752,677 24.6GB  39.4MB/s  110 /   111 [*] FullScan
   [3] project &lt;- filter &lt;- aone_odessa_dev.tmp_segment_time_test                                                                  FINISHED 810,615,799 17.5GB  21.2MB/s   61 /    61 [*] FullScan
finished at 2016-08-16T14:57:36Z

-- memory:1.02GB, peak memory:10.22GB, queued time:1.24ms

20160816_145600_04229_uspws 1.60m rows bytes bytes/sec done total

[0] output <- aggregation <- [1] FINISHED 10 90B 15.0KB/s 1 / 1

[1] aggregation <- aggregation <- [2] FINISHED 36,657 1.8MB 23.5MB/s 60 / 60

[2] aggregation <- project <- innerjoin <- left:project <- filter <- aone_odessa_dev.tmp_segment_time_test <- right:remoteSource FINISHED 951,752,677 24.6GB 39.4MB/s 110 / 111 [*] FullScan

[3] project <- filter <- aone_odessa_dev.tmp_segment_time_test FINISHED 810,615,799 17.5GB 21.2MB/s 61 / 61 [*] FullScan

finished at 2016-08-16T14:57:36Z

指定のセグメントだけを取りたいのにテーブルに対するフルスキャンが走っており、ピークメモリ使用量も大きくなっています。これに対してtimeカラムでセグメントIDを指定してみます。

-- timeでセグメントを指定
SELECT
COUNT(distinct t1.tuuid)
FROM
(SELECT tuuid FROM tmp_segment_time_test t1 WHERE time = 61306 * 3600) t1
INNER JOIN (SELECT tuuid FROM tmp_segment_time_test t1 WHERE time = 51486 * 3600) t2
ON t1.tuuid = t2.tuuid

-- timeでセグメントを指定

SELECT

COUNT(distinct t1.tuuid)

FROM

(SELECT tuuid FROM tmp_segment_time_test t1 WHERE time = 61306 * 3600) t1

INNER JOIN (SELECT tuuid FROM tmp_segment_time_test t1 WHERE time = 51486 * 3600) t2

ON t1.tuuid = t2.tuuid

Presto計算ログ（20秒）

-- memory:1.03GB, peak memory:1.03GB, queued time:446.46us
20160816_145219_04225_uspws                                                                                                        19.54s         rows  bytes bytes/sec done   total                                                   
[0] output &lt;- aggregation &lt;- [1]                                                                                                   FINISHED          0     0B      0B/s    0 /     1                                                   
 [1] aggregation &lt;- aggregation &lt;- [2]                                                                                             FINISHED          0     0B      0B/s    0 /    60                                                   
  [2] aggregation &lt;- project &lt;- innerjoin &lt;- left:project &lt;- filter &lt;- aone_odessa_dev.tmp_segment_time_test &lt;- right:remoteSource FINISHED 14,391,787  712MB   121MB/s    5 /     6 [1976-12-29 10:00:00 UTC, 1976-12-29 10:00:00 UTC)
   [3] project &lt;- filter &lt;- aone_odessa_dev.tmp_segment_time_test                                                                  FINISHED 14,127,595  306MB  21.4MB/s    1 /     1 [1975-11-16 06:00:00 UTC, 1975-11-16 06:00:00 UTC)
finished at 2016-08-16T14:52:39Z

-- memory:1.03GB, peak memory:1.03GB, queued time:446.46us

20160816_145219_04225_uspws 19.54s rows bytes bytes/sec done total

[0] output <- aggregation <- [1] FINISHED 0 0B 0B/s 0 / 1

[1] aggregation <- aggregation <- [2] FINISHED 0 0B 0B/s 0 / 60

[2] aggregation <- project <- innerjoin <- left:project <- filter <- aone_odessa_dev.tmp_segment_time_test <- right:remoteSource FINISHED 14,391,787 712MB 121MB/s 5 / 6 [1976-12-29 10:00:00 UTC, 1976-12-29 10:00:00 UTC)

[3] project <- filter <- aone_odessa_dev.tmp_segment_time_test FINISHED 14,127,595 306MB 21.4MB/s 1 / 1 [1975-11-16 06:00:00 UTC, 1975-11-16 06:00:00 UTC)

finished at 2016-08-16T14:52:39Z

実行時間が20%程度になり、ピークメモリ使用量も10%程度に削減されています。timeカラムインデックスを利用しているため、セグメントIDが「1975-11-16 06:00:00 UTC」という扱いになっています。timeカラムインデックスを利用した格納・取得方法はHiveでもPrestoでも効きますので、時系列に格納する必要性のないデータについては、マスターデータのキーをtimeとして指定しながら格納することで高速な抽出ができるようになります。もちろん結果値は同等です。

注意点としてはtimeはBigInteger型であり、日付型としても扱われることから1億年と2000年前から検索するといった事はできません。このような値をtime値を格納すると正常にパーティショニングされず、timeを利用していないクエリについても正常に取得できなくなる可能性があります。このため大きなID番号を取り扱う際には「time * 3600」ではなく「time * 360」としたうえでセグメントIDとの複合キーにするなど、適切な範囲で散らばるようにIDをグルーピングすべきです。

以上、Treasure Dataで大規模なマスタデータを扱う際にはtimeカラムインデックスが利用できるというTIPSでした。

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

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

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

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

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

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

: HyperLoglogでcount distinctを速くする

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

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

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

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

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

: fastavroとjqでAVRO形式のファイルからデータを取得しよう

AVRO形式のファイルを取り扱いたい AVROとはApacheプロジェクトのひとつとして開発されているデータ交換形式です。　コンパクトなバイナリで高速なシリアライズ・デシリアライズが行えるため、サーバーログなどに利用されています。弊社内での一部システムのログデータにも利用されているのですが、専用の …

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

はじめにビッグデータ解析部でオーディエンスデータ解析基盤の開発、運用を担当している Mike です。弊社ではインターネット広告配信ログをはじめとする「ビッグデータ」と呼ぶにふさわしいデータボリュームを扱うオーディエンスデータ解析基盤を構築しています。今秋、そのうちの１構成要素である、データサイズ …

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

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

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

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

PREV: [GoogleCloudPlatform]インタビュー記事が掲載されました！
NEXT: 第1回 DACライトニングトーク選手権開催！

Tom-N@ck	etrojan	skryo
taisuke-oomi	ryo	matsuari
忍ゑ	takusan	kazrin3
sae	jotaka	Rhiannon
tomoaki-ueda	yosuke-fukumoto	KTBT
hama	Mike	ダーハラ
yuka	yamaken	k-hal
kumata	SHIN-ICHI	鈴幸
shingo-tateishi	T氏	gicogico
pi★shi	OKAMOTO, Nau	shunpei-ishida
たにぐち	ウッディー	waku
matsudasyo	kaho-ikeda	Oyaman
Kiyoshi Ohno	aki	クラヴマガ

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

関連記事