Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
分析システムにR Markdownを組み込む
Search
Kazuhiro Maeda
October 22, 2022
Technology
0
510
分析システムにR Markdownを組み込む
Tokyo.R #102で発表した内容のスライドです
ref)
https://tokyor.connpass.com/event/262836/
Kazuhiro Maeda
October 22, 2022
Tweet
Share
More Decks by Kazuhiro Maeda
See All by Kazuhiro Maeda
Will Positron accelerate us? (update)
kazutan
1
120
積もってく会議メモをどうにかしたかった
kazutan
0
250
Rに管理されてみる
kazutan
0
460
私とR、そしてキャリア
kazutan
2
3.8k
tubeplayR v1.0への道
kazutan
2
220
R, Git, Droneを使ってconfluenceへのKPI予測レポートを自動化した話
kazutan
2
660
週次KPIレポートをconfluenceへUpするためにやったこと
kazutan
1
1.5k
xaringanパッケージの内容をちょっとだけ
kazutan
0
1.1k
最近のRパッケージ開発事情
kazutan
0
370
Other Decks in Technology
See All in Technology
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
270
Apache Spark もくもく会
taka_aki
0
120
機械学習を扱うプラットフォーム開発と運用事例
lycorptech_jp
PRO
0
600
TS-S205_昨年対比2倍以上の機能追加を実現するデータ基盤プロジェクトでのAI活用について
kaz3284
1
210
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
10k
新規プロダクトでプロトタイプから正式リリースまでNext.jsで開発したリアル
kawanoriku0
1
180
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.7k
Automating Web Accessibility Testing with AI Agents
maminami373
0
1.3k
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
MagicPod導入から半年、オープンロジQAチームで実際にやったこと
tjoko
0
110
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
yamada_r
2
120
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
430
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
330
21k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
How to train your dragon (web standard)
notwaldorf
96
6.2k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
How GitHub (no longer) Works
holman
315
140k
Transcript
分析システムにR Markdownを組み込む Tokyo.R #102 kazutan 2022-10-22
はじめに 2 / 23
はじめに 自己紹介 名前/アカウント 前田和寛(Maeda Kazuhiro) @kazutan Twitter GitHub Qiita, r-wakalang,
etc... 3 / 23
はじめに 書籍 4 / 23
はじめに 所属 LINE Fukuoka株式会社 Data Scientist DataLabs - Senior Manager
Data Science Team Machine Learning Team Data Engineering & Solution Team LINE株式会社 CDO Office 5 / 23
はじめに 今回のお話 分析のシステムにR Markdownを組み込んで構築したときのお話 具体的なところについては、すでに発表済み 週次KPIレポートをconfluenceへUpするためにやったこと R, Git, Droneを使ってconfluenceへのKPI予測レポートを自動化した話 今回はこれらを構築するときに私が意識したことや設計時のポイントについてお話しま
す R Markdownを組み込んだKPI予測システム 全体設計をするときに考えたこと Rでシステムを組むときに考えたこと R Markdownをシステムに組み込むときに考えたこと 6 / 23
R Markdownを組み込んだ予測システム 7 / 23
Background KPIsを予測して可視化/レポート化するのを自動化 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を使うメリットって? 表出層を作成するときのコストがかなり少ない ベースがmd UIエンジニアリングスキルがなくても作れる Skeletonがシンプルになる 表現力が高い Pandocを活用できる 非常にパワフル Publishもいろいろできる
システム的に連携しやすい 分析環境からそのまま処理できる render 一発でいけるのは、やっぱりすごい 20 / 23
まとめ 21 / 23
要点のまとめ 全体設計 プロセスを意味のあるまとまりで分離 実行(利用)環境を最適化 Rでの実装について 関数化・モジュール化の徹底 テスト/エラー検知を意識 自分ではない人がメンテできるように R Markdownの実装について
要件定義を忠実にRmdへ 極力Rの処理を入れない 22 / 23
Enjoy! 23 / 23