DatabricksでMLflowを使う② - 実験パラメータとメトリクスの可視化 -

はじめに

前回のこちらの記事ではDatabricks上でMLflowを使って機械学習モデルのトレーニングを行った履歴をノートブック上に統合するための方法について書きました。

DatabricksでMLflowを使う① - ノートブック上での実験トラッキング -

Databricksのマネージド型MLflowではUI上でトレーニングモデルのパラメータやメトリクスの比較、モデルのステージングなどを行うことができます。

この記事では実験ごとのパラメータやメトリクスを可視化して比較する部分について書いています。

実験ごとのUI画面

前回記事でノートブック上で実験ごとのメトリクスなどを確認した画面から、図中赤枠の部分をクリックします。
図2.png

実験ごとの情報がまとめられた画面に移ります。メトリクスやパラメータ、統合されているノートブックなどが表示されます。
図3.png

下のほうにスクロールすると、アーティファクトファイルとしてモデルや環境設定のデータ、実験結果のスクリーンショットなどが保存されています。
図4.png

ノートブックにMLflowを統合した場合は実験idが自動で割り振られて、実行結果ごとにrun_idが割り振られて管理されます。アーティファクトファイルはDBFS内のディレクトリに保存されます。

各実験の比較

ノートブックから「Runs」の右にある下図の赤枠部分をクリックします。
図5.png

各実験の一覧が表示されます。
image.png

比較したい実験を選択して「Compare」します。
image.png

パラメータやメトリクスが比較できます。それぞれのrun idをクリックすると前述の実験の個別ページに移動します。
image.png

下にスクロールするとパラメータやメトリクスを可視化して比較することができます。
image.png

おわりに

今回はDatabricksのUI上で実験パラメータやメトリクスを可視化して比較しました。
次回はトレーニングしたモデルを本運用に移行するためのステージングについて書きたいと思います。


【MLflow】Databrciks 環境で実験トラッキング - Python-

はじめに

Databricks環境下でオープンソースプラットフォームである MLflow を利用します。
実験データの統合・トラッキング方法を解説します。
また、本記事は Python3 を想定しています。

この記事の概要

  • Databricks 環境で MLfow を使うことできること
  • MLflow の使い方
  • サンプルデータを用いた実験の情報をノートブックに統合・トラッキング方法

Databricksのマネージド型MLflow

オープンソースであるMLflowはあらゆる ML ライブラリや言語、デプロイメントツールで動作するように設計されていますが、
自前で実験のトラッキング用のサーバーを用意する必要があります。

Databricks環境下では

  • MLflowはマネージド型のサービスとして利用可能。
  • トラッキング用のサーバーを別途用意する必要なし。
  • 実験のトラッキング情報をノートブックに統合して管理可能。

MLflowの使い方

Databricks上で使っているクラスターがRuntime MLの場合は最初から入っています。
それ以外の場合はMLflowをインストールする必要です。

[crayon-628632d1cbfff624422598/]

上記コマンドでインストールできます。そしてインポートします。

[crayon-628632d1cc009461635141/]

MLflowでは

  • トラッキング開始のモジュールを呼び出してトラッキングを開始
  • 実験のパラメータやログを記録するモジュールで記録
  • トラッキング終了のモジュールで一つの実験トラッキングが終了 という形になります。

終了し忘れ防止のためにもwithを使うのがいいと思います。
実装部分のコードのイメージとしては以下の通りです。

[crayon-628632d1cc00c669814567/]

パラメータ以外にもモデルの記録や実験中に出力した画像などもトラッキング先に保存できます。
モデルの記録には、該当するライブラリのインストールが別途必要です。
例)scikit-learnのモデル → mlflow.sklearn

実装

実際に実装してノートブック上でトラッキングしてみます。

サンプルデータセットと使用モデル

scikit-learnの糖尿病データセットを使います。
カラムの説明などはこちらにあります。
https://scikit-learn.org/stable/datasets/index.html#diabetes-dataset

今回のモデル作成にはElasticNet線形回帰モデルを使います。
調整パラメータとしてalpha、l1_ratioがあります。

ElasticNetについてはこちらの説明がわかりやすかったです。
https://aizine.ai/ridge-lasso-elasticnet/

セットアップ

各種ライブラリのインポートとサンプルデータセットの読み込み、データフレームの作成を行います。

[crayon-628632d1cc00e150303111/]

結果処理部分の実装

ElasticNetで回帰モデルを作ったときの説明変数の各係数をプロットして、それを画像としてドライバノードに保存する処理を定義しています。

[crayon-628632d1cc011503074566/]

実験処理部分の実装

alphaとl1_ratioを指定してモデルのトレーニングを行います。上で定義したplot_enet_descent_pathを呼び出してトラッキング先にログや画像を保存します。

[crayon-628632d1cc013449995752/]

実験

調整パラメータを与えて実験を行います。

[crayon-628632d1cc016490072268/]

出力結果は次のようになりました。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_618791_83f4d625-03b3-a99b-2d41-582a98b8ba97.png

画像を出力してみます。
https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_618791_101943a6-9207-af62-380a-ca11bd234cc1.png

