LogAnalyticsのデータ取得時間の調査方法

こんにちは、kc-dreamです。
前回の記事に引き続き、LogAnalyticsについての補足を書いていきます。

のデータ取得時間の調査方法

LogAnalyticsは各種環境のデータを収集/分析するためのサービスです。
Azure基盤で各種データを収集するので、タイミングによってはデータの取得までに時間がかかることがあります。
例えば、LogAnalyticsを使用してアラートを設定している場合、データの取得時間及びしきい値によってアラートが発報してしまう可能性があります。
そういった場合にデータ取得にかかった時間を調べるためのqueryが用意されているので、本記事で紹介します。

SampleQuery

[crayon-616b634f00e64026262925/]

上記はHeartbeatのデータ取得にかかった時間を調べるSampleQueryです。

[crayon-616b634f00e6f316922280/]

取得時間は[ingestion_time()]から[TimeGenerated]を差し引いた値からデータの取り込みに要した時間を算出可能です。

参考情報

Azure Monitor でのログ データ インジェスト時間
Azure LogAnalytics 概要についてまとめてみた
Azure LogAnalyticsでWindowsServerを監視してみた


Microsoft Azure メンテナンス通知

こんにちは、kc-dreamです。
今回は、Microsoft Azureでのメンテナンスメールについてご紹介していきます。

メンテナンス通知について

Azureでは、年に一度程度の頻度で、仮想マシンの再起動を伴うメンテナンスが計画しております。
特に何月、と決定されているわけではなく、時期は不定期ですが、通常行われる VM 再起動を伴わないメンテナンスで行えないような、ハードウェアの BIOS・ファームウェア アップデートや、基盤側の OS などソフトウェアの大幅な更新といった目的で行われます。
Azureでは、メンテナンスや大きな障害等がある際にメール通知を行える仕組みがあります。
※各サブスクリプション毎に設定が必要
本記事では、この仕組についてご紹介していきます。

通知の種類

大きく分けて4種類あります。
(1) サービスの問題
ユーザーに今すぐ影響を及ぼす Azure サービスの問題。
(2) 定期的なメンテナンス
お使いのサービスの可用性に将来影響を及ぼす可能性のある今後のメンテナンス。
(3) 正常性に関する勧告
ユーザーが注目する必要のある Azure サービスの変化。 Azure の機能が非推奨となるタイミングや、使用量のクォータを超えた場合に関する例も含まれます。
(4) リソース正常性
Azureサービスの問題でリソースが影響を受けている際に確認いただくことが可能となります。
※2019/07/29時点ではプレビューとして提供

設定方法

(1)~(3)の設定方法
AzurePortalより、[モニター]から[Service Health]を選択

[サービス正常性アラートの作成]を選択

必要事項を入力し、作成することで通知が可能

(4)の設定方法
AzurePortalからの設定は現時点ではできません。
本記事では、詳細を省かせていただきますが、下記リンクを参考にして頂ければ簡単に設定可能です。
※本機能は2019/07/29時点ではプレビューとなっております。
Resource Manager テンプレートを使用して Resource Health アラートを構成する

参考情報

Azure Monitor を使ってメンテナンス通知を受け取る
[2018/3/26更新] 新規リリースされた “Azure Monitor” 機能を使って、利用中のリソースに影響しうるメンテナンスや障害のメール通知を受け取る
サービス正常性
Azure Resource Health の概要
Resource Manager テンプレートを使用して Resource Health アラートを構成する
Resource Health は Azure の状態や Service Health ダッシュボードと何が違うのでしょうか。
サービス通知のアクティビティ ログ アラートを作成する


Azure Heat Map の使い方

はじめに

今回は、Azure Heat Map について紹介したいと思います。 
Microsoft の社員が作成したこちらのサイトを見れば、各サービスのアップデート状況やリージョン毎の利用可能状況などが一目で分かると思います。
本サイトについては、こちらからどうぞ:Azure Heat Map

Azure Heat Map について

What is Azure Heat Map ?

Heat Map とは、大まかには色の強弱や濃淡をつけることで、様々な情報を可視化しやすくしたもののことです。Azure Heat Map では、その内容に応じて色の強弱や濃淡やをつけることで、ユーザに Azure が提供しているサービスの状態や状況を一目で理解できるようになっております。

