オプトエンジニアの岡田が、「scalikejdbc-bigquery」というテーマでGoogle Cloud Next'17 TokyoのGoogle Cloud Community fesに登壇した様子をレポートします。
こんにちは。株式会社オプトでエンジニア採用を担当している井上です。 前回に引き続きイベントレポートをお届けします。 非エンジニアですが、社内のエンジニア達の力を借りて、技術面についてもなんとか頑張って書きました（生まれて初めてPRを上げました）。お楽しみいただけたら嬉しいです。
6月14日、Google Cloud Community fes @ Google Cloud Next'17 Tokyoに、 オプトのエンジニア 岡田が登壇しました。今回は、岡田の登壇内容や、他のセッションの様子についてレポートします。
Google Cloud Next'17 Tokyoは、GCPなどGoogle製品の技術や、Google製品を利用している企業による講演などが行われたイベントです。
Google Cloud Community fesは、このGoogle Cloud Next'17 Tokyo初日の夜に、Googleのクラウド技術に関する4つのコミュニティが一同に集い、各コミュニティー3つずつ、合計12のブレイクアウトセッションが行われたイベントです。 岡田は、そのうちの#bq_sushiにて登壇しました。
以前OPT Tech Magazineで公開したこちらの記事をきっかけに岡田宛に直接オファーがあり、登壇に至りました！
岡田登壇内容要約
現状
オプトでは、Scalaが主要な開発言語の一つであり、DBライブラリとしてScalikeJDBCを使っている
Scala, ScalikeJDBCを使う理由
scalikejdbc-bigqueryとは
ScalikeJDBCを使ってBigQueryを利用するためのアダプタライブラリ
BigQueryへのクエリ発行およびエンティティへのマッピング：scalikejdbc-bigqueryで実行
という構成になっている。
scalikejdbc-bigqueryを作った理由
ADPLANというプロダクトで、既存のコードベースを活用しつつBigQueryに移行するため
※ ADPLANとは インターネット広告の効果測定ツール
- PV/クリック/CVログ等を多くの切り口と指標でレポーティング
- 実装はScala/ScalikeJDBC
- 現状はAmazon Redshiftを利用しているが、より高速にインタラクティブクエリを返すためにBigQueryへの移行を検討
scalikejdbc-bigquery作成の経緯
移行の方法を3パターン検討した。
- BigQuery Client Libraryを使って再実装
- 既存コードはそのままに、BigQuery用JDBC Driverを利用
- いい感じのアダプタライブラリ
3パターンの中でメリット・デメリットを考慮し、「いい感じのアダプタライブラリ」を作るのがベストと判断した
移行に着手してみて
- JDBCのAPIと同様のAPIがJava Client Libraryにも用意されており、置換はスムーズだった
- 既存のコードベースをほぼそのままに移行でき、当初の目的を達成できた
- 今も移行途中で、コスト面のリスクは様子見中だが、パフォーマンスは期待通り出そう
メッセージ
ScalikeJDBC / scalikejdbc-bigqueryで、Scalaから簡単にBigQuery使えるのでオススメ！！
スライドはこちら！
岡田への質疑
Redshiftの使用感は？
- 大規模なデータに対しては、BigQueryほどinteractive Queryに強くない
- BigQueryほどfull managedでない（手作業を要する）
コストはどうなりそうか？
- 現状の使われ方ベースで試算すると、Redshiftを起動させ続ける状態よりはBigQueryに移行した方がコストが下がりそう
- しかしクエリ頻度次第では青天井なので、読めない部分もある
→会場からは、「アラートを出すなど工夫しながら使っている」という声も挙がりました。
session1 "Jordan本人だけどなんか質問ある？"より
BigQueryの開発者でBigQuery Analyticsの著者であるJordan Tigani氏と、Felipe Hoffa氏を招いたFireside Chatが行われました。 こちらも面白かったので、質疑応答の一部をご紹介します！
（写真左から、Jordan氏、通訳担当のkazunori_279氏、Felipe氏）
LegacySQL vs StandardSQL
今から使い始める場合、LegacySQLとStandardSQLどっちがいいの？という質問には、 Jordan氏「StandardSQL一択」と即答でした（！） 理由は次の通り。
- StandardSQLにはオプティマイザーがついている
- StandardSQLの“Resource Exceed”エラーに対するtipsもある（続きは明日のプレゼンで、とはぐらかされていましたが、、）
- StandardSQLの方がLegacySQLよりも速い（もしStandardSQLの方が遅い場合、それはバグだ とのこと）
- joinのやり方にバリエーションがある
- BigQuery MateというChrome Extensionを使えば毎回StandardSQLで動く
- LegacySQLに機能追加予定がないのに対し、StandardSQLには機能追加予定がある
障害がたまに発生してしんどい
- 4GB/secのストリーミングなど、GCP側の想定を超えてハードな使われ方をたまにされるのが一因
- ここ数ヶ月で深刻な障害があったので、機能追加ではなく信頼性向上に注力している
エラーメッセージをローカライズできないか
社内の非エンジニアがエラーメッセージ（英語でしか書かれていない）を理解できないのがつらい との声が挙がりました。
これに対してはFelipe氏が次のように回答。
- Redashというオープンソースがあるから、誰か1人が頑張ってくれたらいいと思う（笑）
このセッションの様子は、当日司会をなさったなかむらさとるさんが詳細をまとめていらっしゃいますので、こちらも是非ご覧ください。
http://qiita.com/satoru_mag/items/6e01ea575aaf3b5da760
さいごに
22時までという長丁場でしたが、最後まで盛り上がりを見せており、非エンジニアである筆者も楽しめました。
株式会社オプトでは、6月28日（水）19:00から市ヶ谷Geek★Night「GCPはじめました。」というイベントを開催予定です。 とってもタイムリーですね！！
こんなエンジニアの方は特にウェルカムです！！
また弊社では、通年採用受付中です。 エントリーはこちらから！
※カジュアル面談ご希望の方は、補足欄に「カジュアル面談希望」とご記載ください
