Clever Geek Handbook

Rを使用して実際のビジネス上の問題を解決するその他の例

前回の発表以来、私は何らかの形でデータ処理に関連するさまざまなタスクを試さなければなりませんでした。 タスクは完全に異なりますが、すべての場合において、Rツールを使用すると、それらをエレガントかつ効果的に解決することができました。 実際、以下のケース（写真なし）。







ケース＃1：ドキュメント分析（Web廃棄）



設計問題の記述は簡単です。 Webポータルでのリクエストに応じてのみ利用可能なドキュメントの専門家による分析を行い、初期タスクに関する分析レポートを作成する必要があります。 次のニュアンスではないにしても、簡単に聞こえます。







  1. ドキュメントデータベースには直接アクセスできません。
  2. ポータルAPIは存在しません。
  3. 直接リンクによるドキュメントは、セッション接続および検索を作成するメカニズムを介してのみアドレス指定できません。
  4. ドキュメントの全文は使用できませんが、ページング用のJSスクリプトによって表示が生成されます。
  5. 適切なドキュメントのそれぞれについて、1ページ目のプレーンテキストに基づいて、その属性の要約を作成する必要があります。
  6. ドキュメント〜10万、タスクに実際に関連する〜0.5％、最初のリリースの時間〜1週間。


「古典的な」アナリストのグループが袖をまくり、残業の読み取りと手動の文書処理を開始しました。 このアプローチの短所を納得させる時間も欲求もありませんでした。







私たちは別の方法、つまりRを使用したWebスクレイピングを実行しました。インターネットおよびハブでのWebスクレイピングに関しては、多くの資料がありますが、繰り返しはしません。 ハブでの同様の出版物の例： 「Pythonを使用したWebスクレイピング」 。







古典的なアプローチでは、Perl \ Pythonがそのようなタスクに使用されますが、ツールを組み合わせて作成するのではなく、戦闘条件でRを使用することにしました。 この問題は、次の有限メトリックで正常に解決されました。







  1. Chrome \ Firefoxに組み込まれた開発者ツールを使用したポータルの分析（構造、リクエスト、回答、ナビゲーション）に0.5日。
  2. ドキュメントのリストとその後の属性強化を準備するためのRスクリプトを開発する1日。
  3. タスクの形成、自動化されたデータ収集、および表形式のプレゼンテーション生成に最大8時間。
  4. リストを手動でレビューし、余分な部分を切り取り、適切な可能性のあるドキュメントを読むために、約2日間。 読んだ後、数十の文書だけが不適切と認識されました。


ドキュメントが動的に生成された（JS）という事実にもかかわらず、最初のページを取得するための抜け穴を見つけることが可能であり、必要なすべての属性があったため、Selenium \ PahntomJSが不要になりました。 これにより、データ収集プロセスが大幅に加速しました。







さらに、Webリクエストは非同期モードで動作するため、タスクは（Rによって）並列化されました。 4コアでの実行には約8時間と示されているため、3倍長くなります。







「古典的な」アナリストのグループは懸命に働き続けます...







技術的な詳細



  1. ページを解析し、必要なコンテンツを選択するために、XPath + regexpテクニックのさまざまな組み合わせが使用されました。
  2. コード全体は約200行で、そのうちの50％はコード規則に準拠するためのコメントと長い行のハイフネーションでした。
  3. 明示的な宣言によって接続されたパッケージのセット： 


library(lubridate) library(dplyr) library(tidyr) library(tibble) library(readr) library(stringi) library(stringr) library(jsonlite) library(magrittr) library(curl) library(httr) library(xml2) library(rvest) library(iterators) library(foreach) library(doParallel) library(future)


ケース2：工場製品の品質を予測する



問題の説明も非常に簡単です。







原材料から製品を製造するための技術ラインがあります。 プロセス中、原料はさまざまな物理的処理、すなわち、プレス、成形、化学薬品にさらされます。 処理、加熱...個々のプロセスのメトリックは、さまざまな間隔でさまざまな方法で測定されます。 自動的にどこかで、手動でどこかで、例えば、原材料の実験室管理。 集合的にメトリック〜50-60個。 プロセスの所要時間は1.5〜2時間です。







タスクは、指定された物理パラメーターで出力製品を取得することです。







少し下に行くと問題が発生します。







  1. 技術プロセスの正確な分析モデルはありません。
  2. 原料パラメータは、ダウンロードごとに異なります。
  3. 出力製品のパラメーターを現在の順序に従って変更する必要がある場合、カスタム生産モデルがサポートされます。
  4. フィードバックの原則に基づいた技術ラインパラメータの調整に関する「実験」は、ビジネスにとって高すぎることが判明しました。 製品がリリースされる前のフルサイクルの1.5〜2時間は、1トンの原材料は転送されません。 ラインパラメータが正しく設定されていない場合-欠陥があるため、順序をやり直す必要があります。


