ビッグデータ分析で効果を発揮するAzure Data Explorerとは

はじめに

前回までは、データ活用サービスの基礎知識を説明した。今回はストリームデータ処理に評判があり、入門難易度が低いデータ操作言語「Kustoクエリ言語」が利用できる「Azure Data Explorer」を紹介する。

従来システムの課題とこれから

第1回、第2回の説明から、より高度で柔軟性の高いデータ分析には、次のことが重要であるとわかった。

• DX時代のデータ分析基盤では、柔軟な分析が可能なデータレイク中心アーキテクチャが適している
• これまではバッチ処理が多用されてきたが、IoTやスマートフォン、インターネットアプリケーション全盛の現在ではストリームデータ処理の重要性が増している
• 正確な分析には正しいデータが必要。ゴミはゴミしか生まない
• データ分析の前処理として、データに対するインサイト(洞察)を得るためデータ探索が重要

DX時代のデータ分析基盤を考えるうえで、エンジニアが理解しておくべきことがある。それは従来の概念にとらわれないことだ。データウェアハウスやバッチ処理は歴史が長い。そのため、さまざまなテクノロジーが存在し、ノウハウも蓄積されている。また、それぞれ個人の思い込みもある。

しかし、従来の考えやノウハウは、DX時代のデータ分析基盤では役に立つどころか、逆に理解を阻害したり、考えの幅を狭めたりする可能性もある。新しいデータ分析基盤を考えるうえで、従来と大きく異なる点を2つ紹介する。

短時間に膨大なデータが生成され、システムの構成は複雑
IoTデバイスやスマートフォン、アプリケーションから生成されるテレメトリデータは、1日で数百GBになることも珍しくない。これらを保存するだけでなく、リアルタイムに近い時間で処理することは簡単ではない。またPaaSやWebアプリケーションでは、複数サーバーだけでなくCDN(Content Delivery Network)などにもログデータが分散しているため、大量かつ多数のデータを扱える必要がある。

日々進化改善が必要
一度作ったら終わりではなく、常に改善し続ける必要がある。ユーザーエクスペリエンス向上や分析精度の向上など、最善のビジネス目標を実現するには継続的な改善が必要だ。特にインターネットを利用したシステム(WebサイトやSaaSアプリケーション、オンラインゲーム)では競合が多く、勝ち抜く努力は欠かせない。

Azure Data Explorerとは

Azure Data Explorer(以下、ADX)は、Webサイトやアプリケーションのログデータ、IoTテレメトリデータなど、大量に発生するストリームデータに対応した、高速でスケーラブルなフルマネージドのデータ探索サービスだ。代表的な特徴を紹介する。

高い作業効率
SQLよりも直感的で使いやすい問い合わせ言語「Kustoクエリ言語(KQL：Kusto Query Language)」。KibanaやGrafanaなどを使わなくても簡単にグラフ化できて作業効率が高い。Visual Studioに似た生産性が高く使いやすいユーザーインターフェイスや豊富な分析ライブラリも便利だ。

フルマネージドサービス
フルマネージドサービスであるため、インフラの管理は不要である。ADXを使い始めるには「インスタンスタイプ」と「データの保存期間」などを指定してクラスタを作成するだけだ。またインデックス作成をはじめ、多くの管理作業も不要だ。そのためデータ分析担当者はインフラエンジニアの助けなしに分析基盤を手に入れられる。

高速性
いくら使い勝手が良くてもパフォーマンスが悪ければ実際には使えない。数日から数十日までの比較的新しいデータをメモリにキャッシュすることで、きわめて高速にアクセスできる。例えば10億件のレコードを1秒未満で検索可能だ。

予測可能なコスト
Google BigQueryやAmazon Athenaなどは検索したクエリーサイズ(検索したデータサイズあたりの料金)だが、ADXは作成したクラスタサイズに応じた従量課金になっている。そのためデータ探索をしすぎて、課金がバーストするようなことはない。データ分析者が利用料金を気にすることなしに、納得のいくまでデータ分析ができる。