いくつかパラメータを変えて実験してみます。(合計4パターンほどやってみました)
実験が終わったら右上のあたりに[Runs]と書かれた部分を押します。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_618791_6dd4d923-3f5c-5847-8325-037740512075.png

設定したパラメータの値と出力されたメトリクスが実験ごとに記録されているのが確認できます。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_618791_2ab43d48-afff-2de2-48ff-429a7812cbee.png

おわりに

今回はノートブック上でモデルのトレーニング結果をノートブックに統合・トラッキングする方法について紹介しました。

Databricks では UI 上でこちらの実験データを比較ができるようになっています。
続編として、UI 上のモデル管理について書きたいと思います。

次回もお楽しみに!


Spark + AI Summit 2020ダイジェスト Redash編

はじめに

本記事では Databricks Japan 株式会社主催「Spark + AI Summit 2020ダイジェスト」で紹介されたRedash についてご紹介いたします。

Redash とは

image.png

SQLでの分析結果を可視化し共有するオープンソース BI ツールです。SQLでクエリを作成することで、データソースからデータ取得可能です。
データサイエンティストやSQLアナリストのデータ活用を促進しています。
以下のような本番環境で利用されています。
image.png

DatabricksにRedashが加わる!

米国時間6月24日に Databricks社 が Redashの買収を発表しました。
これにより以下の項目でデータ活用の促進が期待されています。

■パワフルなSQLエディタ

  • スキーマを選択して利用
  • 再利用可能なクエリを作成
  • スケジュール実行やアラートの設定

■可視化と共有

  • 多様な可視化パターンと目的別のダッシュボード作成
  • ドラッグ&ドロップによる可視化グラフのサイズ変更
  • ダッシュボードのチーム間での共有によるナレッジシェア

■多種多様なデータソースに対してクエリ可能(SQL,NoSQL,big data,API)

まとめ

今後DatabricksにRedashが統合される予定です。今後のDatabricksの動向に期待です。


Spark + AI Summit 2020 ダイジェストの内容ご紹介します - Delta Lake -

はじめに

2020年8月26日に Spark + AI Summit 2020 のダイジェストセミナーが実施されました。
この記事ではデータウェアハウスとデータレイクの考え方を統合したレイクハウスという概念を実現するための Delta Lake についてご紹介します。

Delta Lake とは

構造/非構造化データを蓄積するデータレイク上に構成するストレージレイヤーです。

image.png

Delta Lakeによって、構造化されたトランズアクションを実現するストレージレイヤーを構成することができ、レイクハウスの概念を実現することができます。
image.png

データレイクにおける9つの課題と解決策

Delta Lakeはデータサイエンス・機械学習にデータレイクを活用するうえで生じる9つの課題に対応するために開発されました。

  1. データを追加することが難しい
  2. 既存データの変更が難しい
  3. ジョブが途中でエラーとなった時の対応が難しい
  4. リアルタイムデータの取り扱いが難しい
  5. データの履歴をバージョンで保有するとコスト的に厳しい
  6. 大量のメタデータを扱うことが難しい
  7. "沢山のファイル"を適切に扱うことが難しい
  8. 最高の処理性能を享受することが難しい
  9. データ品質を担保することが難しい

ACID トランズアクション

Delta Lakeではデルタログという変更履歴データによってバージョンが管理されます。これにより全オペレーションをトランズアクションとして実行可能なものとなり、履歴データを参照することで過去のトランズアクションをレビューすることも可能となります。(課題1~5の解決策)

Spark の特性

sparkは大量データ処理用のフレームワークとして開発されました。Delta Lakeではparquet形式で格納されており、Spark で処理するデータはその一部がキャッシュ化され、高速なアクセスが可能となるよう最適化されています。また、データとメタデータが常に一緒に格納されているため、カタログとデータを同期する必要がないことも大量データの取り扱いを容易にしています。(課題6の解決策)

インデックス

  • パーティショニング
    典型的クエリのためのレイアウト
  • データスキッピング
    数値統計に基づいて整頓されたファイル群
  • Zオーダー
    複数カラムの最適化レイアウト

というレイアウトが自動で最適化されるため、高速なアクセスを可能とします。(課題7,8の解決策)

スキーマ妥当性の検証

SQLによってデータ品質保証のためのプロファイルを定義し、すべてのテーブルはすべてのエクスペクテーションを満たすデルタ・エクスペクテーションによってデータの品質を担保しています。(課題9の解決策)
image.png

Delta Lakeの活用方法

フォーマットを "parquet" から "delta" にすることでデルタ形式のテーブルを扱うことができます。既存のテーブルを変換して使うことも可能です。また、Delta Lake ビッグデータ・ストレージをオープンな形式で標準化しているため、多種多様なツールからのアクセスが可能となっています。
image.png

まとめ

今回はデータレイクとデータウェアハウスのいいとこどりであるレイクハウスを実現するためのDelta Lakeについてご紹介しました。
次回はDelta Lakeを高速に扱うためのクエリエンジンであるデルタエンジンについてご紹介します。


【AI入門】Azure の音声AIサービスを使って音声からテキストに変換してみた!

はじめに

AI 使ってみたいけど何からやってみようかな???
Microsoft Azure の音声サービス 【Azure Speech SDK】 を使って音声をテキスト変換を体験してみませんか?

