Tag: it

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (6) – センサデータの品質を向上させる7つのポイント(後編)

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 記事の振り返り: 自覚症状が無いセンサデータの品質問題 これまで「自覚症状が無いセンサデータの品質問題」をテーマとし、「センサデータの品質を向上させる7つのポイント」について(前編)と(中編)の2回に分けてお話ししました。生産ラインのDXのために、センサデータを用いてデータ分析をしているのだが、思うような結果が得られていないケースが市場で発生していることをお伝えし、その原因の一つとして、分析対象となるセンサデータ自体の品質問題があることをお伝えしました。この問題は関係者が気付きにくく、対処方法も専門知識と経験が必要となります。 今回の後編では下記の⑥~⑦について御説明します。  図1. センサデータの品質を向上させる7つのポイント ⑥データレイクに蓄積すべきデータの選択(特徴量抽出) これまでの記事で、課題解決にマッチした高品質なセンサデータを収集することが重要だと述べてきましたが、他にも重要なポイントがあります。データレイクに蓄積すべきデータをどのように選択するのかが、昨今、課題となっています。  理由としては、AIモデル開発と更新のために、ある程度の生データ保存が必要となるからです。 この問題は、PoC段階では大きな問題になりません。PoCと称して大量にデータを取って専門の担当者が解析するからです。問題はPoC後の現場での運用です。 図2. 関連データ/センサ/特徴量の戦略的選択  それはなぜでしょうか? 各種センサが作り出すデータ量は非常に大きく、センサによっては毎分1 GB 以上のデータを生成してしまい、通信ネットワークの負荷の問題や、クラウド上でのデータ保存のコストといった現実的な問題が見えてくるためです。 例えば、図1の右側の表に示すように、サーモグラフィは動画像のため、1分間で1GB以上のデータを生成します。この場合、従量課金/ネットワークトラフィック減への対応が必要となります。温度センサ等のデータ量は、数個であれば小容量ですが、数百個もセンサを使用するケースですと、1分間に数MBにもなります。このようなデータをクラウドへ転送し続ける必要があるのでしょうか? また、高額なセンサを減らすために、できるだけセンサの数を絞りたいという要望も出てきます。これがいわゆるデータ選択(特徴量抽出)をどうたらいのかという課題の本質であり、データ分析上、特徴量の選定が重要だという理由とは異なります。では一体、どんなデータが本当に必要なのか、またデータ量を減らす時にどのような形でエッジコンピューティングを活用すべきなのでしょうか? この技術的な見解は、今後、ブログにて紹介させて頂きたいと思っておりますが、ITとOTの両方の視点から検討する必要があります。 キーワードとしてはプロ同士の意見交換です。 ⑦プロ同士の意見交換が鍵となる ここまで、センサデータの品質がデータ分析に与える影響について、データ分析企業の視点で述べてきましたが、どの注意点も専門知識と経験を要するものばかりです。つまり、成功の鍵は、プロ同士の意見交換だと言えます(図3)。もしくは「業界を超えたコラボレーションの必要性」、「ITとOTとの融合が鍵になる」と表現しても良いかもしれません。 特に現場の熟練者との協業は必須となります。現場の熟練者から伺いたい事としては、測定対象物の詳細、製造プロセスや作業工程、異常状態の詳細、また、どういうメカニズムで異常が起こるのか情報交換させて頂くことが重要です。そして、それがどれだけ困ることなのかをプロジェクトチーム内で意見交換をして頂くことが重要だと言えます。そして、センサデータ収集からデータ分析までを広く見渡した上で、AIを用いたセンサデータ分析システムを構築していくことが成功への近道だと筆者は考えています。難しく感じられる方もおられると思いますが、このプロ同士の意見交換に関しては、日本人エンジニアが得意とする高度な擦り合わせ文化が活かせると信じております。 図3. プロ同士の意見交換が大事  以上、センサデータの品質を向上させる7つのポイントを、3回に分けて紹介致しました。気になる点がございましたら、弊社までお問い合わせ下さい! 前回のブログ

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (5) – センサデータの品質を向上させる7つのポイント(中編)

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 記事の振り返り: 自覚症状が無いセンサデータの品質問題  これまで「自覚症状が無いセンサデータの品質問題」をテーマとし、前回は「センサデータの品質を向上させる7つのポイント(前編)」についてお話ししました。生産ラインのDXのために、センサデータを用いてデータ分析をしているのだが、思うような結果が得られていないケースが市場で発生していることをお伝えし、その原因の一つとして、分析対象となるセンサデータ自体の品質問題があることをお伝えしました。 この問題は関係者が気付きにくく、対処方法も専門知識と経験が必要となります。 そこで、「センサデータの品質を向上させる7つのポイント」について、今回の中編では下記の④~⑤まで御説明します。  図1. センサデータの品質を向上させる7つのポイント ④センサの設置方法  センサは種類に応じて必ずメーカが推奨する設置方法が決められています。図2は圧電型加速度センサの設置方法と注意点であり、加速度センサメーカから提供されている一般的な公開情報です。重要なのは、設置方法によっては必要なデータが得られないことです。例えば、計測可能な上限周波数は、プローブだと1 kHzが限界ですが、ネジ留めだと15 kHz近くまで測れます。これも筆者が経験した事例ですが、ユーザ様が自己流で両面テープを用いて加速度センサを貼り付けておられたために、振動が吸収されてしまい、正確な計測ができていなかったことがありました。これはさすがに、高度なデータ分析を実施する以前の問題でしたので、すぐに改善をお願いしました。 図2.  加速度センサの設置ミスによる振動データのロスト   ⑤データ収集装置の選定  データ収集装置自体の性能不足が問題になることがあります。これは盲点であり、自覚症状が出にくいものです。たとえ高精度なセンサを設置してデータ収集したとしても、適切なデータ収集装置を選定しなかったために、データの精度を低下させてしまうケースがあります。特に重要なのは、サンプリング周波数、分解能、同期計測の3つです(図3)。 図3. 適切な計測装置の使用が不可欠  サンプリング周波数に関しては、計測器の選定基準の一つとして必ずカタログ等に記載されており、また、近年はサンプリング周波数が不足しているデータ収集装置は稀なため、選定ミスの原因にはなりにくくなっています。しかし、分解能に関しては注意が必要です。例えば、加速度センサやマイクロフォンを用いた計測では、 24 bit分解能のデータ収集装置を使用するのが業界標準だが、16 bit分解能の装置を使用しているケースがあります(一般的なオシロスコープは8 bit分解能)。この場合、計測データに与える影響としては、波形再現性の悪化と微少な変化の取りこぼしが発生します。仮に機械学習を用いて異常検出をするとしたら、感度不足が起こる可能性があります(表1)。  表1. センサ計測ミスの原因とデータ分析に与える影響    極めて重要であるにもかかわらず、ほとんど意識されていないのが、同期計測です。各種センサデータ同士の時間的タイミングが取れていない場合は、厳密なデータ分析ができない場合があるからです。例えば、周期性のある回転機械や往復運動機械の異常検知を行う場合には、各種信号の立ち上がりタイミングや信号の発生サイクルが異常検知上、大きな意味を持つため、同期が取れていないデータでは異常検出が困難な場合あります(図4)。厳密には、計測装置の同期精度が、実施したいデータ分析用途に合っているかどうか判断する必要があります。高速動作をする精密機械の状態監視では、マイクロ秒レベルの同期精度が要求される場合もあり、一般的な工作機械ではミリ秒レベルで十分な場合があります。 図4.同期計測の重要性 データ収集装置の選定ミスにより、不具合の発見ができなかったという事例を、筆者は数件経験しています。例えば、高速印刷機の印刷ズレの原因分析に携わった時のことです。原因はベアリングのわずかな損傷で、それが原因で印刷ズレが発生していました。ですが、お客様のお持ちのデータ収集装置は、サンプリング周波数と分解能が低く、異常波形が検出できておりませんでした。そのため、筆者が持ち込んだデータ収集装置を使い原因分析は成功しました。加速度センサは最高のものでしたが、それを活かしきれるデータ収集装置の選定に問題があったという事例でした。 これまでの記事で、センサデータの品質を向上させる7つのポイントのうち5つを紹介してきました。 残り2つのポイントは、後編にて御説明します。 前回のブログ  次回に続く

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (4) – センサデータの品質を向上させる7つのポイント(前編)

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 前回の振り返り: 結果が出ないPoC(Proof of Concept:概念実証)  前回の記事では「自覚症状が無いセンサデータの品質問題」についてお話ししました。生産ラインのDXのために、センサデータを用いてデータ分析をしているのだが、思うような結果が得られていないというケースが市場で発生していることをお伝えし、その原因の一つとして、分析対象となるセンサデータ自体の品質問題があることをお伝えしました。 この問題は関係者の自覚症状もないため気付きにくく、対処方法も専門知識と経験が必要となります。 そこで、今回から前編/中編/後編の3回に分けて、「センサデータの品質を向上させる7つのポイント」について御説明します。 センサデータの品質を向上させる7つのポイント  現場では正確なセンサデータ収集(計測)を行っているつもりでも、気付かずに失敗しているケースが数多く存在していることに注意して頂きたいです。これは、計測ミスしたデータをいくら解析しても、良い結果は得られないからです。このような計測ミスを防ぐためのポイントは以下の7つだと言えます。 ※本記事では、上記の①~③まで御説明します。 ① 異常状態の発生メカニズムの理解(測定対象物の理解) この異常状態の発生メカニズムの理解は、測定対象物の理解を深めることだと言い換えることもできます。 いくつか例をあげてみます。ポンプのような回転機械の軸受けの不具合は異常振動として現れ、その結果として異音が発生します。また、音響機器はスピーカの取り付け不具合により、ビビリ音という異音が現れます。そして、プレス機のような往復運動機械の場合は、往復周期がぶれることにより、生産品の加工精度にバラツキが生じることがあります。さらに、射出成形機の場合は、材料の注入圧力の時間的変化にバラツキが生じた場合にうまく成形できない場合があります。 このように、測定対象物の異常状態が、なぜ起きるのかを物理的な観点から把握することが第1ステップとなります。 ところがこれが意外と難しいため、解決策としては、異常状態を把握している可能性の高い、現場の熟練オペレータなどからの情報収集が重要になります。 ② センサの選択(取得データの選定) よくあるミスとしては、センサの選択ミス、いわゆる取得データの選定ミスがあげられます。原因の一つは、上述の「①異常状態の発生メカニズム」が事前に理解できておらず、適切なセンサ選定ができなかったことに起因しています。例えば、回転機械の軸受けの不具合は異常振動として現れるため、異常検知のためには加速度センサを用いて振動データを取得することがベストだと言えます。また、音響機器のスピーカの取り付け不具合によるビビリ音の検出にはマイクロフォンを用いた音響計測が適切だと考えられます。 実はセンサ選定が不要な場合もあります。例えば、機械の制御信号が外部出力されているようであれば、そのままデータ収集することも可能です。 他にも原因があります。それは、システム構築を担当しているシステムインテグレータ(SIer)の得意分野が影響しているケースがあります。実際、SIerが得意としていないセンサは選定候補に上がってこないケースがあります。表1は、状態監視のために使用される代表的なセンサをまとめたものです。センサの種類によっては専門メーカや専門のSIerがいるものもあり、中には高性能な計測器が必要とされるセンサもあります。これは筆者が経験したことですが、製造装置の状態監視の際に、電流を使った異常検知の方が適切だと思われるケースがありました。ですがそこでは加速度センサが使用されていました。理由は業者が得意とするセンサ計測領域に偏りがあったことと、特に明確な理由がないまま、加速度センサが選択されていた状況でした。無論、生データには異常信号が弱く含まれており、データ分析をしても良い結果が得られていませんでした。そのため、筆者はセンサの変更を進言しました。 表1.状態監視に使用される代表的なセンサ ③ センサの取付け位置 センサの取付け位置も重要です。例として生産品の品質管理と製造装置の異常検知の例をあげてみます。機械はローラ機械である。図1左側の写真は、加速度センサを用いた軸受けのモニタリングであり、X、Y、Z軸に加速度センサが取り付けられている。この例は正しく設置されている例である。  医者の診断に例えれば、心臓の診断のために心音を聴こうとする医者は、どこに聴診器をあてるでしょうか? もちろん胸ですよね? 足に聴診器をあてて心音を聴こうとするお医者様がいたらかなり心配になりますよね? このような、あり得ない状況がセンサの取付け位置のミスとして起こっている場合があります。このような事態を防ぐには、「なぜそのセンサを設置するのですか?」とSIerに質問するなり、自問自答してみると良いと思います。また、「設置するセンサの数、取り付け方向はどうすべきか?」という問いに関しても明確な理由を持っておきたいですね。             図1.生産品の品質管理と製造装置の異常検知(ローラ機械の例) 以上、センサデータの品質を向上させる7つのポイントのうち3つを紹介しました。 次回は、④~⑤について御紹介します。 前回のブログ  次回に続く

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (3) – 自覚症状が無いセンサデータの品質問題

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 今回から、「自覚症状が無いセンサデータの品質問題」に関連した話題をお伝えしていきます。  結果が出ないPoC(Proof of Concept:概念実証)  SASは世界各国に支社を持ち、製造業DXの実現に向けた数多くのデータ分析案件を取り扱っています。 よく頂く御相談内容としては、生産品の品質管理と設備保全系に関連するデータ分析システムの導入検討です。(図1)    図1. 生産ライン向けDXとしてよくある御相談   ところが、PoCとしてセンサデータを用いてデータ分析をしているが、思うような結果が得られていないというケースが市場で発生しています。多くの方がデータ分析手法に問題があるのではないかと考え、データ分析のスペシャリストである弊社に御連絡を頂きます。たしかに分析手法の問題もあり、原因は様々ですが、意外と盲点になっているのが分析対象となるセンサデータ自体の品質問題です。  センサデータの品質問題とは何か?  データ分析はデータ収集から始まります。そして、そのデータの質が分析結果に影響を与えることは容易に想像できます。図2はセンサデータ分析システムの構築の流れを示しています。システム構築は、データ収集からスタートし、データ蓄積、そしてデータ分析という順番で実施され、手動でデータ分析の結果が出るようになった段階で自動化するという流れが一般的です。  図2. センサデータ分析システムの構築の流れ   図3は、センサデータの分析の際にAIの導入を意識して描いたものです。流れとしては、経営上の目標設定から始まり、データ取得、特徴量抽出/次元削減、そしてモデル作成へと進んでいきます。ここで皆様に質問させて頂きたいのは、どの工程が一番重要なのかということです。無論、どの工程も専門家の知見が必要であり、重要かつ難易度が高いのは当然ですが、最も重要なのは前半のデータ取得と特徴量抽出だと、あえて強調します。言い換えますと、モデル作成に使用されるセンサデータの品質(精度)が重要だということです。当然ではありますが、センサデータの質が悪い場合、データ分析(作成するモデルの精度)に影響が出てしまうためです。 医者の診断に例えれば、検査データが間違っていたら間違った診断を下してしまうのと一緒であり、センサデータの品質は極めて重要だと言えます。  図3. AIを用いたセンサデータ分析システムの開発の流れ 自覚症状が無いセンサデータの品質問題  この問題の恐ろしい点は、システム開発に携わっている関係者の皆様にとって自覚症状が表れない場合が多いことです。 そもそも、データ分析の結果が出ない原因が、上述のセンサデータの質に関係していることを、どうやって判断すれば良いのでしょうか? 当然、他の原因も考えられます。   先日、お医者様と健康診断の検査結果のお話をした際に気がついたのですが、お医者様は検査データの意味や限界、誤差要因をよく御存知のようでした。そして総合的に私の健康状態を判断しておられるようでした。思わず、その秘密を知りたいと思い質問してしまったのですが、お医者様の回答は「過去の事例と経験即かなぁ~~??」と、お答えいただきました。  ということで、次回以降、私の経験即に基づいたチェックポイントを御紹介していきます。  前回のブログ  次回に続く

