Data Management

Understand why managing your data is essential for analytics

Data Management | Programming Tips
SASからMicrosoft AzureのBlobストレージ内データにアクセスする方法(第1回)

近年、クラウドベンダーが提供するサービスが充実し、より多くのクラウドサービスが誕生してきました。しかし、一つのニーズに対して、複数のサービスを選択できるようになってきているものの、どのサービスが最適なのかを判断することは逆に難しくなってきていると考えられます。最近、SASを活用しているお客様から、「Microsoft社のAzureを使っていますが、これからクラウドにデータを移行して、安くて使い勝手なストレージサービスは何かありませんか」と聞かれたこともありました。 このブログシリーズでは、クラウド上のストレージサービスの一種であるMicrosoft Azure CloudのBlobストレージサービスの概要を紹介した上で、SAS ViyaからそのBlock Blobストレージに格納されているデータへアクセスする方法をご紹介させていただきます。 このブログシリーズは合計2回です。今回のブログでは、まず特定の一つファイルへのアクセス方法をご紹介します。次回のブログでは、より汎用的なアクセス方法、つまり、Blobストレージを一つのファイルシステムとして、SASサーバと連携し、一度に複数のデータにアクセスする方法をご紹介します。ぜひ最後まで、お付き合いいただければと思います。 第1回:https://blogs.sas.com/content/sasjapan/2020/10/01/sas-azure-blob-1/  第2回:https://blogs.sas.com/content/sasjapan/2020/10/05/sas-azure-blob-2/ Blobストレージとは何か? まず、Blobストレージとは何かを紹介する前に、Blobって何でしょうか、から始めます。聞きなれない方もいらっしゃるかと思いますので。実際、BlobはBinary Large OBjectの略称です。本来はデータベースで用いられているデータタイプの種類で、メディアファイルや、圧縮ファイル、実行ファイルなどのデータを格納する時に使用されているものです。 では、Blobストレージとは何か?Microsoft社の紹介では、こう書かれています。 「Blob Storage は、テキスト・データやバイナリ・データなどの大量の非構造化データを格納するために最適化されています。非構造化データとは、特定のデータ・モデルや定義に従っていないデータであり、テキスト・データやバイナリ・データなどがあります。」 少し言い換えますと、Blobストレージは、ログファイルから、画像ファイルやビデオ・オーディオファイルまで格納できます。もちろん、通常目的でのデータ利用にも対応しているため、データの格納場所として使っても問題ありません。(Microsoft Azureの資料によりますと、4.75 TiBまで可能です。) なぜBlobストレージなのか 前文で少し申し上げたSASのお客様から頂いた質問の中で、「安くて使い勝手の良いストレージサービスは」と聞かれた事に関して、安いというポイントに関しては、下記の図をご覧ください。 ソース:https://azure.microsoft.com/ja-jp/pricing/details/storage/(2020/09/09アクセス時点) ご覧のように、ブロックBlobのストレージサービスは、安価で、かつ非構造化データに対応し、一般目的でのデータストレージとして、非常に向いています。 もちろん、ビジネスケースによっては、様々考慮すべき点(既存環境にHadoop環境があるかどうか、スループット、ビッグデータ等々)もありますが、今回は、主にこのブロックBlobストレージを例として紹介します。 SAS ViyaからBlobストレージにアクセスする方法 ここからは、SAS ViyaからBlobストレージにアクセスする方法をご紹介します。下記の方法を使うために、前提条件として、SAS ViyaサーバとBlobストレージがあるAzure間でネットワーク通信ができる必要がありますので、ネットワークセキュリティ条件を確認してから、下記の方法をお試しください。 方法①: SASのPROC HTTPプロシージャを使って、Blobストレージ内の特定の一つのデータにアクセスする方法。 Microsoft Azure側: 1.まず、Azureポータルに入り、「すべてのリソース」をクリックします。(図1-1) 図1-1 2.その配下で、利用されているストレージアカウントをクリックします。(図1-2) 図1-2 3.次に、表示された左側のメニューの中で、「Blob Service」配下のコンテナーをクリックします。(図1-3) 図1-3 *豆知識: ここで、いきなりコンテナーが出てくることに関して、混乱している方もいらっしゃるかもしれないので、少し解説します。こちらのコンテナーとは、Dockerコンテナーの意味ではありません。Blobストレージサービス配下のデータ格納用のサブ階層のことであり、フォルダーのようなものとイメージしてください。(図1-4) 図1-4 4.上記図1-3のように、その中に一つ「folderfirst」というコンテナーが存在しており、それをクリックすると、中に保管されているデータが見えるようになります。(図1-5) 図1-5 5.ここからが重要なポイントです。特定のデータ、例えば、「sas7bdat」データにSAS Viyaからアクセスしたい場合は、該当ファイルの名前をクリックして、下記のようなプロパティ情報を表示させます。(図1-6) 図1-6

Data Management
SAS Japan 0
アナリティクス・ライフサイクルにおけるデータ準備 ─ データ準備の重要性

