Embulk vs Mysqlのハマりポイント

取り込みの業務ででEmbulkを使っていると（個人的にsqoopよりembulk派）思わぬところでつまづく時がある。

mysql pulginとparquet用のプラグインを組み合わせて利用している(orcも)。

MysqlのtmpSpaceがたりない。

洗い替えのパターンなどで、大量のデータを抜き出しているときに起こりやすい。 単純にtmpspaceをあげればいいのだが、根本的な解決にはならないので無理やり抜き出すのをやめて、日時のみなど日付単位で抜き出すことを検討する方向に切り替えた方後々嬉しい。

booleanに気をつける

mysqlだとtinyint(1)がbooleanの定義だが、tinyintなので255くらいまで値が入ってしまう。これを何も考えずに抜き出してしまうと、本来2などの数字が入るべきところが０、１のbooleanに 変更されてしまう。。 JDBCのオプションにtinyInt1isBit:falseを付けよう embulk(liqid)だといこんな感じ options: { tinyInt1isBit: {{ env.TINYBIT }} }

タイムゾーンが設定されていない。

対RDSから取り込むときに多いイメージ。mysql プラグインはタイムゾーンを自動で取得してくれないので、 個別で設定をする必要がある。 options: { useLegacyDatetimeCode: false, serverTimezone: Asia/Tokyo }

BLOBやBINARY、JSONは、デフォルトでstringにしておくとうれしい。

liquidテンプレートを使うことになると思うので、デフォルトのカラムオプションを設定しておくと楽。 VARBINARYという型があることを、ハマって初めて知りました。。。

remove colは組み込み存在する

フィルター用のプラグイン入れずにすみました（そんだけ）！

実はぜんぶstringで抜き出すのが楽

embulk + hiveやらなんやらでETLする場合は、値が変にならにようにstrngで抜き出してしまうのが一番楽。 Hiveなど後続のSQLが事前に定義されたスキーマにいい感じで値をキャストしてくれる。

ただ、それだとETLはシンプルにはならないので、チームの状況とかリソースを鑑みて、そのときどきでよささおうな選択をするのがいい。 特にsqoopなどのシステムからの移行時は、既存のデータの状態を守らないといけないので、一致させることに苦労するので、バランス大事（戒め)

embulkって優秀よね

embulkは一度、テンプレートで設定してしまえば取り込みの運用業務の負荷を大幅に減らすことができます。 sqoop + 内製ETLツールだと3時間かかっていた作業や取り込みが(無駄の多い作業でした。。)、30分ほどでプロダクションインできるようにまでなりました。