Analytics | Internet of Things
0
製造業DXにおけるITとOTとの融合 (2) - 生産ラインにおけるAIを用いた状態監視の種類

医者の診断に例えて学ぶ AIを用いたセンサデータ分析システムに関するよくある誤解について 製造業で盛んに導入されているセンサ。 そのセンサデータを分析してビジネスインパクトのある結果を出すには、どのようにしたら良いのでしょうか? データ分析を成功させるためには、様々な要素が考えられますが、ここではセンサデータの質に注目したいと思います。いくら高度なデータ分析手法を用いても、分析対象のセンサデータが正しく取得できていない場合は、結果が出ないことは容易に想像できますが、あまり議論されることはありません。 これは、センサ計測とデータ分析の両方を視野に入れた幅広いノウハウが必要となり、Information Technology (IT) と Operational Technology (OT)との融合という課題に行き着くためです。 本ブログでは、このマニアックな話題を、医者の診断に例えながら、わかりやすく解説していきます。 はい、今回は、「生産ラインにおけるAIを用いた状態監視の種類」について解説します。 図1に示した通り、種類としては4つに大別されます。 どれを実現したいのかで、取得すべきセンサデータの種類や、データ分析システムの構築難易度が変わってきます。 読者の皆様は、どれを実現したいとお考えでしょうか? 図1.生産ラインにおけるAIを用いた状態監視の種類は4つある 1つ目が異常検知です  これは生産品の品質異常や生産ラインの設備機械の異常を捉えるものであり、学術的には「教師なし学習」と呼ばれる手法を用います。この場合、異常時のデータを予め用意する必要がないため、不具合データの取得が困難な製造業の現場において有効となります。例えば、正常時の各種センサデータを基準とし、どれだけ正常状態から離れたかで、異常を検出する方法です。 2つ目は原因診断です これは異常発生後に、何が原因なのか特定するものであり、学術的には「教師あり学習」と呼ばれる手法を用います。この場合、異常時のデータを予め用意しておく必要があります。 原因診断が必要とされる理由としては、対処方法の検討をつけるためです。 製造装置であれば、点検箇所や分解すべき箇所を特定することにより、分解コストや部品交換コストを抑えることができます。 これは大型機械の場合、特に重要であり、この原因診断は「精密診断」とも呼ばれ、まさに職人技が要求される分野です。 3つ目が品質/寿命予測です これは各種データから、生産品の品質を予測したり、稼働中の設備や部品が、あとどれくらい使用できるか日数を予測するものです。 例えば、生産品の品質予測が可能になると、抜き取り検査の精度が向上し、ランダムにサンプル取得をするのではなく、品質上懸念がありそうなものをサンプルして効率良く評価できるようになります。 また、設備や部品の寿命予測が可能になれば、高額な部品をできるだけ長く使用することができますし、メンテナンス日程を戦略的に決めることも可能になります。 4つ目がパラメータ最適化です これは、期待した品質で生産するためには、どのような製造環境や材料構成が必要なのか、また、どのように製造装置を制御したらよいのか決定することができます。 図1に示したデータ活用の流れは、人間の健康診断と全く同じであり、1番から4番まで順番に実施する必要があり、飛び越えることはできません。 医療に例えますと、1番の「異常検知」は、正常時との変化を検出するものであり、いわば定期健康診断に相当するものです。 2番の「原因診断」は、定期健康診断で早期発見された異常を、さらに掘り下げて精密検査を行うものです。 3番の「品質/寿命予測」に関しては、医学でも同様であるが、これまでの長年にわたるデータが揃うことにより、治癒率予測が可能になります。 4番の「パラメータ最適化」は、健康で過ごすための予防方法だと言えます(図2)。そして、豊かな人生を過ごすために、どなたも4番の予防までを期待されておられると思います。 図2. 医療診断の流れと、生産ラインにおける品質管理/設備状態監視の流れはよく似ている 生産ラインでも同様です。最後の4番まで実現できれば、ビジネス上の費用対効果(ROI)は最大となります。 それには、分析に必要な各種データを準備する必要があり、その質も重要になります。 しかしながら現実問題として、いきなり4番から実現することはできないため、4番のパラメータ最適化の実現をゴールとしながら、1番から順番に実現していく必要があることを御理解ください。また、医学でも同様のことがいえるかと思いますが、生産ラインにおける状態監視対象物によっては、1番の異常検知が技術的な限界となり、2番以降に進めない場合もあります。 この見極めも重要となってきますが、この点は本ブログのテーマとして別途取り扱いたいと思います。 前回のブログ  次回に続く

