slides

fluentd x embulk x bigqueryで作る

バッチ集計処理基盤

@joker1007

メインのバッチ集計処理基盤として

bigqueryを利用するために今取り組んでいること、

そしてそれを支えるfluentdとembulkの

bigqueryプラグインの現状を解説します。

self.inspect

Repro Inc.の最新情報 - Wantedly

Hireling Now :exclamation:

資料作成サボってて時間がやばくなってしまい、

業務時間使って資料作ってたので、

宣伝を入れるからってことで許してもらいました :trollface:

BQの利用背景

構成イメージ図

アプリ自体はAWSでGCP周りはBigqueryだけ使っている イメージ図

RedshiftやEMRでない理由

Bigqueryはイニシャルコストがほぼ0なので試し易い

将来的にはそちらに移行することもあり得る

現在の使い方

実行主体はこんな感じ

module Bigquery
  module QueryJobs
    class CalculationJob1 < Base
      self.template_name = "calculation_job_1"
    end
  end
end

-- calculation_job_1.sql.erb
SELECT id, COUNT(*) FROM <%= table_name %> GROUP BY id

Rukawaの例

module Workflow
  class CalculationJob1 < Rukawa::Job
    def run
      Bigquery::QueryJobs::CalculationJob1.run_with_wait(
        {table_name: "foo"},
        destination_table_name: "foo_count"
      )
    end
  end
end

Rundeckの辛い点

というわけで、今の所集約スケジューラとして利用

その他やっていること

BQ雑感

fluentd x embulkによるデータ転送

基本はfluentd

embulkの利用

embulkを利用する際の工夫

fluent-plugin-bigquery-custom

本家マージ済み

本家にはない

実は本家のメンテナもやってます :smile:

fluent-plugin-bigqueryにじわじわ還元中

本当は一本化したいんだけど、割とアグレッシブに変えたので……。

スキーマの管理

embulk-output-bigquery

必要な機能をいくつかPR

embulk-output-bigqueryの今

sonots先生により、JavaからJRubyにガツっと書き変わった。

なので、Rubyが書けるとカスタムし易い

その他の開発Tips

ユニットテスト用のデータの投入

拙作のbq_fake_viewというgemを使っている

BQのUNIONの速さを利用して、RubyのHash in Arrayなデータ構造を

一行づつ静的なSQLに変換し、viewとしてBigquery上に定義する

メリット

テストが終わったらdata_setごと削除して作り直す

デメリット

開発データの投入

自動expireするdata_setを作って、embulkで投入

Rukawaにパラメーターを渡して実行すると投入できるようにしている

集計結果の受け取りが課題

BQ上での集計結果をアプリ側に戻す必要がある

知見ある人が居たら、教えてください

まとめ