Azure Speech SDK ではリアルタイムでの音声や音声ファイルからもテキスト変換が行えるようなので検証していきます!

今回の検証では以下の方々を想定した記事となっています。

  • これからAIを使って何かしてみたいけど何からやればいいかわからない方
  • Azure を触ったことがある方(Azureアカウントを持っている)
  • 音声サービスを試してみたい方

開発環境

Windows 10
Python 3.6
Anaconda
Azure Speech SDK

マイクから音声を認識する

1.Azureポータルにログインして、音声サービスを作成します。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_63863_1402e263-8cce-8b79-bc7b-ea0f1ede2072.png

2.作成したリソースへ移動し、キーと場所をコピーしておいてください。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_63863_68ff2eaf-ca4b-54ff-4871-60db6592ff8f.png

3.Python 3.6環境を作成します。

[crayon-628632d1ccb6d452906373/]

4.ライブラリをインストールします。

[crayon-628632d1ccb73744687719/]

5.プログラムを作成します。

一度だけ音声入力して認識結果を表示するプログラムです。”YourSubscriptionKey”に先ほどコピーしたキーを, “YourServiceRegion”に先ほどコピーした場所を貼り付けてください。日本語を認識したいのでlanguageは”ja-JP”にします。

[crayon-628632d1ccb76643003890/]

こちらは継続的に音声入力して、認識結果を表示するプログラムです。同様にキーと場所、言語の設定をお願いします。

[crayon-628632d1ccb78197190659/]

6.下記コマンドを実行し、話しかけてみてください。

[crayon-628632d1ccb7a777104591/]

認識結果が以下のように表示されます。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_63863_345b1af5-a1f1-4510-3ef5-d53c737cbcd3.png

音声ファイル(.wav)から音声を認識する
1.導入方法は上と同様にしてください。
2.プログラムを作成します。

.wavファイルを読み込み、音声認識結果を表示するプログラムです。キーと場所を設定してください。

[crayon-628632d1ccb7d790069244/]

音声ファイルはcognitive-services-speech-sdkにあるsampledata\audiofiles\aboutSpeechSdk.wavを用います。

3.下記コマンドを実行し、結果を見てみましょう。

[crayon-628632d1ccb7f947477581/]

キーと場所が正しくないと下記のようなエラーが出ます。

[crayon-628632d1ccb81471412603/]

結果は下記のようになりました

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_63863_eab294e9-03f3-0a1a-bf74-9eb1e1c08bfa.png

52秒あるのですが、最初の一行を認識したら、終了してしまうようです。

4.継続的に読み込み、音声認識するためには、下記のようにします。

[crayon-628632d1ccb84738413298/]

5.再度実行してみましょう。

下記のように継続的に音声認識できているようです!

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_63863_b73cf903-34b7-56db-99e8-cc0970c494cd.png

お疲れ様でした。

最後に

Azure Speech SDK を使って会議の議事録などを自動化できるかもしれないですね!
次回は少し長めの音声でどのくらいテキスト変換できるのか試してみたいと思います!
最後まで読んでいただきありがとうございました。

参考


Delta Lake - Open Source Reliability for Data Lakes について翻訳し、まとめてみた

はじめに

今回は、Michael Armbrust 氏による「Data Reliability for Data Lakes」の動画を翻訳し、まとめてみました。
本動画については、下記リンク先参照でお願いします。

■リンク
・ Delta Lake - Open Source Reliability for Data Lakes

Data Lake について

Data Lake の現状

現在、様々な企業が Apache Spark を用いて、Data Lake にデータを置き、データサイエンスや機械学習のプロジェクトなどに利用してきました。

■Data Lake を利用する3つの理由

  • とても安価に利用可能
  • スケーラブル
  • 置いたデータを様々な用途で利用可能

しかし、Data Lake を利用するにあたって、ある問題が発生しております。それは、Data Lake に置いてあるデータが整理されていない為、プロジェクトの進行が阻まれるという事態です。信頼性の低いデータの存在により、様々なプロジェクトが生まれては失敗で終わるという事態が実際に起きてます。

スクリーンショット 2020-06-18 10.25.29.png

Data Lake を用いたプロジェクトの進め方

図は一般的な Data Lake を用いたプロジェクトの進め方です。
スクリーンショット 2020-06-18 10.40.17.png

■プロジェクトのポイント
①λ-arch を構築
②検証アーキテクチャの構築
③Data Lake の再処理(不純なデータが無いか確認)
④アップデートの実施

実際にプロジェクトを進めていくにあたり重要なポイントは4つですが、図のような構成を組む必要がある為、プロジェクトを順調に進めるのは簡単ではありません。Data Lake において、データの信頼性を維持するのはとても難しく、その理由は3つあります。

スクリーンショット 2020-06-22 15.54.35.png

■複雑な構成になる3つの理由

  • ジョブの失敗
    • 破損したままのデータの放置は復旧に多くの時間が必要
  • 品質の低下
    • 矛盾した不整合データの生成
  • トランザクション不足
    • アペンドや読み込み、バッチやストリーミングの実行がほぼ不可能

Delta Lake について

Delta Lake を用いたプロジェクトの進め方