柔軟性
構造化データだけでなく、半構造化データや非構造化データなど、さまざまなデータを取り込める。また、Microsoft製品に限らず、さまざまなBI環境との連携も可能となっている。

Azure Data Explorerのはじまり

ADXは、2019年に正式リリース(General Availability)になったサービスだが、もともとMicrosoft社が自社で利用するために開発したサービスだ。Microsoft社が、さまざまなサービスを展開しているなかで以下の課題があった。従来のDWHやHadoop/Sparkでは解決できず、新たなサービスとして開発したのがADXである。

• Azure：テレメトリデータなど日々大量発生するログデータがあり、その作業効率を上げる必要があった
• Xbox：多くのデータサイエンティストは、SQLに変わる使いやすいクエリー言語を探していた
• Microsoft365：クラウドサービスに移行する顧客の不満を把握し改善にフィードバックする必要があった
• Defender：悪意のある攻撃者を見つけるため、時系列データに対する機械学習分析の効率を上げる必要があった
• Azure顧客：Azure上のアプリケーションやシステムログをAzureポータルで統合的にリアルタイムで可視化する必要があった

ADXは、社内で使用するだけでなく、Azureの各種サービスのバックエンドでも利用されている。例えば、WebアプリケーションのモニタリングサービスApplication Insightsや、インフラストラクチャのログモニタリングサービスAzure Monitor Log Analyticsなどである。そのため、ADXをバックエンドで利用しているサービスの中には、ユーザーがKustoクエリ言語で検索できる機能を提供していることもある。

Azure Data Explorerのアーキテクチャ

下図はADXのアーキテクチャ図だ。データ分析基盤に必要な3要素「集める」「ためる」「分析する」機能を持っている。ここで注目してほしいのは次の3点だ。

• 「集める」に相当するデータ取り込み部分(図左)
• 「分析する」に相当するAzure Data Explorerエンジン部分(図中央)
• 「分析する」を支援する他ツールとの連携(図右)

データ取り込み
オブジェクト・ストレージ上のデータやローカルデータなどのバッチ取り込みだけでなく、Event Hubなどから10秒以下のレイテンシでのストリームデータ収集も可能だ。

Azure Data Explorerエンジン
クエリーの実行や取り込んだデータのインデックス作成・圧縮・保存などを担当する、システムの中核となるコンポーネント。複数の仮想マシンによるクラスタ構成になっている。

クラスタの作成時には「キャッシュ保持期間」と「データの保存期間」を指定する。キャッシュ保持期間に指定したデータはSSDに格納され、できるだけインメモリアクセスになるように維持される。そのためキャッシュ上のデータに対して、きわめて高速に検索できる。これが高速な検索を実現する仕組みである。

• SSD：キャッシュ保持期間に指定したデータ
• Blob Storage：キャッシュ保持期間以降～データの保存期間までのデータ

他ツールとの連携
ADXのWeb UIを使うと検索結果をビジュアル化できる。それ以外にも、ADXで定義したクエリーをPower BIやKibana、Grafana、Tableauなどからも呼び出せる。使い慣れたツールでADXのパワーを体感できるのだ。

Azureのサービスマップ

Azureには、Data Explorer以外にもビッグデータ分析サービスが複数ある。例えば、Synapse AnalyticsやDatabricks、HD Insight、SQL Databaseなどだ。また連携して使用するエコシステムもある。そこでデータ活用系サービスの全体像を紹介するとともに、それぞれの関係性や機能の違いなどを説明する。

Azureで提供するデータ分析関連サービス

データ分析基盤として使用する代表的なサービスを紹介する。上図に載っていないサービスも一部紹介する。

Synapse Analytics
旧称SQL Data Warehouseを進化させた、SQLとSparkが利用可能な統合分析基盤。今後はデータウェアハウス＋データレイクとして発展予定。

Databricks
AI・機械学習向けビッグデータ分析基盤。Sparkだけでなく、Spark用ストレージレイヤDelta Lake、データサイエンス用ワークスペースなど、分析に必要な機能がすべてそろっている。買収製品なので、Azureだけでなく、AWSでも利用可能。

