2019年を振り返る&2020年の目標とか
はじめに
2019も残すところあと6時間ほどになったので振り返っていこうかなと思う。
細かくやるとしんどいからざっくり
アウトプット
Qiita: 12記事 ブログ: 15記事 Commit: 391コミット
出来事と思ったこと
上司が退職
- めちゃくちゃ辛かった。上司の元が一番成長実感あったし、人間的に尊敬していた
Goを始めた
- もっとしっかりやるつもりだったけど、少しだけになってしまった。クローラーを開発してリリースした。コスト2万削減。予算貢献という分かりやすい貢献ができて嬉しかった。
- GoCon Springにも行った。
インフラ周りが去年よりちょっと触れるようになった
機械学習の勉強始めた
- 個人的にこれが一番大きかったと思う。
- まず、勉強の癖がついた、楽しいからあまり勉強とも思わなくなった。
- アウトプットの習慣も前よりついた。
- Pythonも始めた。
- 会社にKaggleサークルも作った。
2020の目標
初めてのデータ関連タスクを終えての振り返り
はじめに
この記事はデータサイエンスに関して By データミックスコミュニティ Advent Calendar 2019の25日目の記事です。
普段ならQiitaに書くけど、ちょっとポエムな内容なのでブログに。 普段バックエンドを中心に割と何でも屋的にやっているエンジニアである筆者が、データミックスで学んだことがきっかけとなり、データ可視化・分析タスクを行った。当時の日記と主にその振り返りがてら備忘録。
やったこと
- トレジャーデータからGoogle Cloud Storageへのデータの抽出、流し込み
- Jupyter Notebookでのデータ加工、可視化
- 上記に付随した分析
- レコメンドモデルの作成
大変だったこと
知見を持った人が社内に1人もいない
文字通り。当時の日記には、
自分自身も社内にもナレッジが全くないのでグループ巻き込んでやっていきたい。楽しみ9割不安1割
と呑気なことを書いているが、調べ回るの結構大変だった。
トレジャーからどこにどのような形でデータを移せばいいかも分からない、どこで可視化すればいいかも分からない、先が見えない状態でスタートした。
結局は、先にCloud Datalabで分析することを決定。これは、データミックスの立川先生に教えてもらった。
その後は、GCP上にデータを移すということで、BigQueryにするかGCSにするか迷ったが、使ったことあるGCSを選択。
幸いにもトレジャーからGCSへの抽出は便利なワークフローがトレジャー側に用意されていたので登録ということで決着。
さらっと書いたが、ここにたどり着くまでに6営業日も要している。
全部で5500万レコードあるので、どうしようか悩み中。
悩んでいたようだ。
重すぎるデータ問題
GCSからローカルに落とし、jupyterで加工をしているが、凄く遅くて話にならない 書き方が悪いのか否かわからない
上にもちょっと書いてあるが、何しろレコード数が多く、回らなかった。
分析の上手なやり方も分からないため、自分は、6つの可視化項目に対して、全部盛り巨大データをPandasで処理して対応しようとしていた。
これだと到底回らなかったので、トレジャーからのデータのエクスポートの粒度を可視化項目単位に細かくすることで解決した。
一人で泥臭く開拓していくのってここまで大変なのかと感じた2週間くらいだった。
ただ、これで分析のための準備は終了。
レコメンドの精度合っているのか問題
精度が良いのかどうかは分からないが、見た感じだと結構推薦できてそうな雰囲気。
雰囲気はよかったっぽい笑
教師なしのクラスタリングっぽい問題なのでなんとも言えなかったが、観測範囲内ではいいものもあれば悪いものもある。
季節も影響するだろうし、何しろ商品数が多いので精度がバラついた。結局正解が分からなかった。
作成後にデータミックスの授業があったので、久松先生に伺ったところ、次元圧縮をしなければ遅いし、精度も怪しかったらしい。
確かに恐ろしい行列だった。
学んだこと
定義は大事
データ分析の前段にはどのような背景があるのかを理解するべきだと学んだ。
ライトユーザーの割合を出したいと最初に言われ、そのまま受け取ったが、進めていくうちに、それは何回Countできたらだ?と疑問になった。
そのような場面が数回ほどあったので、分析対象に関しては、数字での定義が必須だし、最初にしておくとすんなりと進めると感じた。
また、この辺は結構ドメイン知識も重要になるのではと思う。
触ってなんぼ
よく、勉強で出てきていたが、イマイチ使いどころが分からなかったが、実際に見たいものがあると分かりやすい。
これはすごく感じる。
Pandasもだいぶ書き慣れたし、一番効果があったのが箱ひげ図だった。
最初に箱ひげ図を見た時ってなんだこれしか思わなかった。
でも、自分の知ってるデータで出してみるとなんと分かりやすいもんなんだと感動。
やっぱりエンジニアはとにかく手を動かして学ばないとなとも思わせられた。
前処理が8割の格言
界隈でよく言われることだが、すごく感じた。
また、前処理が8割とよく言われるが、それがよく分かった。
日記にも書いてある。
テーブルによってデータの形式は違うし、分析したい内容次第では、めちゃくちゃ正規表現使うし、とにかくpython,pandasって感じの期間だった。
データを前処理して使いやすい形にしたものを改めてディレクトリに保存、後からそこを参照するという形に落ち着いた。
自分(技術者)が分かるだけではダメ
ビジネスサイドとの作業だが、グラフを載せる順番によって見やすさも変わるし、分析を進めていくともっとこのデータが欲しいといった依頼が来たりと、学びが多かった。
こういう感想の通り。
今回はBizサイドからの依頼だったので、めちゃくちゃ対話もしたし、結果を見せた。
その中で言葉選び一つ、グラフの見せ方一つ、分析結果の共有の仕方一つで捉え方や見やすさが変わるのだなと学んだ。
特に、共有に関しては、依頼シートにベタ打ちで最初渡してしまってすごく見にくかった。渡すフォーマットとかを考えるのって大事。
また、コードコメントを書くようにJupyterにもコメントを書くと結構捗った。
感想
総じていうと、
- 普段のインプットアウトプットを信頼していただいて新しい挑戦をすることができた
- 全ての流れを体感できた
- めちゃくちゃ手を動かして作業ができた
- 楽しさを感じることができた
- レコメンドモデル作成が一応できた
といったあたりに非常に満足感を感じている。
それに対し、
- どうしても顧客データなので即アクションに繋がらない
- 正しい(効率の良い)やり方なのか分からない
- フィードバックを受けられない
ここはすごくもどかしかった。
満足9,不満1くらいかな。
日記には、
自分で手を動かして分析したり、レコメンド作ったりととてもいい経験をすることができた。
楽しいと書いてあった。
もっと機械学習していきたいなと感じた、終わり。
【Data Gateway Talk vol.4】に参加しました
はじめに
タイトルの通り
Data Gateway Talk vol.4というイベントに参加しました。
Data Gateway Talkはデータアナリスト/データサイエンティストの 登竜門(Gateway to Success)となることを目指した勉強会です。
「LTに登壇してみたかったけど、ちょっと自分はまだ早いなぁ」と思っていた方向けに「LT初登壇枠」を設けております。 この機会にぜひ登壇してみてはいかがでしょうか?
このイベントはこんな方にぴったりです。
- 聴講者:他社のデータアナリスト/データサイエンティストが何をやっているかを聞きたい方
- LT初登壇枠:何かしらの勉強会で登壇をしたいと思っていたが、躊躇いがあった方
- 全員:データアナリスト/データサイエンティスト同士の交流を広めたい方
カジュアルな勉強会ですので、奮ってご参加頂ければと思います。
とのこと。
ちょうど、社長からデータ収集+分析基盤構築+データ可視化という広めなミッションをいただいていたのでいいところだった
印象に残ったこと
いつも通りTwitterからいくつか振り返る
データ分析チーム立ち上げについて #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
意思決定をサポートすることがミッション #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
データ活用の環境構築について、聞きたい #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
取得データは開発者ドキュメントで全て管理している #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
自動化は正義 まさに #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
会場でもあったレコチョクさんで、ちょうどデータ分析チームを立ち上げた方のLT。
自分自身今から立ち上げるので、ハード面でも、周りとのソフト面についても参考になるような話が聞けてよかった。
自分が与えられたデータ収集基盤+可視化というミッションは、意思決定に繋がる部分になるので、しっかりと利用者が使いやすく、汎用性の高い設計にしたいなと感じた。
分析をすることが目的ではない #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
受け側のデータリテラシーを考慮>エンジニアにも言える、ビジネスサイドにいかに分かりやすい説明するか、できない人はできなし、俺は苦手 #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
- データ活用の成功体験を与える
— Kazuki Takahashi (@cuzkop) 2019年11月21日
- リテラシーを向上させる
→データ分析の文化を作る #dgtalk
次はネクソンさんのデータアナリストの方
これから自分がどういうことをするのかということを、始める前に考えることができた。
目的に対して、数ある手段の一つだし、専門性を持ってる訳でもない。なので、しっかりと段階をふみ、手段とした人に伝わるようにしたい。
最後に
結構アナリスト寄りの話が多かったかなと体感している。ただ、懇親会等でエンジニアの方とも話せたのでよかった。
あと、登竜門のわりに意外と強強さん多いなと感じた
まだ本格的に始める前なのですが、もしかしてみんな強強? #dgtalk
— Kazuki Takahashi (@cuzkop) 2019年11月21日
【Connehito Marché vol.6 〜機械学習・データ分析市〜】に参加しました
はじめに
タイトル通りです。
Connehito Marché vol.6 〜機械学習・データ分析市〜という勉強会に参加してきました。
12名の方が5分くらいでLTするというイベント。
印象に残ったこと
かなり多くの方が話してたので、個人的に思ったことをツラツラとTwitterとともに振り返りながら。
野澤さんWantedlyのインタビューで見た #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
pickleファイルなるものがあると #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
特徴量のメモ残せるのか! #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
特徴量管理やってみよう #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
最初は会場であるコネヒトの@takapyさんの発表。Kaggle等の特徴量管理についての話。
まだこの苦労について実感してないので先に知れてよかった。確かにいろんな特徴量作るとどれがどれだっけってなるのは容易に想像できるし、使ってみたいと思った一つ。
関係ないPJでも能動的に関わる、全体像がわかって良いよな #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
対面でいろんなメンバーとの会話、あんまりしてない、しなきゃな #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
知見の共有大事だ #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
yu-ya4さんの発表。これは、データ分析や、エンジニアという職種に限らずすごく大事なことだが、実践できてないなあと耳が痛かった。
やりたいことをやってたい人なので割と自由にやってしまうけど、組織に属し同じミッションの元何かを作るためのポジティブな社内政治は、この瞬間にも未来にも自分に恩恵をもたらしてくれるんだろうなと思う。
Let's実践。
— Kazuki Takahashi (@cuzkop) 2019年11月5日
jupyterへのメモって大事なんだな #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
Jリーグのドメイン知識でフォルランw懐かしいw #コネヒトマルシェ
— Kazuki Takahashi (@cuzkop) 2019年11月5日
こちらはコネヒトのshnagaiさんの発表。自分がサッカー好きなので前のめりで聞くことができた。
フォルランとかいうすごく懐かしい話題も出てきたし。普段インフラみられてる方が挑戦、それに対して助言してくれるメンバーがいる組織、いいなあ。
Jupyterへのメモは自分もやってるけど、ないと結構分からなくなるから大事だなと思ってる。
まとめ
かなり多くの発表があったのでかい摘んでの感想になったが、とても有意義な時間が過ごせた。
この勉強会に比べると、自分みたいな機械学習駆け出しでも聞きやすく参加しやすかった。
いい雰囲気だったし、何かあれば次も参加したい。
そろそろ何かLTデビューしてみようかなあ。
唯一の後悔といえば、引越しの片付けがあって懇親会に参加できなかったこと。
運営の方、楽しい勉強会ありがとうございました!
【LT,分野初心者大歓迎!! ML for Beginners! MeetUp #1 LT会】に参加しました
はじめに
8月からML勉強し始めたビギナーとして、LT,分野初心者大歓迎!! ML for Beginners! MeetUp #1 LT会に参加してきました。
内容
特に何について初心者と言及されていた訳ではないですが、初心者8名がLTするという内容です。
印象に残ったこと
強強な人もいてくれてるのか #MLbeginners
— Kazuki Takahashi (@cuzkop) 2019年10月27日
とにかく強強な人ばかりだったという印象
こういう結果が出て欲しいという意向が必ず存在する
— Kazuki Takahashi (@cuzkop) 2019年10月27日
フラットに仮説を立てられることはほとんどない #MLbeginners
データをできてしまう歪めてしまう、データアルケミストになってはいけない #MLbeginners
— Kazuki Takahashi (@cuzkop) 2019年10月27日
これからやっていく人間としては最初に持つべき視点としてあるべきだなあと思った。
実際にやってみるのが一番早い #MLbeginners
— Kazuki Takahashi (@cuzkop) 2019年10月27日
とりあえず文書分類やってみる 結構ここのとりあえずで色々できてるのがすごいと思う #MLbeginners
— Kazuki Takahashi (@cuzkop) 2019年10月27日
一番印象に残っているLTがこれ。
@TwYamatさんが発表してくださった内容。
研究室の教授の無茶振り(?)で機械学習を始めたが、どのように勉強していったかという内容だったと記憶している。
プログラミング自体も初めてだと言っていたが、記事分類までもうやられているそう。
この発表内であった、実際にやってみる、とりあえず文書分類やってみるといったハングリーさが凄いなと感じた。
自分は割と理解してから手を動かしたくなるので、とりあえずやってみる精神は凄く見習おうと感じた。
感想
上記の通り、とりあえずやってみることを意識して写経なりなんなりしてアウトプットするということを思い出さされた、いい機会になった勉強会だった。
作ってみました、そこから理解していますの説得力凄いしな。
なんでもやってみよう。
追記
運営の方ありがとうございました!もっと初心者の発表も聞きたいです!(笑)
Porterのステミングアルゴリズムをpythonで使う
はじめに
Pythonと機械学習の勉強のため、個人的に言語処理100本ノックをやっている
それの52問目にステミングアルゴリズムを使用せよとあった。
52. ステミング 51の出力を入力として受け取り,Porterのステミングアルゴリズムを適用し,単語と語幹をタブ区切り形式で出力せよ. Pythonでは,Porterのステミングアルゴリズムの実装としてstemmingモジュールを利用するとよい.
ステミングとは?
検索エンジンのアルゴリズムで、語形が変化する単語の語幹でマッチングを行うこと。英語などの言語には、意味的には同じ単語で語形が変化するものがある。
(参考) ステミングとは - SEO用語集 / 株式会社クロスウォーク
インストール
pip install stemming
でインストールできる。
Successfully installed stemming-1.0.1
と表示されれば成功。
色々公式ドキュメント読んでもうまくわからなかったので、触り倒した結果、以下で使えそう。
from stemming.porter2 import stem
これで何か実行してエラーが出なければ問題ない。
使い方
print(stem("Natural")) # Natur
これでいける。
最後に
今回は課題の中で使うだけだったが、もう少し触ってみようと思う。
BacklogからGitLabに移行した
はじめに
社内で、ずっとBacklogを使ってたのだが、GitLab使いやすくね?となったのでサラッと移行した。
やったこと
- リポジトリの移行
- コミット履歴は引き継ぐ
- 自動デプロイ部分をJenkinsに頼っていたところをGitLabCIにやらせる
リポジトリの移行
以下記事を参考にした
【Git】リポジトリをそのまま別の管理ツールへ移行する方法(Backlog→GitLab を例に)
4年くらい前の記事だが何も問題はなかった。これでリモートリポジトリはGitLabになった。
自動デプロイ
ここがかなり苦戦した。苦戦ポイントは以下。
- そもそもデプロイが走らない
- CIと言っても自動デプロイしかしない参考が少ない
- デプロイ後のブランチを確認すると以下が出る
$ git branch * (detached from {#commit id}) develop master
解決方法
デプロイが走らない問題
色々と以下対応。
- gitのバージョンを2.x系にアップグレード
- 変更のあるディレクトリの書き込み権限をgitlab-runnerユーザーに与える
git fetch-pack: expected shallow list
の対応
デプロイ後のブランチ問題
今回のpush先はdevelopブランチだったため、割と強引に解決。
解決するためのgitlab-ci.ymlが以下
stages: - deploy deploy_dev: stage: deploy tags: - develop-deploy only: - develop environment: name: develop script: - pwd - origin=$(pwd) - cd /path/to/project - pwd - \cp -rf "${origin}/." . - git branch -d develop - git checkout -b develop
cpしていることが色々な原因なんだろうけど、今の知識と移行スピード考えるととりあえずのこの対応しかできなかった。。。 折を見てgitlab-runner用のサーバを立ててdockerで運用していきたい。