日常的なタスクと統合タスクの関係は何ですか？
- 営業日を通して、ITのさまざまなランクの一般ユーザーと管理者の両方は、ビジネスプロセスのほとんどの場合、意思決定と一連の儀式アクションを実行する手段としてのみ使用されます。
- ユーザーはいくつかの区分的に統合された情報システムに囲まれています。意思決定には、「10」個のソースを調べ、データをわずかに「洗練」し、考え直し、MS Officeと数学に精通しているレベルに従ってマウスをExcelにドラッグする必要があります。
- 「5つの画面に入力して[次へ]、[次へ]、[次へ]をクリックする]よりも複雑な反応については、修正アクションを導入するために1〜2週間ミニプロジェクトを起動するために[キャップをクリックする]必要があります。
このようなタスクを自動化する古典的なアプローチは、ビジネスプロセスに関するコンサルタントを引き付けることです。 グローバル統合を備えた単一プラットフォームへの移行に関する提案の形成。 分析と選択; RFI / RFP; 入札; 長年の実装。 実装中に道徳的に時代遅れであったプラットフォームで多くのお金のためのいくつかの結果。
もちろん、少し誇張しますが、ソリューションの実行中に無限のグループ会議に費やした時間とお金でさえ、給与基金で数千万ルーブルを費やし、多くのイニシエーターはプロジェクトの終わりまでにすでに他の場所で働いています。
実際、最初のニーズを受け入れられる程度に満足させるには、データのローカルな「ステッチング」、その処理、およびわかりやすい視覚化を実行するだけで十分だったというのは逆説的です。 同時に、現実世界の類推の言語に切り替えて、家の修理と建設に関して話すとき、すべてが誰にとっても明白であり、猫によって引き裂かれた壁紙のために誰もすぐに新しい家を建てることを提案しません。
そのため、このような問題を解決するために、データサイエンスコミュニティで利用可能なツールを使用することにしました。 私たちに完全に合った最小セットはR言語、IDEはRStudio 、統合ゲートウェイはDeployR 、クライアントWebアプリケーションサーバーはShinyです。 視覚化について話すとき、当然、これはPieChartsではなく、インタラクティブなJS要素を含む情報を提示するための現代の人間工学の原則です。
初期段階では、すべての製品がオープンソースまたはコミュニティエディション形式で使用されることが重要です。 問題が突然解決され、拡張と加速が必要であることが突然判明した場合、各コンポーネントには非常に低コストの商用バージョンがあり、無料製品の大規模な制限がなくなります。
ビッグデータはどこですか？
実用的な問題を解決し、再びビッグデータの世界は非常に限られており、主に大規模なIT企業やネットワーク企業から需要があると確信しました。 コンピューティングツールの開発を考慮して、コンピューターのRAMのフレームワークに収まらないデータ量としてのビッグデータという用語の最初の解釈は、通常のタスクでは意味を失います。 ラップトップに16 Gb、サーバーに〜500 Gbを配置できます。クラウドでは、通常2Tb DDR4 RAM + 4 Tb SSD（Amazon EC2 X1）を搭載したサーバーを注文できます。
便宜上、そのようなデータのワークフロー内での指定は大きいと思われますが、それでもコンピューターのRAM容量よりも少ないため、 Compact Dataという用語を採用しました。
そのため、通常の企業の実際のタスクでは、必要な精度と速度で意思決定を行うにはCompact Dataで十分です。
詳細については、Googleの同僚は通常、会話を空間次元から時間次元に変換します。 「私にとって、 ビッグデータという用語はデータのサイズを指すものではありません。 GoogleソフトウェアエンジニアのFelipe Hoffa氏は次のように述べています。
Rサクセスストーリー
最初の成功事例として、1週間で次のBIシステムを取り出しました。 予想外に、現在利用可能なシステムからの報告に経営陣が不満を抱いていることが判明しました。 そのため、6か月間、ファイナリストの中からBIシステムのレビュー、分析、さらにはパイロットが実施されました。 供給と実装の契約はすでに管理テーブルにありました。 最後の瞬間、私たちはドアに足を踏み入れ、Rツールに基づいた代替スタンドを作るために3〜4日間頼みました。この5日間で、私たちは両方とも貧弱なBIパイロット機能（特にサードパーティICからの合成データ）ダッシュボードでの追加の分析の多くは、ユニットのパフォーマンスのいくつかの穴を特定し、予測分析を固定します。 したがって、1週間後、BIとの契約は本来あるべき場所（廃棄物入れ）に置かれ、実装のためにカルトブランシュを受け取りました。 6か月後、管理とユーザーの欲求の頂点に達したため、プロジェクトの開発は凍結されました。 その過程で、開発中に既存のシステムを拡張するために別の入札を遅くし（そして、一瞬、ほぼ40万ドル近くになります）、ビジネスに必要なすべてを行いました。
次のデータサイエンスの事例は、「スマートファーミング」というファッショナブルなタスク、つまり植物の灌漑の制御という文脈で登場しました。 「注ぐリットルはどれくらいですか？」という単純な質問は、タスクの全体を発生させます。 これは、不規則に非常に不正確にデータを収集するさまざまなセンサーからのキャリブレーションとデータ収集であり（たとえば、土壌水分の測定では異なる動作をしません）、これらのセンサーの地理的位置を最適化し、無料の散乱データと複雑な物理的および数学的な交換モデルを使用して重み付き天気予報を構築します現在の状況に応じて水生植物。 また、農学者のコンピューター上で、これらすべてを明確かつわかりやすくインタラクティブに理解する必要があります。 約3か月稼働した後、プロトタイプが組み立てられました。 そして、すべてが上記のツールR + bashで行われます。
さまざまなマウスキャリアと比較して、Rよりも魅力的なものは何ですか？
- これは完全なプログラミング言語です。 最新のHadley Wickhamパッケージは、Rを、データをほとんど宇宙軌道に投入するという便利さへと引き上げました。 関数型プログラミングのサポートも積極的に拡大しています。
- 幅広い数学的パッケージとアルゴリズム。
- devopsに基本的に埋め込みます。 gitのソースには、自己テストのメカニズム、自己文書化の可能性（ R Markdown ）があります。 アジャイル手法のコラボレーションとアプリケーション。
- Stackoverflowコミュニティ。
- ...および他の多くのグッズ。
結論
タスクのペアについてはまだアクティブな作業が進行中ですが、全体として得られた経験により、ローカルの「ステッチング」の問題でほぼすべてのタスクに自信を持って取り組むことができます。 一般的に、一般ユーザーによるRの機能の感覚は次のように説明できます。
経験を一般化する場合、そのような「ステッチング」はほとんどどこでも需要があります。 主なことは、新鮮な外観で見ることです（私たちはTRIZおよび100年または2年遅れの発明に関する文献を読みます）。経営者はリスクを取ることを恐れません。 そのような活動の開始時の基本的な論文は、小さなステップでの昇進です。
理想的なケースでは、作業の結果、小さなコンポーネントが表示されます：
- 必要なすべてのソースからデータを収集し、舞台裏で高度な処理を行います。
- ユーザーに美しいインタラクティブな画像を提供します（すごい効果が望ましいですが、それ自体で終わりではありません）。
- 写真に加えて、最適なソリューションの選択に関する詳細なインタラクティブレポートと推奨事項を提供します。
- 可能な範囲で、他の情報システムで必要な変更を独自に実行します（運用分析の始まり）。
作業範囲は、意図的に最大2か月に制限されています。 原則として、反復的かつインタラクティブな開発により、この期間はさまざまなIPのギャップにあるローカルの問題を概念的に解決することができます。 作業の完了後、結果のコンポーネントを実際のビジネスプロセスに「駆り立て」、効果を予想されたものと比較する必要があります。 タスクが残っているか、新しいタスクが表示される場合は、優先順位を設定して新しい反復を開始します。
重要なことは、各反復が次のことを行うことです。
- 実際のビジネスニーズに基づく。
- ビジネスに真の効果をもたらします。
- 完成し、自給自足。
同時に、重いプロジェクト管理のオーバーヘッドはありません。タスクはスコープ内に表示され、ドキュメントは最小限必要なだけ作成されます。
データサイエンスがビッグデータの応用における複雑な数学的アルゴリズムとして議論される可能性は低いことを改めて指摘します。 実際のビジネスタスクははるかに散文的ですが、それらを解決するメリットは非常に大きい場合があります。 Rツールとデータサイエンスアプローチは、これをうまく機能させることができます。
素晴らしいことは、陰謀が最後まで続くことです。 次のステップと次の要求がどうなるかを事前に知ることはできません。有能な手と明るい頭は、現在の欠点を修正するだけでなく、新しいビジネスチャンスを提供することもできます。
次の投稿： 「ビジネスタスクを自動化するツールとしてのエコシステムR」