概要 第一回の「CASサーバーとSWATパッケージ」に続き、第二回としてCASのアクションセットの活用やCASサーバーへのデータ読み込みなどの基本操作の方法について紹介します。 アクションセットについて CASサーバー上での分析作業を開始する前に、“アクションセット”という重要な概念に関して紹介します。 アクションセットは、関連する機能を実行するアクションの論理的なグループです。 SAS Viyaでは、関数のことを「アクション」、関連する関数のグループを「アクションセット」と呼んでいます。アクションでは、サーバーのセットアップに関する情報を返したり、データをロードしたり、高度な分析を実行するなど、さまざまな処理を実行できます。 アクションセットを使ってみましょう それでは、サンプルコードを使いながら、SAS Viyaのアクションセットでデータの読み込みからプロットまでの一連の操作を説明します。 ・データの読み込み CASサーバーにデータを読み込むには二つの方法があります。一つはread.csv()でcsvファイルをRデータフレームの形で読み込んだ上で、as.casTable()を使用する方法です。この関数はデータをRのデータフレームからCASテーブルにアップロードすることができます。今回の例では金融関連のサンプルデータhmeqを使って紹介します。 library("swat") conn <- CAS(server, port, username, password, protocol = "http") hmeq_data <- read.csv(“hmeq.csv”) hmeq_cas <- as.casTable(conn, hmeq) もう一つはcas.read.csv()を使って、ローカルからファイルを読み込んで、そのままCASサーバーにアップロードする方法です。仕組みとしては、一つ目の方法と大きくは変わりません。 hmeq_cas <- cas.read.csv(conn, hmeq) as.casTable()或いはcas.read.csv()からの出力はCASTableオブジェクトです。その中に、接続情報、作成されたテーブルの名前、テーブルが作成されたcaslib(CASライブラリ)、およびその他の情報が含まれます。 Rのattributes()関数を使えば中身を確認できます。 attributes(hmeq_cas) $conn CAS(hostname=server, port=8777, username=user, session=ca2ed63c-0945-204b-b4f3-8f6e82b133c0, protocol=http) $tname [1] "IRIS" $caslib [1] "CASUSER(user)"
Tag: アナリティクス・ライフサイクル
本シリーズの記事について オープンソースとの統合性はSAS Viyaの一つの重要な製品理念です。SAS言語やGUIだけではなく、R言語やPythonなどのオープンソース言語でも、SAS ViyaのAI&アナリティクス機能を活用することが可能になっています。このシリーズの記事は、R言語からSAS Viyaの機能を活用して、データ準備からモデルの実装までの一連のアナリティクス・ライフサイクル開発をサンプルコードの形で紹介していきます。 CASサーバーとSWATパッケージとは コードの内容を紹介する前に、まずCASサーバーとSWATパッケージに関して、簡単に紹介します。CASはSAS Cloud Analytic Serviceの略称です。SAS Viyaプラットフォームの分析エンジンで、様々な種類のデータソースからデータを読み込み、メモリーにロードし、マルチスレッドかつ分散並列でハイパフォーマンスな分析処理を実行します。現在のCASサーバーは3.4.0以降のバージョンのPythonと3.1.0以降のバージョンのRをサポートしています。 オープンソース言語のクライアントからCASサーバーのインタフェースを使用するために、SASからSWAT(SAS Scripting Wrapper for Analytics Transfer)というパッケージをGithubに公開し、提供しています。RとPythonにそれぞれ対応しているバージョンはありますが、本記事のサンプルコードではR用の SWATをメインで使用します。SWATパッケージを通してCASサーバーと通信し、インタフェースを直接利用することができます。データサイエンティストはSWATパッケージを使用し、RやPythonからSAS Viyaの豊富なAI&アナリティクス機能を活用し、様々なデータ分析処理を行ったり、機械学習や深層学習のモデルを作成したりすることができます。 環境の準備 R言語用SWATパッケージを利用するために必要なRの環境情報は以下の通りです。 ・64-bit版のLinux或いは64-bit版のWindows ・バージョン3.1.0以降の64-bit版のR ・Rパッケージ「dplyr」、「httr」と「jsonlite」がインストールされていること 筆者が使用している環境は64-bit版のWindows 10と64-bit版のR 3.5.3となり、IDEはRstudioです。 パッケージのインストール SWATをインストールするために、標準的なRインストール用関数install.package()を使用します。SWATはGithub上のリリースリストからダウンロードできます。 ダウンロードした後、下記のようなコマンドでSWATをインストールします。 R CMD INSTALL R-swat-X.X.X-platform.tar.gz X.X.Xはバージョン番号であり、platformは使用するプラットフォームと指しています。 或いはRの中から下記のコマンドのようにURLで直接インストールするのもできます。 install.packages('https://github.com/sassoftware/R-swat/releases/download/vX.X.X/R-swat-X.X.X-platform.tar.gz', repos=NULL, type='file') この部分の詳細はR-swatのGitHubのリンクを参考にしてください。 SAS Viyaと一回目の通信をやってみよう 全ての準備作業が完了したら、問題がないことを確認するために、Rから下記のコードを実行してみます。 library("swat") conn <- CAS(server, port, username, password,
この記事はSAS Institute Japanが翻訳および編集したもので、もともとはIvor G. Moanによって執筆されました。元記事はこちらです(英語)。 Webセミナー「Data Preparation in the Analytical Life Cycle」について このWebセミナーでは「アナリティクス・ライフサイクルにおけるデータ準備」というテーマを取り上げ、データ準備の定義と、このライフサイクルの各ステップについて論じています。最初に現在の市場状況とデータ準備に関する人々の見方を考慮に入れた上で、議論の対象は、アナリティクス・ライフサイクルを構成する様々な領域と、データ準備が果たす役割へと移ります。そして最後に、データ・ガバナンスの役割を検討します。この簡潔版のブログ投稿シリーズでは、同Webセミナーから、いくつかの主題を取り上げて論じています。 データ準備の概念と重要性 「データ準備」とは、アナリティクスやビジネスインテリジェンス(BI)で利用するためのデータを収集/処理/クレンジングする工程に含まれる全てのタスクを指します。したがって、データ準備には、アクセス、ロード、構造化、パージ、結合(ジョイン)、データタイプの調整、フィールド値の整合性チェック、重複のチェック、データの統一化(例:1人の人物に2つの誕生日が存在する場合)などが含まれます。 データの量やソースの数が増えるにつれ、適切なデータ準備を行う取り組みは、コストと複雑性がともに増大していきます。そのため、データ準備は今、市場を形成しつつある新たなパラダイムとなっています。また、データ準備は事実上、セルフサービス型のデータ管理の取り組みと化しています。従来のデータ管理プロセスは、ある程度まではデータ統合および準備を実行できますが、今では、ダイナミックかつ詳細な作業や最終段階の作業に関しては、データ準備ツールを用いてセルフサービス方式で実行されるようになりつつあります。 明らかなことは、データを整形し、アナリティクスに適した状態にする上でデータ準備がますます重要になりつつある、ということです。今では、以前よりも多くの企業がデータドリブン(データ駆動型)を実現しています。それらの企業はデータに基づいて意思決定を行いますから、「データに素早くアクセスし、分析に適した状態に準備できること」が極めて重要です。Hadoopなどのビッグデータ環境は、「それらの環境からデータを移動することが不可能」ということを意味します(が、それは問題とはなりません)。その代わり、「アナリティクス向けにデータを準備する工程の一環として、ビッグデータを適切な場所で適切に処理し、その結果のデータを他のソースと組み合わせること」が重要となります。 したがって、データ準備は、あらゆるアナリティクス・プロジェクトの不可欠な構成要素と言えます。適切なデータを取得し、それを適切な状態に準備することによってこそ、アナリティクスの疑問に対して優れた答えを得ることが可能になるのです。質の低いデータや不適切に準備されたデータを使用すると、分析結果が「信頼に足るもの」になる可能性は低下してしまいます。 アナリティクス・ライフサイクルにおけるデータ準備を理解する アナリティクス・ライフサイクルには「ディスカバリー」および「デプロイメント」という2つの主要なフェーズが存在します。「ディスカバリー」プロセスは、イノベーションを生み出すビジネス上の疑問を提起することによって推進されます。したがって最初のステップは、ビジネスにおいて何を知る必要があるかを定義することです。その後、ビジネス上の疑問は「問題を説明する表現」へと変換され、その結果、予測的アナリティクスを用いてその問題を解決することが可能になります。 そして言うまでもなく、予測的アナリティクスを利用するためには、適切に準備された適切なデータが必要不可欠です。Hadoopや高速化・低価格化するコンピューターといったテクノロジーの進歩により、従来では考えられなかったほど大量かつ多様なデータを蓄積し利用することが可能になっています。しかしながら、この動向は、多種多様なフォーマットのソースデータを結合する必要性や、生データを “予測モデルへの入力として利用できる状態” に変換する必要性を増大させたにすぎません。コネクテッド・デバイスが生成する新しいタイプのデータ(例:マシンセンサー・データやオンライン行動のWebログなど)の出現により、「データ準備」段階は以前にも増して難しい課題領域となっています。多くの組織は依然として、「データ準備タスクに過大な時間を費やしており、場合によっては[全作業時間の]最大80%を占めている」と報告しています。 データ準備は継続的なプロセスである データ探索では、対話操作型かつセルフサービス型のビジュアライゼーションツール群を活用します。これらのツールは、統計知識を持たないビジネスユーザーから、アナリティクスに通じたデータサイエンティストまで、幅広いユーザーに対応している必要があります。また、これらのユーザーが関係性/トレンド/パターンを洗い出し、データに関する理解を深めることを可能にしなければなりません。言い換えると、このステップ(=探索)では、プロジェクト初期の「疑問提起」段階で形成された疑問やアプローチを洗練させた上で、そのビジネス課題を解決する方法についてアイディアの開発とテストを行います。ただし、より照準を絞ったモデルを作成するために変数の追加/削除/結合が必要になる可能性もあり、その場合は当然、「データ準備」を再び実行することになります。 「モデル作成」段階では、分析モデルや機械学習モデルを作成するためのアルゴリズムを使用します。その目的は、データ内に潜む関係性を浮き彫りにし、ビジネス上の疑問を解決するための最良のオプションを見つけ出すことです。アナリティクス・ツールは、データとモデリング手法をどのように組み合わせれば望ましい結果を高い信頼性で予測できるかを特定するために役立ちます。常に最高のパフォーマンスを発揮する唯一万能のアルゴリズムは存在しません。そのビジネス課題を解決するための “最良” のアルゴリズムが何であるかは、そのデータによって決まります。最も信頼性の高い解を見つけるためのカギは実験を繰り返すことです。適切なツールでモデル作成を自動化することにより、結果が得られるまでの時間が最小化され、アナリティクス・チームの生産性が向上します。そして、ここでも再び、さらなるデータが追加される可能性があります。 常に最高のパフォーマンスを発揮する唯一万能のアルゴリズムは存在しません。そのビジネス課題を解決するための “最良” のアルゴリズムが何であるかは、そのデータによって決まります。 「実装」段階へ もちろん、モデルの作成が済んだら、それらをデプロイ(=業務システムに組み込んで運用)する必要があります。しかし、その後も「データ準備」の取り組みは停止しません。モデルの良否はそれが利用するデータに左右されるため、モデル(およびデータ)については鮮度を維持し続けなければなりません。データ準備とデータ管理は、極めて継続的なプロセスなのです。
この記事はSAS Institute Japanが翻訳および編集したもので、もともとはIvor G. Moanによって執筆されました。元記事はこちらです(英語)。 Webセミナー「Data Preparation in the Analytical Life Cycle」について 我々は最近、「アナリティクス・ライライクルにおけるデータ準備」に関するWebセミナーを録画しました。このセミナーでは、データ準備の定義と、アナリティクス・ライフサイクルの各ステップの概要を押さえた上で、現在の市場状況とデータ準備に関する人々の見方を確認します。その後、議論の対象は、アナリティクス・ライフサイクルを構成する様々な領域と、データ準備が果たす役割へと移ります。そして最後に、データガバナンスの役割を検討します。 この簡潔版のブログ投稿シリーズでは、同Webセミナーから、いくつかの主題を取り上げて論じています。 昨今では、欧州連合(EU)の「一般データ保護規則(General Data Protection Regulation: GDPR)」やその他の規制の結果として、データ管理に関する新たなガバナンス要件が出現しています。これらの要件はデータ準備プロセスに対し、いくつかの興味深い影響を及ぼしています。この投稿はデータ準備に関する投稿シリーズの第3弾であり、この分野に見られる最近の変化と、それらが業務にどのように影響を与えているかに注目します(シリーズ第1弾はこちら、第2弾はこちら)。また今回は、「アナリティクス・ライフサイクルにおけるデータ準備」工程を整備する取り組みに関して、いくつかの重要な教訓を引き出します。 データガバナンスは必須であり、「データ準備」工程もその対象である これは非常に重要なポイントです。データ準備は、多くの企業や組織にとって目新しい領域かもしれません。特に、これを独立した領域として扱うアプローチに関しては、馴染みが薄いでしょう。しかしながら、データ準備のプロセスが組織のデータガバナンス・プロセスおよびルールに準拠しなければならない点が変わるわけではありません。これはデータ統合/データ管理ソリューションにも当てはまります。言い換えると、全てのデータ関連プロセスは、組織の総合的なデータガバナンス・プロセスに適合しなければなりません。 データ準備はなぜ重要なのでしょうか? 第一の理由は、アナリティクスの取り組みの大部分が、アナリティクス・ライフサイクル全体にわたって様々なユーザーグループ(例: IT部門、データサイエンティスト、ビジネスユーザー)の協働作業によって行われるからです。全てのユーザーが同じデータと同じ原則を用いて作業する必要があり、さもないと、分析モデルの作成結果は、最良の場合でも「あいまい」となり、最悪の場合は「全くの的外れ」となりかねません。 ガバナンスは用語集の整備を促進し、透明性の向上を実現することができます。 このコラボレーションは、データガバナンス原則に従わなければならず、また、この原則によって推進されなければなりません。これは言い換えると、データガバナンスは、このプロセス[=アナリティクス・ライフサイクル]の重要な構成要素であり、また、相互協力や協働作業の向上を実現するために活用されるべきである、ということです。データガバナンスは決して、「ありとあらゆる手を尽くして克服または迂回する必要のある障害物」と見なされるべきではありません。 ガバナンスは用語集の整備を促進し、透明性の向上を実現することができます。これは実際問題としては、「毎日データを用いて作業するわけではない非技術系のビジネスユーザーでも、自律的に取り組むことができ、セルフサービス操作でデータ品質を心配することなく必要な情報を取得できるようになる」ということを意味します。また、組織の側では「全てのユーザーが高品質なデータを取得していること」、そして「データが法的または倫理的な要件に則して適切に利用されていること」を確信できるようになります。 データ準備は継続的なプロセスである データ探索では、対話操作型かつセルフサービス型のビジュアライゼーションツール群を活用します。これらのツールは、統計知識を持たないビジネスユーザーから、アナリティクスに通じたデータサイエンティストまで、幅広いユーザーに対応している必要があります。また、これらのユーザーが関係性/トレンド/パターンを洗い出し、データに関する理解を深めることを可能にしなければなりません。言い換えると、このステップ(=探索)では、プロジェクト初期の「疑問提起」段階で形成された疑問やアプローチを洗練させた上で、そのビジネス課題を解決する方法についてアイディアの開発とテストを行います。ただし、より照準を絞ったモデルを作成するために変数の追加/削除/結合が必要になる可能性もあり、その場合は当然、「データ準備」を再び実行することになります。 セルフサービスとデータ準備 したがって、現代のデータ準備ツールは、セルフサービスを加速できるようにデータガバナンス機能と緊密に連携しなければなりません。セルフサービス・アナリティクスが機能するのは、セルフサービス型のデータ準備環境と一緒に運用される場合のみです。残念なことですが、「セルフサービス・アナリティクスへのアクセスを与えられても高品質なデータを利用できない状況に置かれたビジネスユーザーは、利用できるソースが何であれ、そこから単純に品質を検討することなく、自身が必要とするデータを引き出すだけであり、その場合でも結果は良好だろうと思い込んで疑わない」というのは真実です。また、アナリティクス・ライフサイクルが真に機能するのは、あらゆる場所にセルフサービスを整備した場合のみです。 したがって、「アナリティクス・ライフサイクルにおけるデータ準備」については、2つの重要なメッセージがあります。 恐らく最も重要なのは、アナリティクス・ライフサイクルは統合型のプロセスである、と理解することです。このプロセス内で活動するユーザーグループは多岐にわたり、このライフサイクルの様々な段階で運用されるツールも多種多様です。そのため、「調和のとれたコラボレーション」と「各段階間の遷移の容易さ」が極めて重要なのです。 恐らく最も重要なのは、アナリティクス・ライフサイクルは統合型のプロセスである、と理解することです。 私は、アナリティクスとデータ準備 ── ここでの「データ準備」とはデータ品質、データ統合、データガバナンスを確保するプロセスを意味します ── の両方をカバーする統合アナリティクス・プラットフォームこそがアナリティクス・ライフサイクル全体を促進する、と考えます。これは非常に重要なポイントです。アナリティクス・プロセスを加速したいとお考えのお客様の場合は特に、統合プラットフォームが優れた効果を発揮します。 第二の重要ポイントは、データガバナンスが担う中心的役割です。私の経験によると、ガバナンスは、アナリティクス・ライフサイクル内でセルフサービスを実現するために不可欠なサポート機能です。ユーザーが自立して行動し、例えば用語集を利用して、あるいはメタデータ管理機能を通じて、利用したいデータや適切なコンテキストに即したデータについて自身が必要とする知識を入手できる、ということは極めて重要です。したがって、ガバナンスはアナリティクス・ライフサイクルの必要不可欠な構成要素である、と言えるのです。 詳しい情報については、「アナリティクス・ライフサイクルにおけるデータ準備」について論じているWebセミナー(英語)をご覧ください(視聴にはユーザー登録が必要です)。
この記事はSAS Institute Japanが翻訳および編集したもので、もともとはIvor G. Moanによって執筆されました。元記事はこちらです(英語)。 Webセミナー「Data Preparation in the Analytical Life Cycle」について このWebセミナーでは「アナリティクス・ライフサイクルにおけるデータ準備」というテーマを取り上げ、データ準備の定義と、このライフサイクルの各ステップについて論じています。最初に現在の市場状況とデータ準備に関する人々の見方を考慮に入れた上で、議論の対象は、アナリティクス・ライフサイクルを構成する様々な領域と、データ準備が果たす役割へと移ります。そして最後に、データ・ガバナンスの役割を検討します。この簡潔版のブログ投稿シリーズでは、同Webセミナーから、いくつかの主題を取り上げて論じています。 この投稿は、アナリティクス・ライフサイクルにおけるデータ準備の役割に関するWebセミナーに基づく投稿シリーズの第2弾です。第1弾では、データ準備がアナリティクス・ライフサイクルの中にどのようにフィットするかを論じました。この投稿では、データ準備に関するいくつかのトレンドと、その結果として進化を遂げた構造やプロセスのいくつかを取り上げて検討します。現在のデータ準備パターンの形成を推進してきた主な課題は2つあります。それは、顧客需要に関する課題とデータ品質に関する課題です。 顧客需要 データ準備に関する現状の大部分は、データ量とデータソース数の増大によって推進されています。ビッグデータの出現は、データ・フォーマットの種類の増加や、ソーシャルメディアやマシンセンサーのような新しいデータソースの出現と相まって、データの保管や利用が難しくなることを意味しました。それと同時に、組織や企業は「意思決定をサポートするためにデータを効果的に活用することが、ますます必要不可欠になっている」ということを認識するようになりました。 ユーザーはより一層多くのデータを必要としています。彼らは手元のデータと外部のデータの両方を分析に含められるようになりたいと考えています。セルフサービスの人気が高まっているのは、柔軟性と自律性が高く、より低コストで、より高速であることに加え、統制も容易だからです。また、他の部門のために行う作業が減少します。 ガードナー社は以前、次のようにコメントしました。「セルフサービス型のデータ準備ソフトウェアの市場は、2019年までに10億ドル(1,100億円、1ドル110円換算)に達し、16.6%の年間成長率を示すと想定されます。潜在的なターゲット・ユーザーにおける現在の導入率は5%であり、これが2020年までには10%以上に成長すると想定されます。ベンダーは自社のビジネス戦略を計画する際に、この市場機会を理解しなければなりません」。しかしながら、セルフサービスのこうした急速な普及は、データサイエンティストにとって頭痛の種を生み出します。セルフサービスは高品質なデータ準備を必要としますが、残念ながら、それには時間がかかり、近道はほとんど存在しません。 データ準備工程からアナリティクス工程へのスムーズな遷移は極めて重要です。その実現には強力なアナリティクス機能とビジュアライゼーション機能が必要となりますが、ユーザーが必要な情報をデータから素早く引き出せるようにするためには強力なデータ管理も必要です。 データ準備工程からアナリティクス工程へのスムーズな遷移は極めて重要です。その実現には強力なアナリティクス機能とビジュアライゼーション機能が必要となりますが、ユーザーが必要な情報をデータから素早く引き出せるようにするためには強力なデータ管理も必要です。動きの速い市場では、俊敏な企業になる必要があります! こうした状況を受け、多くの企業では、データ準備やソフトウェア・エンジニアリングを担当するデータエンジニアという新たな職務役割が台頭しています。データエンジニアの仕事は、分析モデルの作成を行うデータサイエンティストにデータを渡す前に行われます。 データ品質の重要性 この新しい台頭中のデータエンジニアという仕事の役割は、データ品質が不可欠であるという事実の認識が広がっていることの証と言えます。言い換えると、データ管理とは、データの収集や整形を行うことだけでなく、データの品質が適切である状態を確保することでもある、ということです。したがって、データ品質は、データ準備の領域においても必要不可欠なテーマとなりつつあります。 SASは以前から、この領域の先頭を走り続けてきました。我々は相当以前から、「データ準備は単なるデータ読み込みに留まらない工程であり、データ品質の問題も含める必要のある工程である」と認識していました。アナリティクス手法はその入力として、価値の高いデータを必要とします。入力データがクリーンかつ高品質でない場合、出力はそれに応じて劣悪なものとなります。なぜなら、アナリティクス手法には、「ゴミを入れれば、ゴミしか出てこない」という格言がまさに当てはまるからです。 入力データがクリーンかつ高品質でない場合、出力はそれに応じて劣悪なものとなります。なぜなら、アナリティクス手法には、「ゴミを入れれば、ゴミしか出てこない」という格言がまさに当てはまるからです。 データの確認と修正 例えばSAS® Data Preparationでは、ユーザーは、どのようなデータがインポート済みで、どのようなデータが利用できるかを見ることができます。ユーザーはデータのサンプルを見てその感触を得ることができ、初見の段階で全てが一目瞭然です。しかも、ユーザーはデータ・プロファイルを見れば、もう少し詳しい情報を確認することもできます。プロファイルには、データが様々な形態で保管されている(例:正式名称と略語が混在している)という情報が示される可能性があります。こうしたデータ状態は、分析モデルに深刻な問題を引き起こしかねないため、複数の異なるデータソースを統合する前の段階で解決されなければなりません。 したがって基本的には、そのデータには今すぐ修正や標準化が必要です。この目的のために利用できる可能性のある解決手段は、いくつも存在します。例えば時系列分析の場合、我々はデータをフィルタリングし、欠損値を含む全ての項目を除去することができます。あるいは、データの表記法に一貫性がない場合には、異常値や重複を除去するために、そのデータを訂正およびクレンジングする必要があります。こうした操作の全てがデータ準備の重要な構成要素であり、それに関する認識と重要性がともに高まり続けているのです。 将来に向かって進むために これら2つの領域(顧客需要とデータ品質)は、データ準備とデータ管理の領域において、および、そこで利用可能なツールにおいて、近年の発展を非常に強力に推進してきました。セルフサービス型のツールは、ますますユビキタスな存在となっており、データ品質を確保する機能要素との組み合わせによって、あらゆる領域で最良のソリューションを実現しています。 次回の投稿では、データ管理に関する新たな規制やガバナンス要件を取り上げます。
近年、AIや機械学習がブームとなり、キーワードだけが先走りしている傾向にあります。結果、「AI・機械学習を活用する」こと自体が目的化し、ツールや環境を導入したものの、ビジネス価値創出に至らないケースも多いようです。 その最大の要因は、肝となる「アナリティクス・ライフサイクル」の欠如にあります。 まず、業務課題を明確化した上で、その課題を解決するためにはデータ分析が必要であり、分析には元となるデータが必要になります。必要なデータを準備し、その中身を探索し、その結果に基づいて予測モデルを開発し、作成されたモデルを業務に実装する、このサイクルを素早く回し続ける、これが、企業が抱える業務課題を解決し、ビジネス価値(収益の拡大、コストの削減、リスクの低減、など)を創出するための鍵なのです。 アナリティクス・ライフサイクルを構成する3つの要素: アナリティクス・ライフサイクルを素早く回すためには、上記3つの要素がシームレスに連携する必要があります。しかし、多くの企業では、従来から、複数の異なるベンダーの異なる商用ソフトウエアや環境、あるいはオープンソースソフトウエアなどを継ぎ接ぎして分析環境を構築してきたため、このサイクルを回すためには多大な時間を擁してしまい、変化への素早い対応は困難な状況にありました。 この課題に対して、AIプラットフォーム SAS® Viya®では、アナリティクス・ライフサイクルに必要な機能要素を網羅した上で、それぞれがシームレスに連携し、高速に回し続けることが可能となっています。 そして、SAS Viyaには、分析者のスキルレベルに応じて、プログラミングインターフェースとグラフィカルインターフェースの両方が備わっています。 データサイエンティストであれば、データの準備から探索、そしてモデル生成までをお好みの言語(SAS, Python, R, Java, Lua)を使用して実施することができます。 一方で、コーディングスキルを持たないビジネスユーザーであれば、統合グラフィカルユーザーインターフェース上でアナリティクス・ライフサイクルをシームレスかつ高速に回し続けることが可能となっています。 企業が、その企業の競合企業よりも早く、正確に、アナリティクス・ライフサイクルを回すことによって、以下が実現されます。: より多くの反応率の高いマーケティングキャンペーンをより早く実施し、より多くの新規顧客を獲得し、既存顧客の離反を防止 より早く正確に、より多くの製造設備の異常予兆を検出し、設備のダウンタイムを最小化し、生産量を最大化 より多くの種類の不正をより早く正確に検知し、不正により齎されるリスクや損失を低減し、企業の信頼度を向上 企業を取り巻く環境の変化に、より素早く対応 …など Data:データの準備 異なる分析要件ごとに、分析者自身で、分析に必要なデータは都度準備する必要があります。SAS Viyaでは、分析者自身で分析に必要なデータをセルフサービス型で準備することができるようになっています。 マウスのポイント&クリック操作だけで、データのプロファイリングからクレンジング、加工・変換・結合などを自由自在に行うことができ、分析プロセス全体の中で7、8割の工数を占めると言われるデータ準備工数や時間を大幅に削減することが可能となります。 Discovery:データの探索とモデル生成 次に、準備したデータの中身を探索します。SAS Viyaでは、コーディングスキルを持たないビジネスユーザーでもマウスの簡単操作だけで、データの探索や分析が可能になっています。単一の画面内で、過去の見える化から高度な機械学習までもが可能で、できあがった画面をレポートやダッシュボードとして即座に全社に公開し、共有することもできます。 データサイエンティストであれば、モデル生成の手前のビジュアルなデータ探索手段として活用することができます。 データ探索の結果に基づき、予測モデルを構築します。 SAS Viyaでは、ビジュアルなUIからマウスのドラッグ&ドロップ操作で、機械学習、時系列予測、テキスト解析の各種モデル生成プロセスをグラフィカルなフロー図(パイプライン)として描き、実行することが可能になっています。 このモデル生成パイプラインは、ドラッグ操作で一から作り上げることもできますし、SASの長年のベストプラクティスに基づき、予め用意されているパイプラインのテンプレートを使用して、精度の高い予測モデルを自動生成することも可能です。 Deployment:モデルの業務実装 生成されたモデルは統合的に管理した上で、業務に実装することができます。 モデル管理画面では、モデルにテストデータを当てはめてスコアリングテストの実施や、モデルのデプロイ(業務実装)、業務に実装後のモデル精度のモニタリング、再学習を実行し、モデル精度を改善、そしてバージョン管理など、モデルを統合管理することができます。 管理されたモデルは、異なる業務要件ごとに異なる環境へデプロイ(業務実装)することができます。 REST API:既存のアプリケーションからREST APIを通じて、SAS Viyaサーバー上にあるモデルにデータを当てはめてスコアリング(予測処理)を行い、結果を受け取ることができます。 インデータベース:モデルをデータベース内にデプロイし、データベース内で直接スコアリングを実施することができます。これによって、スコアリング対象の大量のデータを転送する必要が無くなり、処理の効率化や意思決定の迅速化も図れます。 インストリーム:SAS Viyaには、オンライン機械学習・リアルタイム処理向けにストリーミングのエンジンも実装されています。SAS Viyaのリアルタイムプロセスにモデルをデプロイすることで、リアルタイム・スコアリングも実現されます。 以上のように、企業が業務課題を解決し、ビジネス価値を創出するためには、「アナリティクス・ライフサイクル」が肝であり、このサイクルをシームレスかつ素早く回し続けることが、企業の変化対応力、競争力強化に直結するということです。 従来からSASを活用し、ビジネス価値を出している企業はすべてこのサイクルを回し続けています。そして、AIプラットフォームSAS Viyaでは、これを強力に支援することができるということです。