Tokyo.R #102で発表した内容のスライドです ref) https://tokyor.connpass.com/event/262836/
分析システムにR Markdownを組み込むTokyo.R #102kazutan2022-10-22
View Slide
はじめに2 / 23
はじめに自己紹介名前/アカウント前田和寛(Maeda Kazuhiro)@kazutanTwitterGitHubQiita, r-wakalang, etc...3 / 23
はじめに書籍4 / 23
はじめに所属LINE Fukuoka株式会社Data ScientistDataLabs - Senior ManagerData Science TeamMachine Learning TeamData Engineering & Solution TeamLINE株式会社CDO Office5 / 23
はじめに今回のお話分析のシステムにR Markdownを組み込んで構築したときのお話具体的なところについては、すでに発表済み週次KPIレポートをconfluenceへUpするためにやったことR, Git, Droneを使ってconfluenceへのKPI予測レポートを自動化した話今回はこれらを構築するときに私が意識したことや設計時のポイントについてお話しますR Markdownを組み込んだKPI予測システム全体設計をするときに考えたことRでシステムを組むときに考えたことR Markdownをシステムに組み込むときに考えたこと6 / 23
R Markdownを組み込んだ予測システム7 / 23
BackgroundKPIsを予測して可視化/レポート化するのを自動化daily KPIを算出算出したKPIスコアを用いてモデリングfitting, forecastレポート作成各KPI指標をplot, table化関係者が閲覧できる、confluence Wiki上の適切な場所へレポートs区政上記をすべて自動で定期的に実行できるようにする詳細は「 R, Git, Droneを使ってconfluenceへのKPI予測レポートを自動化した話」を参照8 / 23
Overviewシステムアーキテクチャ9 / 23
全体設計をするときに考えたこと10 / 23
プロセスを意味のあるまとまりで分離プロセスを大きく分割する1. データ加工2. モデリング3. Rmd生成/加工4. render/publishできるかぎり「疎」な結合にするブロック別での開発をスムーズにするため最適化のために必要(次のスライド)それぞれのブロックを差し替え可能にするため-> 1枚のRmdファイルで組まないこと11 / 23
実行(利用)環境を最適化すべてをR上で処理する必要はないデータ加工プロセスはPresto/Sparkなどで実行「Rは読めないけどSQLは読める」という人はたくさんいるデータエンジニアリングを他のメンバーに託せるあるいはDWHやData Martを準備してもらう時系列モデリングについても、適切なツールがあるならそれを利用ただし、組み合わせるものが増えるとコストも上がる主にメンテナンスやトラブルシューティングパフォーマンスとのバランスなどで決定12 / 23
Rでシステムを組むときに考えたこと13 / 23
関数化・モジュール化の徹底処理は関数に書き出すプロセスを構造化後のメンテナンスコストを低下各処理でのI/Oを明確化テスト設計がスムーズにバグ対策にもパッケージ化とは異なることを意識パッケージの関数は汎用性などを求めるシステムにおける関数化の目的は上述の通り汎用性は二の次14 / 23
テスト/エラー検知を意識するちゃんと動くのが前提動作確認はきっちりする必要ありテストは重要単体/ユニットテストをできるように組む「テストがしやすい」粒度での関数化/モジュール化を増やしすぎるとコストが跳ね上がるバグを見つけやすいレベルを意識して想定できないからエラーは発生するエラーが発生しないシステムなんてないどの処理でエラーが発生したのかをnoticeするように15 / 23
自分ではない人がメンテできるようにマニアックよりもクオリティを高い技術力を発揮できるのは気持ちいいでも、あなたがずっとそれを見続けるのですか?属人化に直結する複雑な構成にするのは避けようどうせメンテナンス性も低下する資料をちゃんと作る他の人が読んでも理解できるようにする工夫をコメント充実ドキュメントを作成資料作成まで含めての工数を見積もることそして、1ヶ月後の自分は別人だと考えよう16 / 23
R Markdownをシステムに組み込むときに考えたこと17 / 23
要件定義を忠実にRmdへ使われないレポートは価値がない価値 = ユーザーの期待に応えることユーザーニーズをきっちりと把握することそのうえで、R Markdownを設計するテンプレート化Rmdの特徴はテンプレート化できること定常的/定型的なレポートがいいRmdは基本テキストファイル(md)普通にRから文字列をいじれるglueパッケージなどを利用して動的に書き換えると楽18 / 23
極力Rの処理を入れないRmd内のチャンクで複雑な処理はしないRチャンク内でのエラーは追いにくいRでの実行環境など想定しにくいものが多いRmdでのデバッキングはめんどくさい毎回renderするのは大変あくまで表出層のみに留めるだいたいこんな感じに整形済みの必要なデータ読み込み可視化数値の動的な代入(必要なら)文字列の加工など19 / 23
R Markdownを使うメリットって?表出層を作成するときのコストがかなり少ないベースがmdUIエンジニアリングスキルがなくても作れるSkeletonがシンプルになる表現力が高いPandocを活用できる非常にパワフルPublishもいろいろできるシステム的に連携しやすい分析環境からそのまま処理できるrender一発でいけるのは、やっぱりすごい20 / 23
まとめ21 / 23
要点のまとめ全体設計プロセスを意味のあるまとまりで分離実行(利用)環境を最適化Rでの実装について関数化・モジュール化の徹底テスト/エラー検知を意識自分ではない人がメンテできるようにR Markdownの実装について要件定義を忠実にRmdへ極力Rの処理を入れない22 / 23
Enjoy!23 / 23