Snowflake の データレイクエクスポートを早速使ってみた！

この記事は[Snowflakeアドベントカレンダー](https://adventar.org/calendars/5085)の15日目の記事です。

# Snowflake使ってますかーー？？？

**Snowflakeのおかげで運用コストや気を使うところが減ってとても助かっているのはだれでしょう？
そう私です。**


# 今日のエピソード

たまにSnowflakeからS3などにデータを出力することを強いられることってありますよね？


偉い人「ちょっと、菱沼くん、Snowflakeに入ってるデータをHiveのパーティション形式で書き出しといてよ」
私（わかりました！）「**めんどくせー、なんでわざわざSnowflakeに入ってるデータを外に出すんだよ…**」

はい、こういうこと日常的にありますよね？
これまでだと、よいしょっと言う感じでなんかいい感じのソリューションを引っ張り出してきて書き出したり、変換してたんですが、それも今日でおしまいです！

# 今日ご紹介したいのは…

これ
[DATA LAKE EXPORT PUBLIC PREVIEW IS NOW AVAILABLE ON SNOWFLAKE](https://www.snowflake.com/blog/data-lake-export-public-preview-is-now-available-on-snowflake/)

**データレイクエクスポートがパブリックレビューになったよ！**

どんな機能なのかと言うと

1. Hive形式のパーティションで書き出せるようになった。オプション例：`partition by ('year=' || year_col || '/date=' || date_col)`
    - =>**これだ！これが欲しかったんだ！！**
2. 1ファイルサイズを最大サイズを指定できるようになった。オプション例： `max_file_size = 512000000`
    - =>**これで色々遊べそうだぞ！！**
3. ファイル名にジョブIDが含まれるようになった。
    - =>**サポートで便利！！**

というわけです。

# 早速使ってみましょう

今回使用した環境

|項目|値|
|---|:-:|
|ウェアハウス|XS|
|ソーステーブル|外部テーブル|
|ソーステーブルの物理サイズ|10GB|
|ソーステーブルの行数|29,150,283行|
|ソーステーブルのロケーション|S3(東京リージョン)|
|アンロード先のロケーション|S3(東京リージョン)|

まずは、一発ドンと、ソーステーブルを新機能を使わずにアンロードしてみます。

```
COPY INTO @churadata_output_test/auto/
FROM (
    select * from "CHURADATA_DB"."PUBLIC"."HOGE"
    where dt = '2020-07-20'
)
FILE_FORMAT = parquet_auto_format
;
```

|項目|値|
|---|:-:|
|実行時間|2分3秒|
|input_bytes,output_bytes|6,532,309,385(6.5GB)|
~~あれ、元のファイルよりだいぶ小さくなったな。すごい。本題じゃないから割愛~~
S3を見に行くと1ファイルはデフォルトの**16MB**でした。
![S3_Management_Console-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75613/0220d740-54c8-ce3f-6198-3fdb68567343.png)

よく見るとファイル名に数字が振られてますね。これがジョブIDかな？

# Hiveパーティション形式で書き出しみましょう！

```
COPY INTO @churadata_output_test/part/
FROM (
    select * from "CHURADATA_DB"."PUBLIC"."HOGE"
    where dt = '2020-07-20'
)
partition by ('dt=' || dt)
FILE_FORMAT = parquet_auto_format
;
```

**Hiveパーティションの指定をしても、指定しなかったときと比べて、クエリの実行時間は変わりませんでした。**

|項目|値|
|---|:-:|
|実行時間|2分5秒|
|input_bytes,output_bytes|6,532,309,385(6.5GB)|

そしてちゃんとHive形式のパスに格納されています！
![S3_Management_Console-5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75613/6b2e001b-a219-eb2b-911e-9fedc2fed0f6.png)
![S3_Management_Console-7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75613/715d825a-3801-cd51-38fc-172d105d2808.png)

先ほどとはファイル名の命名規則が少し変わって、長い名前になりました。これがジョブIDなのでしょうか？


# max_file_size を使って見ましょう！

`max_file_size` を設定するとパフォーマンスが変わったりするんでしょうか？

```
COPY INTO @churadata_output_test/part_32/
FROM (
    select * from "CHURADATA_DB"."PUBLIC"."HOGE"
    where dt = '2020-07-20'
)
partition by ('dt=' || dt)
FILE_FORMAT = parquet_auto_format
max_file_size = 32000000
;
```

結果はこんな感じになりました

|max_file_size|実行時間|実際のファイルのサイズ|
|---|:-:|:-:|
|32000000|1分 53秒|30.7 MB|
|64000000|1分 53秒|61.1 MB|
|128000000|1分 50秒|122.6 MB|
|256000000|1分 53秒|244.1 MB|
|512000000|1分 52秒|384.4 MB|
|1024000000|1分 51秒|384.8 MB|
|2048000000|1分 51秒|385.5 MB|

うぉ、意外なことに、6GB程度のテーブルサイズでは、20ファイル程度にしかならず、1ファイルの容量が400MBまで届きませんでした。

ただ、どれも `max_file_size` を指定しないよりもすこしだけ高速にアンロードができています。


# 終わりに

これで冒頭のエピソードに合ったような、Hive形式で書き出してくれ！（Sparkで処理した！）
って時でもばっちりですね！

Snowflakeの新機能が待ち遠しいです！

**早く Snowpark 使いたーい！**