この記事はSAS Institute Japanが翻訳および編集したもので、もともとはIvor G. Moanによって執筆されました。元記事はこちらです(英語)。 Webセミナー「Data Preparation in the Analytical Life Cycle」について このWebセミナーでは「アナリティクス・ライフサイクルにおけるデータ準備」というテーマを取り上げ、データ準備の定義と、このライフサイクルの各ステップについて論じています。最初に現在の市場状況とデータ準備に関する人々の見方を考慮に入れた上で、議論の対象は、アナリティクス・ライフサイクルを構成する様々な領域と、データ準備が果たす役割へと移ります。そして最後に、データ・ガバナンスの役割を検討します。この簡潔版のブログ投稿シリーズでは、同Webセミナーから、いくつかの主題を取り上げて論じています。 データ準備の概念と重要性 「データ準備」とは、アナリティクスやビジネスインテリジェンス(BI)で利用するためのデータを収集/処理/クレンジングする工程に含まれる全てのタスクを指します。したがって、データ準備には、アクセス、ロード、構造化、パージ、結合(ジョイン)、データタイプの調整、フィールド値の整合性チェック、重複のチェック、データの統一化(例:1人の人物に2つの誕生日が存在する場合)などが含まれます。 データの量やソースの数が増えるにつれ、適切なデータ準備を行う取り組みは、コストと複雑性がともに増大していきます。そのため、データ準備は今、市場を形成しつつある新たなパラダイムとなっています。また、データ準備は事実上、セルフサービス型のデータ管理の取り組みと化しています。従来のデータ管理プロセスは、ある程度まではデータ統合および準備を実行できますが、今では、ダイナミックかつ詳細な作業や最終段階の作業に関しては、データ準備ツールを用いてセルフサービス方式で実行されるようになりつつあります。 明らかなことは、データを整形し、アナリティクスに適した状態にする上でデータ準備がますます重要になりつつある、ということです。今では、以前よりも多くの企業がデータドリブン(データ駆動型)を実現しています。それらの企業はデータに基づいて意思決定を行いますから、「データに素早くアクセスし、分析に適した状態に準備できること」が極めて重要です。Hadoopなどのビッグデータ環境は、「それらの環境からデータを移動することが不可能」ということを意味します(が、それは問題とはなりません)。その代わり、「アナリティクス向けにデータを準備する工程の一環として、ビッグデータを適切な場所で適切に処理し、その結果のデータを他のソースと組み合わせること」が重要となります。 したがって、データ準備は、あらゆるアナリティクス・プロジェクトの不可欠な構成要素と言えます。適切なデータを取得し、それを適切な状態に準備することによってこそ、アナリティクスの疑問に対して優れた答えを得ることが可能になるのです。質の低いデータや不適切に準備されたデータを使用すると、分析結果が「信頼に足るもの」になる可能性は低下してしまいます。 アナリティクス・ライフサイクルにおけるデータ準備を理解する アナリティクス・ライフサイクルには「ディスカバリー」および「デプロイメント」という2つの主要なフェーズが存在します。「ディスカバリー」プロセスは、イノベーションを生み出すビジネス上の疑問を提起することによって推進されます。したがって最初のステップは、ビジネスにおいて何を知る必要があるかを定義することです。その後、ビジネス上の疑問は「問題を説明する表現」へと変換され、その結果、予測的アナリティクスを用いてその問題を解決することが可能になります。 そして言うまでもなく、予測的アナリティクスを利用するためには、適切に準備された適切なデータが必要不可欠です。Hadoopや高速化・低価格化するコンピューターといったテクノロジーの進歩により、従来では考えられなかったほど大量かつ多様なデータを蓄積し利用することが可能になっています。しかしながら、この動向は、多種多様なフォーマットのソースデータを結合する必要性や、生データを “予測モデルへの入力として利用できる状態” に変換する必要性を増大させたにすぎません。コネクテッド・デバイスが生成する新しいタイプのデータ(例:マシンセンサー・データやオンライン行動のWebログなど)の出現により、「データ準備」段階は以前にも増して難しい課題領域となっています。多くの組織は依然として、「データ準備タスクに過大な時間を費やしており、場合によっては[全作業時間の]最大80%を占めている」と報告しています。 データ準備は継続的なプロセスである データ探索では、対話操作型かつセルフサービス型のビジュアライゼーションツール群を活用します。これらのツールは、統計知識を持たないビジネスユーザーから、アナリティクスに通じたデータサイエンティストまで、幅広いユーザーに対応している必要があります。また、これらのユーザーが関係性/トレンド/パターンを洗い出し、データに関する理解を深めることを可能にしなければなりません。言い換えると、このステップ(=探索)では、プロジェクト初期の「疑問提起」段階で形成された疑問やアプローチを洗練させた上で、そのビジネス課題を解決する方法についてアイディアの開発とテストを行います。ただし、より照準を絞ったモデルを作成するために変数の追加/削除/結合が必要になる可能性もあり、その場合は当然、「データ準備」を再び実行することになります。 「モデル作成」段階では、分析モデルや機械学習モデルを作成するためのアルゴリズムを使用します。その目的は、データ内に潜む関係性を浮き彫りにし、ビジネス上の疑問を解決するための最良のオプションを見つけ出すことです。アナリティクス・ツールは、データとモデリング手法をどのように組み合わせれば望ましい結果を高い信頼性で予測できるかを特定するために役立ちます。常に最高のパフォーマンスを発揮する唯一万能のアルゴリズムは存在しません。そのビジネス課題を解決するための “最良” のアルゴリズムが何であるかは、そのデータによって決まります。最も信頼性の高い解を見つけるためのカギは実験を繰り返すことです。適切なツールでモデル作成を自動化することにより、結果が得られるまでの時間が最小化され、アナリティクス・チームの生産性が向上します。そして、ここでも再び、さらなるデータが追加される可能性があります。 常に最高のパフォーマンスを発揮する唯一万能のアルゴリズムは存在しません。そのビジネス課題を解決するための “最良” のアルゴリズムが何であるかは、そのデータによって決まります。 「実装」段階へ もちろん、モデルの作成が済んだら、それらをデプロイ(=業務システムに組み込んで運用)する必要があります。しかし、その後も「データ準備」の取り組みは停止しません。モデルの良否はそれが利用するデータに左右されるため、モデル(およびデータ)については鮮度を維持し続けなければなりません。データ準備とデータ管理は、極めて継続的なプロセスなのです。