ちなみにこちらのサイトは Microsoft の社員が作ったもので、Microsoft のサービスや商品ではありませんので、よろしくお願いします。

Azure Heat Map

こちらは、Azure Heat Map のサイトのトップページです。最初にこのサイトに飛ぶと、こちらが表示されます。

ここでは、Azure のサービスを機能毎に色分けしておりますが、そこに色の強弱ををつけることでサービスのアップデート状況をユーザに提供しております。
右上のタブを選択すると、以下の情報を確認することができます。

・All Updates Equal:直近6ヶ月以内にアップデートされたサービスほど濃い色で表示
・Latest More Important:直近1ヶ月以内にアップデートされたサービスほど濃い色で表示
・Only Last 7 days:直近7日以内にアップデートされたサービスのみ濃い色で表示(直近のものは白枠で表示)
・Heat ALL Up:アルファベット順にそれぞれのサービス毎に並び替え(アップデート状況は別)
また、サービスにカーソルを合わせることで、以下の情報を知ることが出来ます。

・アップデート回数
・直近6ヶ月以内のアップデート回数
・直近1ヶ月以内のアップデート回数
・最新更新日
・最新更新内容

Azure Changes Highlights

こちらは、 Azure サービスを直近3ヶ月以内にアップデートしたトピック毎に分けて表示しております。

以下のアップデート項目に分けて、表示しております。
・Region & Datacenters:サービス利用地域関連のアップデート
・Pricing & Offerings:料金関連のアップデート
・Retirements:サービスの全体、または部分的な廃止関連のアップデート
・Security:セキュリティ関連のアップデート
・Compliance:コンプライアンス関連のアップデート
・Open Source:オープンソース関連のアップデート
・SDK & Tools:SDK やツールのアップデート
・Services:サービス関連のアップデート
・Features:機能面関連のアップデート
サービスにカーソルを合わせることで以下の情報が分かります。

・そのサービスの分野
・最新更新日

Azure SLA Board

こちらは、Azure の SLA (Service Level Agreement) を表したものになります。

サービス毎に、それぞれの SLA を見分けられるようになっております。
サービスにカーソルを合わせることで、以下の情報が分かります。

・SLAの状態
・最終更新日
・バージョンの状態

Azure Region Scope

リージョン毎にサービスの使用可能状況を見ることが出来ます。

こちらのページでは以下の情報が得られます。
・Current Region:選択地域のサービスの使用可能状況
-Non-Regional:どの地域でも同じ様に利用可能なサービス
-Generally Available:選択地域で基本的に利用可能なサービス
-In Preview:今後、利用可能となる予定
-Futer Availability:将来的には利用可能となる予定
・Compared To:Current Region と比較した場合のそのリージョンにおける Azure サービスの利用可能状況
また、リージョン同士で利用可能なサービスの状況を比較することもできます。

・Ahead:Current Region が Compared To に比べて優れているサービス(アップデート状況や利用可能状況などにおいて)
・Behind:Current Region が Compared To に比べて劣っているサービス(アップデート状況や利用可能状況などにおいて)

Azure Services Menu

Azure サービスがクラウド環境でどれだけ親しまれて利用されているかをメニュー形式で表したものです。

・Starters:IaaS や基本的なサービスなど
・Main Dishes:PaaS やマネージドサービスなど
・Desserts:特徴的なサービスなど

おわりに

Azure Heat Map の紹介は以上となります。
こちらのページを使えば、Azure サービスの最新状況や利用可能状況がひと目で分かるので、ぜひ一度、このサイトを見て頂ければと思います。


Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、Webキューワーカーに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】

概要

このアーキテクチャスタイルのコアコンポーネントは以下の3点。
クライアント要求にこたえるWebフロントエンド
バッチジョブを実行するワーカー
もしくはCPUを集中的に使用するタスク
非同期メッセージキュー
これらに加えて、一般的に以下のコンポーネントが組み込まれます。
システムの要件にフィットする範囲で、特定の機能を分離し、各種マネージドサービスを組み合わせる、というイメージです。
1つまたは複数のデータベース
DB読み取り高速化のためのキャッシュ
静的コンテンツを提供するCDN
構成図は以下の通り。

以下のような特徴を持つアプリケーションに適しています。
比較的単純なドメインのアプリケーション
時間のかかるワークフローバッチ操作があるアプリケーション

利点

