Gunosyデータ分析ブログ

Gunosyで働くデータエンジニアが知見を共有するブログです。

データ分析部で一年仕事をしての学び

こんにちは、去年の4月に新卒としてGunosyに入社し、データ分析部に配属された山田です。 先日、LabBase様からインタビューを受けてこんな記事が公開されたりしました。

labbase.jp

また、先週は今年の新卒の片木くんがデータ分析部で何をやっているのかを書いてくれました。

data.gunosy.io

今年は新卒エンジニアの数が多かったので研修がかなり充実しているのですが、去年は新卒エンジニアが僕一人だったのでそのあたりの内容は実際に仕事をしながら学んでいくことになりました。 そこでこの記事では、データ分析部に配属されて一年仕事した上で学んだことを軽く紹介したいと思います。

数値を疑うこと

Gunosyの方針を示す「Gunosy Way」の一つに「数字が神より正しい*1」という言葉があり、実際に社内ではあらゆる数値を元に意思決定が行われています。 しかし、意思決定の根拠にすべき数値が間違っている、ということも往々にしてあり得ます。

間違っている場合、数値が異常に高かったり低かったり、あるいはやたらと分散が大きかったりと、結果をよく見てみれば「なにかおかしいな」と気づけることもあります。 そのため集計した数値を鵜呑みにするのではなく、それがちゃんと合ってそうかどうかチェックするのも大切です。 おかしいと思ったら異なる期間で集計したものと比較してみたり、送られているログの量や中身をチェックしてみると「集計クエリが間違っていた」「送信しているログ自体がおかしくなっていた」等のミスを発見できることもあります。

そのためにまず最初に「なにかおかしいな」と気づく必要がありますが、普段からプロダクトの数値を見ていないと気づきにくかったりします。 なのでちゃんと普段からプロダクトの各種数値がどう変化しているのかちゃんと追っておくことが大事ですし、それでも分からない時は恥ずかしがらずに分かる人に聞いてみることも必要です。

実行速度は思ったよりもシビアだった

「データ分析部」というと、日頃から集計やデータマイニング、機械学習のモデルづくりなどをしている、みたいな印象を受けるかもしれません。 当然それらも行っていますが、Gunosyのデータ分析部ではそれを実際のプロダクトに実装し、本番に適用するところまで自分で行うことになります。 そうなると当然、分析やモデル学習時に気をつけていたこととは別に、エンジニアリング的な観点で気をつけることも出てきます。 そのうちの一つがコードの実行速度についてでした。

単なる実験のスクリプトなら、極端に時間がかかるわけでも無ければそこまで実行時間を突き詰める必要もないでしょう。 しかし実際にプロダクトに使われているコードを弄るとなると、ちょっとした実行時間の増加で大きなユーザ影響を与えてしまいます*2

例えば僕は入社後しばらくプッシュ通知の改善を行っていましたが、一度に数百万人のユーザに対して通知を送信する必要があるためちょっとしたロジックの変更で送信完了までの時間が大幅に増えてしまったことがあり、それを元に戻すのに非常に苦労しました。 こういう影響はなかなか開発環境の少ないユーザ数だと気づきにくく、実際に本番に出してみないとわからないことも多いです。 そのため、新しいロジックを本番に適用する時は比較的ユーザ影響が少ない時間帯を狙うなど、必要以上に影響が広がってしまわないように気をつけなければいけません。 実際、上の例では最初に通知するユーザ数が少ない時間帯を狙って本番適用していたため、影響が広範囲に広がる前に切り戻すことができました。

当然、実行速度についてはAPIに関しても同様のことが言えます。 ロジックの変更となると、何かとベクトル演算が増えたり、DBから新しいデータを取ってきたりすることが増えたりします。 ちょっと重めの処理をする必要がある時は適切にキャッシュを使うなどして計算する頻度を減らしてやる必要があります。 (もちろん、DBに対する負荷にも気をつけないといけません)

大規模データの扱い

GunosyではAWSのEMRクラスタ上にPresto*3を立てて、データ集計・分析やロジックのためのデータ作成に使用しています。 しかしロジックのためにクエリを投げる場合、なにせ扱うログの量が膨大なので重いクエリになりがちです。 そのようなクエリは数分に一度などの高頻度で投げられる上、同じPrestoに別のロジックのクエリも投げられていたりするので、うっかりすると別のロジックのパフォーマンスを阻害しかねません。

なので重いクエリをできるだけ軽くするのも大切ですが、最初はクエリのどの部分がどのように処理に負荷をかけているのか全くわかっていませんでした。 どのような処理を行うとクエリが重くなるかはを知るのにはこのページがとても参考になりました。

support.treasuredata.com

また、それでもどうしてもクエリを軽くできない場合でも、定期的に中間テーブルを作るなどの方法で解決することもあります。

おわりに

本記事では一年間データ分析部で仕事をして学んだことをいくつか紹介しました。 ですがこれからもまだまだ学ぶべきことは多いので、謙虚かつ貪欲に吸収していきたいと思います。

Gunosyでは新卒エンジニアの募集を通年で行っています。

www.wantedly.com