【はじめての Databricks】金融取引データから異常検知 #3 Anomaly Detector

はじめに

Databricks の Notebook から Azure Anomaly Detector の API を叩いて結果を可視化するところまでを行います。

連絡目次

  1. 導入/環境設定
  2. Collaborative Notebook でデータ可視化
  3. Anomaly Detector をデータ探索ツールとして使ってみる → 本稿
  4. 1つ目のモデル構築 (データの偏り 未考慮)
  5. 2つ目のモデル構築 (データの偏り 考慮)

Anomaly Detector とは

Anomaly Detector はマネージド型AIサービスとして提供されている Azure Cognitive Services の一つです。

  • 時系列データセットから異常検出
  • 教師なし学習
  • 異常に対する感度を微調整可能
  • APIでアプリケーションへ組み込み可能
  • データ型や欠損値に対する制約がちょっと厳しい

予測結果の可視化一例
image.png
X軸が時間、Y軸が数値。青の実線が投入したデータ。
解析の結果異常ではないと判定されたエリアが水色、異常値と判定されたデータは赤でプロットされている。

本連載の主題である異常検知モデルには利用していませんが、時系列データの特徴をさっと把握したいときに使えるかも、入力/出力ともにシンプルなので Detabricks の可視化機能と相性いいかも、ということで試してみました。

テストデータ生成

Anomaly Detector に投入する Body データは以下を満たす必要があります。

  • UTC 形式のタイムスタンプ (カラム名 = timestamp)
  • 数値 (異常検出対象。カラム名 = value)

今回は前記事で周期性を明確に見られた区間を抜粋し、 Step が前者、トランザクション数が後者になるようにデータを成型、テストデータとしました。

[crayon-5f6bdd8b41368031749055/]

テストデータを棒グラフにしてみます。数値の吹き出しがある箇所でトランザクションの少ないことはすぐ分かりますが、他にも特筆すべきポイントがあるかもしれません。

[crayon-5f6bdd8b4137a798721003/]

result image.png

環境変数設定

まず Anomaly Detector のリソースを作成します。 (こちらの記事が参考になります)

エンドポイント URL と API Key を取得したら、クラスタの環境変数に追加しておきます。(Notebook に平打ちするのはセキュリティ上よろしくない)

2020-08-26_19h18_03.png
2020-08-26_19h19_51.png

関数定義

パラメータや実行関数を定義します。

[crayon-5f6bdd8b41389177129310/]

実行・結果可視化

API にデータを投げ、元のデータフレームと結合します。

[crayon-5f6bdd8b41397033714247/]

isAnomaly (予測結果。1=異常、0=通常) に絞ってグラフ化します。吹き出しの出ている箇所は目視では気が付きませんでしたが、確かに別の日の同じ時間に比べるとトランザクション数が低いように思われます。

[crayon-5f6bdd8b413a3490571409/]

result image.png

plot option
image.png

まとめ

私たちはグラフにするとなんとなく分かったような気になってしまう傾向があります。Anonaly Detector は先入観なしに時系列データを見てみたい時に便利かもしれませんね。次回は実際に決定木を用いてモデルを構築します。お楽しみに!

参考リンク

Anomaly Detector 公式トップページ
Anomaly Detector API の使用に関するベスト プラクティス
Cognitive Service: Anomaly Detector APIを試す
クイック スタート:Anomaly Detector REST API および Python を使用し、時系列データ内の異常を検出する


【はじめての Databricks】金融取引データから異常検知 #2 データ可視化

はじめに

機械学習モデルを作る際、まずは様々な切り口でデータを眺め、仮説を立てるプロセスが必要不可欠です。
本稿では Collaboravive Notebook の可視化機能を用いて、データの全体像を把握します。

連絡目次

  1. 導入/環境設定
  2. Collaborative Notebook でデータ可視化 → 本稿
  3. Anomaly Detector をデータ探索ツールとして使ってみる
  4. 1つ目のモデル構築 (データの偏り 未考慮)
  5. 2つ目のモデル構築 (データの偏り 考慮)

データ概要