・理解しやすい比較的単純なアーキテクチャ
展開と管理の容易さ
・フロントエンドとワーカーは独立に拡張可
・懸念事項の明確な分離

課題

情報の入出力が多いコンポーネントでは、システムの要望に応じてコードが肥大化しやすい傾向があります。
・フロントエンドとワーカーが、複数の機能を持った単一のコンポーネントになりやすい (= モノリシックコンポーネント)
・フロントエンドとワーカーがデータスキーマやコードモジュールを共有している場合、隠れた依存関係が存在する可能性あり

ベストプラクティス

各マネージドサービスでベストプラクティスが用意されています。
・適切であれば、複数のストレージ技術を混在させる
・以下のベストプラクティス設計に準ずる
API 設計のベストプラクティス
自動スケールのベストプラクティス
キャッシングのベストプラクティス
CDN のベストプラクティス
ジョブに最適なデータストアの使用 データのパーティション分割のベストプラクティス

対応するAzureサービス

核となるサービスは、App Serviceです。
WebjobsApp Serviceのサービスの一つで、ワーカーの役割を果たします。これらをQueue StorageもしくはService Busでつなげる形です。
アイコンと概要をまとめます。

先ほどの構成図にあるアーキテクチャを組んだ場合、以下のような構成になります。
※ 図ではDocumentDBになっていますが、現在はCosmosDBとしてリニューアルされていますのでご注意を。

まとめ

Webキューワーカーの特徴と、使用されるサービスについて見ていきました。次回はCQRSについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


Azureアーキテクチャガイドまとめ 2【N層】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、N層アーキテクチャに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】

概要

N層アーキテクチャと呼ばれるもの中で代表的なものが、以下の三層アーキテクチャです。
・プレゼンテーション層
・中間層
・データ層
下記の例では、中間層が二つ(Middle Tier 1 / Middle Tier 2)あり、別々の機能を持たせています。名称はとっつきにくいですが、よく見るような一般的な構成です。

以下のような特徴を持つアプリケーションに適したアーキテクチャスタイルです。
単純なWebアプリケーション
・オンプレアプリをAzureに最小限のリファクタリングで移行
・オンプレアプリとクラウドアプリの統一的開発

特徴は以下の通り。

一般的なIaaSアプリとしての実装
・レイヤー
-論理レイヤーと物理レイヤーに分断し、責任を分離し、依存関係を管理する
-上位レイヤーは下位レイヤーのサービスを利用可。逆は不可
・2種のアーキテクチャ
-クローズドレイヤー (直下のレイヤーのみを呼び出し可)
-オープンレイヤー (下のすべてのレイヤーを呼び出し可)

利点

・オンプレ/クラウド間の移植性が高い
・エンジニアにとって学習コストが低い
・異種混在環境(Windows/Linux)への適合性が高い

課題

・各機能の独立展開不可
管理コストが高い
・大規模システムのセキュリティ管理が難しい場合あり
・中間層が無意味に待ち時間を増やす場合あり

ベストプラクティス

スケーラビリティ、信頼性、セキュリティの各層の境界としてサブネットを活用し、以下のマネージドサービスを利用する
・キャッシング
・オートスケール
・ロードバランサ
・メッセージング
-各層の分離に非同期メッセージングを使用
・データストレージ
-アクセス制限のため、中間層からの要求だけ許可
-高可用性実現のため、可用性グループを使用

対応するAzureサービス

各層のコンピューティングにVirtual Machineを利用し、マネージドサービスを追加していく形です。アイコンと一緒に覚えてしまいましょう。

まとめ

N層アーキテクチャの特徴と、使用されるサービスについて見ていきました。次回はWebキューワーカーについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


Azureアーキテクチャガイドまとめ 1 【はじめに】

はじめに

Azureクラウドアプリケーションアーキテクチャガイド。皆さんご存知でしょうか?
いわば、Azure版のWell-Architectedフレームワークです。非常に示唆に富む内容なので、分からない用語や概念を調べつつ、まとめようと思います。
本稿では、「はじめに」から、第一章「アーキテクトスタイルの選択」の導入部までを扱います。

従来のオンプレ環境と最新のクラウド環境

ご存知の通り、クラウドまわりの技術は急速に進化しています。マイクロサービス、コンテナ、AI/MLなどなど。
流れが早すぎて潮流が読めないなと感じていた折、冒頭に従来のオンプレ環境と"最新の"クラウド環境の比較表を発見。図示します。

