SAS Japan

活用事例からデータ分析のテクニックまで、SAS Japanが解き明かすアナリティクスの全て
Analytics
データ分析効率化の秘訣:SAS ViyaとAzure Synapseの高速データ転送方法の紹介

1.背景 データ管理と分析の世界では、効率的かつ迅速なデータの転送と書き込みは極めて重要です。特に大規模なデータウェアハウスサービスを利用する際には、このプロセスの最適化が不可欠です。Azure Synapse Analyticsは、そのようなサービスの一つとして注目を集めており、SAS Viyaを使用する多くの企業やデータアナリストも、より効率的なデータハンドリングを追求しています。 SAS ViyaのユーザーはSAS/ACCESS to Microsoft SQL Serverを使用してAzure Synapseにデータを転送および書き込む際に、より高いデータ書き込み効率と転送速度を求めるのは当然です。データ処理能力をさらに強化し、書き込み効率を高めるために、SAS Access to SynapseのBulkLoad機能は非常に優れた選択肢です。BulkLoad機能はデータの書き込み速度を大幅に向上させるだけでなく、Azure Data Lake Storage Gen 2(以下、ADLS2と称する)を利用して、安定かつ安全なデータストレージおよび転送環境を提供します。 ただし、BulkLoad機能を使用する際にはADLS2の設定と構成が関わってくるため、構成および使用のプロセスが複雑に感じられたり、疑問が生じたりすることがあります。このブログの目的は、管理者およびユーザーに対して、明確なステップバイステップの設定プロセスを提供し、構成の過程で見落とされがちなキーポイントを強調することで、設定時の参考になるようにすることです。 以下は本記事内容の一覧です。読者は以下のリンクをで興味のあるセクションに直接ジャンプすることができます。 2.Bulkload機能について 3.BULKLOAD機能を利用するためのAzure側で必要なサービスの作成 3-1.Azure Data Lake Storage (ADLS) Gen2のストレージアカウントの作成 3-2.ストレージアカウントのデータストレージコンテナの作成 3-3.ストレージアカウントの利用ユーザー権限の設定 3-4.データ書き込み用のSASコードの実行 3-5.Azureアプリの設定 4.SAS Viya側の設定とAzure Synapseへの接続 4-1.SAS Studioでの設定 4-2.Azure SynapseのSQLデータベースをSASライブラリとして定義 4-3.Azure Synapseへデータの書き込み 2.Bulkload機能について なぜSAS ViyaがBulkload機能を使用してAzure Synapseに効率的にデータを書き込む際にADLS2サービスが必要なのか、そしてそのプロセスがどのように行われるのかを説明します。 Azure Synapse Analyticsは、柔軟性が高く、高いスループットのデータ転送を可能にするために、COPY

Analytics | Data Management
小林 泉 0
ガウディとサグラダ・ファミリアに学ぶデータ分析基盤アーキテクチャのための原則