HD Insight
HadoopやSpark、HBase、Kafkaなどオープンソースをベースとしたビッグデータ分析基盤。Databricksはオープンソースをベースにしながら大幅な機能拡張を施しているのに対し、HD Insightはオープンソースを使いやすいように組み合わせたソリューション。

SQL Database
SQL Server互換のフルマネージドデータベース。Amazon Aurora相当。RDBMSなので万能だが、ビッグデータ分析基盤ではデータソースとして、もしくは分析結果の格納先として使うことが多い。

Data Lake Storage Gen2
Blob Storage(オブジェクトストレージ)をベースとし、HDFS互換のインターフェイスを備えたデータレイクソリューション向けストレージ。

Data Factory
データを抽出、変換、ロードするETLサービス。Azure Data Explorerをデータ入力先／データ出力先としても指定できる。

Stream Analytics
ストリームデータ向けのリアルタイム分析や複合イベント処理(CEP:Complex Event Processing)エンジン。Event Hubsなどから取り込んだデータに対して演算・ソート・集計などを実施し、結果をData Lake StorageやSQL Database、Synapse Analyticsなどに出力する。一種のフィルタ的エンジン。

Event Hubs
大量のストリームデータ向けデータ収集基盤。

Data Share
複数組織や複数利用者に対応したビッグデータ向けデータ共有サービス。

Azure Data Explorerと他サービスの違い

ADXで最初に戸惑うのは、Azureで提供している他のデータ分析系サービスとの「違い」や「使い分け」だろう。ADXがOLTPでないのは当然として、DWHでもない。そこでAzureにおける典型的なデータウェアハウスソリューションとストリームデータ処理ソリューションを紹介する。なお、これらは参考例であり、さまざまなパターンが「Azureアーキテクチャセンター」で公開されている。

上記の図でADXはストリームデータ処理にしか登場しないが、データウェアハウスソリューションでも利用できる。ストリーミングデータの取り込みや、収集したデータをデータウェアハウスに渡す前の前処理(データ探索やデータ変換)などだ。参考までにADXとDWHの比較を下表に示す。

	ADX	DWH
データソース	ログデータが主体。半構造化、非構造化データも可	基幹系システムの構造化データ
データ取込方法	バッチ、ストリーム	バッチ
データ保存期間	通常は1カ月から長くても1年程度	長く保存可能
ACID特性	完全ではない。トランザクションやトランザクションログが ないため、厳密な一貫性や耐障害性はない	あり
データ更新	更新不可で追記のみ。削除は限定的に提供	システムに依存するが更新できることが多い
問い合わせ言語/UI	WebUIやKQLを使うことでNotebook的な作業環境を提供	SQL

Azure Data Explorerが
効果を発揮するデータ探索

データ分析(データサイエンス)は一般に次の手順で行われる。これらはデータエンジニアやデータサイエンティストなど分析チームの役割で、ビジネス部門の利用者がBIツールなどで分析する前の仕組み作りである。

1. データ取り込み
2. データ探索
3. 準備とトレーニング
4. モデルとサービス

分析の前処理として重要なのが前回で説明した「データ探索」だ。少量のデータ(数百MB程度)であれば、Excelなどの表計算ソフトを用いたり、既存のデータベースを利用したり、BIツール等を用いてデータを分析することもできる。しかし、数GBあるいは数TBになると、一般的なコンピュータだと計算量やメモリが足りずに処理を実施できない。

また「Explanatory Data Analysis(EDA：探索的データ分析)」は大量の仮設分析試行をこなす必要があるので、高速に処理できる基盤が欲しいところだ。

ADXには次の特徴があり、データ探索で効果を発揮する。

• 10億件のレコードを1秒未満で検索できる高速性
• 生産性が高くビジュアル化もできるKustoクエリ言語(KQL)
• インスタンス単位の課金で、分析担当者は料金を気にせずクエリを実行できる(BigQueryなどは問い合わせ量に応じた課金)

Azure Data Explorerのユースケース