受注生産の開始からすぐにラインパラメータを正しく設定し、それらをそのまま調整する必要があります。 生産プロセスで起こりうる変動を平準化するプロセス。







入り口にあったもの：







  1. 技術プロセスの説明。
  2. 特定の注文をリリースするときにパラメーター値を含むVBAオートメーション要素を含むExcelの「シート」。 異なるシフトと異なる工場-わずかに異なる充填スタイル。


Rによる通常の手段の困難なタスクは、2つのステップで解決されました。







  1. Excelデータを構造化ビューに適応的にインポートします。
  2. RandomForestアルゴリズムを使用して予測モデルを構築します。
  3. RandomForest実行の結果とプロセスの一般的な物理的考慮事項に基づいてパラメーターリストを削減します。


出力製品のパラメータを3〜5％の範囲で予測することで得られた精度は、規格に対して非常に十分で適切であることが判明しました。







公平を期すために、これはすべて「概念実証」モードで行われたことに注意する必要があります。 「解決不可能な」問題の解決可能性の実証と解決策のもう少し詳細な研究の後、技術的パラメーターを測定する手順を改善する分野に重点が移りました。 これはまさに、Rの運用上の使用により、二次的なデジタルの問題に対する意識を取り除き、物理的な世界の主要な問題に戻ることができる場合です。







技術的な詳細



  1. コード全体は約150行で、そのうち30％はコード規則に準拠するためのコメントと長い行のハイフネーションでした。
  2. 明示的な宣言によって接続されたパッケージのセット： 


 library(dplyr) library(lubridate) library(ggplot2) library(tidyr) library(magrittr) library(purrr) library(stringi) library(stringr) library(tibble) library(readxl) library(iterators) library(foreach) library(doParallel) library(zoo) library(randomForest)


ケース3：混合生産環境での分析と検証の統合



問題文：







  1. 階層オブジェクトの場合、SAPからExcel形式で何百ものダウンロードがあります。 アンロード形式は人間の視覚に焦点を当てており、機械の知覚には非常に不便です。
  2. サードパーティシステムからのExcelアップロード+手動入力/デジタル化データがあります。
  3. Accessデータベースにデータがあります。


合計すると、分析するすべてのオブジェクトについて数十万円のレコードが存在する可能性があります。







必要です：







  1. カスタムマルチパラメータルールに従って、個別のレポートの一部としてデータ調整を実行します。
  2. カスタムマルチパラメータールールに従って、さまざまなデータソースからのデータを相互検証します。 不一致の結果をアナリストに報告してください。
  3. このすべての情報に基づいて、毎月の分析レポートを作成します。 さまざまなグラフィカルおよび表形式の表現を備えた何百ものページ
  4. 未知のルールに従ってデータを操作可能な任意に操作するための分析ツールを提供します。


RC PoCを開始する前の推奨ソリューション：









はい、タスクは大量のデータとレポートがあるという理由だけで、2日間は決して大規模ではありません。

実現可能性を証明するために、Rに基づいて「概念実証」を実施しました。







PoCの一環として：







  1. フローティングデータ形式をサポートするExcelデータをインポートする
  2. アクセスデータをインポートします。
  3. チェックのサブセットの実装（数値、テキスト、結合）。
  4. グラフィカル/表形式の表現の生成。
  5. グラフィック、テキスト、表を含むhtml \ doc表現の生成。
  6. データ分析インターフェース


一般に、パイロットの結果によると、すべての要件の技術的実現可能性の確認が行われました。 開発の可能性が概説されています。 Rを使用した実装の人件費の推定値が取得されました。SAPと比較した推定値は1桁以上低くなっています。 自動化および構成機能は、他のすべてのソリューションよりも何倍も優れています。







PoCの技術的詳細



  1. コード全体は約500行で、そのうち20％はコード規則に準拠するためのコメントと長い行のハイフネーションでした。
  2. データ配列をインポートする時間は秒です。
  3. チェックの実行時間は秒です。
  4. 出力レポートの生成時間（html \ doc）-分単位。
  5. 明示的な宣言によって接続されたパッケージのセット： 

     library(dplyr) library(lubridate) library(ggplot2) library(tidyr) library(magrittr) library(purrr) library(stringi) library(stringr) library(tibble) library(readxl) library(iterators) library(foreach) library(doParallel) library(zoo) library(gtable) library(grid) library(gridExtra) library(RColorBrewer) library(futile.logger)


おわりに



事実は事実です。 Rを信じることができますが、信じることはできません。 可能性を疑うことができます。 スタンドからそのように行動することを発表するまで、100回確認して待つことができます...しかし、勇気と忍耐を持ち、データ処理への古いアプローチをRプラットフォームで置き換える人々は、ここで複数の節約と利益を受け取ります。







前の投稿： 「Rを使用したライブ分析の準備と他のビジネスユニットへの転送」







More articles:


All Articles