Scalaを導入した話について(後編)

Scalaを導入した話について(後編)


昨日に引き続き、
キャリアDiv. マーケティング企画統括部 データアナリティクス部 マーケティングテクノロジーグループのよしだといいます。

今回は、後編ということでScalaを導入してから、現在までの過程を振り返ってみたいと思います。

導入初期について

社内勉強会の開催

社内勉強会は、週に1回業務時間の内1時間を使って開催しています。

Scalaの入門ということで、以下のカテゴリに分けて一つづつ関係するblogの記事や本家のドキュメントを見たり、REPLで動かしたりしました。

  1. 開発環境の構築
  2. Scalaプロジェクトを作る
  3. Scala REPLの使い方
  4. リテラル
  5. 制御構文
  6. コレクション
  7. 関数
  8. オブジェクト指向言語としてのScala
  9. 例外処理

入門編の社内勉強会を終わった段階で振り返りをしてみた際に、以下のような感想を聞くことが出来ました。

  • 未知との遭遇
  • PHPとは考え方が違った
  • Javaに慣れていると引っかかるところがあった

もちろん、厳しい声もありました。
特に準備不足が否めない回もありましたし、私自身がScalaを理解しきってから教えているわけではないので、途中でハマったりして進展がなかった回もありました。

2015年12月現在であれば、はてな教科書に沿って進めていくことで、
Scalaの基礎(怖くない方の)が身につくと思います。

ライブラリの選定

基本となるフレームワークは、Skinny Frameworkを選びました。

とは言え、バッチ処理がメインのプロジェクトですので、必要最低限のモジュールだけ採用しました。

特にSkinny-ORMは、いざとなったらScalikeJDBCをシームレスで使うことができるので、
既存のSQLを利用しつつ、SkinnyMapperの便利な機能も活用でき、大変助かりました。

その他の主なライブラリは、以下のとおりです。

特に、Scalazは\/Validationが使いたかったので、選びました。
その他のライブラリについても、様々なデータソースに対応する必要があるため、まずはじめにCSVファイルと外部APIのSOAPに対応したものを選択しました。

導入してみてどうだったのか

導入後の検証

一部の処理をScalaに変更した結果を検証しました。

これまで順番で行っていた処理を並行処理にした結果、半分近くの時間で済むようになりました。
処理を新たに追加しても処理にかかる時間の増加も少ないものでした。

同時期にクラウド環境の移設も行ったため、最終的に必要なデータを集計する時間の大幅な短縮を達成できました。

テストについて

テスティングフレームワークは、Skinnyが採用しているScalaTestを利用しています。

書き方としてはFlatSpecFunSpecを主に利用しており、目的や用途に応じて使い分けています。

DiagrammedAssertionsを使うとエラーの結果を詳細に表示してくれるいわゆる power-assert が使えるので、ほぼこれで書いています。

また、TableDrivenPropertyChecksのおかげでパラメタライズドテストも充実させることができています。

学習コスト

社内勉強会を継続的に開催してはいますが、個人のこれまでの経験の差は埋められるものではないので、各自で研鑽をする必要があります。
ですので、業務時間では実践できる場として活用してもらって、業務時間以外でも自主的に情報収集や練習をやってほしいと思ってます。

言語としてコストが高いと感じた点としては、特にOptionやEitherといった概念はScalaで初めて知った方が多く、慣れるまではレビューで指摘される機会が多かったように思います。

また、map, flatMap辺りの型合わせもコンパイラやIDEに教えてもらいながら進めていたように見受けられました。

慣れるまではJavaやPHPっぽいコードでしたが、徐々にScalaらしいコードになっていくのを見てて、このチームであれば大丈夫だと確信しました。

特に変化が見られたのは、型に守られているため、防御的プログラミングをしがちな箇所をかなり減らすことが出来ており、コードを書く量も既存のPHPに比べ減っていました。

今後の予定

今後新しく追加するバッチ処理はScalaで作っていきますが、まだ、既存の処理の一部だけをScalaに移行したに過ぎないので、既存のを徐々に置き換えつつ改善していければと考えています。

特に、外部のAPIを利用してデータを取得する必要があるものの一部にSOAPが使われていたので、scalaxb + dispatchを利用していますが、
出来ればdispatchを止めて別のライブラリにしようと検証している最中です。

また、データのリアルタイム性が必要になった際には、Apache Sparkを採用してみたいという野望もあります。

将来的には、Scalaの採用だけに止まらず、様々なデータ分析のニーズに応えられるようなチームにしていきたいと考えています。