drill超簡単チューニング

®© 2016 MapR Technologies 1®© 2016 MapR Technologies 1MapR Confidential © 2016 MapR Technologies

®

Drill 1.4 超簡単パフォーマンスチューニング板垣輝広 System Engineer, MapR technologies2016/3/22

®© 2016 MapR Technologies 2®© 2016 MapR Technologies 2MapR Confidential

MapR Drill 1.4 超簡単パフォーマンスチューニング• Parquet（パーケ）ファイル• Parquetパーティションプルーニング• Parquetメタデータキャッシュ


1.ParquetファイルParquet は列⽅向にデータ変換しバイナリ形式でファイルに格納します。また、カラム情報であるメタデータも同時に格納するために、読み出し時に外部のスキーマ情報に頼る必要がありません。• Parquetの利点は⼀般的なカラムナストレージと同様、列⽅向にデータを保存して読み

出せるため、必要なデータのみをすばやく読み取ることができることです。• また、列⽅向には同⼀型のデータが並んでいるため⾼い圧縮率が適⽤可能で、それが

データ容量の節約とさらなるデータ読み取りの⾼速化に貢献することなどです。

http://www.slideshare.net/julienledem/th-210pledem?related=1


Parquetフォーマットテーブルの作成

http://parquet.incubator.apache.org/documentation/latest/

• Create table as selectでファイルからテーブルを再作成するだけでパーケフォーマットでデータを格納します。（デフォルトがパーケフォーマットです）

create table dfs.tmp.orders_tableasselect * from dfs.`/DATA_TSVH/orders.csv`;

作成例

カラム１のデータ

カラム2のデータ

メタデータ


2.パーティション・プルーニング• CREATE時に指定したパーティションキーに基づき、同じデータを持つレコードは同じファイルに格納することでWhere条件で指定されたデータを格納するファイルのみをスキャンします。

create table dfs.tmp.orders_tablepartition by ( o_orderdate ) as select * from dfs.`/mapr/demo.mapr.com/TPCH/DATA_TSVH/orders.csv`;

パーティションテーブル作成例


パーティション・プルーニングのPlan出力

EXPLAIN PLAN for select * from test_parquet1 where O_ORDERDATE = '1992-06-03';+------+------+| text | json |+------+------+| 00-00 Screen00-01 Project(*=[$0])00-02 Project(*=[$0])00-03 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=/tmp/test_parquet1/0_0_53.parquet]], selectionRoot=maprfs:/tmp/test_parquet1, numFiles=1, usedMetadataFile=false, columns=[`*`]]])

アクセスプランの確認例:

１ファイルにのみアクセス


3.Parketメタデータのキャッシュ• Parquet フォーマットのテーブルにおいてアクセスするファイル数が多い場合、メタデータをキャッシングすることでquery-planning phaseのパフォーマンスの向上が期待できます。(数千ファイル以上の場合など）

• REFRESH TABLE METADATAコマンドでテーブルのルートディレクトリを指定してキャッシュファイルを作成します。

• 一度キャッシュされたメタストアデータは全セッションで有効です。

• Parquetファイルに対する変更があった場合は、最初のクエリ実行時に動的にファイルを再作成します。

0: jdbc:drill:zk=maprdemo:5181> REFRESH TABLE METADATA dfs.tmp.test_parquet1;コマンド実行例

$ ls -afltr-rwxr-xr-x 1 mapr mapr 3869602 3月 12 10:42 1_8_9.parquet-rwxr-xr-x 1 mapr mapr 6369606 3月 12 10:42 1_3_3.parquet-rwxr-xr-x 1 mapr mapr 146423 3月 12 11:56 .drill.parquet_metadata-rwxr-xr-x 1 mapr mapr 6249975 3月 12 10:42 1_7_5.parquet-rwxr-xr-x 1 mapr mapr 6341667 3月 12 10:42 1_3_4.parquet

件数/データタイプ/NULL値の有無等の情報を格納

手動でファイル削除することで設定を無効化できます。


Parquetメタデータのキャッシュの確認

EXPLAIN PLAN for select * from test_parquet1 where O_ORDERDATE = '1992-06-03';+------+------+| text | json |+------+------+| 00-00 Screen00-01 Project(*=[$0])00-02 Project(*=[$0])00-03 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath[path=/tmp/test_parquet1/0_0_53.parquet]], selectionRoot=/tmp/test_parquet1, numFiles=1, usedMetadataFile=true, columns=[`*`]]])

アクセスプランの確認例

キャッシュしたメタデータを使用


Parquetメタデータのキャッシュの効果• テーブルを構成するParquetファイルの数が多い場合に効果的です。

• Parquetフォーマットでは各ファイルにメタデータを保持しているため、アクセスするファイル数が多くなるに従いオーバーヘッドが増加しますが、キャッシングによりオーバヘッドを削減できます。（検証では1000 parquet ファイルで約1秒程度）

• 特にTableau(BIツール）からのDrill ODBC経由での接続時には、SQL構文解析フェーズでLimit 0句のクエリを内部発行しますので応答時間が改善されます。


Partition pruning + MetaData Cacheの効果seconds

selectl_returnflag,l_linestatus,sum(l_quantity) as sum_qty,sum(l_extendedprice) as sum_base_price,sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,avg(l_quantity) as avg_qty,avg(l_extendedprice) as avg_price,avg(l_discount) as avg_disc,count(*) as count_orderfromlineitemwherel_year = ‘1996’ and l_month = ‘01’ group byl_returnflag,l_linestatusorder byl_returnflag,l_linestatus;

Amazon EC2 X3.large (2 vcpu / 15GB memory) × 3 nodes12GB text data (1億件) total 840 files

総ファイル数が800程度であったためMetaDatacaheの効果はあまり得られませんでしたが、Partition pruningにより大幅に応答時間が向上

0

10

20

30

40

50

60

70

CSV Parquet Parquet+Cache

FULL Scan( 84 months) - 12GB 1Month Scan- 150MB

59.854.7

29.4

2.3

28.1

1.5


Q & A@mapr

[email protected]

Engage with us!

mapr-technologies

drill超簡単チューニング

Technology