Analytics | SAS Events
SAS Global Forum 2019 論文紹介シリーズ 第4回「オペレーショナル・アナリティクス for IT」

前回は、ビジネス価値創出につながる「オペレーショナル・アナリティクス for Data Scientist」ユースケースの論文を紹介しました。今回は、企業様にとって、クラウド上のインフラアーキテクチャと分析プラットフォームのデプロイメントについて、ご紹介します。昨今、なぜ「コンテナ」が注目されているのか、そして、クラウドやコンテナ上に分析プラットフォームを移行/構築し、活用することに関心があるのであれば、ぜひ最後までご覧ください。 1.Cows or Chickens: How You Can Make Your Models into Containers モデルは特定の作業(新しいデータをスコアリングして予測を出すこと)として役割を果たしてきています。一方、コンテナは簡単に作成し、廃棄し、再利用できることができます。実際、それらは簡単にインテグレートさせ、パブリッククラウドとオンプレミス環境で実行できます。SASユーザは本論文を通じて、簡単にモデルの機能をコンテナに入れることができます。例えば、パブリッククラウドとオンプレミス環境でのDockerコンテナ。また、SASのModel Managerは様々なソース(オープンソース、SAS、コンテナ等々)からモデルの管理を行うことができます。したがって、この論文はそれらの基本知識と、どのようにSASの分析モデルをコンテナに入れることをメインに紹介します。 2.Orchestration of SAS® Data Integration Processes on AWS この論文では、Amazon Web Services(AWS)S3でのSASデータインテグレーションプロセスの構成について説明します。例としては、現在サポートしているお客様がクレジット報告書を生成するプロセスを毎日実行しています。そして、そのお客様の対象顧客は1カ月ごとに1回その報告を受け取ります。データ量としては、毎日に約20万の顧客情報が処理され、最終的に毎月約600万人の顧客へ報告することとなります。プロセスはオンプレミスデータセンターで始まり、続いてAWSのSASデータインテグレーションでAPR計算が行われ、最後にオンプレミスデータセンターで報告書が生成されます。さらに詳しい情報としては、彼らのアーキテクチャ全体はマイクロサービスを使われていますが、同時にAWS Lambda、簡易通知サービス(SNS)、Amazon Simple Storage Service(Amazon S3)、およびAmazon Elastic Compute Cloud(EC2)などの独立した高度に分離されたコンポーネントも使われています。つまり、それらにより、データパイプラインに対するトラブルシューティングが簡単になっていますが、オーケストレーションにLambda関数を使用することを選択すると、プロセスがある程度複雑になります。ただし、エンタープライズアーキテクチャにとって最も安定性、セキュリティ、柔軟性、および信頼性もあります。S3FやCloudWatch SSMのようなより単純な代替手段がありますが、それらはエンタープライズアーキテクチャにはあまり適していません。 3.SAS® on Kubernetes: Container Orchestration of Analytic Work Loads 現在、Big Dataの時代で、Advanced analyticsのためのインフラストラクチャに対するニーズが高まっています。また、分析自体に対して、最適化、予測が最も重要領域であり、小売業、金融業などの業界ではそれぞれ、分析に対する独自の課題を抱えています。この論文では、Google Cloud

Analytics
John Green 0
Not your father’s IT Department

Today’s IT department isn’t your grandfather’s IT department. It’s not even your father’s IT department. When people talk about Information Technology Departments of the past, it's usually broken into three distinct periods: The Mainframe; PCs; the Internet/post PC. The IT department was seen as the hardware support arm of an