Data Management
SAS Japan 0
アナリティクス・ライフサイクルにおけるデータ準備 ─ ガバナンス、品質、準備

この記事は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セミナー(英語)をご覧ください(視聴にはユーザー登録が必要です)。

Data Management
SAS Japan 0
アナリティクス・ライフサイクルにおけるデータ準備 ─ 準備作業のトレンド

この記事は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つの領域(顧客需要とデータ品質)は、データ準備とデータ管理の領域において、および、そこで利用可能なツールにおいて、近年の発展を非常に強力に推進してきました。セルフサービス型のツールは、ますますユビキタスな存在となっており、データ品質を確保する機能要素との組み合わせによって、あらゆる領域で最良のソリューションを実現しています。 次回の投稿では、データ管理に関する新たな規制やガバナンス要件を取り上げます。  

Analytics | Data Management
SAS Japan 0
データ品質を改善する7つのアナリティクス手法

この記事はSAS Institute Japanが翻訳および編集したもので、もともとはGerhard Svolbaによって執筆されました。元記事はこちらです(英語)。 データサイエンティストはデータの取り扱いに多くの時間を費やします。データ品質は、ビジネス課題を解決するために機械学習を適用したり、AIモデルをトレーニングしたりする上での必須要件です。しかし、アナリティクスとデータサイエンスは、データ品質に関する要件を引き上げるだけではありません。データ品質の改善に多大な貢献を果たすこともできます。 欠損値の補完と複雑な外れ値の検出は、恐らくデータ品質に関して最もよく知られた2大アナリティクス機能ですが、決してこの2つだけがそうした機能というわけではありません。本稿では、アナリティクスでデータ品質を改善できる7つの方法についてご説明します 1. 外れ値の検出 アナリティクスは、標準偏差や分位数のような統計的指標に基づく外れ値検出において重要な役割を果たします。これにより、各変量ごとの外れ値の検出が可能になります。また、外れ値検出には、クラスター分析や距離尺度の手法を含めることもできます。これらの手法は、多変量の観点からデータ内の外れ値や異常値を特定することを可能にします。 予測モデルや時系列手法を用いた個々の外れ値検出は、許容範囲や最適な修正値を個別に計算することを可能にします。全体平均は、望ましくないバイアスを分析に混入させる恐れがありますが、グループ内平均はそれに代わる優れた選択肢となる可能性があります。 アナリティクスとデータサイエンスは、外れ値や妥当性の無い値の検出や特定を実行するための手法を提供するだけでなく、代わりに使用すべき最も蓋然性の高い値に関する提案も行います。 2. 欠損値の補完 アナリティクスは、横断的データや時系列データの中の欠損値に対する代替値を提供することができます。平均ベースの手法から、個別の補完値を生成する手法まで、様々な補完手法が存在しますが、いずれも決定木や、時系列向けのスプライン補完のようなアナリティクス手法に基づいています。欠損値の補完により、不完全なデータセットでも分析に使用することが可能になります。 3. データの標準化と重複除去 分析するに当たってユニークキーが利用できないデータベースの中で重複を特定および排除するタスクは、レコード間の類似度を記述する統計的手法に基づいて実行することが可能です。これらの手法は、住所、氏名、電話番号、口座番号のような情報に基づき、レコード間の近接度や類似度に関する指標を提供します。 4. 様々に異なるデータ量のハンドリング アナリティクスを活用すると、サンプルサイズの設計と検定力分析が求められる対照実験のための最適なサンプルサイズの設計が容易になります。予測モデル作成時にサンプルが小さい場合や、イベント数が少ない場合のために、アナリティクスは希少イベントをモデル化するための手法を提供します。時系列予測に関しても、アナリティクスでは、いわゆる「間欠需要モデル」を利用できます。このモデルは、不定期かつ低頻度に発生する非ゼロ数量のみを用いて時系列をモデル化します。 5. アナリティクスに基づく入力変数変換 アナリティクス手法は、選択した分析手法に適合するように、分布に対する変数変換を実行できます。対数変換や平方根変換は、例えば、「右に裾を引いているデータ」を正規分布に変換するために使用されます。 多くのカテゴリーを伴う変数に関しては、アナリティクスでは、カテゴリを組み合わせるための複数の手法を利用できます。この場合、複数のカテゴリーに対する組み合わせロジックは、各カテゴリー内のオブザベーション数と、ターゲット変数に対する関係とに左右されます。この手法の例としては、決定木や根拠の重み(WOE)計算があります。 テキストマイニングを利用すると、自由形式のテキストを、アナリティクス手法で処理可能な「構造化された情報」に変換することができます。 6. 予測モデル作成のための変数選択 変数選択のための手法は数多く存在します。これらを利用すると、予測モデルを作成する際に、ターゲット変数と強い関係を持つ変数のサブセットを特定することができます。これらの手法の例としては、R2(=決定係数)のようなシンプルな指標や、LARS、LASSO、ELASTIC NETのような高度な指標があります。 多くのアナリティクス手法は、分析モデル自体の中で変数選択のための様々なオプションが利用可能です。例えば、回帰における変数増加法、変数減少法、ステップワイズ法によるモデル選択などが挙げられます。 7. モデル品質やwhat-if分析の評価 アナリティクス・ツールはしばしば、モデルの作成や検証を支援するように設計されています。予測モデルの作成時には、例えば、利用可能なデータが持つ予測力を初期段階で素早く洞察することが重要となるケースは多々あります(これを「高速予測モデリング」と呼ぶこともあります)。 また、これらのツールは、モデルの品質やwhat-if分析用の特徴量を迅速に評価する手段も提供します。what-if分析は、変数や変数グループの重要度を判断する際に特に役立ちます。what-if分析は、特定の変数群が利用できない場合にモデルの予測力がどのように変化するか推計します。 これらの例の出典は、SAS Pressの書籍『Data Quality for Analytics Using SAS』(SASで実現するアナリティクス向けのデータ品質) です。ガーハード(Gerhard)氏によるコンテンツは、Github、SAS Support Communities、同氏のデータサイエンス関連書籍でも見つかります。