何かしら指針がないと沈没しそうです。
さて、本ガイドはどんな内容でしょうか?

"このガイドでは、スケーラブルで回復性と可用性が高いクラウド アプリケーションを設計するための構造化されたアプローチについて解説します。
(本文より抜粋)”

構造化されたアプローチ、いい言葉ですね。詳しく見ていきましょう。

ガイドの構成

ガイドは以下の5つステップで構成されています。
1. アーキテクチャスタイルの選択
2. コンピューティングおよびデータストア用テクノロジの選択
3. Azureアプリケーションの設計 10の原則
4. ソフトウェア品質 5つの柱
5. クラウド設計パターンの適用

ステップ1を行う前に、アーキテクチャの要件の明確化が必要になります。
というより、明確にしないと先に進めないようになっています。
設計後半で要件の見落しに気づいて大幅な手戻りが...なんて場面を回避できます。ついつい技術要素に目が向きがちなので、これはありがたい。

アーキテクチャスタイルの選択

要件の集合からテンプレートを選択というイメージです。合計7パターン。

各スタイルの概要は下記の通り。

用語は聞いたことあっても、具体的に何のことを言っているのかわからない、というのが正直な感想。

制約・課題・利点

それぞれのスタイルの説明に移る前に、なぜこの段階で型にはめる必要があるのかを整理します。
スタイルの選択は、制約をもたらす
各スタイルは、固有の課題を持っている
制約を満たす場合、利点が生まれる
制約、課題、利点の概要と関係性を図示します。

もっとも利点マイナス課題が大きくなるスタイルを見つけることで、最適なアーキテクチャに最短距離で近づくことが出来る、という格好です。

おわりに

次回以降は各アーキテクチャスタイルについて解説します。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


【AI入門】第4弾 Azure Databricks : Pyspakの基本操作をやってみた!

はじめに

これまでのAzure Databricks の操作紹介第4弾目の記事です。
【Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント】の続きになります。
これまでの記事は以下のから参照できます。
Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項
Azure Databricks: 3-1. DBFSにBlob Storageをマウント
Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント

この記事の概要

この記事では、サンプルデータからAzure Databricks を利用した Spark の操作について紹介しています。
PySpark ・ SQL を使いながらデータ分析を行い最後はCSV形式で出力します。

こんな方に読んでもらいたい

  • Databricks に関して興味のある方
  • PySpark ・ Spark SQL を勉強している方
  • データ分析に興味のある方

サンプルデータセット

今回はkaggleのデータセット「Brazilian E-Commerce Public Dataset by Olist」をサンプルデータとして使います。
このデータはOlist StoreというブラジルのECサイトで行われた2016年から2018年までの約10万件の注文に関するデータが含まれています。
データ量としてはビッグデータというほどに多くありませんが、注文の商品明細やレビューなどが複数のCSVに分かれて保存され、それぞれがIDで紐づけられているため、PySparkやSpark SQLの練習に適しています。

CSVの読み込み

注文ごとの商品の明細情報「olist_order_items_dataset.csv」を使ってデータの読み込みとPySparkの操作を行っていきます。

DataFrameに読み込み

下記スクリプトでCSVをSpark DataFrameとして読み込みます。
読み込むCSVはカラム名を示す行が先頭にあるため、読み込みオプションとして「header=”true”」、またカラムのデータ型を自動推定するため「inferSchema=”true”」として読み込んでいます。
(※CSV読み込みオプションの詳細はDatabricksドキュメントも参照してください)

[crayon-616b634f01a9e218513353/]

画像1.png

スキーマを指定して読み込み

スキーマを指定して読み込みを行う場合は下記のようにします。

※指定できる型はSparkドキュメントも参照
カラムのデータ型指定にinferSchemaを使用した場合、型推定のため1回余計に読み込むことになり、読み込みのパフォーマンスが低下します。
データのスキーマがわかっている場合は、スキーマを指定して読み込むことを推奨します。

[crayon-616b634f01aa5406460183/]

画像2.png

データ型の確認

[crayon-616b634f01aa8944199774/]

画像3.png

PySparkでのDataFrameの基本操作

読み込んだCSVでPySparkの基本操作を実行します。
指定行数抽出して表示

[crayon-616b634f01aab971231766/]

画像4.png

