既存ログからBigQueryのスキーマをGuessする - Qiita
はじめに 既存のログからBigQueryのスキーマを推測してくれるツールを作ったので、それを紹介します。 結構複雑なスキーマのログをひとつのテーブルで扱いたいという要件があったので作りました。 使い方 bq_guessというGemで、READMEに書いてあることがすべてです。 例えば次のようなJSON Linesのログがあったとき、こんな感じでスキーマを出してくれます。 $ cat existing_log.jsonl {"required":123,"optional":true,"nested":{"required":1234,"optional":"yes"},"array":[0,1,2,3,4]} {"required":456,"optional":false,"nested":{"required":1234,"optional":"yes","nested":{"prop
google-api-ruby-client で BigQuery にクエリを投げるとメモリを大量に喰って憤死する - Qiita
問題 google-api-ruby-client を使って BigQuery にクエリを投げると、内部で representable gem というものを使っているせいで、レスポンスの結果を全てモデルオブジェクト化しようとしてCPUとメモリを大量に消費する。 例えば、手元の例では2.4MBの結果を取得するのに、Rubyプロセスが500MBに肥大化した。 対策 EDIT: 0.11.0 で skip_deserialization option を指定すると、オブジェクト化をスキップできるようになりました。See also issues/475 無駄にオブジェクト化しないでくれ、ということで monkey patch してしまった。 # monkey patch not to create representable objects which consumes lots of memor
Ruby製のシンプルなワークフローエンジンRukawaの紹介 - Qiita
Bigqueryを使ったバッチジョブを色々と実行しているのですが、Rakeで複雑な依存関係を管理したり、並列実行させたりするのが辛くなってきたのでRukawaというワークフローエンジンを自作しました。 自作したのは、RailsプロダクトにAirflowとかLuigiとかAzkabanとか入れるにはちょっと重厚過ぎる感じだったのと、Rubyで書ける方が楽で良いやという理由からです。 RukawaとはRUby KAntan Workflow Assistantの略です(後付け) (本当はミッチーとか水戸の方が好きなんだけど良い名前が浮かばなかった) 実際は、並列実行を可能にして書き方を変えてみたRakeとそんなに大差無い。 Rukawaの機能 ジョブの定義 まず実行したい処理をジョブクラスに記述します。 module ExecuteLog def self.store @store ||= {
Bigquery上で実行するバッチ処理のテストコードを書く (Ruby編) - Qiita
bigquery上でデータを加工して集計する時、このSQLが本当に合ってんのかテストコードで検証したくなる。 しかし、こういう外部サービスを使った処理のテストコードを書くのはとても面倒臭い。 とはいえ、書かんわけにもいかんし、実際に動かしてみないと分からないこともあるので、実際にbigqueryで処理を実行してテストする方法をまとめてみる。 テストデータのロード bigqueryにデータを突っ込む方法はバルクロードするかStreaming Insertの二つ。 しかし、バルクロードはテストコードを書く時に困るのが、データ量に関わらず処理に一定時間かかること。 どれだけ小さいデータでも最低1分前後は待たされる上に、時々謎の刺さり方をして最悪数分かかる場合がある。 一方でStreaming Insertはまずテーブルを作っておかなければいけないし、Streaming Insertのレスポンスが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - abronte/BigQuery: A BigQuery wrapper