前回の筆者ブログ「STEAM教育の進化にみるAI活用に必要な芸術家的思考」において、AI/アナリティクス時代に芸術家的思考が必要だという話をしました。今回はその派生で、AI/アナリティクス時代に作られるデータ分析基盤の作り方について、「時間をかけて大規模に創造する」という点で類似している建築物、そのなかでも、自然摂理・数学・幾何学と芸術を融合された象徴としてのサグラダ・ファミリアとその大部分の設計を担ったガウディの考え方に学んでみようと思います。 ガウディとサグラダ・ファミリアの特徴 終わりがなく常にその時代の人によって継承され・作り続けられる ガウディは、サグラダ・ファミリアを完成という終わりを目指さないものとして考えていたそうです。教会という性質や、建築費を寄付で賄うという性質もあり、またガウディが世の中に残したかった、「象徴」として、建築物の完成・利用されるというアウトカムではなく、時代時代の人々が建築に携わり続けることで象徴としての役割をもたらすことをアウトカムとしたということだと私は個人的に解釈します。これは、誰かが作ったものを使うという一方的な関係性を超え、インクルージョンすなわち関与するという関係性をもたらします。 サグラダ・ファミリアの建設はゆっくりと進む。 なぜなら、私のクライアント(神)は完成をお急ぎではないからだ by ガウディ 自然摂理と数学・幾何学に基づく美しさ サグラダ・ファミリアの棟の形は放物線です。ネックレスを想像してみてください。長さや幅を変えると様々な放物線になることが分かると思いますが、そのような「逆さ実験」を繰り返しそれをさかさまにしてあの様々な棟の形になっています。これは、ガウディが何事も自然法則に基づくべきという考えに基づいています。 放物面は幾何学すべての父 by ガウディ 継続のための象徴性の維持 サグラダ・ファミリアは建築費を寄付に依存しています。そのため継続的に人々・社会の関心を惹き続ける必要があります。 サグラダ・ファミリアの思想に学ぶ、活用されるデータ分析基盤アーキテクチャに役立つ原則 原則①レジリエンスー蓄積するデータは常に変化する 「どのようなデータを蓄積しておいたらいいですか?SASさんの経験に基づいて教えてください」 「いま取得できるデータを全部蓄積しようと思うんです。あとでどれが必要になるかわからないから」 このようなお話をよくお聞きします。データ活用ニーズはマーケットの変化、競合他社の変化などによって刻々と変化していくため、利用データのニーズを気にすることは浸透していますが、一方で見落としがちなのは以下の2点です。 過去のデータは過去しか表していない。たとえば売上データ一つとっても、それは過去の自社の行動・意思決定の結果でしかなく、役に立つときもあれば、目的によっては全く役に立たない場合もある。 今得られているデータや分析に利用できそうなデータは今のテクノロジーで得られうるデータ、今のテクノロジーで分析しうるというデータにすぎない。将来テクノロジーの進化によって、新しいデータ、新しいデータ粒度が取得できるようになったり、また分析テクノロジーの進化によって想定してなかったデータが利用価値を生み出したりする可能性もある。 この2つの前提にたつと、どのようなデータをためるべきかという議論が意味がないわけではありませんが、「それほど」意味がないということが分かると思います。それよりは、システムアーキテクチャの原則として、将来、データのVolume, Velocity, Veriety に対応できるように硬直化しないことに、より注意を払うことが重要です。また、蓄積しておいたデータが結果的に使われないということもあるかもしれませんが、そのこと自体を失敗としてシステムの価値評価としては用いるべきではありません。重要なことはそのような重要でないデータが認識されたときに素早くストレージコストを低減するようなアクションができるという俊敏性なのです。それは最近のはやり言葉でいうと、レジリエンスと言ってもいいかもしれません。 原則②アーキテクト担当は芸術家的思考が大事 筆者自身、これまでデータ分析基盤システムのアーキテクチャを何度も担当してきました。そしてアーキテクトを育てる際にいつも言っていた言葉があります。「アーキテクチャは機械的に決まるものではないよ。意思だよ意思。あなたがやりたいように決めていいんだよ」いま思うと、STEAM教育に新たに加えられた芸術家的思考を唱えていたことになります。もちろん基本的な知識や経験に基づいたうえでですが、なかなか自分勝手にアーキテクチャを決めていいと思っているアーキテクト担当者も多くなく、結果として、様々な過去のしがらみに忖度したスパゲッティ状態の新システムが出来上がることも少なくありません。そのような結果にならないためには、その企業・自分たちの組織・自分自身ととことん向き合って、全体アーキテクチャにその思いを込める、ということが重要になってきます。もちろんコーチとしてはこのアドバイスの仕方では不足でして、もっと言語化してアクショナブルにしないといけないとは思いますが。 0から独創性は生まれない by ガウディ 原則③アーキテクチャ図は美しく 図やダイアグラムで人に何かを伝えるためには、見る際にそれを阻害する雑音となる不要な情報を削り本当に必要な情報のみに研ぎ澄ますという最低限のことだけではなく、見たいという気持ちにさせたり、見てみようと思わせたり、ちゃんと見ようと思わせたり、あるいは言語的な情報理解だけではない、感情を引き起こさせることで正しく記憶されます。幾何学的な対称性などのバランスを整えることは、「本日はお集まりいただきありがとうございます」に匹敵する挨拶レベルの基本行動規範です。さらには、複雑なアーキテクチャと向き合う場合には、数学的・幾何学的な視点で眺めなおすことで、構成要素が変わらなくても、アーキテクチャ図としてのエントロピーを低減し、構造の整理をすることで、オーディエンスの正しい理解・伝達コストを低減することが可能です。また、そのようにできる限り美しさを追求することで、逆に多くの部分が視覚情報として自然なものとなる、すなわち無の情報となることで、本質的に最も注目すべきポイントにオーディエンスの目を向けさせることができます。 原則④アーキテクチャの思想定義が重要 これは、上述の芸術家的思考と関連しますが、いわゆる芸術作品を評価した文章のような、背景・アーキテクトの思いなどをシステム設計思想として言語化し文書化して受け継いでいくことが重要です。芸術作品と同じように、作品=システムだけでは、作者がどのように自己と向き合い、世の中を見て、どのような思想で創造したのかを把握することは難しいです。サグラダ・ファミリアは未完成部分のガウディによる設計書が失われたため、現在の関係者たちはガウディの思想に基づきながら設計をしています。同様に、データ分析基盤システムが変化し続ける中担当者は変わっていきますが、システムの変更・改修の際にその「思想」に基づくことで、一貫性・効率性・投資対効果・透明性を高めることができるでしょう。 原則⑤アーキテクチャの思想定義の象徴化が重要 象徴化というと小難しい印象になりますが、データ分析基盤の「モットー」や「ビジョン」を常に発信していくということです。最近筆者が耳にした良いなぁと思った例を2つほどご紹介します。この2つの例では、情報システム部門のトップが常にこのワードを取引先ベンダーにもユーザーサイドにも宣伝していることが重要です。あらゆるステークホルダーがこのモットー、ビジョン、象徴に軸足を置くことで、そこからさまざまな提案・理解が派生するものの、このシステムに対する取り組みを将来に向けて継続・推進することに大きく役立っています。 「システム部門がボトルネックにならないセルフサービス化」 昨今、セルフサービスばやりですが、このフレーズにはユーザー部門からの並々ならぬプレッシャーと、それにこたえることがIT部門の使命だという企業としての一体となったデータ活用戦略が表現されており、様々な提案活動・意思決定の原則として非常によく機能しています。これによってステークホルダーが一丸となって、同じ世界を目指し続けることを可能としています。 「バッチ処理だけではなく真のリアルタイム処理にも同時に対応したシステム」 ビジネスにおいては、常に新しい技術・知識を関連付けて新しい商品やサービス、ビジネスプロセス、市場を創造していく必要がありますが、ITやAI/アナリティクスが主役の昨今、情報システム部門がそのような新しい技術・知識をユーザー部門に提案することが、外部ベンダーに頼らず自社内でスピーディーにイノベーション・トランスフォーメーションしていくうえで重要になってきます。ITの観点でいち早く世界中の情報を収集し、新しい技術を試し、ユーザー部門からのリクエストにリアクティブに備えるというよりは、プロアクティブに提案していく、こうすることで、データ分析基盤の位置づけや価値を確固たるものにし、継続的な進化をするものとして、持続的な成長をしていくことが可能になります。 原則⑥走りながらの変化を前提とする 筆者は、芸術の創作活動に詳しくありませんが、想像するに芸術作品の多くは、ウォーターフォール型ではなくアジャイル型ではないでしょうか。下書きを何度も繰り返したり、小さな単位の作品を小出しにしたりしながら、最終的にそれらの集大成として一つの大きな創造物が作られることが多いように見受けられます。場合によっては、その時代時代のトレンドに左右されながら、その一連の創造活動が行われる場合もあります。何事もそうですが、アイディアはエクスポーズしてフィードバックを得ながらブラッシュアップすることが最短経路での最大効果を生み出すことが多いです。データ分析基盤も同様です。まずデータを蓄積してそれが完了したら使ってみるというのをシーケンシャルに行おうとするケースがいまだ散見されます。蓄積してみた直後に、「使いたいデータがなかった」という事件は実際に起きています。なので、これはお勧めしません。データの価値は蓄積ではなく活用して始めて判明するからです。使ってもらって修正して、というフィードバックループを早く回して軌道修正をこまめに繰り返しながら進むことが重要です。 あらためて、Think Big, Start Small アナリティクスの世界では古くからある使い古された原則です。以前は、データ活用成熟度が高い企業のみがアナリティクスへの投資に踏み出していたため、他に参考にする企業もあまりなく、弊社がグローバルの知見や海外の先進事例や経験に基づいてお手伝いをしながらも、お客様自身でとことん考えビジョンを掲げ、少しずつ成果を出しながら投資を継続しながら、適用ビジネス、人材、組織共に、徐々に規模を拡大していくというやり方が主流でした。つまり芸術家的思考がやはりその根底にあったと言えます。 一方で、昨今AIブームの中AI市場が急速に拡大し、多くの企業がデータ活用に踏み出しています。そのため巷では、成功例・失敗例があふれ、それを参考にすることで、データ分析のビジネス活用に、組織的・人材育成的、IT投資的に、何か初めから答えがあるかのような錯覚をし、自社をとことん見つめたうえでのビジョンがないままに、手段が目的化し、組織化や人材育成あるいはデータ統合基盤の構築からスタートしようとしているケースをよく見かけます。その結果、人材育成は出来たはずなのにデータ活用によるビジネスの成果につながっていなかったり、データ統合基盤は出来たのに使われていない、データサイエンス組織に人材は集めたが具体的なビジネス適用につながらないといった結果に陥っているケースも見られます。会社の戦略が、自社のXXXというコアコンピテンスに基づき、XXXのようにビジネスを変革する、というものではなく、単に「データドリブン組織になる」「データドリブン経営をしていく」という手段が目的化しているときに、そのような思わしくない状況になるようです。 データ分析基盤のアーキテクチャもそうですが、今一度終わりのないこのデータ活用の取り組みに、ガウディがサグラダ・ファミリアに込めた戦略=芸術家的思考を参考にし、企業・組織の血となり骨となるデータ活用の取り組みの位置づけを考えてみるのはいかがでしょうか。