全レコード数のカウント

[crayon-616b634f01aad750218640/]

画像6.png

計算列の追加

[crayon-616b634f01aaf785396453/]

画像7.png

カラムを指定して抽出

[crayon-616b634f01ab2528910769/]

画像8.png

条件でレコード抽出

[crayon-616b634f01ab4900617523/]

画像9.png

レコードのカウント

[crayon-616b634f01ab7973201456/]

画像10.png

レコードの集計

[crayon-616b634f01ab9831295056/]

画像11.png

Spark SQLを使用した操作

DataFrameをTemp Tableに登録することでSpark SQLを使用した集計が可能になります。
Temp Tableの登録

[crayon-616b634f01abb412284172/]

画像12.png

Spark SQLによるカラム抽出

[crayon-616b634f01abd404483053/]

画像13.png

%sqlマジックコマンドを使用する場合

[crayon-616b634f01abf484439968/]

画像13.png

DataFrameの結合

データセットに含まれる他のCSVファイルと組み合わせて商品カテゴリごとの売り上げを集計してみます。
各商品の詳細情報「olist_products_dataset.csv」をDataFrameに読み込みます。

[crayon-616b634f01ac2003954592/]

画像15.png

[crayon-616b634f01ac5826196835/]

画像16.png

2018年1月の商品カテゴリごとの売り上げ金額を集計します。
「sum(price)」をソートすると「relogios_presentes」の売り上げが最も高いことがわかりますが、ポルトガル語なので何の商品カテゴリかわかりません。

[crayon-616b634f01ac9068796672/]

画像17.png

データセットにカテゴリを英語翻訳したCSVファイルがあるため、これも読み込みます。

[crayon-616b634f01acd161686102/]

画像18.png

結合して翻訳します。

[crayon-616b634f01ad2560030575/]

画像19.png

Databricksではデータの可視化も簡単にできます。
売り上げが最も高いのは「watches_gifts」であることがわかりました。
画像20.png

CSVの書き出し

DataFrameを書き出す場合は下記コマンドを使用します。

[crayon-616b634f01ad7687918056/]

画像21.png

CSVは指定したパスに直接書き出されるのではなく、指定パスのディレクトリが作成され、直下に分割されたCSVファイルとして出力されます。

[crayon-616b634f01ada431701149/]

画像22.png

ファイルを1つのCSVとして出力する場合は、HadoopのFileUtil.copyMergeを使用し、上記で出力したファイルをマージして1ファイルにまとめます。

[crayon-616b634f01ade711665557/]

画像23.png

[crayon-616b634f01ae1755353517/]

画像24.png

Clusterのメモリ量に余裕がある場合は、下記スクリプトで1ファイルにデータを書き出すことができます。
この場合でも「output.csv/part-00000-xxxxxxxxx.csv」のような名称でファイルが出力されるため、出力後必要に応じてファイルの移動を行います。

[crayon-616b634f01ae5756504334/]

画像25.png

[crayon-616b634f01ae8411232625/]

画像26.png

最後に

Azure Databricks 上で Spark を操作していきました。
データを元に特定の課題解決に向けて Azure Databricks を活用する1つの方法として知っていただけたと思います。
今後も様々なデータを Azure Databricks 上で分析していきたいです。

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

弊社は、Databricksのソリューションパートナーとしてお客さまのデジタルトランスフォーメーションの推進に貢献致します。

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

Azure Databricksソリューションページはこちら
Databricks ソリューションパートナーに関してはこちら


Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント

前回記事

Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項
Azure Databricks: 3-1. DBFSにBlob Storageをマウント

サービスプリンシパルの作成

Azure DatabricksのDBFSにAzure Data Lake Storage Gen2 (ADLS Gen2)をマウントするには、サービスプリンシパルの設定が必要になるため,あらかじめ作成しておきます。
(サービスプリンシパルはアプリケーションに対して割り当てるユーザーIDのようなものです。)
「すべてのサービス」の「ID」カテゴリから「Azure Active Directory」を開きます。

メニューの「App registrations」を開き、「+新規作成」をクリックします。