Analytics | Data Management
SAS Japan 0
SASのアナリティクスをコンテナ内で実行する8つの理由

この記事はSAS Institute Japanが翻訳および編集したもので、もともとはJames Ochiai-Brownによって執筆されました。元記事はこちらです(英語)。 自己完結型のパッケージ内でソフトウェアを実行するというアイディアは、2013年のDockerの立ち上げと共に広まり始め、今ではアプリケーション開発とDevOpsのコミュニティにおけるホットなトピックとなっています。Red Hat社による最近の調査では、調査対象企業の57%が、いくつかのワークロードにコンテナを利用しており、次の2年間で採用数が2倍近くになると期待している、と回答しています。 SASはこのトレンドを認識しており、現在ではデプロイメント・オプションの一つとしてSAS for Containersを提供しています。これが仮想マシン上でSASを実行する手法の完全なリプレースになるとは思われませんが、そこには顕著なメリットがいくつか存在します。 1. アナリティクスへのセルフサービス型アクセス 組織の中には、「SASを利用したいが、それを手にできない分析担当者」を抱えているところもあります。また、SAS Platformを保有しているものの、そのオンボーディング・プロセスに承認手続きが設けられているビジネス部門も存在します。プラットフォームの運用管理者がファイルシステムやセキュリティモデルに変更を加えなければならない可能性があり、そのプロセスに時間がかかることもあります。 コンテナを利用すると、物事がよりセルフサービス型になります。IT部門はSAS用の標準的なコンテナイメージを準備し、それを社内のユーザー向けに提供します。分析担当者は用途に応じてその中から選択し、自分専用のインスタンスを起動するだけで、数分以内にSASでの作業を開始できます。Domino Data LabとBlueData は、こうした機能を提供するコンテナベースのデータサイエンス・プラットフォームの例です。 2. 様々なソフトウェア・ツールやバージョンに関するニーズへの対応が簡素化 SAS Platformの従来型の実装は、多数のユーザーによって共用されます。ユーザーは設定済みのソフトウェアを使用しなければなりませんが、それが最新バージョンであるとは限りません。コンテナを利用すると、IT部門はデータ分析担当者に対し、SASとオープンソースのソフトウェアを組み合わせた幅広い種類のコンテナイメージを提供することができます。例えば、SAS 9.4、SAS Studio、Jupyter Notebookを組み合わせたコンテナイメージも可能ですし、SAS Studio、Jupyter Notebook、R Studioのいずれからでもアクセスできる形でSAS Viyaの機械学習機能を提供するようなイメージも可能です。IT部門は、試用版ソフトウェアを提供することさえ可能です。開発者は、特定のプロジェクトに必要なソフトウェア・コンポーネントやAPI群を組み合わせて、独自のコンテナイメージを作成することもできるようになります。 3. ソフトウェア・アップデートの容易化 実際には、コンテナ内のSASソフトウェアがアップデートされることはありません。必要なのは、新しいバージョンで別のコンテナイメージを作成し、それを用いて別のコンテナを構築することだけです。つまり、ソフトウェアのアッグレード中にユーザーの作業を邪魔することは一切ありません。週末の作業も不要ですし、アップグレードがうまく進まないときに、どうやってシステムを元に戻せばよいかパニックになることもありません。新しいコンテナをテストし、準備が整った段階でそれをユーザー向けに展開すればよいのです。様々なバージョンのコンテナイメージを保持できるため、ユーザーは時間的な余裕をもって自分のコードを各バージョンでテストしたり、問題がないことを確認した上で新しいバージョンに移行したりできるようになります。 4. スケーラブルかつ柔軟で、隔離された計算処理環境 コンテナ・オーケストレーター(例:Kubernetes)は、多くのコンテナを起動することで、大きなコンピューティング・リソースを割り当てることができます。そのため、オンボードするユーザーが増えても、ジョブがスローダウンすることはありません。リソース消費が特に激しいプロセスを実行する場合でも、それが他のユーザーに影響することはありません。各コンテナは、それぞれのマシンのリソースの範囲内でのみ実行可能です。したがって、より多くのパワーが必要な場合は、コンテナを停止し、より大きなマシン上でそれを起動し直します。作業の完了後にコンテナを終了すると、そのマシンは他のユーザーのために解放されます。 5. アナリティクスをWebアプリに統合することが可能 今や、アナリティクスは分析担当者だけのものでありません。デジタル変革に取り組んでいる組織は、顧客がデジタルチャネルを通じて利用するWebアプリやモバイルアプリの背後にアナリティクスを組み込もうとしています。具体的には、画像処理、レコメンデーション、意思決定支援などを含むAIアプリケーションなどが考えられます。これらのWebアプリは従来の方式で実装されたSAS Platformと組み合わせて機能させることも可能ですが、その一方で、必要なSASソフトウェア、分析モデル、小型の実行エンジンとしてのサポーティング・コードだけで構成した実行エンジンを軽量なコンテナに実装すると複数の利点があります。こうすることで、開発者は、他のユーザーに影響を与えることなく、SASソフトウェアの設定やAPI群を変更する自由を手にします。これは、アプリケーションがPythonまたはJavaで実装される方法に似ています。 6. 自動モデル・チューニング モデルの中には、データが変化するたびに、あるいは新しいフィードバックを受け取るたびに、頻繁に更新する必要があるものもあります。コンテナを利用すると、そうしたモデルを再チューニングし、その結果をコンテナ内にパッケージし、実業務環境にデプロイするまでのプロセスを自動化することができます。 7. DevOpsやCI/CDによるデプロイメントの合理化/効率化 典型的なSASユーザーはDevOpsの世界には馴染みがないかもしれませんが、DevOpsは昨今の主流となりつつあるアプリケーション開発手法です。アナリティクスをWebアプリに統合したい場合、私たちはこのプロセスに沿って進める必要があり、それを最も簡単に行う方法が、コンテナを利用する手法です。SASコードとモデルをコンテナ内にカプセル化すると、アプリ開発者(=Dev)側では、デプロイのために運用チーム(=Ops)側に渡す前に、コンテナに接続しテストを実行できるようになります。「継続的インテグレーション(CI)」と呼ばれる手法では、アプリ(SASのパーツを含むアプリ)の全てのブランチ(分岐)における変更は、それらが一緒に正しく機能する状態を確保するために、定常的にマージされ、自動テストにかけられます。「継続的デリバリー(CD)」と呼ばれる手法は、本番の業務環境へのリリースまでのプロセスを自動化します。これにより、アナリティクス・プリケーションの開発とデプロイを数週間ではなく、数日または数時間で完了することが可能になります。   8. ほぼ全ての場所にデプロイすることが可能 コンテナはポータブル性に優れているため、オンプレミスのデータセンターから、パブリッククラウドや、ドローン/トラック/列車に搭載されたエッジデバイスに至るまで、あらゆる種類の場所でSASの実行エンジンを動かすことが可能です。 コンテナは、イマジネーション豊かなアナリティクス活用を実現可能にする大きなポテンシャルをもたらします。あなたがSAS Viyaのライセンスをお持ちの場合は、SASが運営するDockerイメージ・ライブラリへのアクセス権を有していますから、そこから事前準備済みのコンテナイメージの形でSAS

