X

Big Data、Data Integration、Data Lakeに関するテクノロジー、製品・サービス情報、セミナー情報などをお届けします

ADWからObject StoreのParquetファイルにアクセスしてみる

突然ですが、みなさんパルケってますか?
Big Data界隈では、すっかりお馴染みのApache Parquetですが、実は最近OracleDBとも仲良しになってきました。今日は、Autonomous Data Warehouse (以下 ADW)の外部表としてObject Storeに置いてあるParquetファイルを参照する方法をご紹介したいと思います。
そもそも、Parquetとは何かという方向けに簡単に説明をしておきます。列志向で圧縮され、かつIndexも保持できるファイルフォーマットで、まるでデータベースのようなファイルです。列方向にデータを取り出すことができるため、大きなデータから少数の項目を取り出すBI的な用途に向いているため、データレイクに格納されたデータを加工し、分析用に渡す時のフォーマットとして非常に人気があります。
ところで余談ですが、これ日本語だと何て読むのでしょうか。(Apacheあるある)
日本のお客様やSIerの方は「パーケ」と呼んでいる方が多い気がします。
弊社USのメンバーは「パーケッ」とか「パークィ」発音しているように聞こえます。しかし、EMEAのメンバーの中には「パルケト」(おそらくスペイン語?)と発音している人がいて、私的にはそれがカッコよく聞こえたので「パルケッ」と呼んでいます。そのため、Parquet化することを「パルケる」と2年ぐらい言い続けてきたのですが、日本オラクル社内ですら流行らないので「パーケ」派に改宗しようかと悩んでいます。

さて、本題に戻ります。

1.サンプルデータのダウンロード
まずは、チュートリアル用のデータですが、ADWのサンプルデータをparquetに変換されたものを用意しています。(ここからダウンロード可能)
このファイルは、OracleのBig Data Cloud Service上でHiveにより作成しました。

create table sales_extended_parquet stored as parquet as select * from sales_extended_csv

 
Hiveの環境なんてないんですど!という方は、pythonでpyarrow.parquetを使うことで簡単にparquetファイルを作成できます。

 import pandas as pd
 import pyarrow as pa
 import pyarrow.parquet as pq

 df = pd.read_csv('sales_extended.csv')
pq.write_table(df,'sales_extended.parquet')

 

2.Parquetファイルの確認
CSVファイルであれば、様々なツールでレイアウトを確認できますが、parquetの場合は「parquet-tools」を利用します。(gitからダウンロードできます)

サンプルデータ「sales_extended.parquet」のスキーマを確認

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ parquet-tools schema sales_extended.parquet
 
message hive_schema {
  optional int32 prod_id;
  optional int32 cust_id;
  optional binary time_id (UTF8);
  optional int32 channel_id;
  optional int32 promo_id;
  optional int32 quantity_sold;
  optional fixed_len_byte_array(5) amount_sold (DECIMAL(10,2));
  optional binary gender (UTF8);
  optional binary city (UTF8);
  optional binary state_province (UTF8);
  optional binary income_level (UTF8);
}

ファイルの先頭数行を確認

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
$ parquet-tools head sales_extended.parquet
 
prod_id = 13
cust_id = 987
time_id = 1998-01-10
channel_id = 3
promo_id = 999
quantity_sold = 1
amount_sold = 1232.16
gender = M
city = Adelaide
state_province = South Australia
income_level = K: 250,000 - 299,999
 
prod_id = 13
cust_id = 1660
time_id = 1998-01-10
channel_id = 3
promo_id = 999
quantity_sold = 1
amount_sold = 1232.16
gender = M
city = Dolores
state_province = CO
income_level = L: 300,000 and above
 
prod_id = 13
cust_id = 1762
time_id = 1998-01-10
channel_id = 3
promo_id = 999
quantity_sold = 1
amount_sold = 1232.16
gender = M
city = Cayuga
state_province = ND
income_level = F: 110,000 - 129,999

 

3.ADWのテーブル作成

このデータをADWから外部表で参照できるようにしていきましょう。
そのために、Object Storeにファイルを格納します。
ここでは、OCI上の「tutorial_load_adw」というバケットに保存します。

File listed in object store bucket

