TreasureDataのtd import:prepare機能の比較検証

★★★ お知らせ ★★★

◆ 6月のPS Liveは決済サービスStripeのデモ!◆
決済サービスのStripeでサブスクリプションの支払い機能を作ってみた
Stripeの機能の一部を切り出して、簡単なサブスクリプションを作るとどうなるのかを、デモをまじえてご紹介します。
⇒ 詳細はこちらから

◆【セミナー開催】 可視化ツールGrafana~初めてのダッシュボード作成◆
デモンストレーション付き!
本セミナーでは、売上データを用いて、4種類のパネル作成方法をお見せします。
⇒ お申込みはこちらから

◆ エンジニア業務環境アンケート結果 ◆
エンジニアが自分の働き方にどういったことで満足していて、不満を感じているのか、働きたい会社像として何を求めているのか、業務環境調査を実施しました。ぜひご覧ください。
⇒ アンケート結果はこちらから

まだまだ暑さは続いておりますが、いかがお過ごしでしょうか。 SSTDの高橋です。

先日、データサイエンティスト養成読本を個人的に購入しました。 まだ読み終わってはいませんが、せっかく購入したので、こちらの「Data Scientist Casual Talk in 白金台」に参加する予定です。 参加される方はどうぞよろしくお願い致します。 書籍自体はログ収集からログ解析まで幅広い内容をサポートしているので、非常に勉強になりそうです。また、書籍内でも紹介されているfluentdは、過去のブログ記事でも紹介したことがありましたが、リアルタイムログ収集ツールとして非常に有用です。そのため、今後の本ブログでも詳しく紹介していきたいと思います。

1

 

さて、それではブログの内容に入ります。 今回は、tdの0.10.84から実装されたtd import機能について紹介していきます。

td import機能とは

これまでTreasureDataに100MB以上のファイルをアップロードする際には、bulk_import機能を利用することが推奨されてきました。 しかし、tdのbulk_import機能は、データ圧縮などのCPUをフルに利用する場面での処理速度に課題がありました。 そのため、0.10.84以降からJavaによって新たに開発されたtd import機能が実装されました。 これによって、皆様のお手持ちのデータをよりスピーディーにTreasureDataへのアップロードが可能となります。

さて、td import機能の中でもmsgpackへのデータ圧縮を行うtd import:prepare機能に今回は焦点を当て、どの程度処理速度が向上したかを比較してみたいと思います。 比較対象として、td bulk_import:prepare_partsを利用します。 利用方法については、bulk_importとほぼ同様のため、こちらのドキュメントを参照して頂きたいと思います。

検証環境

今回は、表2で示す検証用データをAWS S3上に用意していたため、AWS EC2を用いて検証を行いたいと思います。

表1. 実行環境(AWS)
インスタンスt1.small
OSAmazon Linux 64bit
コア数1 ECU(1 ECU × 1仮想コア)
メモリ1.7 GB
root volumeEBS 100 GB
Ruby version1.9.3
td version0.10.86
表2. データセット
データの内容wikipediaのpageviewの統計情報2011年11月1日~5日
データサイズ約 35 GB
ファイル数120ファイル(1月1日0時から1月5日23時まで)
レコード数約 5.2 億行
平均ファイルサイズ約 296 MB
カラムヘッダーprojectcode, pagename, pageviews, bytes, time(ファイル名から時刻を抽出を行い、UnixTimeに変換した時刻を追記)
カラム例“aa.b”, “Main_Page”,”54″, “874168”,1294056000
<利用するコマンド>

$ td import:prepare ./wiki/*.tsv --format tsv \
--columns projectcode,pagename,pageviews,bytes,time \
--time-column 'time' -o ./out_prepare/

$ td bulk_import:prepare_parts ./wiki/*.tsv --format tsv \
--columns projectcode,pagename,pageviews,bytes,time \
--time-column 'time' -o ./out_bulk/

検証結果

表3. 検証結果(AWS)
機能import:preparebulk_import:prepare_parts
処理時間合計3時間10分21秒15時間15分27秒
処理時間平均95.175 sec457.725 sec
圧縮後の合計ファイルサイズ約 9.7 GB
2
 

結論

今回は、AWS EC2のsmallインスタンスで比較検証を行った結果、表3に示す結果が得られました。 処理時間自体は全体的にかかってしまっていますが、import:prepareとbulk_import:prepare_partsを比較してみると、処理時間を約5分の1短縮できていることが分かります。 このように性能向上を果たすためにどのような工夫をしているのかは、Githubでチェックしてみましょう。

皆様もご自身の環境で検証して頂き、処理速度が向上したことを体験して頂ければと思います。 以上、import:prepareの紹介を終わります。

アバター画像
About Kai 34 Articles
マーケティング業務を担当。セミナー、勉強会の企画運営、情報発信を行う。API事業を中心に、リード獲得、ナーチャリングに注力。
ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。


ご覧いただきありがとうございます。
ブログの最新情報はSNSでも発信しております。
ぜひTwitterのフォロー&Facebookページにいいねをお願い致します!



>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

Be the first to comment

Leave a Reply

Your email address will not be published.


*


質問はこちら 閉じる