それでは、Delta Lake を用いた場合はどうなるでしょうか。
Delta Lake を用いた場合は、Data Lake の時の構成とはだいぶ異なり、プロジェクトの進め方は図の様になります。
スクリーンショット 2020-06-18 11.05.51.png

Delta Lake の一番の特徴は、データを利用するまでデータの品質を向上させることが可能という点です。
それを可能にしているのが、Delta Lake の下記の3つの特徴です。

  • フル ACID トランザクション
  • オープンソース
  • Apache Spark を利用

Delta Lake の場合、図のように「Bronze」、「Silver」、「Gold」といった3つの段階を踏んでおります。
それぞれの段階における内容についてまとめました。

  • Bronze
    • 生データの摂取と、最小限の構文解析
    • 数年にわたる長期保存が可能
  • Silver
    • データのフィルタリングやクレンジング、強化などを適用した中間データ
    • 簡単にデバッギングできるようクエリが可能
  • Gold
    • 実行可能な綺麗なデータ(BI や ML での利用も可能な状態)
    • Spark や Presto で利用可能な状態のデータ

スクリーンショット 2020-06-23 10.21.03.png
また、Delta Lake は Bronze に生データを置いている為、ビジネスロジックの変更などで計算し直す必要が出た場合は Silver と Gold を削除し、再び Bronze から始めるだけなので、とても簡単に実行できます。

おわりに

「Data Reliability for Data Lakes」の翻訳は以上です。
Delta Lake の流れや仕組みについて詳しく記載されており、とても役立つ動画です。本編では、より詳細な内容について話されているので、ぜひ御覧ください。

 

 

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Delta Lake について翻訳し、まとめてみた

はじめに

Delta Lake について、下記のリンク先の記事と動画を参考に、内容を翻訳してまとめてみました。
本記事にはより詳細な内容が記載されているので、そちらも参照してください。

■リンク

Delta Lake について

Delta Lake とは

Delta Lake はデータレイクに信頼性をもたらすオープンソースのストラテジレイヤです。
Delta Lake を利用するメリットとしては、3つ挙げられます。
image.png

Delta Lake の特徴

Delta Lake には、ユーザが快適に利用できるよう10の機能があります。
■Delta Lake の10の機能

  • ACID トランザクション
    • ACID トランザクションをデータレイクに提供
    • 最強の分離レベルであるシリアライザビリティを提供
  • スケーラブルなメタデータのハンドリング
    • Spark の分散プロセス力を利用して、数十億のファイルを持つペタバイト規模のテーブルの全てのメタデータを簡単に処理可能
  • タイムトラベル(データのバージョニング)
    • ロールバックや監査証跡の全履歴、そして再現可能な機械学習実験などがデータのバージョニングで可能
  • オープンフォーマット
    • Delta Lake の全データを ApacheParquet 形式で保存
    • Parquet にとってネイティブな効率的な圧縮とエンコーディングスキームを提供
  • 統一されたバッチとストリーミングのソースとシンク
    • Delta Lake のテーブルはバッチテーブルでもあると同時に、ストリーミングソースやシンクでもある
    • ストリーミングデータの読み込み、バッチ履歴の埋戻し、対話型クエリをそのまま使用可能
  • スキーマの実施
    • Delta Lake はスキーマを指定して実行する機能を提供
    • 不良データによるデータ破損を回避し、正しいデータタイプとカラムの存在を確認することが可能
  • スキーマの進化
    • Delta Lake デーブルスキーマに変更を加え、自動的に適用される
    • DDLといった面倒は不要
  • 監査履歴
    • Delta Lake のトランザクションログは、データに関するあらゆる変更履歴を記録
    • 完全な監査証跡も提供
  • アップデートと削除
    • データセットのマージ・更新・削除する Scala/Java API のサポート
    • GDPR と CCPA に簡単に準拠でき、変更データキャプチャなどのユースケースも簡素化可能
  • Apache Spark API との 100% の互換性
    • 大規模データ処理エンジンとして利用される Spark と完全互換性
    • Delta Lake を最小限の変更で既存のデータパイプラインと利用が可能

Data Lake と Delta Lake の違い

下記は、Data Lake と Delta Lake の違いを図に表したものです。
image.png

  • 信頼性
    • Delta Lake:高(スキーマの ACID 操作を強化することでデータの信頼性を高める)
    • Data Lake:低(あらゆるデータを許可し、結合も遅いため、大量の孤立したデータが生まれる)
  • 統一性
    • Delta Lake:高(バッチやストリームデータを同一のパイプラインで生成可能)
    • Data Lake:低(ストリーミングプロセスにはホットパイプランが必須)
  • パフォーマンス
    • Delta Lake:高(Zオーダスキッピングファイルで効率的な読み取り)
    • Data Lake:中(シーケンス読み取り)
  • 使いやすさ
    • Delta Lake:中(DBA オペレーションを求められる)
    • Data Lake:高(スキーマへの記述も不要で、どのようなデータも許可)

信頼性、統一性、パフォーマンス、使いやすさ、の4項目でそれぞれ比較した結果、Delta Lake の方がData Lake に比べてより優れているのがわかります。

おわりに

Delta Lake に関する説明は以上となります。
より詳細な内容については、リンク先の記事等を参照ください。

 

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


MLflow についてまとめて翻訳してみた

