分析システムにR Markdownを組み込む

Tokyo.R #102で発表した内容のスライドです
ref) https://tokyor.connpass.com/event/262836/

Transcript

1. 分析システムにR Markdownを組み込む
   Tokyo.R #102
   kazutan
   2022-10-22
   

   View Slide

2. はじめに
   2 / 23
   

   View Slide

3. はじめに
   自己紹介
   名前/アカウント
   前田和寛(Maeda Kazuhiro)
   @kazutan
   Twitter
   GitHub
   Qiita, r-wakalang, etc...
   3 / 23
   

   View Slide

4. はじめに
   書籍
   4 / 23
   

   View Slide

5. はじめに
   所属
   LINE Fukuoka株式会社
   Data Scientist
   DataLabs - Senior Manager
   Data Science Team
   Machine Learning Team
   Data Engineering & Solution Team
   LINE株式会社
   CDO Office
   5 / 23
   

   View Slide

6. はじめに
   今回のお話
   分析のシステムにR Markdownを組み込んで構築したときのお話
   具体的なところについては、すでに発表済み
   週次KPIレポートをconfluenceへUpするためにやったこと
   R, Git, Droneを使ってconfluenceへのKPI予測レポートを自動化した話
   今回はこれらを構築するときに私が意識したことや設計時のポイントについてお話しま
   す
   R Markdownを組み込んだKPI予測システム
   全体設計をするときに考えたこと
   Rでシステムを組むときに考えたこと
   R Markdownをシステムに組み込むときに考えたこと
   6 / 23
   

   View Slide

7. R Markdownを組み込んだ予測システム
   7 / 23
   

   View Slide

8. Background
   KPIsを予測して可視化/レポート化するのを自動化
   daily KPIを算出
   算出したKPIスコアを用いてモデリング
   fitting, forecast
   レポート作成
   各KPI指標をplot, table化
   関係者が閲覧できる、confluence Wiki上の適切な場所へレポートs区政
   上記をすべて自動で定期的に実行できるようにする
   詳細は「 R, Git, Droneを使ってconfluenceへのKPI予測レポートを自動化した話」を参照
   8 / 23
   

   View Slide

9. Overview
   システムアーキテクチャ
   9 / 23
   

   View Slide

10. 全体設計をするときに考えたこと
    10 / 23
    

    View Slide

11. プロセスを意味のあるまとまりで分離
    プロセスを大きく分割する
    1. データ加工
    2. モデリング
    3. Rmd生成/加工
    4. render/publish
    できるかぎり「疎」な結合にする
    ブロック別での開発をスムーズにするため
    最適化のために必要(次のスライド)
    それぞれのブロックを差し替え可能にするため
    -> 1枚のRmdファイルで組まないこと
    11 / 23
    

    View Slide

12. 実行(利用)環境を最適化
    すべてをR上で処理する必要はない
    データ加工プロセスはPresto/Sparkなどで実行
    「Rは読めないけどSQLは読める」という人はたくさんいる
    データエンジニアリングを他のメンバーに託せる
    あるいはDWHやData Martを準備してもらう
    時系列モデリングについても、適切なツールがあるならそれを利用
    ただし、組み合わせるものが増えるとコストも上がる
    主にメンテナンスやトラブルシューティング
    パフォーマンスとのバランスなどで決定
    12 / 23
    

    View Slide

13. Rでシステムを組むときに考えたこと
    13 / 23
    

    View Slide

14. 関数化・モジュール化の徹底
    処理は関数に書き出す
    プロセスを構造化
    後のメンテナンスコストを低下
    各処理でのI/Oを明確化
    テスト設計がスムーズに
    バグ対策にも
    パッケージ化とは異なることを意識
    パッケージの関数は汎用性などを求める
    システムにおける関数化の目的は上述の通り
    汎用性は二の次
    14 / 23
    

    View Slide

15. テスト/エラー検知を意識する
    ちゃんと動くのが前提
    動作確認はきっちりする必要あり
    テストは重要
    単体/ユニットテストをできるように組む
    「テストがしやすい」粒度での関数化/モジュール化を
    増やしすぎるとコストが跳ね上がる
    バグを見つけやすいレベルを意識して
    想定できないからエラーは発生する
    エラーが発生しないシステムなんてない
    どの処理でエラーが発生したのかをnoticeするように
    15 / 23
    

    View Slide

16. 自分ではない人がメンテできるように
    マニアックよりもクオリティを
    高い技術力を発揮できるのは気持ちいい
    でも、あなたがずっとそれを見続けるのですか?
    属人化に直結する
    複雑な構成にするのは避けよう
    どうせメンテナンス性も低下する
    資料をちゃんと作る
    他の人が読んでも理解できるようにする工夫を
    コメント充実
    ドキュメントを作成
    資料作成まで含めての工数を見積もること
    そして、1ヶ月後の自分は別人だと考えよう
    16 / 23
    

    View Slide

17. R Markdownをシステムに組み込むとき
    に考えたこと
    17 / 23
    

    View Slide

18. 要件定義を忠実にRmdへ
    使われないレポートは価値がない
    価値 = ユーザーの期待に応えること
    ユーザーニーズをきっちりと把握すること
    そのうえで、R Markdownを設計する
    テンプレート化
    Rmdの特徴はテンプレート化できること
    定常的/定型的なレポートがいい
    Rmdは基本テキストファイル(md)
    普通にRから文字列をいじれる
    glue
    パッケージなどを利用して動的に書き換えると楽
    18 / 23
    

    View Slide

19. 極力Rの処理を入れない
    Rmd内のチャンクで複雑な処理はしない
    Rチャンク内でのエラーは追いにくい
    Rでの実行環境など想定しにくいものが多い
    Rmdでのデバッキングはめんどくさい
    毎回renderするのは大変
    あくまで表出層のみに留める
    だいたいこんな感じに
    整形済みの必要なデータ読み込み
    可視化
    数値の動的な代入
    (必要なら)文字列の加工など
    19 / 23
    

    View Slide

20. R Markdownを使うメリットって?
    表出層を作成するときのコストがかなり少ない
    ベースがmd
    UIエンジニアリングスキルがなくても作れる
    Skeletonがシンプルになる
    表現力が高い
    Pandocを活用できる
    非常にパワフル
    Publishもいろいろできる
    システム的に連携しやすい
    分析環境からそのまま処理できる
    render
    一発でいけるのは、やっぱりすごい
    20 / 23
    

    View Slide

21. まとめ
    21 / 23
    

    View Slide

22. 要点のまとめ
    全体設計
    プロセスを意味のあるまとまりで分離
    実行(利用)環境を最適化
    Rでの実装について
    関数化・モジュール化の徹底
    テスト/エラー検知を意識
    自分ではない人がメンテできるように
    R Markdownの実装について
    要件定義を忠実にRmdへ
    極力Rの処理を入れない
    22 / 23
    

    View Slide

23. Enjoy!
    23 / 23
    

    View Slide