Analytics | Students & Educators
0
SASによる因果推論:PSMATCHプロシジャによる傾向スコアマッチング

はじめに 因果効果の推定手法の1つである傾向スコアマッチング、およびSASでの実装方法について紹介します。傾向スコアマッチングのSASでの実装にあたっては、本記事ではSAS/STAT 14.2(SAS 9.4)で追加されましたPSMATCHプロシジャを使用します。因果推論の基本的な枠組みや傾向スコア・傾向スコアマッチングの統計的理論については、詳しく解説を行いませんので、そちらに関心がある方は書籍等を参考にしていただければ幸いです。 理想的なランダム化比較試験においては、ランダム化により治療群と対照群間で測定・未測定の交絡因子(confounders)の分布が期待的に等しくなるため、単純な群間比較によって治療(介入、曝露)の興味のあるアウトカムに対する効果を評価することが可能です。しかし、ランダム化が行われなかった実験研究や観察研究のデータから因果関係を見出そうとする場合には、一般に交絡(confounding)と呼ばれるという問題が生じます。これは簡単に述べると、治療群と対照群で集団の特性が異なることで2つの集団が比較可能ではない状況、治療群と対照群でのアウトカムの違いが治療だけではなく集団の特性の違いにも依存する状況を意味しています。つまり、ランダム化が行われなかった実験研究や観察研究のデータから因果効果を推定する際には、交絡を十分に制御した上で群間比較を行う必要があり、世間一般で因果効果の推定手法と呼ばれるものは、交絡を調整方法する方法だと認識していただいてよいかと思います。因果効果の推定手法は回帰や層別化、標準化など様々なものがありますが、本記事ではマッチング法に注目します。マッチング法は、治療群と対照群から類似した特徴を持つ被験者をペアとし(マッチングさせ)、マッチした対象集団において治療を受けた群と受けなかった群を比較するという方法です。  ただ、一言にマッチング法と言っても複数の交絡因子(共変量)の情報をそのまま用いる「共変量マッチング」と、共変量の情報を傾向スコアという一次元の情報に落とし込んだ上でマッチングを行う「傾向スコアマッチング」という2つの方法に大きく分かれます。初学者にとっては前者の方がより直感的な方法かと思いますが、共変量が高次元である場合や変数のカテゴリ数が多い場合にはその実施が困難になります。そのような場合にしばしば用いられるのが後者の傾向スコアマッチングです。マッチングには、治療群と対照群の構成比率やマッチング方法など様々なオプションがありますが、傾向スコアの分布が同じ(治療群と対照群が交換可能)であるmatched populationを作成するというのが共通の考え方です。また、傾向スコアマッチングの実施手順は連続である単一の共変量を用いた共変量マッチングと同様であり、大きくは以下のような手順となります。 【傾向スコアマッチング法のステップ】 共変量の特定、測定 傾向スコアのモデル指定、傾向スコアの推定 マッチングアルゴリズムの決定、マッチングの実施 マッチングした対象者で構成された集団(matched population)における治療群と対照群での交絡因子の分布評価 4.で評価した共変量が不均衡である場合には2.に戻る 群間比較の実施 推定結果の解釈   記法と仮定 記法 以下の記法の下で傾向スコアマッチングに関する議論を行います。アルファベットの大文字は確率変数を、小文字はその実数値を意味するものとします。なお、以降でボ-ルド体としている場合は単一の変数ではなくベクトルであることを意味しているものとします。 A:二値の治療変数 Y:観察されるアウトカム Ya:潜在アウトカム X:共変量(一般にはベクトル) 仮定 本記事では以下の識別可能条件を仮定します。理想的なランダム化比較試験においては研究デザインによってその成立が認められますが、観察研究ではあくまで”仮定”となります。つまり、その成立を認めることが妥当であるかどうかの議論が別途必要となることにご注意ください。また、各条件の詳細や意図する内容については本記事では取り扱いませんので、他の記事や書籍等をご参照ください。 【識別可能条件 (Identifiability assumptions) 】 一致性 (consistency) If Ai = a, then YiA = Yia = Yi  特にAが二値であるとき、   Yi = AYia=1 + (1-A) Yia=0   条件付き交換可能性 (conditional

Analytics
SAS Hackathon 2023 / チームZEAL参加報告

本記事では、ZEAL - Analysis and Projections of the Japanese Economyについて、チームメンバーに直接お話を聞き、背後にある思いやチャレンジなどについて解き明かします。 SAS Hackathon 2023 参加の背景 SIerであるZEALには、データアナリスト・データサイエンティストといったロールで働く社員は現状まだ多くはない。しかし今後はそういった人材を増やし、データ活用の世界に進出していくという目標を掲げている。 SAS Hackathon開催の知らせを受け取ったとき進むべき道が定まった。部内でプレゼンを行い、SASの取り扱い経験を問わず、興味を持った社員でチームZEALを結成した。 それがハッカソン開催の約1年前でした。そして半年前頃からテーマを何にするかチーム内で議論してきました。 SDGsをキーワードに、カーボンフットプリントを可視化することでCO2排出量を減らす事に貢献する、であったり、今後人類が必ず直面する喫緊の課題で身近な問題でもあり必ず解決する必要がある問題でもある食料問題に取り組む、など様々な案が出た。 最終的に定まったテーマは、「不確実性を消し去ることで、新型コロナのようなアウトブレイクに対して飲食業界が効果的な対策を立案できるよう支援すること」になった。当初は有価証券報告書による企業業績の変動をコロナ前とコロナ後で比べていく方針だったが、データ数が少なかったため断念せざるを得なかった。そこで、ある程度データ数が確保できる家計の支出データを使うことにした。 やはり当初から食料問題に取り組むという案が出ていたことと、コロナのようなパンデミックの影響が強く出た分野であったため、飲食業界を選択しました。家計の外食支出の変動から、間接的に飲食業界の隆盛を予測する、というものです。 コロナによる影響の強弱について念のため全産業分野を網羅的に確認した。ここでSAS Viyaの機能が役に立った。コロナの影響が特に大きかった産業分野は、飲食、交通(航空)、教育・娯楽だった。中でも交通(航空)は飲食業以上に影響が大きかった。しかし交通(航空)はテーマには選ばなかった。食糧問題に取り組むという基本方針があったからだ。 SAS Viyaは統計的知識がそこまで無くても十分に扱え、確実に結果を出すことができました。これはZEALが得意とする、「可視化によるインサイトの引き出し」というアプローチにもとてもフィットしていました。操作性も他のBIツールと比べて特段難しいというわけではなかったので問題はありませんでした。 ハッカソンに取り組む上で直面したチャレンジ 当初使用を想定していた有価証券報告書データのデータ数が時系列予測をするうえで足りないということが途中で判明したため、そこから別のデータを探し出す作業に急遽取り組む必要があった。3,4日で新しいデータが見つかった。 この部分はテーマ選定の際にも問題になりましたが、テーマはいろいろ考えられたとしても、それに必要なデータソースを集められなければ実際には分析を進めることができません。使えるデータの種類によって、取り組めるテーマが決まる、という側面がありました。 幸いZEALのサービスに、CO-ODEという日本の政府・自治体が出しているオープンデータを集積したデータベースがあり、そこに分野別家計支出データがあったので使うことにした。   具体的な取り組み内容 2つの時系列予測モデル 時系列予測モデルを2つ用意し、2つのモデルの予測値の差分をパンデミックの影響度合いとして可視化した。 つまりは、2019年12月末までをパンデミック前期間、2020年1月以降をパンデミック後期間とし、パンデミック前期間のデータで訓練したモデルをパンデミック前モデル、パンデミック後期間のデータで訓練したモデルをパンデミック後モデルとし、両者同じ将来期間のデータに対して予測をさせたうえで、その予測値の差分を取りました。 パンデミック前モデルとパンデミック後モデルの作成はいずれもSAS Viya Visual Forecastで複数のモデルを作成し、その中から精度が最も良いもの(=チャンピオンモデル)を選ぶという方法を採用した。いずれもチャンピオンモデルは、季節性モデルが選ばれた。 この辺り大変な作業のように聞こえますが、全てSAS Viya Visual Forecastによって自動処理されるのでとても簡単でした。 データの加工・整形で一工夫 必要なデータは全てCO-ODEから得ることができたが、データの加工・整形に多少の工数が必要だった。 CO-ODEの最大の売りは網羅性で、様々なソースからデータを手当たり次第かき集めてきています。使い方は使う人によって千差万別、逆に言うと使い方によってはひと手間かける必要があります。今回特に問題になったのは、時間粒度の違いでした。 データソースによって四半期粒度のもの、日次粒度のもの、と様々だったが、最終的に、月次粒度で統一した。四半期粒度のものは内挿によって月次粒度に変換した。 そこは少し試行錯誤が必要でした。一方データのETLに関しては、CO-ODEからはCSVがそのまま取り出せるので、それをそのままViyaにアップロードするだけで済みました。 成果 パンデミックによる影響を、予測値の差として可視化することに成功した。これは将来また別のパンデミックが起きたときにも参考値として利用できるものだ。 また、直接的な成果というわけではないのですが、ハッカソンを通して普段関わりのない社員同士が初めて関わりを持つようになり、社内のコミュニケーションが活性化しました。これは思わぬ収穫でした。 展望

1 2 3 4 5 54