はじめに

MLflow について、下記のリンク先の動画と記事を元に内容をまとめて翻訳しました。

■本動画リンク
MLflow: Infrastructure for a Complete Machine Learning Life Cycle with Mani Parkhe & Tomas Nykod

■本記事リンク
Introducing MLflow: an Open Source Machine Learning Platform

MLflow - 完璧な機械学習(ML)ライフサイクルのためのインフラ

ML 開発の困難さ

図は一般的な ML のライフサイクルとなります。基本的には取得したデータをチェックした後にトレーニングし、デプロイした後で、新たにデータを取り込ませたりすることで改善させる、といった形になります。
image.png
ML の開発が困難な理由としては、以下が挙げられます。

  • どのライフサイクルにおいても利用できるツールが豊富にある
  • それぞれのライフサイクルで使用するツールが必ずしも同じでは無い
  • 次のライフサイクルにデータやモデル、コードを渡すのに苦労する

MLflow について

MLflow は、そんな ML 開発における問題点を解決するオープンソースの ML プラットフォームです。
image.png
主な特徴は以下となります。

  • どの ML ライブラリや言語にも対応
  • どの環境でも同じ様に実行可能
  • 1人、または複数人の場合でも利用できるデザイン設計
  • ビッグデータや Apache Spark に対応可能

MLflow デザインの哲学

MLflow のデザイン哲学は2つあります。

■デザイン哲学

  • 「API ファースト」のオープンプラットフォーム
    • どんなライブラリや言語、でも実行可能な環境
    • 既存の ML プラットフォームやワークフロとの統合が可能
  • モジュール設計
    • 個々人で異なるコンポーネントの利用が可能
    • ML ツールデベロッパが多くのユーザと簡単に繋がることが可能

MLflow コンポーネント

MLflow の主なコンポーネントは3つあります。
image.png
■コンポーネント

  • MLflow Tracking
    • 実験の記録やクエリを行う
  • MLflow Projects
    • どのプラットフォームでも再利用可能なフォーマットにパッケージング
  • MLflow Models
    • 様々なデプロイツールをサポートするモデルフォーマット

MLflow Tracking

image.png
MLflow Tracking は 機械学習コードを実行して視覚化した際、パラメータやコードのバージョン、そしてメトリクスなどのロギングや、ファイルのアウトプットをするための API と UI です。

■MLflow Tracking の特徴

  • 簡単なコード数行で、パラメータやメトリクスなどのトラッキングが可能
  • notebook やスタンドアローンなスクリプトなど、どの環境でも利用可能
  • ローカル環境のファイルやサーバにログの結果を保存し、複数の実行の比較が可能

MLflow Projects

image.png
MLflow Projects は再利用可能なデータサイエンスコードをパッケージングするためのスタンダードなフォーマットを提供するサービスです。

■MLflow Projects の特徴

  • Porject はそれぞれコードや Git リポジトリがついたディレクトリ
  • 記述ファイルを使って依存関係とコードの実行方法を特定

MLflow Models

image.png
MLflow Models は “flavors” と呼ばれる 複数のモデルで ML モデルをパッケージングする方法です。MLFlow は、異なる flavor のモデルをユーザが開発できるよう、様々なツールを提供します。MLflow モデルは、任意のファイルを含んだディレクトリと使用可能な flavors をリストする MLmodel 記述ファイルとに保存されます。

  • MLflow Models の例
[crayon-628632d1cd47c315404199/]

上記のモデルを例にすると、このモデルは sklearn モデル flavor か python_function モデル flavor をサポートするツールと使用することができます。
MLflow は、一般的なモデルを様々なプラットフォームに開発するためのツールを提供します。例えば、python_function flavor をサポートするモデルを Docker ベースの REST サーバや Azure ML、Amazonn SageMaker、そしてバッチとストリーミング推論のための Apache Spark のユーザ定義関数としてデプロイすることができます。
MLflow Models をトラッキング API を使用してアーティファクトとして出力すると、MLflow はどのプロジェクトで実行したのかを自動的に記録します。

おわりに

MLflow についてのまとめは以上となります。
本編では、より詳し解説やデモなども紹介されているので、本編もぜひ確認ください。

 

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Detecting Financial Fraud at Scale with Decision Trees and MLflow on Databricks 翻訳まとめ

はじめに

今回は、2019年5月2日に Elena Boiarskaia 氏、 Navin Albert 氏、そして Denny Lee 氏によって投稿された「Detecting Financial Fraud at Scale with Decision Trees and MLflow on Databricks」 の翻訳をまとめたものを紹介します。
本記事のリンクは下記参照で。

■リンク
Detecting Financial Fraud at Scale with Decision Trees and MLflow on Databricks

Databricks 上で決定木と MLflow を用いた大規模な金融詐欺の検出

人工知能(AI) を使った大規模な不正パターンの検出はとても難しく、その理由は3つあります。

■3つの理由

  • ふるいにかける履歴データの多さ
  • 機械学習の発達とディープラーニングの技術の複雑さ
  • 実際に起きた不正行為(動作)の例が少ない

更に、金融業界においてはセキュリティに対する懸念と AI を用いた不正行為の判別方法に対する説明が重要で、これが不正パターン検出に向けた作業をより難しくしてます。