Data Management
クラウド上のSAS Viyaから、オンプレミス上にあるデータへ、セキュアにアクセス

近年、クラウドファーストを唱える企業が増加し、データ分析のために、クラウド上に展開されている分析サービスを活用したり、クラウド上に独自に分析アプリケーションを構築するケースも増えています。 しかし、クラウド上にある分析サービスやアプリケーションで分析する対象のデータは、オンプレミス上に蓄積されているケースが大半であり、クラウドからこれらのデータにアクセスできるようにするための作業や環境設定は面倒かつ非効率で、膨大なデータをクラウドとやり取りするなどの運用コストも大きく、かつセキュリティのリスク回避も考慮しなければなりません。 こうした課題を解決するために、SAS ViyaではSAS Cloud Data Exchange (CDE)を提供しています。 SAS Cloud Data Exchange (CDE) は、プライベート/パプリックのクラウド上にあるアプリケーション(=SAS Viya)からファイヤーウォールの後ろにある、顧客のオンプレミス上にあるデータに安全かつ確実にアクセスし、大量のデータをクラウドへ高速に転送することを可能とするデータ接続機能です。 CDEは、SAS Viyaのセルフサービス・データ準備向け製品であるSAS Data Preparationに含まれる機能です。 CDEを使用すれば、クラウド上にあるSAS Viyaからオンプレミス上にある様々なデータソース(Oracle, Teradata, Hadoop etc.)へ最小限の手順で容易かつセキュアにアクセスすることが可能になります。 サポート対象データソース: ・DB2, ODBC, Apache Hive, Oracle, Redshift, SQL Server, Postgres, SAP HANA, Teradata, SAS Data Sets CDEでは、最小限の一つのポート(Https port)を使用し、オンプレミス上にあるデータソースにアクセスするための資格情報(ユーザーID /パスワード)も保護された領域に格納し、使用するため、安全性が高められています。 また、クラウド上のSAS Viyaが複数のワーカーノードで分散構成されている場合には、オンプレミス上のデータを並列で高速にSAS Viya環境へロードすることが可能です。 利用手順概要は以下の通りです。 オンプレミス側にSAS Data Agent

Data Management
小林 泉 0
Hadoopだからこそ必要なセルフサービス-そしてアダプティブ・データマネジメントの時代へ