「名前」に任意の名称を入力し、「リダイレクトURI」にAzure DatabricksのURL( https://japaneast.azuredatabricks.net/ )を入力して「登録」をクリックします。

登録後に表示される「アプリケーション(クライアント)ID」と「ディレクトリ(テナント)ID」はマウント時のパラメータとして必要になるため、コピーして控えておきます。

続いて、サービスプリンシパルのクライアントシークレットを作成します。
メニューの「証明書とシークレット」を開き、「+新しいクライアントシークレット」をクリックします。
「説明」と「有効期限」を設定して「追加」をクリックします。

作成されるとクライアントシークレットの文字列が表示されます。この文字列は作成後最初の1回しか表示されないため、コピーして控えておきます。
クライアントシークレットもマウント時の必要パラメータとなります。
(秘密情報の管理にAzure Key Vaultを使用する場合はクライアントシークレットをキーコンテナーに登録しておきます。)

Azure Data Lake Storage Gen2 (ADLS Gen2)とファイルシステムの作成

ADLS Gen2はAzure Storageのオプション扱いであるため、作成はストレージアカウントの作成の手順に準じます。
作成の変更点は、作成の「詳細」設定で「階層構造の名前空間」を有効化することです。
(ADLS Gen2は後から有効化できないため、使用する場合は新規でストレージアカウント作成が必要です。)

作成が完了したら、作成したリソースを開きます。
「階層構造の名前空間」を有効化していると、概要の「サービス」が「Blob」から「Data Lake Gen2ファイルシステム」に変化しています。

ファイルシステムの作成

ADLS Gen2にファイルシステムを作成します。
「Data Lake Gen2ファイルシステム」をクリックしてADLS Gen2メニューを開きます。

「+ファイルシステム」をクリックし、「名前」に任意の名称を入力して作成を行います。

ADLS Gen2へのアクセス権限の付与

サービスプリンシパルに対するADLS Gen2のアクセス権限の付与します。
作成したファイルシステムを開きます。

メニューから「アクセス制御(IAM)」を開いて「ロールの割り当てを追加する」をクリックします。

「役割」を「ストレージBLOBデータ共同作成者」に変更し、「選択」で作成したサービスプリンシパルを選択して「保存」をクリックします。

「ロールの割り当て」タブをクリックするとサービスプリンシパルに割り当てられた権限が確認できます。

ADLS Gen2をDBFSにマウント

DBFSにADLS Gen2をマウントするには、下記のスクリプトを使用します。
(ストレージ、サービスプリンシパル情報、マウント先DBFSディレクトリは作成したリソースに合わせて変更してください。)
[crayon-616b634f025b0547681015/]

参考

3分でわかるAzureでのService Principal
ナレコムAzureレシピ - Azure Databricksを使ってみた
Databricks Documentation - Data Sources - Azure Data Lake Storage Gen2
チュートリアル:Spark を使用して Azure Databricks で Data Lake Storage Gen2 のデータにアクセスする

 

 

 

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

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

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

 

 


【Azure Databricks 入門】第3.1弾 DBFS に Blob Storage をマウント

はじめに

Azure Databricks 第3.1弾として DBFS に Blob Storage をマウントする方法を解説します。

  • Azure Databricks に興味がある
  • 機械学習に興味がある
  • クラウド上でデータ分析をやってみたい

上記の項目に当てはまる方はぜひ読んでいただきたい内容となっています。

記事の概要

  • ストレージアカウントの作成から DBFS に Blob Storage をマウント方法を解説しています。
  • Blob Storage のアンマウント方法を解説しています。
  • ストレージアカウントキーなどの秘密情報を管理する Azure Key Vault を使用します。

前回記事

Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項

既存の Blob Storage をマウントする場合の方法

※既存のBlob Storageをマウントする場合は以下の方法で作成してください。

  • 「DBFSにBlob Storageをマウント」から操作を実行
  • Azureポータルの「リソースの作成」をクリック
  • 一覧から「ストレージアカウント」を選択して作成を開始

ストレージアカウントの作成

画像1.png

作成に必要な情報を入力します。
設定内容は任意ですが、
「リソースグループ」と「場所」はAzure Databricksと同じものを指定します。
設定が出来たら「次: 詳細 >」をクリックします。

画像2.png

「詳細」設定に関しては、今回はデフォルトのままでいきます。
「確認および作成」をクリックします。

画像3.png

設定内容に誤りがないことを確認、
「作成」をクリックします。

画像4.png

しばらく待機し、作成が完了したら作成したリソースに移動します。
画像5.png

マウント時のパラメータとして
ストレージアカウントの「アクセスキー」が必要です。

メニューの「アクセスキー」を開きます。
「key1」または「key2」いずれかの「キー」をコピーして控えておきます。

画像6.png

Blobコンテナーの作成とファイルの配置

ストレージアカウントのメニューの「概要」に戻り、
「サービス」の「BLOB」をクリックします。

画像7.png
「+コンテナー」をクリック
「名前」を任意のコンテナ名、
「パブリックアクセスレベル」を「プライベート」
としてコンテナを作成します。

画像8.png
ファイルを配置するため作成したコンテナーをクリックします。
コンテナーを開きます。

画像9.png

「↑アップロード」をクリックします。
ファイルを選択して「アップロード」をクリックします。

画像10.png

アップロードが完了するとコンテナーにファイルのリストが表示されます。
画像11.png

DBFSにBlob Storageをマウント

Blobコンテナーのマウント

Blob Storageのマウントは下記のスクリプトを使用します。

※以下の項目は作成したリソースに合わせて変更してください。
- ストレージ情報
- マウント先の DBFS ディレクトリ

一度マウントすると、Clusterを停止・変更してもマウント状態が維持されます。
マウントされた状態で再度操作を実行するとエラーが発生します。
マウント状態をチェックするか、スクリプトをコメントアウトしてエラーの回避します。

[crayon-616b634f02e38045583326/]

画像12.png

下記スクリプトでマウントされているディレクトリを確認します。
Blob Storage をマウントしたディレクトリがリストで確認できます。

[crayon-616b634f02e40423961608/]

画像13.png

マウントされたディレクトリの確認

下記スクリプトを使用してマウントしたディレクトリ内のファイルを表示します。

※ マウントしたディレクトリにファイルが存在しないとエラーが発生します。

[crayon-616b634f02e43154553324/]

画像14.png

Blob コンテナーのアンマウント

ストレージのマウントを解除する場合は下記スクリプトを使用します。

[crayon-616b634f02e45556338458/]

画像15.png

秘密情報の安全な管理

秘密情報をスクリプト上に記載することはセキュリティ上の懸念となります。

ストレージアカウントキーのような秘密情報を安全に管理するため、
Azure Key Vault の使用が推奨されます。

Azure Key Vault のキーコンテナー作成

Azure ポータルの「リソースの作成」で「Key Vault」を検索します。
検索候補の「Key Vault」をクリックして作成を開始します。

画像16.png

「キーコンテナーの作成」に必要な情報を入力します。

  • 「名前」: 任意の名称
  • 「リソースグループ」: Azure Databricksと同じものを指定
  • 「場所」: Azure Databricksと同じものを指定。

その他の設定はデフォルトのままとします。

画像17.png

作成が完了したらリソースに移動します。
画像18.png

キーの登録

作成したキーコンテナーにストレージアカウントキーを登録します。
作成したリソースのメニューから「シークレット」を開きます。
「+生成/インポート」をクリックします。

画像19.png

  • 「アップロードオプション」:「手動」と選択
  • 「名前」:任意の名称を入力
  • 「値」:ストレージアカウントキーを入力

「作成」をクリックします。

画像20.png

Databricks に Azure Key Vault を登録

キーコンテナーのメニューから「プロパティ」を開きます。
「 DNS 名」と「リソース ID 」をコピーして控えておきます。

Databricks ワークスペースのホーム画面を開きます。
URL に「#secrets/createScope」を追加します。
「Create Secret Scope」のページを開きます。

  • 「Scope Name」に任意のスコープ名を入力
  • 「DNS Name」: 作成したキーコンテナーの「プロパティ」の「DNS名」を入力
  • 「Resource ID」: 作成したキーコンテナーの「プロパティ」の「リソースID」を入力

※ Databricks作成時にStandard Planを選択した場合、
「Manage Principal」は「All Users」のみ選択できます。

入力したスコープ名はキーの取得に必要となるため控えておきます。

画像21.png

Notebookを開き、下記のスクリプトでスコープのリストを確認します。
スコープが登録されていると、
登録したスコープがリストにあることが確認できます。

[crayon-616b634f02e4b531794698/]

画像22.png
BlobコンテナーのマウントにKey Vaultのキーを使用する場合は、
Blob Storageの情報を下記のように書き換えます。

[crayon-616b634f02e54597648571/]

最後に

ストレージアカウントの作成から DBFS に Blob Storage をマウントする方法を解説していきました。
Azure Key Vault を使用した秘密鍵情報の管理を行うことで、データ分析業務に注力できる環境整備が行えそうですね。
Azure Databricks でデータ分析を行う際の参考になれば幸いです。

次回もお楽しみに!

参考

Databricks Documentation – Data Sources – Azure Blob Storage
クイックスタート:Azureポータルを使用してAzure Key Vaultから秘密を設定および取得する

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

弊社は、Databricksのソリューションパートナーとしてお客さまのデジタルトランスフォーメーションの推進に貢献致します。

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

Azure Databricksソリューションページはこちら
Databricks ソリューションパートナーに関してはこちら


Azure Databricks: 2. Databricksの基本事項

前回記事

Azure Databricks: 1. リソースの作成

Databricks File System (DBFS)

Azure DatabricksのClusterには、Databricks File System (DBFS)という分散ファイルシステムがインストールされています。DBFSのファイルはAzure Blob Storageに永続化されるため、Clusterが終了してもデータが保持されるようになっています。
NotebookからDBFSにアクセスする場合には、Databricks Utilities(dbutils)、Spark API、open関数等のFileIOを使用しますが、OSとDBFSでルートディレクトリの扱いが異なるため、ファイルにアクセスする上で注意が必要になります。

Databricks Utilities(dbutils)

dbutilsでは、DBFSのルートディレクトリを基準にパスを参照します。
dbutilsで「/mnt/my_blob_container」を指定した場合は「dbfs:/mnt/my_blob_container」を参照することになります。
dbutilsでClusterのローカルストレージを参照する場合は「file:/home/ubuntu」のように、OSのローカルパスに「file:」を追加したものを使用します。

Spark API

Spark APIでファイルを読み込む場合、DBFSのルートディレクトリを基準にパスを参照します。
ただし、dbutilsとは異なり「file:/home/ubuntu」のような形でClusterのローカルストレージを参照することはできません。
そのため、Sparkでファイルの読み込みを行う場合はファイルをDBFS上に配置する必要があります。

FileIO (上記2つ以外のファイル操作)

Pythonのopen関数等のFileIOで読み込みを行う場合、OSのルートディレクトリを基準にパスを参照します。
DBFSルートディレクトリはOS「/dbfs」にマウントされているため、DBFSの「/mnt/my_blob_container」にアクセスする場合は、「/dbfs/mnt/my_blob_container」のように「/dbfs」を追加したパスを使用します。

マジックコマンド

Databricksでは、セルにマジックコマンドを指定することで、各種スクリプトの実行ができます。
マジックコマンドは1セルにつき1つだけ指定できます。

Markdown形式でのコメント挿入: %md

セルにMarkdownを記載してコメントとして挿入します。
[crayon-616b634f03731791405077/]

Databricks File System(DBFS)のファイル操作: %fs

Databricksの分散ファイルシステムであるDBFSのリスト、コピーといったファイル操作をシェルコマンドライクに記述して実行します。
ディレクトリにあるファイルのリストを表示する場合は、下記コマンドを使用します。
[crayon-616b634f03737220928253/]

上記コマンドはPythonの下記スクリプト実行結果と同等となります。
[crayon-616b634f0373a654119603/]

OS (Linux)のシェルコマンド実行: %sh

OSのシェルコマンドを実行する場合には「%sh」を使用します。
DBFSを%shで参照する場合は下記のとおりです。
[crayon-616b634f0373c040864895/]

各言語のスクリプト実行: %python, %scala, %sql, %r

Notebookで指定した言語以外の言語を使用する場合は、対応言語のマジックコマンドを使用します。
[crayon-616b634f0373e217177958/]
[crayon-616b634f03740327154055/]

言語間で変数は共有されないため、マジックコマンドの変数に値を引き渡す場合は一旦DBFSにファイル出力をする等で渡す必要があります。

他のNotebookの実行と読み込み: %run

他のNotebookを実行する場合は「%run」で対象Notebookを指定して実行します。
%runで実行すると、同じ言語であれば他のNotebookで定義された変数をそのままの変数名で参照することができます。
メンテナンス性を高めるために、スキーマ定義を別Notebookで記述しておくといったような使い方ができます。
[crayon-616b634f03742828482342/]

参考

Using Notebooks

 

 

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

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

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