image.png

ドメインのエキスパートチームは、検出パターン構築のために詐欺師の一般的な行動をベースとしたルールを用意することとしました。ワークフローには、金融詐欺の分野におけるエキスパートがまとめた特定の動作の要件が含まれています。
データサイエンティストは利用可能なデータのサブサンプルを取得し、これらの要件や既存の詐欺の例を用いて、ディープラーニングや機械学習のアルゴリズムのセットを選択します。
検出パターンを本番で利用するにあたり、データエンジニアは主に SQL を用いてモデルを閾値を持つルールセットへと変換します。結果、金融機関は一般データ保護規則(GDPR)に準拠した、不正取引の特定につながる明確な証拠を提示することができますが、ハードコード化されたルールセットを用いた不正検知システムにも問題点はありました。

■問題点

  • 不正パターンの変化に対するアップデートにとても時間がかかる
  • 現在の市場で起きている不正行為の変化に即座に対応できない

image.png

それに加えて、上述したワークフローのシステムはサイロ化されていることが多く、図のようにドメインエキスパート、データサイエンティスト、データエンジニアがすべて区画化されています。
データエンジニアは、大量のデータを管理し、ドメインエキスパートやデータサイエンティストの作業を本番レベルのコードに変換する役割を担っています。
共有のプラットフォームが無いため、ドメインのエキスパートとデータサイエンティストは、解析の為に1台のマシンに収まるサンプリングされたデータに頼るしかありません。これによってコミュニケーションが困難になるだけでなく、最終的には連携にも支障をきたします。

image.png

この記事では、以下の内容について紹介していきます。

  • Databricks のプラットフォーム上の機械学習のユースケースに、様々なルールに基づいた検知のユースケースを変換する方法
  • 大規模なデータセットからモジュール機能を構築するフレームワークを活用し、機械学習による不正検知データパイプラインを作成とリアルタイムでデータを可視化する方法
  • 決定木と Apache Spark MLlib を用いた不正の検出方法と、モデルの精度向上のために MLflow を用いた反復処理と改良方法

機械学習を用いた解決

金融業界において、機械学習モデルは特定した不正ケースを正当化する方法が無い「ブラックボックス」な解決策を提供するものと考えられてきたため、機械学習モデルに対して消極的です。
GDPR の要件と金融規制により、データサイエンスの力を活用することは一見不可能に見えますが、大規模な不正行為の検出に機械学習を適用したことで、上述した多くの問題を解決できることを様々な成功事例が証明しています。

image.png

実際に確認された詐欺行為の事例が少ないため、金融詐欺の検出の為に、教師あり機械学習モデルをトレーニングするのは非常に困難です。しかし、特定の不正行為を識別する既存のルールセットの存在は、合成ラベルのセットと特徴量の初期セットの作成の手助けになります。
ドメイン分野のエキスパートによって開発された検出パターンの出力は、適切な承認プロセスを経て本番利用に使われる可能性があります。期待される不正行為フラグを生成するため、機械学習モデルをトレーニングするためのスタート地点として利用されることで、下記の3つの不安要素を解決できます。

■3つの不安要素

  • トレーニングラベルの欠如
  • 使用するモデルの選定
  • モデルに適切なベンチマークを有しているかどうか

ルールに基づく不正行為フラグを認識するよう機械学習モデルをトレーニングすると、混同行列を介して期待される出力との直接比較ができます。結果がルールベースの検出パターンと厳密に一致している場合、このアプローチは機械学習ベースの不正防止に懐疑的な方々の信頼を得るのに役立ちます。
このモデルの出力は解釈がとても簡単で、元の検出パターンと比較した場合に予想される偽陰性、および偽陰性のベースラインの議論として役立つと思われます。
さらに、機械学習モデルの解釈が難しいという懸念については、初期の機械学習モデルとして決定木モデルが利用されれば、より緩和されると思われます。

■決定木モデルを利用するメリット

  • モデルは一連のルールに沿ってトレーニングされているため、決定木は他のどの機械学習モデルよりも優れている可能性があるから
  • モデルの最大限の透明性

モデルの透明性は、アルゴリズムに組み込まれた機能を理解することによって最終的に達成されます。解釈可能な機能があると、解釈可能で防御可能なモデル結果が得られます。
機械学習でアプローチすることの最大の利点は、最初のモデリング作業以降はモジュール化されたラベルや特徴量、あるいはモデルタイプセットのアップデートを短い時間でシームレスに生産可能という点です。ドメインエキスパート、データサイエンティスト、データエンジニアが同じデータセットを大規模に処理し、ノートブック環境で直接やりとりができる Databricks 統合分析プラットフォームによって、さらに促進されます。それでは、始めていきましょう。

データの取得と探索

この例では、合成データセットを使用します。
自分でデータセットを読み込む場合は、Kaggle からローカルにデータセットをダウンロードし、Azure 、または AWS にデータをインポートしてください。
以下の表は、PaySim のデータセット情報です。 PaySim のデータは、アフリカ諸国で実施されたモバイルマネーサービスの1ヶ月間の財務ログから抽出した実際の取引のサンプルをもとに、モバイルマネーの取引をシミュレーションしています。

image.png

データの探索