これまで説明してきたように、ADXには次の特性がある。

• パワフルでリアルタイムに近いデータ収集機能
• 生産性が高く直感的に使える問い合わせ言語＆ワークスペース
• 半構造化データや非構造化データにも対応したビッグデータに対する高速なクエリー
• インスタンス単位の課金で、料金を気にせずクエリを実行可能(BigQueryなどは問い合わせ量に応じた課金)

そのため、以下のようなユースケースが考えられる。それぞれについて説明する。

• IoTアプリケーション
• 大量の時系列ログデータが存在するプラットフォーム
• SaaSアプリケーション

IoTアプリケーション

IoTアプリケーションの特徴は、大量のデバイスからのセンサーデータが絶え間なく送られてくることだ。求められるのは、リアルタイムに近いデータ収集機能と、収集したデータに対して遅延が少なく高速なデータ分析機能だ(整形、集計、可視化など)。

この事例では、エレベーターから生成される稼働情報データをリアルタイムに収集し、監視担当者が見るダッシュボードにグラフとして表示している。

ADXは、Event HubsやIoT Hubなどと連携して、ほぼリアルタイムにデータを収集できる(10秒未満のレイテンシ)。1時間おき・1日おきに実行するETLツールに頼らなくてもよい。エレベーターから生成されるログデータ(JSON形式)をEvent Hubs経由で取得し、ADXのクエリー機能で担当者がわかりやすいようにデータを整形している。

またADXには、定義したクエリーをGrafanaやKibanaなど、外部のダッシュボードツールから呼び出す機能がある。この機能を利用すると、利用者が使い慣れたダッシュボードのなかにADXのクエリーを組み込むことで、IoTデバイスから送信されたデータをグラフ化し、ほぼリアルタイムにダッシュボードに表示できる。

大量の時系列ログデータが存在するプラットフォーム

大規模Webサイトやオンラインゲーム、アドテクノロジー企業など、Webベースの企業では毎日膨大なログデータが発生している。このような企業では、いくつかの利用方法がある。

1つはリアルタイム性を活かした使い方だ。大量のアクセスログや行動ログをニアリアルタイムに収集・監視し、異常検知などに役立てる方法がある。

もう1つは、収集した行動ログデータをデータ探索し、新規顧客獲得やユーザーエンゲージメント向上につなげる分析に役立てることだ。大規模Webサイトやオンラインゲームは日々進化している。常に利用状況を監視し、今後の改善や新機能につながる分析は欠かせない。

ADXは大量のログデータをリアルタイムに近い時間で収集できる。また、インメモリの特性を活かして、数日から1ケ月程度までの時系列データを高速に分析できる。そのためデータ探索のツールとして適している。

SaaSアプリケーションのユーザーサポート

大規模アプリケーションで問題になるのは、システムを構成する要素が多いことだ。大量のWebサーバーやデータベースサーバー、さらにはCDN(Contents Delivery Network)なども存在する。世界レベルで展開しているサービスでは、さらに複雑になる。

システムにエラーが発生したとき、どのようにトラブルシュートするのか考えていただきたい。数台程度のシンプルなシステムでも、Webサーバーのログ、APサーバーのログ、アプリケーションサーバーのログ、DBサーバーのログ、OSのログなど、さまざまなものを調べる必要がある。

数台でも厳しいのに、数百台になると現実ではない。到底grepでは太刀打ちできない世界だ。そこでADXのログ収集機能と数億件のレコードを一瞬に検索できる高速性、また使いやすくビジュアル化も簡単なワークスペースを使うことで、トラブルシューティングや利用者からの問い合わせ対応に役立てられる。

おわりに

Azure Data Explorerは、Microsoft社での必要性からボトムアップ的な発想で生まれたこともあり、多機能でさまざまな側面を持ち、これまでの製品やサービスとは単純比較できないサービスだ。ここまで読んでいただければ、適した用途はなんとなくわかっていただけたと思う。

そこで次回は、実際にAzure Data Explorerを操作し、具体的にどのようなことができるのか解説する。