PaySim というアフリカ諸国で実行されたモバイル決済サービスのトランザクションログデータです。

カードや銀行口座を持っていない人たちがどんどん経済圏に流入しているような地域では、日常の決済手段に加えて、出稼ぎ労働者の送金手段として、生活インフラの一部として普及しているそうです。

Spark Dataframe と View について

Spark Dataframe と View (もしくはTable)で、利用できるコマンドが異なっています。
私の場合は PySpark を使い慣れていないので、モデリングを行う際に前者を、データ探索やアドホックな可視化をしたい場合に後者、といった使い分けをすることが多いです。

image.png

前準備

ここからは実際に Notebook 上でコードを実行しつつ、データの中身を見て行きます。まず直接SQLを書けるようにするために以下のコードを実行します。不正取引の実行者はもともと大量の預金がある口座を使っているとは考えにくい(足が着いたら口座凍結される)ので、口座残高の変化を算出するカラムを追加しています。

[crayon-5f6bdd8b427f9659542514/]

result image.png

それぞれのカラムの詳細は以下の通り。
今回の場合、isFraud が目的変数(最終的に予測したい値) になります。

カラム名 明細
step 現実世界でのタイムスパンの通し番号。1ステップ1時間で30日間分のデータ。計 744 ステップ。
type 取引タイプ。CASH-IN (入金), CASH-OUT(出金), DEBIT(デビット), PAYMENT(通常支払い), TRANSFER(送金)の5種類
amount 現地通貨での取引額
nameOrig 取引実行者の顧客ID
oldbalanceOrg 取引実行者の初期残高
newbalanceOrig 取引実行者の取引後残高
nameDest 取引先の顧客ID
oldbalanceDest 取引先の初期残高 (nameDest が M で始まる場合情報なし)
newbalanceDest 取引先の取引後残高 (nameDest が M で始まる場合情報なし)
orgDiff 取引実行者の口座残高の変化
destDiff 取引先の口座残高の変化
isFraud 正解ラベル。1が実際に不正取引であった取引、0が通常取引
isFlaggedFraud 予測結果。1が不正取引と予測された取引、0が通常取引と予測された取引

データ可視化

Notebook 上でクエリを実行した場合、デフォルトでは表形式で出力されます。
以下のようにドラッグアンドドロップで、クエリの実行結果をそのまま可視化できます。Excel のピボットグラフのような使用感です。わざわざ matplotlib 使わなくてもいいのでとても便利。

gif_4.gif

1. 不正取引の全体に占める割合

件数ベースで 約 0.13%、金額ベースで 約 1.1%。
かなり偏りがあるので、Train モデリングに使用するデータは注意する必要があります。

[crayon-5f6bdd8b4280c821895374/]

result0 image.png

2. 取引タイプ毎 トランザクション数 及び 金額総計

左2つの円グラフが通常取引の集計です。TRANSFER と CASH_OUT で取引金額の 3/4 位を占めています。PAYMENT は小口取引が多く、TRANSFER は大口取引が多いようです。この辺りは利用用途をイメージすると肌感とも合致します。
右2つが不正取引の集計結果です。トランザクション数と取引金額ともに CASH_OUT と TRANSFER が半々。

[crayon-5f6bdd8b4281b525977124/]

result1 image.png

plot option 1 image.png

取引タイプ毎 平均単価

0 が通常取引、1 が不正取引の平均単価です。CASH_OUT の相違が顕著です。
※ 統計量については Spark Dataframe での算出がスムーズです → こちら

[crayon-5f6bdd8b42828188535891/]

result2 image.png

plot option 2 image.png

3. TRANSFER 及び CASH_OUT ヒストグラム

不正取引には 10 mil の付近にスパイクが見られます。取引金額の初期上限値と思われます。今回のデータには含まれませんが、モバイル決済の登録時情報やアクセスログなども踏まえて分析するとおもしろそうです。

[crayon-5f6bdd8b42835194423472/]

result3 image.png

plot option 3 image.png

4. TRANSFER 取引金額 時系列推移