Databricks File System(DBFS)にデータをアップロードしたので、Spark SQL で素早く簡単に DataFrame を作成できます。
image.png

DataFrame を作成したので、スキーマと最初の1000行を見て、データを確認しましょう。
image.png

image.png

トランザクションの種類

データを可視化して、取引の種類と全体の取引量に対する貢献度を見てみましょう。
image.png

金額を把握するために、取引の種類や送金額への貢献度に応じたデータの可視化をします。

image.png

ルールベースのモデル

モデルのトレーニングに、既知の詐欺事件の大規模なデータセットから始めることは滅多に無いです。ほとんどの実用的なアプリケーションでは、不正検知パターンはドメインの専門家によって確立された一連のルールによって識別されます。ここでは、これらのルールに基づいて「label」と呼ばれるカラムを作成します。

image.png

ルールによってフラグ化されたデータの視覚化

これらのルールは、非常に多くの不正ケースにフラグをよく立てます。フラグがついた取引数を可視化します。約4%のケースと、ドル総額の11%が不正行為としてフラグが付いてるのが分かります。

image.png

適切な機械学習モデルの選択

多くの場合、ブラックボックス化されたアプローチを使用してた不正検出は使用されません。

  • ドメインの専門家は取引が不正であると識別された理由を理解できなくてはいけない
  • 行動を起こす場合は、証拠を法廷に提出する必要がある

以上の理由から、決定木は簡単に解釈できるモデルであり、このユースケースの出発点として最適です。詳細については、意思決定ツリーに関するこのブログ 「The Wise Old Tree」 を参照ください。

image.png

トレーニングセットの作成

MLモデルを構築して検証するために、「.randomSplit」を用いて 80/20 の分割を行います。ランダムに選択されたデータの80%がトレーニング用に、残りの20%が結果の検証用に確保されます。

image.png

機械学習モデルのパイプラインの作成

モデルのデータを準備するために「.StringIndexer」を使用してカテゴリ変数を数値に変換します。次に、モデルに使用したい機能を全部組み立てます。決定木モデルに加えて、これらの特徴準備ステップを含むパイプラインを作成し、異なるデータセットでこれらのステップを繰り返すことができるようにします。
最初にパイプラインをトレーニングデータに適合させ、その後にそれを使用してテストデータを変換するので注意してください。

image.png

モデルの可視化

パイプラインの最後のステージである決定木モデルの「display()」を呼び出すことで、各ノードで選択された決定を持つ初期フィットモデルを表示できます。これは、アルゴリズムが結果の予測にどのように到達したかを理解するのに役立ちます。

image.png
image.png

モデルのチューニング

最適なツリーモデルが得られることを確認するために、いくつかのパラメーターのバリエーションを使用してモデルを相互に検証します。データが96%の陰性と4%の陽性のケースで構成されている場合、不均衡な分布の説明に、Precision-Recall(PR)評価指標を使用します。

image.png

モデルのパフォーマンス

モデルを評価するには、トレーニングセットとテストセットの精度再現率(PR)とROC曲線下の面積(AUC)メトリックを比較します。PR と AUC は共に非常に高いようです。

image.png

モデルがどのように結果を誤分類したかを見るために、matplotlib とpandas で混同行列を可視化します。

image.png

クラスの調整

可視化した結果、以下の事がわかりました。

  • モデルが識別した元のルールよりも2421個も多くケースを識別している
  • アルゴリズムによって検出されなかったが、もともと識別された58個のケースがある

アンダーサンプリングを使用してクラスのバランスを取り、予測をより改善してみます。全不正ケースを保持し、不正ではないケースをダウンサンプリングしてその数と一致させ、バランスのとれたデータセットを取得します。
新しいデータセットを視覚化すると、イエスとノーのケースがほぼ 50/50 であることがわかります。

image.png

パイプラインのアップデート

次に、ML pipeline を更新して新しいクロスバリデータを作成します。ML pipeline を使用しているため、新しいデータセットで更新するだけで、同じパイプラインステップをすばやく繰り返すことができます。

image.png

結果の確認

新しい混同行列の結果を見ると、モデルは1つの不正なケースのみを誤認しました。クラスのバランスを取ることで、モデルが改善されたようです。
image.png

モデルのフィードバックと MLflow の利用

生産用のモデルが選択されたら、フィードバックを継続的に収集して、モデルが引き続き対象の動作を識別していることを確認します。ルールベースのラベルから始めているので、人間のフィードバックに基づいて検証された真のラベルを将来のモデルに提供したいと考えています。
この段階は、機械学習プロセスの信頼と信頼を維持するために重要です。アナリストはすべてのケースをレビューすることはできないため、モデルの出力を検証するために、慎重に選択されたケースをアナリストに提示していることを確認します。例えば、モデルの確実性が低い予測は、アナリストが検討するのに適した候補です。このようなフィードバックが加わることで、モデルは変化する景色に合わせて改善・進化を続けていきます。