PL/SQLからこのバケットにアクセスするため認証トークンを使用して、credentialを作成します。
*事前にIDCS上でAuth Tokenを作成しておく必要があります。パスワード欄にはこのAuth Token作成時に提供されるものを入力してください。
*PL/SQLは、SQL*plusやSQL Developerからも実行できますが、ADWでは便利なノートブック機能を提供しており、Webブラウザ上でPL/SQLやSQLを記述することができます。

 
1
2
3
4
5
6
7
8
9
begin
  DBMS_CLOUD.create_credential (
    credential_name => 'OBJ_STORE_CRED',
    username => user@oracle.com',
    password => 'the-password'
  ) ;
 
end;
/

いよいよ外部表の作成です。
DBMS_CLOUDパッケージを利用して、テーブル名、credential、ファイルのURL、ファイルフォーマットを指定するだけで完成です。
*ファイルを指定すると、ADWはメタデータを読み取り自動でDDLを整形するためカラムの指定などは不要です(便利!)
*事前にcreate tableしておくことも可能です。
 カラム名が同じであれば自動マッピングされます(超便利!)

 
1
2
3
4
5
6
7
8
9
begin
    dbms_cloud.create_external_table (
       table_name =>'sales_extended_ext',
       credential_name =>'OBJ_STORE_CRED',
       format =>  '{"type":"parquet",  "schema": "first"}'
    );
end;
/

 

4.クエリしてみよう

テーブルの確認と抽出

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
desc sales_extended_ext;
 
Name           Null? Type           
-------------- ----- -------------- 
PROD_ID              NUMBER(10)     
CUST_ID              NUMBER(10)     
TIME_ID              VARCHAR2(4000) 
CHANNEL_ID           NUMBER(10)     
PROMO_ID             NUMBER(10)     
QUANTITY_SOLD        NUMBER(10)     
AMOUNT_SOLD          NUMBER(10,2)   
GENDER               VARCHAR2(4000) 
CITY                 VARCHAR2(4000) 
STATE_PROVINCE       VARCHAR2(4000) 
INCOME_LEVEL         VARCHAR2(4000)
 
select prod_id, quantity_sold, gender, city, income_level from sales_extended_ext where rownum < 10;

Results of query against parquet file.

通常のCSVファイルの外部表であれば、このファイルの11カラム全てをスキャンした後5つのカラムが選択される処理が実行されます。しかし、parquetファイルの場合、column pruningとpredicate pushdown機能により、最初から5つのカラムだけスキャンされるため、DBサーバに返されるデータ量が削減され、結果クエリのパフォーマンスが向上します。
以下の表は、parquetとCSVの場合でI/O量を比較したものです。

  1. parquetファイルから1つのカラムを抽出 3.36MB

  2. parquetファイルをフルスキャン(全てのカラムを抽出) 15.7MB

  3. CSVファイルから1つのカラムを抽出 59.13MB

  4. CSVファイルをフルスキャン(全てのカラムを抽出) 60.13MB
    フルスキャン同士の比較(2 vs 4)でI/O量に差があるのは、parquetの場合は圧縮機能により1/4のサイズになっているためです。

IO Results.  Queries against Parquet files minimize data movement.

いかがでしたでしょうか?
ADWは、Object Storeから直接データに簡単にアクセスすることが確認できましたね。
ここまで根気よく読んでいただけた方に、とっておきの情報を公開します。実は、、、この機能、さらなる進化が予定されています。
それはBig Data SQLとの融合です!
今のアーキテクチャは、外部表として読み取られたデータを内部的にOracle型にパースした後にSQL処理をDBサーバ上で行います。
このままでも十分なのですが、Exadataで言うところのcellサーバの機構を間に搭載する予定です。
背景を少し説明しておきますと、
DBに格納するデータは精々GB~TBですが、Object Storeには数百TB~PBクラスのデータが想定されます。この時に、ADWのサイジングはどうすべきでしょうか?PBを想定してADWのコア設定したのでは、せっかくのクラウドによるコスト削減効果が薄れてしまいます。
そんな時に、ADWが外部表としてObject Storeをクエリした際にサーバーレスなBig Data SQLに処理をオフロードすることでこの課題を解決できます。
ADWを過度にスケールアップすることなく、性能と安定性を維持することが可能になります。
そう遠くないタイミングで当機能はリリース予定ですので、乞うご期待ください。
そのために、今のうちから「パルケる」運用を始めていきましょう。

以上

本資料は、Oracle Big Data blog(https://blogs.oracle.com/datawarehousing/oracle-autonomous-data-warehouse-access-parquet-files-in-object-stores)を抄訳したものです。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha