クラウドで1200テーブル/dayのETLを低スペックなシステム(クラスター)で捌く時に考慮すること

この記事はデータ基盤 Advent Calendar 2020 20日目の記事になります

今回は、オンプレで動いていたHiveのJob2000Jobほどをクラウドに移行した時にクラウド貧乏にならないためにやったこと

を書いていこうと思います。

オンプレのクラスター

まず初めに、一台あたり以下のようなスペックのモンスターマシンがクラスターを形成していることが多いと思うのですが、私が担当していたシステム配下のようなスペックのマシンが連なっていました。

CPU　56
メモリ　500GB
ディスク　100TB

こんなマシンと同等スペックをクラウドに持っていこうものなら正直一瞬でクラウド貧乏になってしまいます。

現在では、クラウド移行した際にスペックを1/10くらいにして月20万くらいで1200テーブルくらいのETLを捌いて慎ましく運用を行っています。

元々

CPU　56
メモリ　500GB
ディスク　100TB
が10台

移行後

CPU　16
メモリ　32GB
ディスク　1.25 TB
が5台

ここで職人ごごろがくすぐられてしまって、いくつか対策を練ったのです。

対策その１. 後発のクエリエンジンに移行する

MRなど使っているクエリなどをであれば積極的にTezやSparkに移行しましょう。
移行したのにMR->MRでは移行したメリットありません。

現に、クラウド移行のついでにHive On Sparkに移行したのですが、それだけでも3倍くらい早くなりました。

あとはSparkに移行することによって、Hiveではできなかった、細かなチューニングができ様々なメリットを享受できます。

対策その2.parquetファイルフォーマットを使う

sparkの場合はparquetにしておけばまず間違い無いでしょう。
csvやjsonをそのまま使っている場合は即座に、parquetフォーマットへと移行しましょう。

対策その3.ファイルサイズを5Gくらいにする

小さいファイルが1000くらいと１０個くらいではクエリの速度が数十倍変わる時があります。
一つ一つのファイルのサイズ常に気を配りましょう。

対策その4.repartionを用いて適度に中間ファイルをoutする

ワークフローのリカバリー性もありますが、0 or 1 ではなく途中の結果をクラウドストレージに出すことにより、最終的には早くなった。ということは結構あります。
途中の処理でrepartitionを用いて、ファイルを整列させてストレージにアウトことで、データが均等に分散され後続の処理のクエリが高速になる事例に何度も遭遇しました。

対策その5.casheする

Lazyにキャッシュます。なるべく不要なファイルは読まないようにsparkが考慮してくれます。

spark.sql("CACHE LAZY TABLE as SELECT * FROM hogehoge.pekepe")

対策その6.Spark SQLのhint文を利用する

複数の副問合せなが連なる場合、そのSELECT文ごとに
/*+ REPARTITION(15) */
のようなsparkのヒント文を利用した方がいいです。

hiveと違って、処理の間間でこういったチューニングがSQLでできるのがsparkの強み

select
/*+ REPARTITION(15) */
hoge
from
peke
のように利用します。

対策その７. クラスターの設定はしっかりと行う

EMRは適当に立ち上げてしまうと、あまり効力を発揮できません。

以下のスライドにまとめて記載をしております。

https://speakerdeck.com/yuki_saito/aws-detareikushi-li-ji-ri-deng-tan-zi-liao?slide=22

まとめ

やはりETLの技術スタックはSpark強いですね。

もちろん、マシンスペックでブイブイ言わせることも可能なのですが、ふと職人芸を発揮したい時はこう言ったことを追い求めてみるのも楽しいですね。

お次は、simonritchieさんです。