ここからは取引タイプ TRANSFER のみを抜粋してみてみます。日ごとの周期が見られ、120-420 のステップではこれがはっきりしています。STEP 345 付近でスパイクが見られます。例えば日本で言う5-10日のようなイベントによるものかもしれません。

[crayon-5f6bdd8b42842999381983/]

result4image.png

plot option 4 image.png

5. TRANSFER トランザクション 時系列推移

トランザクション数のほうがはっきりと周期性を確認できます。月単位/年単位のログがあれば、システム負荷の予測を通して運用コストの最適化を検討できそうです。

[crayon-5f6bdd8b4284f446814886/]

result5 image.png

plot option 5 image.png

6. TRANSFER 口座残高の変化

取引実行者の口座残高変化額、取引相手の口座残高の変化額を、取引実行者と取引相手のペアごとに見てみます。まずは通常取引。

[crayon-5f6bdd8b4285c916066883/]

result6 image.png

plot option 6 image.png

次に不正取引です。destDiff もしくはnewbalanceDest や oldbalanceDest が特徴量として効いてくるモデルが生成されそうです。(本番でのモデル運用考えるとこれら数値の算出タイミングが気になるところです)

[crayon-5f6bdd8b42869474568444/]

result7 image.png

plot option 7 image.png

まとめ

データ全体の傾向や特徴を簡単に見てきました。次回は時系列データからの異常検知に Azure Anomaly Detector を利用してみます。お楽しみに!

備考:連番テーブル作成

今回のデータでは必要ありませんが、SparkSQLでは以下のように連番テーブル(いわゆるダミーテーブル)を作成できます。

[crayon-5f6bdd8b42940960255756/]

参考リンク

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 Visualization


【はじめての Databricks】金融取引データから異常検知 #1 導入/環境構築

はじめに

データ分析プラットフォームである Databricks は、その特性上、主に処理速度やコストの面で他のサービスと比較されがちです。もちろんそれらの点において高く評価されているからこそ欧米でのデファクトスタンダードになっているわけですが、私自身は、サービスとしての完成度の高さが一番の強みだと感じています。例えば、

  • 知識の共有がしやすい
  • ユーザビリティを強く意識して作られている GUI
  • 他のサービス (データベースとかBIツール) との連携性がいい
  • モデルの利用や継続的な改善に至るまでの導線がスムーズ

といった点です。つまり、

  • 分析チームの生産性を上げやすく、
  • 学習コストが低い

サービスに仕上がっていると言えます。ただ、日本語の情報が少なかったり技術難易度が高いレクチャーが多かったりと、初心者にとってはまだまだハードルが高いのが現状です。本連載がそのハードルを下げるものになれば幸いです。

テーマ選定の背景

本連載は、Databricks 社が展開している以下のコンテンツをベースにしています。
モバイル決済のログデータから、各決済が正常取引か不正取引かを判定しよう、というものです。

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

このコンテンツを選んだ理由は以下の通りです。

  • テーマが異常検知
    • どの業界でも普遍的なテーマ
    • 手元のデータだったらどうかという想像がしやすい
    • 継続的な改善が不可欠で、Databricksの利点が生きる (異常の定義は時々刻々と変わる)
  • 決定木のアルゴリズムを使う
    • モデルの説明性・透明性が高く、既存のルールとの比較が容易
    • リモデルに要する工数が低い
    • ドメイン知識を反映しやすい
  • データを入手しやすい
    • Kaggle に登録すればすぐに使える

