[EXPORTER] Add support for gzip compression

[Haser0305]

#1822
目前增加參數 compression.type 使的 exporter 支援 gzip 壓縮方法，未來支援其他的壓縮演算法可以透過這個參數設定。
目前在建立 gzip 壓縮檔按時，有發現文件內容開頭會是 1f 8b ，因此沒有在針對寫出的檔案附加上 gzip 結尾。

[chia7712]

感謝新增此功能，不過我們在議題有提到說要寫入檔案的 metadata 這件事情有想法嗎？會在這個PR完成嗎

[Haser0305]

感謝新增此功能，不過我們在議題有提到說要寫入檔案的 metadata 這件事情有想法嗎？會在這個PR完成嗎

好的，那我接著在這 pr 處理寫入檔案 metadata 的部分。
那如果是在檔案結尾處的地方寫的話，那我在最後面新增一個 byte 來紀錄是哪種壓縮方式，如 1: gzip，這樣可行嗎？

[chia7712]

那如果是在檔案結尾處的地方寫的話，那我在最後面新增一個 byte 來紀錄是哪種壓縮方式，如 1: gzip，這樣可行嗎？

我覺得既然要新增 metadata 在檔案結尾了，可以順便思考一下還有哪些資訊可以一併放進去？例如：

1. 資料筆數
2. Topic partition 資訊
3. 壓縮格式
4. 其他等等

[Haser0305]

我覺得既然要新增 metadata 在檔案結尾了，可以順便思考一下還有哪些資訊可以一併放進去？例如：

1. 資料筆數
2. Topic partition 資訊
3. 壓縮格式
4. 其他等等

我目前預計在 metadata 放入以下資料

1. connector name：如果不同次備份內容混淆，可以依照此區分
2. topic partition 資訊：輔助上述功能
3. 1st record offset： 可以讓檔名與 offset 脫鉤
4. 1st record timestamp：與上面功能差不多，並且如果未來有需要還原時快速判斷檔案是否需要，可以用到
5. record count：紀錄檔案中包含多少筆資料
6. roll.duration：可以知道此檔案所包含的時間區間大概有多長
7. compression type：壓縮演算法名稱

感覺以上資料應該可以讓 exporter 備份出來的檔案可以更自由的處理，並且如古有要在 importer 端增加功能應該也可以靠 metadata 資訊先行處理。

如果上述資料可以的話，我應該會透過 protocol buffer 序列化後 放在檔案尾部，估計會透過 int 的 -1 來區分 data 跟 metadata

[chia7712]

估計會透過 int 的 -1 來區分 data 跟 metadata

不好意思，這句話我看不太懂？如果是要定位 metadata 的範圍，可以在檔案結尾保留一個整數長度來描述 metadata 的大小

[Haser0305]

估計會透過 int 的 -1 來區分 data 跟 metadata

不好意思，這句話我看不太懂？如果是要定位 metadata 的範圍，可以在檔案結尾保留一個整數長度來描述 metadata 的大小

因為有 topic partition，如果依照最大範圍給定的話 topic 需要給到 255Bytes，在想說固定會不會有點大。

再來現在有個問題是如果 metadata 放到尾部的話，有的 filesystem 不能使 inputstream 有 seek 的功能，這樣可能會有點難處理，不知是否可以將 metadata 放在檔案的頭部，這樣一開始先透過 protocol buffer parse metadata 後，接著都是 record 應該也就沒有這問題了。

[chia7712]

再來現在有個問題是如果 metadata 放到尾部的話，有的 filesystem 不能使 inputstream 有 seek 的功能，這樣可能會有點難處理，不知是否可以將 metadata 放在檔案的頭部，這樣一開始先透過 protocol buffer parse metadata 後，接著都是 record 應該也就沒有這問題了。

放在頭部的話，有些統計資訊就無法事先得知了？

[Haser0305]

放在頭部的話，有些統計資訊就無法事先得知了？

看起來好像是的，那就維持寫在檔案尾部，固定大小。
之後嘗試看看 inputStream 能不能 skip Bytes 到 metadata 的部分來讀取。
剛剛測試了一下在 local ftp 的情境下 skip 少數 byte 是沒有問題。

[chia7712]

剛剛測試了一下在 local ftp 的情境下 skip 少數 byte 是沒有問題。

可否確認一下 ftp protocol 是否有支援 seek ?

[Haser0305]

可否確認一下 ftp protocol 是否有支援 seek ?

依目前使用 retrieveFileStream 建立的 inputStream 可以透過 skipNBytes 來跳過前面的資料，目前幾次測試在200MB的資料中，可以跳到正確的位置上面。

[chia7712]

依目前使用 retrieveFileStream 建立的 inputStream 可以透過 skipNBytes 來跳過前面的資料，目前幾次測試在200MB的資料中，可以跳到正確的位置上面。

我比較擔心是只有特定的 ftp server 才支援這個功能，可否查一下 ftp 這個協定是否有明確說要支持 seek

[Haser0305]

我比較擔心是只有特定的 ftp server 才支援這個功能，可否查一下 ftp 這個協定是否有明確說要支持 seek

我剛剛看了一下 skipNBytes 他的實作方式是透過拋棄的方式來跳過的，因此跳到後面應該就跟下載完所有東西差不多。
因此現在改用 setRestartOffset 來跳過前面的資訊。

這方法需要在支援 REST command 的 ftp server 才行，有在 rfc959 中列出此命令，並在 rfc5797 中要求要有的基本指令中有包含 REST，從這邊判斷應該大部分的 ftp server 應該都支援 rest 功能的。

[chia7712]

這方法需要在支援 REST command 的 ftp server 才行，有在 rfc959 中列出此命令，並在 rfc5797 中要求要有的基本指令中有包含 REST，從這邊判斷應該大部分的 ftp server 應該都支援 rest 功能的。

ok 感謝確認 這樣應該就沒問題

[Haser0305]

目前測試下來，感覺 metadata 寫入的部分可能發另外一個 pr 處理會比較好。
現在要解決 data 壓縮但是 metadata 不壓縮來維持固定大小並寫入在同一個檔案中，以目前的 recordWriter 來說可能會需要改不少的地方，如一個 recordWriter 的多 outputstream（有無壓縮等） 管理，metadata 資訊傳遞到 recordWriter 的方式等。

[chia7712]

目前測試下來，感覺 metadata 寫入的部分可能發另外一個 pr 處理會比較好。

聽起來不錯，麻煩先開好議題

另外這隻PR就鎖定在一個壓縮上嗎？

[Haser0305]

聽起來不錯，麻煩先開好議題

#1830

另外這隻PR就鎖定在一個壓縮上嗎？

是的，這隻 pr 就針對一個任務中可以設定為透過 gzip 壓縮

[chia7712]

LGTM

[chia7712]

LGTM