2014 およそ2014年からSAS on Hadoopソリューションを本格展開してきました。時代背景的には、2014頃は依然として、業態の特性からデータが巨大になりがちで、かつそのデータを活用することそのものが競争優位の源泉となる事業を展開する企業にHadoopの活用が限られていたと思います。その頃は、すでにHadoopをお持ちのお客様に対して、SASのインメモリ・アナリティクス・エンジンをご提供するというケースが大半でした。 その後、急速にHadoopのコモディティ化が進んだと感じます。 2015 2015頃になると、前述の業態以外においてもビッグデータ・アナリティクスの成熟度が上がりました。データ取得技術の発展も伴い、これまで活用していなかった種類や量のデータを競争優位性のために活用を志向するようになり、蓄積および処理手段としてのHadoopの選択が加速します。この頃になると、数年前には必ずあったHadoopそのものの検証ステップを踏まない企業が増えてきます。データ量、処理規模、拡張性、コスト効率を考えたときに妥当なテクノロジーがHadoopという結論になります。ビッグデータはデータのサイズだけの話ではありませんが、筆者の足で稼いだ統計によると、当時大体10TBくらいが、従来のテクノロジーのまま行くか、Hadoopを採用するかの分岐点として企業・組織は算段していたようです。この時期になると、従来のテクノロジーの代替手段としてのHadoopの適用パターンが見えてきました。 新しいデータのための環境 従来捨てていた、あるいは新たに取得可能になった新しいデータをとりあえず蓄積して、何か新しいことを始めるためのある程度独立した環境として、コスト効率を考慮してHadoopを採用するパターン 既存のデータウェアハウスへ価値を付加(上の発展形であることが多い) 新たなデータを使用してHadoop上で加工し、アナリティクス・ベーステーブルにカラムを追加し、アナリティクスの精度を向上 ETL処理負荷やデータ格納場所のHadoopへのオフロード BI & アナリティクスの専用基盤 SQLベースのアプリケーションだけをRDBMSに残し、その他の機械学習、ビジュアライゼーションなどSQLが不向きな処理をすべてHadoop上で実施 多くは、インメモリアナリティクスエンジンと併用 データレイク (筆者の意見としては)いざ新しいデータを使用しようと思ったときのスピード重視で、直近使用しないデータも含めて、全てのデータを蓄積しておく。よくあるのが、新しいデータを使用しようと思ったときには、まだデータが蓄積されておらず、利用開始までタイムラグが生じてしまうケース。その時間的損失すなわち利益の喪失を重要視し、そのような方針にしている企業が実際に当時から存在します。 2016 海外の事例等では数年前から見られましたが、2016になると、日本でも以下の傾向が見られます 既存Hadoopをそのコンセプトどおりスケールアウトしていくケース グローバル・データ・プラットフォームとして、複数のHadoopクラスターを階層的に運用するケース AI、機械学習ブームにより機械学習のためのデータの蓄積環境として IoTの流れにより、ストリーミング処理(SASでいうと、SAS Event Streaming Processingという製品です)と組み合わせて まさに、Hadoopがデータプラットフォームとなる時代がやって来たと思います。その証拠に、SAS on Hadoopソリューションは、日本においても、金融、小売、通信、サービス、製造、製薬といったほぼ全ての業種において活用されています。 Hadoopの目的は、従来型のBI・レポーティングではなく、アナリティクス このような流れの中で、Hadoopの採用には一つの確固たる特徴が浮かび上がっています。もちろん弊社が単にITシステムの導入をゴールとするのではなく、ビジネス価値創出を提供価値のゴールにしているというバイアスはあるのですが。。。 Hadoopの導入目的は、ビジネス価値を創出するアナリティクスのためであることがほとんどである したがって、Hadoopに格納されるデータには主にエンドユーザーがアナリティクス観点の目的志向でアクセスするケースがほとんどである つまり、ある程度の規模のITシステムではあっても、Hadoopに格納されるデータはアナリティクスの目的ドリブンでしかアクセスされません。主たるユーザーは、分析者やデータ・サイエンティストです。彼らが、「使いたい」と思った瞬間にアクセスできる必要があるのです。このようなユーザーサイドのリクエストは、従来のBIすなわちレポーティングのような固定化された要件定義をするような依頼ではないため、その都度従来のようにIT部門と要件をすり合わせて、IT部門にお願いするという方法では成り立ちません。その数日、数週間というリードタイムが意思決定を遅らせ、企業の業績に悪影響をもたらすからです。あるいはIT部門の担当者を疲弊させてしまいます。つまり、アナリティクスにおいては、分析者・データサイエンティストが自分自身で、Hadoop上のデータにアクセスし、必要な品質で、必要な形式で、必要なスピードで取得するために自由にデータ加工できる必要があるのです。 このあたりの話については、下記でも紹介していますので、是非ご覧ください。 【ITmedia連載】IT部門のためのアナリティクス入門 第2回 やっと分かった ビッグデータアナリティクスでHadoopを使う理由 第3回 データ分析で成功するためのデータマネジメントとIT部門の新たな役割  【関連ブログ】 アナリティクスの効果を最大化するデータマネジメント勘所 これが、Hadoopにおいて、セルフサービス・データマネージメント(データ準備)ツールが不可欠な理由です。SASはアナリティクスのソフトウェアベンダーとして、このHadoop上でITスキルの高くない分析者・データサイエンティストでも自分自身で自由にデータを取得できるツールを開発し提供しています。それが、SAS Data Loader for Hadoopです。 SAS Data Loader

Analytics | Data Management
小林 泉 0
アナリティクスの効果を最大化するデータマネージメント勘所