公式ドキュメントでは、既存の異常検知ロジックをコードで記載、その結果を正解ラベルに用いて機械学習モデルを構築しています。実ビジネスでは最初にこのようなプロセスを踏むのが定石のようですが、今回利用するデータには通常/異常の判定情報が付与されています(詳細は連載#2で触れます)。そこでリモデルまでの流れの見通しをよくするために、本連載ではこれを正解ラベルとしています。

また、データ探索の一部に Azure Anomaly Detector (時系列データから異常を見つけるマネージドAIサービス) を利用してみたり、作成したモデル2種それぞれの使い方を考えてみたりと、ちょっとアレンジを加えています。

連絡目次

  1. 導入/環境設定 → 本稿
  2. Collaborative Notebook でデータ可視化
  3. Anomaly Detector をデータ探索ツールとして使ってみる
  4. 1つ目のモデル構築 (データの偏り 未考慮)
  5. 2つ目のモデル構築 (データの偏り 考慮)

Azure Databricks とは

過去書いた記事のリンクです。

前置きが長くなりました。
では環境構築していきます。

ワークスペースの作成

以下の URL から Azure ポータルへログイン
https://azure.microsoft.com/ja-jp/
image.png

左上のをクリックし、検索窓に Databricks と入力し、候補に出てきた Azure Databricks をクリック
image.png

作成をクリック
image.png

以下のようにワークスペースを設定、作成をクリック
(ワークスペースの展開に2-3分を要します)
image.png

しばらくするとワークスペース展開完了の通知が届くので、リソースに移動をクリック
image.png

こちらの画面に遷移すればワークスペースの作成完了
2020-08-21_13h49_44.png

クラスタの作成

Cluster タブを選択し、Create Cluster をクリック
2020-06-26_12h08_24.png

任意でクラスタ名を設定し、Creater Cluster をクリック
有償版であれば詳細を設定できます。今回はオートターミネーションを 60分 に設定。

2020-06-28_11h18_52.png

しばらく待つと Status が Running に。これで完了。
2020-06-28_11h25_22.png

データのアップロード

以下サイトからデータをダウンロードします。※ Kaggle のユーザーアカウントが必要
Kaggle - Synthetic Financial Datasets For Fraud Detection
image.png

Data タブを選択し、Add Data をクリック
2020-06-26_12h01_49.png

Upload File → browse と進み、ダウンロードしたファイルを選択
2020-06-26_12h03_15.png

アップロードが完了するとこちらの画面に。デフォルトでは File Store にデータが格納されます。
Create Table with UI をクリック
2020-06-26_12h05_47.png

先ほど作成したクラスターを選択し、Preview Table をクリック
2020-06-26_12h53_28.png

デフォルトではアップロードしたファイル名がそのままテーブル名になっているので、これを sim_fin_fraud_detectionに変更します。
オプションは、First row is header (最初の行をカラム名として読み取り)と Infer Schema (各カラムのデータ型自動類推)にチェックを入れ、Create Table をクリック
2020-06-26_12h56_47.png

mlflow experiment 設定

機械学習のライフサイクル管理にとても便利な mlflow ですが、今回はモデルの比較という用途に絞って最低限の設定を行います。

Workspace → ユーザー名 → プルダウンで Createと進み、MLflow Experiment をクリック
2020-06-26_13h40_47.png

名称を任意で指定、Create をクリックします。Artifact Loacation は特別に指定しなくてOK
2020-06-26_13h41_41.png

以下の画面に遷移します。Experiment ID は Notebook の中で使うのでメモしておきます。
2020-06-26_13h42_29.png

Collaborative Notebook 作成

実際にコードを記載して分析ロジックをくみ上げたり、その中にメモを残したりする Collaborative Notebook を作成します。使い勝手は Jupyter Notebook にかなり近いです。

トップ画面から、Create a Blank Notebook をクリック
2020-06-28_12h17_08.png

任意で名称を変更、作成したクラスタを選択して、Create をクリック
2020-06-28_12h20_01.png

以下の画面になればOKです。
2020-06-28_12h21_05.png

使用方法

灰色のエリア(セル)にコードを書き、shift + enter を押すことで、セルが実行されます。
image.png

%md の後に文章を入力、セルを実行することで、markdown 形式で Notebook 上にメモを残すことができます。
image.png

セル中央部の下もしくは上にマウスカーソルを当て、+ をクリックすると新しいセルを追加できます。
image.png

セル左上のプルダウンより、対象のセルから上、もしくはセルより下のセルを実行できます。
image.png

セル上部の消しゴムアイコンから clear result を選択することで、実行結果をクリアできます。
image.png

クラスタが停止した場合は、クラスタアイコンから、Start Cluster をクリックします。
image.png

mlflow 初期設定

クラスタに mlflow をインストールするために、 Notebook 上に以下のコマンドを実行します。

[crayon-5f6bdd8b44701873144962/]

= の後に、先ほど作成した mlflow experiment の id を入力、同じく実行します。

[crayon-5f6bdd8b44714386830174/]

結果
MLflow Version: 1.9.1

以上の2つのセルを実行しておくことで、この Notebook 上で行うモデリング処理が mlflow に記録されるようになります。

備考:Notebook のインポート

Databricks の公式事例ページや Github には、そのまま活用できる Collaborative Notebook がアップロードされています。以下の方法でインポート可能です。

Workspace から User を選択し、以下のプルダウンから Import をクリックします。
2020-06-26_13h58_59.png

URL を選択し、インポートしたい Notebook の URL を張り付け、Import をクリックします
2020-06-26_14h00_20.png

まとめ

次回はインポートしたデータの中身を見ていきます。お楽しみに!

参考リンク

Detecting Financial Fraud at Scale with Decision Trees and MLflow on Databricks
Detecting Financial Fraud at Scale with Decision Trees and MLflow on Databricks 翻訳まとめ
Azure Databricks: 1. リソースの作成
Azure Databricks で、他の Notebook を呼び出す、基礎: Hello World レベル
pysparkでデータハンドリングする時によく使うやつメモ


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


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

はじめに

本記事では、機械学習モデルのライフサイクル管理を行うオープンソースプラットフォームであるMLflowをDatabricksの環境下でトラッキングする方法について書きます。(Python3を想定しています)

Databricksのマネージド型MLflow

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

Databricksの環境下では、MLflowはマネージド型のサービスとして使うことができるのでトラッキング用のサーバーを別途用意する必要がありません。また、実験のトラッキング情報をノートブックに統合して管理することもできます。

今回は実験の情報をノートブックに統合してトラッキングする方法について書きます。

MLflowの使い方

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

[crayon-5f6bdd8b44e45998434008/]

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

[crayon-5f6bdd8b44e55691504474/]

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

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

[crayon-5f6bdd8b44e61406899162/]

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

実装

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

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

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

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

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

セットアップ

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

[crayon-5f6bdd8b44e6d184237772/]

結果処理部分の実装

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

[crayon-5f6bdd8b44e7a685767943/]

実験処理部分の実装

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

[crayon-5f6bdd8b44e85292862107/]

実験

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

[crayon-5f6bdd8b44e93863126914/]

出力結果は次のようになりました。
スクリーンショット 2020-08-25 17.00.47.png

画像を出力してみます。
スクリーンショット 2020-08-25 17.00.56.png

いくつかパラメータを変えて実験してみます。(合計4パターンほどやってみました)

実験が終わったら右上のあたりに[Runs]と書かれた部分を押します。
スクリーンショット 2020-08-25 17.08.27.png

設定したパラメータの値と出力されたメトリクスが実験ごとに記録されているのが確認できます。
スクリーンショット 2020-08-25 17.10.19.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を高速に扱うためのクエリエンジンであるデルタエンジンについてご紹介します。


Azure Speech SDKを用いて、音声からテキストへ変換すーる

はじめに

Azure Speech SDKを用いて、音声からテキストへ変換してみます。

開発環境

  • Windows 10
  • Python 3.6
  • Anaconda
  • Azure Speech SDK

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

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

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

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

[crayon-5f6bdd8b455cc545864812/]

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

[crayon-5f6bdd8b455db995090909/]

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

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

[crayon-5f6bdd8b455e6127885210/]

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

[crayon-5f6bdd8b455f3641338439/]

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

[crayon-5f6bdd8b45601790219385/]

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

音声ファイル(.wav)から音声を認識する

1.導入方法は上と同様にしてください。

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

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

[crayon-5f6bdd8b4560d727311524/]

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

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

[crayon-5f6bdd8b4561a810596395/]

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

[crayon-5f6bdd8b45624548441134/]

結果は下記のようになりました。
image.png

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

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

[crayon-5f6bdd8b45630484850045/]

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

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

お疲れ様でした。

参考


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ソリューションページはこちら