MLflow は、異なるモデルのバージョンを学習する際に、このサイクルを通じて助けてくれます。様々なモデル構成とパラメータの結果を比較しながら実験を追跡できます。例えば、MLflow UI を使用して、バランスの取れたデータセットと不均衡なデータセットで学習したモデルの PR と AUC を比較することができます。
データサイエンティストは、MLflow を使用して様々なモデルのメトリクスや追加の可視化や成果物を追跡することで、どのモデルを本番環境に導入すべきかの判断に役立てることができます。データエンジニアは、選択したモデルとトレーニングに使用したライブラリのバージョンを.jarファイルとして簡単に取得して、本番の新しいデータに展開することができます。
このように、モデルの結果をレビューするドメインエキスパート、モデルを更新するデータサイエンティスト、本番でモデルを展開するデータエンジニアの連携は、この反復プロセスを通じて強化されていきます。

結論

Databricksプラットフォームを使用する主な利点

  • データサイエンティスト、エンジニア、ビジネスユーザーがプロセス全体でシームレスに連携できること
  • データの準備、モデルの構築、結果の共有、モデルの本番環境への導入を同じプラットフォームで実行できる
  • チーム全体に信頼が構築され、効果的で動的な不正検出プログラムに繋がる

わずか数分で無料の試用版にサインアップしてこの Notebook を試して頂き、独自のモデルを作成してみてください。

おわりに

Detecting Financial Fraud at Scale with Decision Trees and MLflow on Databricks の翻訳まとめは以上です。
本記事にはより詳しく記載がされているのでそちらも参照ください。

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


[WVD ARM ] Application groups・Workspace及びユーザー管理編

はじめに

本記事では WVD ARM の管理操作についてご紹介します。
WVD ARM とは 既存のPower ShellベースのWindows Virtual Desktop(WVD)から、Azure Portal 上で操作可能になった新しい Windows Virtual Desktop です。

便宜上 Power ShellベースのWVDを WVDv1、 WVD ARM を WVDv2と表記します。
なお、Windows Virtual Desktop(WVD)についての解説は割愛しています。
※2020年6月1日時点ではプレビュー状態です。

Application groups

WVDv2 の利用ユーザーに対してアプリケーションの使用権限を付与や管理を行います。

WVDv2 から追加・改善された箇所は以下の2点です。

  • ユーザーが同じホストプール内にある Desktop Application ・RemoteApp 両方に登録可能
    ※WVDv1では同じホストプールに登録不可
  • Azure PortalでのRemoteAppの設定が可能 ※WVDv1ではPower Shellで操作可能
    作成方法は以下のリンクに進み「Step5:RemoteAppの作成」をご参照ください。
    https://www.cloudou.net/windows-virtual-desktop/wvd016/

注意事項
Workspace に Application groups を紐付ける際、Desktop Application ・ RemoteAppは同じWorkspace に紐づける必要があります。

Workspace

利用者側の使用するアプリケーションを接続画面に表示できます。
WVDv1では「WVDテナント」でしたが、 WVDv2では Workspace と名称が変更しています。

作成するタイミング別の作業手順は以下の通りです。

  • ホストプール作成時 ※WVDv1 Power Shellで操作可能
    以下のリンクから「Step3:Host Pool (+Desktop)の作成」を参照
    https://www.cloudou.net/windows-virtual-desktop/wvd016/
  • 個別作成
    Azure Portal > WVD > Workspace > 「+追加」 をクリック > 各項目に必要事項を入力
    image.png

注意事項
利用者側に表示させたい Desktop Application を Workspace に紐づける必要があります。

ユーザー管理

WVDv1 はユーザー管理を Power Shell での操作が必要でしたが、WVDv2 では Azure Portal で以下の操作が可能です。

  • 管理権限の割り当てが可能 ※ WVDv1 では Power Shellから操作可能
  • グループ単位で追加可能 ※ WVDv1 では選択不可

操作手順は以下の通りです。

■ 管理権限の割り当てが可能 ※ WVDv1 ではPower Shell から操作可能
手順: Azure Portal > WVD > Host Pool(他のカテゴリーも選択可) > アクセス制御
image.png

■ グループ単位で追加可能 ※ WVDv1 では選択不可
手順: Azure Portal > WVD > Application groups (他のカテゴリーでも選択可) > Assignments > 「+ 追加」 を選択 > 追加するユーザーまたはグループを選択
image.png

ユーザーの接続状況を確認可能

Azure Portal 上でユーザーの接続状況を確認できます。
以下が接続状況を確認するまでの手順です。

■ ユーザーの接続状況を確認可能 ※WVDv1 ではPower Shellで操作可能
手順: Azure Portal > WVD > Users > 確認するユーザーを選択 > Sessionsを選択
接続中: Active
未接続: Disconnected
image.png

注意事項
ユーザーアカウントが WVD 用の Azure AD に同期している必要があります。

最後に

最後まで読んでいただきありがとうございました。

WVDv1ではユーザー管理やアプリケーショングループ・Workspaceでの作業は Power Shell での操作が必要でした。WVD ARM では Azure Portal で操作可能になり、数クリックで管理やデプロイができ、WVDv1より利便性が向上しています。

この機会にWVD環境構築を試してみてはいかがでしょうか?

Windows Virtual Desktop (WVD)をより詳しく知りたい方

Windows Virtual Desktop (WVD)に関しての情報は以下のリンクをご参照ください
■ Windows Virtual Desktop サービスについて知りたい

■ Windows Virtual Desktop ARM を作成