変わ(る・るべき・れる)データマネージメント データ、さらにはビッグデータを使用して競争優位性を獲得しようとするにつれて、企業・組織はよりスピード感をもって、試行錯誤を繰り返す必要にせまられおり、データマネージメント戦略やアプローチについても従来とは異なる方法にシフトしつつあります。 これまでのアプローチ 従来のアプローチでは、まず、ビジネスユーザー部門が「問い」を決めた上で、IT部門が「問いへの答え」のためのインフラとデータを準備していました。例えば、「先月の地域別、製品別、チャネル別の売り上げはどうなっているか?」や、顧客へのアンケートに基づいて、「顧客は何を考えているか?」などです。このような過去や現状を把握するための「問い」は、ほとんどの企業・組織で共通している、基本的な業務プロセスを実行するために適した方法です。 この方法では、ユーザー部門が本当に欲しい答えを得るまでにはIT部門と何度もやり取りを繰り返す(Iteration)必要があります。その作業には数週間要するケースも少なくありません。ビジネスユーザーにとっては、事前に完璧な「問い」をシステム的な要件として定義することは困難であり、一方でIT部門は業務に対する理解が100%完全ではないためです。しかし、ひとたび、ITインフラやデータが用意されると、その後は、「決まりきった反復的な(Repeatable)」分析、すなわち現状を把握するための分析(これはAnalysisです)ビジネス・インテリジェンスという目的に使用されます。 アナリティクスおよびビッグデータ時代のアプローチ 新たな洞察の発見や予測モデルを作成し、よりよい意思決定やアクションを実践することを主目的とするアナリティクスにおいては、このプロセスが極端に言えば逆になります。まず、IT部門が収集したデータを蓄積する基盤を構築し、その後にビジネスユーザーがその基盤を利用して新しいアイディアや問いを探索するという順序です。この作業は、創造的な発見的プロセスであり、ビジネスユーザーは使用しているデータが特定の目的にあっているかどうかを自身で判断することができると同時に、これまで知らなかった傾向や関係性を明らかにしたり、更なる深い分析のために役立つかもしれないデータを見つけたりします。 この新しいアプローチの特徴は、ユーザー自身でデータ加工やその先の分析を繰り返し実施(Iterative)することに適しているということです。アナリティクスにおいては、仮説検証、試行錯誤、さらには失敗をいかに高速に実施するかが重要なため、この繰り返し作業(Iterative)をユーザー自身で迅速に行う必要があるのです。 RepeatableとIterationとの違い 同じ動作を繰り返す、例えば毎月同じ種類のデータに対して同じクエリーを実行しレポートを作成するようなことがRepeatableです。それに対してIterationとは、異なる動作を繰り返す事を指し、データや見方を変えながらデータを探索しつつ仮説検証を繰り返したり、予測モデル作成や機械学習アルゴリズムのための説明変数や特徴量を探索しながら作成していくことを意味しています。BIレポーティングは、 Repeatable, アナリティクスはIterativeと覚えておいてください。 Iterativeなデータ加工プロセスでは以下のように、SQLだけでは困難な処理が多く含まれます。 集約(合計や平均などだけではなく、中央値や標準偏差などを含む) 転置(下記ABTにも関連) 統計的判断(ある事象、たとえば売り上げの減少が、単なる偶然のバラツキの範囲なのかなのかそうでないか) 欠損値や異常値の検出と補完(0で補完するだけでなく、平均値や中央値など) 新しい変数(カラム、列、特徴量とも言います)の作成 重複データの検出と対応 クレンジングや表記をあわせる標準化 SQLジョイン マージ(SQLジョインでは不可能な複雑な条件でデータを結合) 数値データの変換(対数変換や標準化) 次元圧縮 よく見かける現場の状況 これら2つのアプローチの違いは、従来活用していなかった履歴データや、ビッグデータ、非構造化データと呼ばれるような装置からのログデータやテキストデータを活用しはじめようとする際に顕著になります。業務システムや既にデータウェアハウスに格納されている、主キーやカラム構造がわかりやすいデータとは異なり、このような新しいデータは、行を特定するためのID項目。がなかったり、論理的な1行が複数行にまたがっていたり、欠損値が多い、そもそもどんな値が格納されているべきかを業務ルールから特定できるわけではないなど、必ずしもRDBMSに格納しやすいデータとはいえません。このようなデータを、キー構造や値の制約などを厳格に管理することに重きを置く従来型のRDBMSに格納しようとすると、IT部門は、まずユーザー部門に対しして、「どのような種類のデータをどのように使用するのか」といった目的定義からスタートします。わかりやすくいうと、どのようなSQLを投げるかが決まらないとテーブル構造やリレーションシップなどのデータモデル設計ができないからです。しかし、「アナリティクス」においては、どのようにデータを加工するかは、分析のプロセス中に考えることですし、分析が進むにつれて加工の仕方も変わってくるため、あらかじめ用法を明確に定義しておくことはできません。データを触ってみないと加工の仕方は決まりませんし、将来的に別の活用方法になることもあります。同じデータであっても、データを縦方向に長くする方が良いのか、横方向に長くのが良いかは、そのときどきのデータの見方によって変わります。従来のデータマネージメントのアプローチでは、この瞬間に「卵とニワトリ」の問題が発生し、アナリティクスの取り組みの大幅なスピードダウンを招くことになります。 なぜ従来型のアプローチになるのか? IT部門がこのような従来型のデータマネージメント・アプローチを取ろうとするのには、理由があります。RDBMSを利用する場合、さらにはHadoopを利用する場合には特に、ビジネスユーザーが生データを加工することはIT技術的・スキル的に困難だと考えており、なんらかの「おぜんだて」をしてユーザーに使いやすいソフトウェア環境とともに「公開」しようとする意識があるためです。実際にそのとおりであり、高度な分析をするためには、さすがにSQL程度は使えるor考え方がわかる必要はありますが、HadoopのMapReduceはハードルが高すぎます。しかし、アナリティクスにおいてSQLは道具として不十分であり、必要なデータ加工をするためにはMapReduceやその他のデータ加工言語を駆使して、場合によっては分散コンピューティングを意識しながら使いこなさないと実現できないデータ加工要件が存在します。この部分のスキルを獲得したり人材を確保するのはコスト高であるだけでなく、ビジネス・スピードを損ないます。   先行してビッグデータアナリティクスで競争優位性を築いている企業・組織はここの事情が少し異なります。彼らにとってアナリティクスの活用はビジネスモデルの根幹であるため、スキル獲得(教育、学習、採用)はコストがかかってもMUSTであると考えています。ただ、それでも、分析組織として拡大・成熟してきたチームの管理者は、昨今のデータ分析人材難もあいまって、自分の抱えるチームの生産性に課題を感じ始めています。 最新のテクノロジーがアプローチ方法の変革を可能にします 実は、このようなIT部門の懸念はすでに過去のものとなっています。テクノロジーは進化しソフトウェアは成長しています。いまや、データサイエンティストのような「分析もITもこなすスーパーマン」ではない「ビジネスユーザー出身の分析者」(ガートナーはこれを市民データサイエンティストと呼んでいます)であっても、Hadoopの技術的なスキルなくとも、グラフィカルなユーザーインターフェースや分析者が通常分析に使用する言語で、Hadoop上のデータを自由自在に加工できる手段が存在します。つまり、ビッグデータ時代においては、データは基本的な欠損値の補完などのクレンジング処理だけを施した生データを置いておくだけで、データ分析者が、高度なITスキルを持たなくともハイパフォーマンスに分析処理を実行することができるのです。   アナリティクス担当者(誤解しないでください。レポーティングしたい分析者とは異なります)が考えていることは、 「データの形式や品質はさておき、とにかくデータにアクセスできるようにして欲しい。加工は自分たちでできるから、とにかくスピード優先で」   となります。このような要望にこたえるためには、従来型のテクノロジーを使用したデータウェアハウスの改修という方法では困難です。様々な形式のデータを、データモデル設計をすることなく、適切なコストで、まずは蓄積するということが必要になり、そこは今の時代においてはHadoopが最適です。また場合によって、既存のシステムとの連携においては、フェデレーション技術のように仮想的に集めたかのように見せる必要があるケースもあります。このような環境では、従来のデータウェアハウスのように整ったデータが準備されているわけではなく、使用する際に整えることになるため、分析者がデータ品質を目的に応じて整える必要があり、Hadoop上でデータプロファイリングやクレンジングを自身で実施します。さらには、あらかじめ直近使用する予定のないデータをも捨てずに蓄積しておくデータレイクという戦略をとる企業・組織も出てきました。 最初のゴールはABT作成である IT部門が、このアナリティクスにおけるデータ加工の最初のゴールを理解すると、企業・組織におけるアナリティクスの取り組みが飛躍的に加速し、IT部門のビジネスへの貢献の仕方も理にかなったものになり、IT投資の目的や方向性を設定しやすくなります。 アナリティクスが欲しているのは、BIクエリーに適している正規化データモデルやスタースキーマ・データモデルではありませんし、また「目的特化型のデータ・マートが欲しい」というわけでもありません。まず最初の目的は、ABTすなわち、Analytical Base Tableを整えることです。ABTとは、15年以上前からある考え方で、アナリティクスにおいてデータの分布の確認や傾向の探索、予測モデルの作成のための基本テーブルのようなものです。 顧客の購買行動を予測する際を例に考えてみましょう。当時はそのまま「1顧客1レコード」と呼んでいましたが、最近ではSASジャパンでは「横持ちテーブル」ということが普通です。対して、履歴データを縦に持ったものを「縦持ち」と言います。簡単に言うと、顧客に関する全てのデータ、顧客マスターにある属性情報に始まり、契約情報、購買履歴、コミュニケーション履歴、キャンペーンへの反応履歴、店舗やWeb上での行動履歴、など、最近の言葉で言えば、顧客の360度ビューをデータとして表現し、1人の顧客につき1行使用し、これら情報を列方向に持たせたデータです。ご想像の通り、このテーブルは時には列数が数百、数千、数万になったりすることもあります。ただ単に履歴を横に持つから横に長くなるというよりは、顧客を特徴づける説明変数や特徴量を作成していくことでも、その数が増えていきます。単にAという商品を買ったというだけでなく、何曜日の何時にどの店舗に来店したのか、来店頻度は? 金額は? 金額の合計は? など、その顧客がどのような行動、嗜好をもつ顧客なのかを特徴づけるデータを作成します。どのような列、説明変数や特徴量を作成するのが良いかは、今回の趣旨ではないので省略しますが、これまでの業務上の勘と経験、ノウハウ、そして一番重要なのは、企業が顧客とどのような関係を気づきたいかという顧客戦略、これらがあれば、おのずと決まってきます。また、ある程度世の中にベストプラクスもあるので、書籍や弊社コンサルタントに期待することもできます。   なんだ、全てのデータをくっつけたデータマートを作ってあげればいいのではないかと思うかもしれませんが、ABTを作成する作業は前述の通り分析作業をしながらのIterativeなプロセスのため、分析者自身が作っていく必要があります。アナリティクスの活用成熟度の高い分析チームになると、データの一貫性を理由として、複数のテーマでこのABTの一部の列を共有するようになります。この段階になって初めて、ある程度仕様が固定化されたデータマートのようになりますが、ビジネスの変化に応じて柔軟・迅速に変更していく必要があるという性質は変わりません。  IT部門の新たな役割:データスチュワード このように、アナリティクスのためのデータマネージメントプロセスを実践するためには、アナリティクスという具体的なビジネス価値を創出するための要求とスピードに対して、迅速に対応する必要があります。その主たる役割は、従来型のシステム開発データベース構築やデータモデルの設計ではなく、「ユーザーの使いたいデータはどこにあるのか?」、「社外データはどのように調達できるかどうか?」、「他部門ではどのようにそのデータを活用しているのか?」といった疑問に答える役割で、一般的には、「データスチュワード」として定義されている役割です。データスチュワードという役割は、約10年前にその必要性が叫ばれたBIをサポートするBICC(ビジネス・インテリジェンス・コンピテンシー・センター)でも定義されていましたが、昨今、アナリティクスの広まりによって、その役割の重要性が再認識され始めています。部門横断的に業務とアナリティクスおよびITに対する一定の理解とスキルを有しつつ、主たる役割はアナリティクスとそれに必要なデータやスキルを効果的・効率的にマッチングすることです。最近では、必要な全てのデータやスキルを組織内で準備することが現実的ではなくなってきており、その解決策の一つである、「オープンイノベーション」の事務局的な役割を担っているケースもあります。

Back to Top