5/21(木) 「自宅からでOK! Azure で始めるデータ分析ことはじめ ~ データ分析もリモートワークスタイルから ~」オンライン座談会を開催します!

はじめに

この度、マイクロソフト社と共同開催にて
「自宅からでOK! Azure で始めるデータ分析ことはじめ~ データ分析もリモートワークスタイルから ~」と題しましたオンライン座談会を開催することとなりました。

今回のウェビナーでは、

  • Azureを用いたデータ分析方法について、実際の事例から導入のための考え方や工夫のご紹介
  • Azure Windows Virtual Desktopを使ってリモートワーク環境下でセキュアに最適な分析環境の実践方法のデモンストレーション

を予定しています。

また、終了後には座談会形式で日頃のお悩みについて、口頭またはチャット機能でご質問いただけるQnAタイムも設けております。

こんな方におすすめです

  • AI活用をこれから導入を考えている方(データ分析未経験でも可)
  • リモートワークでのデータ分析環境にお困りの方

開催概要

スピーカー

日本マイクロソフト株式会社
塚本修一様

株式会社ナレッジコミュニケーション
中西 貴哉
井村 真樹

株式会社ナレッジコミュニケーションについてのご紹介

株式会社ナレッジコミュニケーションでは、これまで下記のような取り組みを行なっております。

■検証記事
・Azureデータ分析入門 #1 【はじめに】
https://azure-recipe.kc-cloud.jp/2019/09/excel-azure-notebook-databricks-01/
・WVD(Azure Windows Virtual Desktop)検証記事
https://azure-recipe.kc-cloud.jp/2020/05/remote/
・AzureML検証記事
https://azure-recipe.kc-cloud.jp/category/bigdata/

■実績掲載
名古屋大学様及び中部電力様 事例
https://prtimes.jp/main/html/rd/p/000000008.000004474.html
トヨタ情報システム愛知株式会社様 事例
https://www.zaikei.co.jp/releases/709075/

タイムスケジュール

ご参加方法

以下のURLをクリックしていただき、「イベントに登録」フォームで必要事項のご記入をお願いいたします。
https://mktoevents.com/Microsoft+Event/177302/157-GQE-382?ls=Website&lsd=AzureWebsite
申し込み完了後、Microsoft TeamsのURLを発行いたしますので、そちらからご参加をお願いいたします。

ランチタイムのお時間での開催になりますので、リラックスしながらご参加いただければと思います。
それでは、皆様のご参加を心よりお待ちしております。


Azure Remote Rendering やーる

Azure Remote Rendering(プレビュー)が昨日公開されたので、さっそく試してみました!

Azure Remote Renderingとは、データサイズの大きい3Dモデルをクラウドでレンダリングし、その結果をストリーミングすることで、リアルタイムにHoloLens2などのデバイスに表示することができるサービスです。

Azure Remote Renderingについて

システム要件について

remote rendering accountの作成

1.azure portal にログインし、remote renderingを検索、remote rendering account を作成します
image.png

2.リソース名、サブスクリプション、リソースグループを指定します
image.png

3.デプロイ完了したらリソースに移動してください
image.png

クイックスタート

下記のドキュメントを参考に進めていきます。
https://docs.microsoft.com/en-us/azure/remote-rendering/quickstarts/render-model

1.サンプルプロジェクトをクローンします

[crayon-62f0b02411cb3693714733/]

2.UnityHubのリストに追加からARR\azure-remote-rendering\Unity\Quickstartを開きます
※Unityのバージョンは2019 3.1f1

image.png

3.Scenes->QuickStartを開きます

4.RemoteRenderingゲームオブジェクトを選択し、InspectorビューにアカウントIDとKey、ドメインを入力します

image.png

アカウントIDはリソースのremote rendering の概要に載っています。
image.png

リージョンの名前は、リソースグループから確認できます。例:米国東部なら、ドメインはeastus.mixedreality.azure.comです。
image.png

リージョンの名前について

5.UnityのPlayボタンを押すと表示されました!
image.png

表示するサンプルのモデルについて

Name Value
Required VM size standard
Number of triangles 18.7 Million
Number of movable parts 2073
Number of materials 94

表示するモデルのカスタマイズはこちらから

HoloLens2にデプロイ

こちらのドキュメントを参考にします
https://docs.microsoft.com/en-us/azure/remote-rendering/quickstarts/deploy-to-hololens

1.Build Settingsを開き、UWPにSwitch Platformして、下記のように設定し、フォルダを指定してBuild

image.png

2.ビルドしたフォルダの中にある.slnファイルをVisualStudio2019で開き、Release・ARM64で、リモートコンピュータ(HoloLens2のIPアドレス)を指定してCtrl+F5

藤本賢志(ガチ本)@pixivFANBOXはじめました@sotongshi

Azure Remote Renderingのサンプルやってみた

Embedded video

See 藤本賢志(ガチ本)@pixivFANBOXはじめました's other Tweets

PCにデプロイ(割愛)

こちらのドキュメントを参考にします
https://docs.microsoft.com/en-us/azure/remote-rendering/quickstarts/deploy-to-desktop


Data Lake Storage Gen 2 ファイルシステム情報確認方法 【Azure Databricks 接続用】

はじめに

Data Lake Storage Gen 2 で作成したファイルシステムを Azure Databricks に接続する際には、以下の情報が必要になります。

  • アプリケーションID
  • ディレクトリID
  • クライアントシークレット
  • ストレージアカウント名
  • ファイルシステム名

どたばたしていると控えておくのを忘れてしまうこともしばしば。
クライアントシークレットは一度しか発行されませんが、その他については再確認が可能です。
Azure コンソールからの確認手順を記しておきます。

ストレージアカウントとファイルシステム名の確認

コンソールのトップ画面から Azure Databricks を選択。(最新のリソースからアクセスしたほうが早いことも)
image.png

接続対象の Azure Databricks を選択。
2020-02-13_16h19_24.png

リソースグループをクリック。
2020-02-13_16h21_45.png

ここでストレージアカウント名 を確認できます。対象のストレージアカウントをクリック。
2020-02-13_16h23_35.png

コンテナを選択。
2020-02-13_15h31_08.png

こちらがファイルシステム名です。
2020-02-13_16h32_12.png

アプリケーションID と ディレクトリID の確認

トップ画面より、Active Directory を選択
2020-02-13_16h33_58.png

アプリの起動から、登録した内容をクリック。
2020-02-13_15h37_46.png

アプリケーションID と ディレクトリID が確認できました。
2020-02-13_15h38_45.png

 


Azure SQL Database 単一データベースの作成方法

こんにちは、kc-Dreamです。
今回は、SQL Databaseの単一(シングル)データベースをAzure Portalから構築する方法についてご紹介します。

Azure SQL Databaseについて

Azure SQL Databaseは下図の種類があり、今回ご紹介するのはシングルデータベースとなります。

image.png

 

  • 単一データベースは、フル マネージドの分離されたデータベースを表します。 このオプションは、信頼性の高い 1 つのデータ ソースを必要とする最新のクラウド アプリケーションとマイクロサービスがある場合に使用できます。 単一データベースは Microsoft SQL Server データベース エンジンの包含データベースに似ています。
  • マネージド(管理者常駐型)インスタンスは、Microsoft SQL Server データベース エンジンのフル マネージド インスタンスです。 これには、一緒に使用できる一連のデータベースが含まれています。 このオプションは、オンプレミスの SQL Server データベースを Azure クラウドに簡単に移行するため、および SQL Server データベース エンジンが提供するデータベース機能を使用する必要があるアプリケーションに使用します。
  • エラスティックプールは、CPU やメモリなどのリソースの共有セットを含む単一データベースのコレクションです。 単一データベースはエラスティック プールの内外に移動できます。

デプロイ モデル

構築方法

Azure PortalからSQL Databaseを選択し、新規SQL Databaseを作成していきます。

 

image.png

基本

image.png

  • サブスクリプションの選択
  • リソースグループの選択
    • 新規リソースグループの作成も可能
  • データベース名を入力
  • サーバー
    • SQLデータベースがのるサーバを新規作成を行います。
    • 既存サーバを使用することも可能です。
    • 新規作成する場合、サーバ名、ログインユーザ名、パスワード、場所を入力し作成を進めます。※SQL DatabaseはPaaSサービスなのでサーバを直接設定するようなことはできません。

image.png

  • エラスティックプールの使用有無
    • 本記事ではシングルデータベースの構築についてなので無を選択します。
  • データベースの設定より使用するSQL データベースのスペック等を選択します。 image.png

ネットワーク

image.png

  • ここではSQL Databaseへの接続方法について選択します。

追加設定

image.png

  • データソース
    • 新規に作成し使用する場合、なしを選択
    • バックアップから復元の場合には、バックアップを選択
  • データベース照合順序

タグ

image.png

  • タグ設定を行う場合、入力します。

確認および作成

  • 選択及び入力した設定項目を確認できます。また、SQL Databaseが起動できるかどうかの検証が行われます。
  • 問題なければ作成を選択
  • デプロイ後、バックアップ設定は変更することをオススメします。

おわりに

今回はシングルデータベースの構築についてご紹介しました。
マネージドインスタンス、エラスティックプールについての構築方法についても今後ご紹介したいと思います。


Azure LogAnalytics 番外編

こんにちは、kc-dreamです。
今回はAzure LogAnalyticsの番外編ということで、Kustoクエリについてご紹介します。

 

 

Kusto概要

Kusto は、ビッグ データに対する対話型分析を格納して実行するためのサービスです。
これはリレーショナル データベース管理システムに基づいており、データベース、テーブル、列などのエンティティをサポートし、複雑な分析クエリ演算子 (計算列、検索とフィルター処理、行、グループごとの集計、結合など) を提供します。

Kusto の概要

 

Kustoクエリとは

Kusto クエリは、データを処理して結果を返すための、読み取り専用の要求です。 要求は、構文を読みやすく、作りやすく、自動化しやすくするように設計されたデータフローモデルを利用してプレーンテキストで述べられます。 クエリでは、データベース、テーブル、列など、SQL に似た階層に編成されたスキーマ エンティティが使用されます。

概要

 

Kustoクエリの使用方法

[crayon-62f0b0241268d300828968/]
  • Kustoクエリにはステートメントが1つありますが、それは表形式ステートメントです。 このステートメントは StormEvents という名前のテーブルの参照から始まっています (このテーブルをホストするデータベースはここでは接続情報の一部として暗に示されるだけです)。
  • そのテーブルのデータ (行)が StartTime 列の値でフィルター処理され、さらに State 列の値でフィルター処理されます。
  • "FLORIDA" 行の数がクエリにより返されます。

Kustoチートシートまとめ

SQLクエリからKustoクエリを使用する際のクエリをまとめています。

SQL から Kusto カンニングペーパー
SQL から Azure Monitor へ

 

LogAnalyticsで実際に使用してみる

別記事でご紹介しているので、参考にしてもらえると幸いです。
別記事リンクは以下になります。

Azure LogAnalytics 概要についてまとめてみた
Azure LogAnalyticsでWindowsServerを監視してみた
LogAnalyticsのデータ取得時間の調査方法

参考情報

Azure Monitor ログ クエリ
Kusto Query Language (KQL) from Scratch
Azure Monitor でログ クエリの使用を開始する

おわりに

Kustoクエリについては、Azure環境にてログや各種リソースメトリックを収集したデータを活用する際に使用するので、自身がよく使うコマンドは覚えておくのが便利です。


【Azure 初心者向け】Azure VM を利用してファイルサーバ構築を検討する

はじめに

Azure のファイルサーバを構築する際に考えられる構成をご紹介します。
特に Azure 仮想マシン(Windows) を利用した場合について解説します。

記事の概要

  • Azure Files を利用した場合のメリットデメリット紹介
  • Azure 仮想マシンを利用した場合でのメリットデメリット紹介
  • Azure 仮想マシンで利用するストレージの解説・接続方法の紹介

Azure でファイルサーバを構築する際の構成

① Azure Files を利用
② Azure 仮想マシン(Windows)を利用

この記事では、上記 2 パターンのうち Azure 仮想マシン(Windows)に焦点をあてご紹介します。

Azure Files を利用した場合

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_229923_32ba6b89-22e4-6f13-cc65-da91592c3013.png

【メリット】

  • ファイル共有の最大サイズが 1TiB
  • 構築が簡単

【デメリット】

  • NTFS による権限設定ができない
  • オンプレミス ドメインのリソースが利用できない
  • 同時アクセス数が多い場合、パフォーマンス低下が懸念される
  • SMB ポート利用が制限されるネットワークでは利用が現実的でない

Azure 仮想マシン(Windows)を利用した場合

【メリット】

  • 既存のオンプレミス環境との互換性が高く、ハイブリッドの構成も可能
  • オンプレミス ドメインのリソースを利用
  • 記憶域プールを構成することで 1 ドライブあたりの容量を最大化できる
  • スループットの変化に柔軟に対応できる
  • 容量の追加が容易
  • Reserved Instance でコストメリットを訴求

【デメリット】

  • 冗長構成をとる場合価格が2倍以上になる(単純に VM が2台構成)
  • ネットワークの構成やストレージの管理など、構築や管理にそれなりのコストがかかる

Azure 仮想マシンで使用するストレージ

Azure 仮想マシンで使用するストレージは、管理ディスクと非管理ディスクの 2 通りが利用できます。

管理ディスクと非管理ディスクでは課金の考え方が異なります。
SSD を利用しない場合は非管理ディスクを選択することでコストメリットが出せる場合もあります。

Azureディスクストレージの種類(2021 年 5 月 12 日現在)

Azure 仮想マシンがサポートするディスクドライブの最大容量は4TBです。
Windows Server の機能である記憶域プールを利用することで、より大容量のドライブを作成することが可能です。
また、使用する VM によりアタッチできるディスク本数が変動します。

下記記事は参考情報です。
Azure の Windows 仮想マシンのサイズ

ディスクを仮想化する記憶域プール機能 (1/3)

Azure VM に大容量ディスクを作ってみる

複数のディスクを利用する場合、
ディスクを配置するストレージアカウントは別々にすることをお勧めです。

同じストレージ アカウントに複数のディスクを配置すると、ストレージアカウントの iOPS 上限の影響を受けパフォーマンスが低下する場合があります。
※管理ディスクにはストレージアカウントの考え方がないため、管理ディスクを利用する場合は考慮の必要はありません。

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_229923_c2bf7d91-f84f-28d0-4803-d2bda5da578b.png

Azure 仮想マシンとの接続方法

オンプレミスのドメインリソースを利用する場合、VPN や ExpressRoute などの閉域回線を利用します。

ExpressRoute は価格は高めですが、送信転送量を料金に含めることで通信にかかる料金を固定できるプランが存在します。
一定以上の帯域を確保する必要がある場合、ExpressRoute の利用がお勧めです。

ExpressRoute の価格

VPN や ExpressRoute を利用する場合、VPN Gatewayが必要になります。

VPN Gateway の価格

冗長構成を組む場合
ファイルサーバーを冗長化するソリューションとして記憶域スペースダイレクトがあります。これは Azure 仮想マシンでも有効です。

ゲスト仮想マシン クラスターで記憶域スペース ダイレクトの使用

※この場合仮想マシンは最低2台、ストレージ容量は 2 倍必要なので、コストも 2 倍になります。

おわりに

Azure 仮想マシン(Windows) を利用したファイルサーバの構成について解説しました。
今回ご紹介した以外にも、Azure では様々な方法で構築することが可能です。
Azure でファイルサーバを検討する際の参考になれば幸いです。


Azure Backup 番外編

こんにちは、kc-dreamです。
今回は、Azure Backup 番外編ということで、スナップショット取得時の挙動について簡単ではありますが、まとめたいと思います。

 

スナップショット/復元ポイントの動作について

Azure Backup のインスタントリストアでは、まずVMディスクのスナップショットを作成し、
ディスクと同じストレージアカウント上に保存します。その後、増分データがRecovery Servicesコンテナーに送られ、保存されます。
このスナップショットは、バックアップポリシーの "インスタント回復スナップショットの保持期間" で決められた日数保持され、その後自動的に削除されます。

スナップショット/復元ポイントの動作については、上記が前提となっております。

  • コンテナーへのデータ転送の終了を待たずに、復旧に利用できるバックアップジョブの一環として取得されるスナップショットを使用できます。 これにより、復元をトリガーする前にスナップショットをコンテナーにコピーする待機時間が短縮されます。
  • スナップショットを既定で2日間ローカルに保持することで、バックアップと復元の時間が短縮されます。 この既定のスナップショット リテンション期間の値は、1 から5日の間の任意の値に構成できます。
  • 最大32TBのディスク サイズがサポートされます。Azure Backupでは、ディスクのサイズ変更は推奨されません。
  • Standard HDDディスクおよび Premium SSDディスクと共にStandard SSDディスクがサポートされます。
  • 復元時に、(ディスクごとの) アンマネージド VM の元のストレージ アカウントを使用できます。この機能は、ストレージアカウント間に分散しているディスクが VM にある場合でも使用できます。さまざまなVM構成で復元操作が速くなります。
  • インスタントリストアでPremium Storageを使用している VM のバックアップについては、割り当てられた合計ストレージ領域の50% の空き領域 (最初のバックアップにのみ必要) を割り当てることをお勧めします。最初のバックアップが完了すると、バックアップに50% の空き領域は不要になります。

復元時間について

スナップショットが削除された復元ポイントからの復元では、Recovery Servicesコンテナーから
バックアップデータの転送に伴い復元に時間がかかります。
※復元対象のデータ容量により変わります。

Azure Backup のインスタント リストア機能を使用してバックアップと復元のパフォーマンスを改善する

復元ポイントについて

復元ポイントは保持期間に従って自動的に管理され、個別に手動で削除することはできません。
復元ポイントおよびバックアップデータを削除するには、VM のバックアップを停止する必要がございます。

VM の保護を停止する - Azure VM のバックアップを管理する

復元可能タイミング

 

image.png
- 上図にあるように①のTake snapshotジョブが完了した時点でBackup自体は完了しているので、VMの復元が可能です。
- ②については、Recovery ServicesコンテナーへBackupデータを転送するため時間(24時間以内完了)がかかります。

おわりに

番外編ということでスナップショット取得時の挙動についてご紹介しました。


Azure Backupの復元方法について

こんにちは、kc-dreamです。
今回はAzure Backupの復元方法についてご紹介したいと思います。
image.png

Azure Backupとは

Azure Backup サービスでは、Microsoft Azure クラウドにデータをバックアップします。 オンプレミスのマシンとワークロード、および Azure 仮想マシン(VM) をバックアップできます。

下記から抜粋
Azure Backup とは

Azure Backupを使用した復元方法

Azure Backupには大きく3種類の復元方法が用意されています。
本記事では3種類の復元方法について簡単ではありますが、ご紹介していきたいと思います。

1,VM の新規作成

Azure VM が新規作成され、復元されたディスクがアタッチされます。
このオプションでは、容易にVMを作成いただける反面、細かな構成の変更を自身で実施する必要があります。

  • バックアップされた VM が静的 IP アドレスを持っていた場合、復元された VM は競合を回避するために動的 IP アドレスを持つことになる。
  • Ubuntu など cloud-init ベースの Linux ディストリビューションを使用している場合、セキュリティ上の理由から、復元後にパスワードがブロックされます。 復元した VM で VMAccess 拡張機能を使用して、パスワードをリセットしてください。
  • VM でドメイン コントローラーとの関係が破損しているために復元された VM にアクセスできない場合は、下記リンクの手順に従って VM を起動します。
  • 復元された VM には可用性セットがありません。 ディスクの復元オプションを使用する場合、提供されているテンプレートまたは PowerShell を 使用してディスクから VM を作成するときに可用性セットを指定することができます。

復元後の手順 - Azure VM の復元

2,ディスクの復元

こちらのオプションでは、ディスクのみが復元されます。
復元されたディスクを利用して、自由な構成のVMを後から作成することができます。

例えば、PowerShell を使用して Azure VM を作成する方法として、
以下の公開情報に記載のような手順を実施いただくことができます。

既存の VHD を管理ディスク (Managed Disk) に変換し、VM をデプロイする
※バックアップ対象が管理ディスクの場合にも、手順 2 に記載のサンプルコードをお役立ていただけるかと存じます。

3,ディスクの置き換えについて

ディスクの置き換えオプションでは、既存の VM のディスクのみが付け替えられます。
このため、VM の設定をすべて引き継ぐことができる、最も簡単な復元方法となります。

VMにアタッチされていたディスクはすべてディタッチされた状態で残り、
新たに復元され作成されたディスクがアタッチされ、VM が起動します。

ディスクの置き換えオプションは現在管理ディスクでのみサポートされております。
その他の制限事項については以下のリンク参照願います。

復元オプション - Azure VM の復元
*既存ディスクの置き換えは、暗号化されていないマネージド VM でサポートされています。
非管理ディスク、汎用化された VM、またはカスタム イメージを使用して作成された VM では、サポートされていません。

おわりに

簡単ではありますが、Azure Backupの復元方法についてまとめたので参考にしていただければ幸いです。
2020-01-08_11h02_53.png


Excel / Azure Notebooks / Databricks で同じことをやってみる #4 【Databricks編】

はじめに

Excel / Azure Notebook / Databricks で同じことをやってみる #1 【はじめに】
Excel / Azure Notebook / Databricks で同じことをやってみる #2 【Excel編】
Excel / Azure Notebooks / Databricks で同じことをやってみる #3 【Azure Notebook編】
に続き、Databricks を用いて簡易集計及び可視化を行います。

Databricksとは?

概要

以前の記事でも取り上げましたが、こんな特徴のデータ分析基盤プラットフォームです。
・Apache Spark環境を数分でセットアップ
-分析環境がすぐに作れる
-スケーラブル
-自動でスケーリング可能
-Sparkを作った人達が、Spark用にカリカリにチューニングしたプラットフォーム
・Notebookをバッチスクリプトとして使える
-例えば、データストリームに対して、Aの処理を一週間に一回かけて、Bのテーブルに追記する、
という処理が必要な場合、Aの処理を記載したNotebookを、バッチジョブとして設定できる
・バージョン管理が楽
-いわゆるタイムマシーン機能が使える
-複数人での作業がしやすい
・マジックコマンドが便利
-デフォルト言語としてPythonを設定しても、セルの頭にマジックコマンド(%sql)でクエリが書ける
・簡単に可視化
-発行したクエリをそのままグラフ化
-別途ライブラリのインポート不要
・オートターミネーションで安心
-クラスタをxx分未使用の場合には停止(=課金されない) といった設定ができる
-高額なクラスタを立ち上げっぱなしで、気が付いたらものすごい課金が…みたいなケースを回避できる
-今回発生した費用のまとめは後述します

設定

こちらのドキュメントを参照いただき、
・Azure Portal へのサインイン
・Spark クラスタの作成
・notebookの作成
まで行ったら準備完了です。

操作のきほん

Notebook自体の操作は、Jupyter Notebookとほとんど同じです。結構直感的に操作できますが、迷ったときは公式ドキュメントを参照しましょう。

データの準備

ストリーミングデータや大規模なテーブルを接続するのであれば、データの保存先は、Blob Storage Gen 2 や Delta Lake が候補になります。
今回は、そこまで大きくないCSVデータx3ですので、Databricksにテーブルを作成します。
ホーム画面の下記の場所に、CSVデータをドラッグアンドドロップ

Create Table with UIをクリック

作成したクラスタを選択し、Preview Tableをクリック

デフォルトだと、列名やスキーマはこのようになっています

First Row is Header オプションで、一行目を列名として読みこみ、Infer Schema オプションの指定でスキーマを類推してくれます。
Create Tableをクリックし、しばらくするとテーブルの作成が完了します。CSVファイル3つそれぞれでこれらの作業を行います。

Data タブをクリックすると、テーブルを確認できます。

やってみる

流れ

Azure Notebookの回でやったように、Sparkで中間テーブルを作成します。
そこから先は、SQLオンリーでグラフ化まで行います。

手順

PySparkのライブラリをインポート。今回の用途であればこれだけでOK
[crayon-62f0b02412e8b469755503/]
先ほど作成したテーブルの名称を変数に格納
[crayon-62f0b02412e92851553799/]
それぞれのテーブルをSparkで読み込み
[crayon-62f0b02412e94304613849/]
テーブル結合のために、必要な列名を確認しておきます (結果は省略)
[crayon-62f0b02412e96013393914/]
中間テーブル (name: sql_tbl) を作成します。コードは#3 Azure Notebookの回で説明したものと同じです。
[crayon-62f0b02412e98216980838/]
ここからは全部SQLで記載していきます。%sqlとセルの頭に入れれば、SQL文として処理してくれます。結合処理を再度行うのは面倒なので、このテーブルは永続化しておきましょう。一時テーブルで良いときは、CREATE TABLE を CREATE OR REPLACE TEMPORARY VIEW AS にすればOK
[crayon-62f0b02412e9a228385152/]
以下で中間テーブルのスキーマが確認できます
[crayon-62f0b02412e9c786538825/]
結果

集計後テーブル (name: sql_tbl2) を作り、永続化させます。
[crayon-62f0b02412e9e252421961/]
集計後テーブルに対してクエリを発行します。可視化した時に同じくらいのスケールに収まるように、送料の割合を1000倍しておきます。
[crayon-62f0b02412ea0473770446/]
結果はこちら。デフォルトだと表が出力されます。下のボタンでクエリの結果をそのまま可視化可能。

こんな感じです。アドホックな分析にとても便利!

費用

料金体系

クラスターの起動時間に応じて、分単位で、以下のマシンリソースに対して課金されます。 (詳細はこちら)

料金表だけを見ていると意識に上がりずらいのですが、Databricks Unit には Driver とWorkerの2タイプがあり、クラスタを立ち上げると両方が起動され、課金されます。それぞれにインスタンスを割り当てて処理をしてもらうわけですが、当然、性能の高いインスタンス(= 高いDBU値) ほど、高コストになります。
今回使用したのはもっとも安価な 0.5 DBU のインスタンス。

今回の費用概算

今回の簡易分析・可視化で、どのくらいの費用が発生したか概算してみましょう。以下は今回使用したクラスタの設定画面。費用に大きく響いてくるところなので、本格的に分析基盤を立ち上げる際には、分析対象と内容に応じて、必要十分な計算資源を割り当てるように留意する必要があります。

設定は以下の通り。
クラスタのJob履歴を見てみたところ、Workerのスケーリングはしなかったようなので、クラスタの起動中は、0.5 DBU + 0.5 DBU で合計 1 DBU 使ってる計算になります。
・リージョン: 米国西部 2
・ワークロード:データ分析
・レベル:Standard
・Driverタイプ:F4s (0.5 DBU)
・Workerタイプ:F4s (0.5 DBU)
・最小ワーカー数: 1
・最大ワーカー数: 4
・自動停止
・15分操作がなかったらクラスタを停止
分単位の課金なので、Cluster の Event Log から、ここ2日間で何分間クラスタを起動したかざっくり見てみます。3回起動/停止しているようです。合計約70分。

Databricks の料金表を参照し、70分間インスタンスを起動した今回の費用概算と、仮に48時間インスタンスを立てたままにした場合の料金を比較してみました。
当たり前ですが、オートターミネーションした場合と継続利用では、かなりの金額差がありますね。

分析プラットフォームサービスは、どうしてもマシンスペックでの比較がされやすい傾向にあります。
しかし、実運用に則して考えると、Databricks の費用対効果の高さはピカイチじゃないかと思います。

まとめ

さいごにDatabricksの長所をおさらい。
・すぐApache Spark環境を作れる
・Notebookをバッチスクリプトとして使える
・バージョン管理が楽
・マジックコマンドが便利
・簡単に可視化
・オートターミネーション
アドホックな分析をするなら、SQLをそのままかけて、すぐに可視化できて、クラスタのオートターミネーションが利用できる Databricks が最高に便利。

おわりに

Databricks、簡易的な可視化ならできるけど、ちょっと凝ったグラフは?BIとの接続は?
ということで、次回は DatabricksPower BI につなげてみようと思います。お楽しみに!

参考サイト

クイック スタート: Azure portal を使用して Azure Databricks 上で Spark ジョブを実行する
Databricksで分析業務がはかどっている話
平成最後の1月ですし、Databricksでもやってみましょうか

 

 

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

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

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

 

 


Excel / Azure Notebooks / Databricks で同じことをやってみる #3 【Azure Notebook編】

はじめに

前回行ったExcelでの簡易集計と可視化を、Azure Notebooksでやってみます。

Azure Notebooksとは?

概要

データ分析プラットフォームのデファクトスタンダード、Jupyter Notebookをクラウド環境で起動できるAzureサービスです。他にはGoogle Colaboratoryが有名ですね。
ローカルでJupyter Notebookを使う場合、環境構築でつまづくこともしばしば。クラウドであればそのあたりほんと楽です。
・数ステップでAzure上に環境設定可能
・クラウド上で共同作業可能
・メモリ4GB, ストレージ1GBまで無償
Notebookはデータサイエンティストやアナリスト専用のものではありません。
分析に都合のいいプラットフォームがそろってて、メモ書きが残せて、みんなとシェアできる、いい感じに使いやすい "ノート" だと考えて、身構えずに触ってみましょう。

インストール

まずはAzure Notebookをセットアップします。 手順はこちら。Microsoftアカウントがあればすぐに数ステップでできます。

操作のきほん

初めてNotebookに触れる人のために、基本操作とショートカットをご紹介します。
セルを選択、コード入力後、Shift + Enterでそのセルのコードを実行できます。

セルの中を選択すると、枠が緑色になりEdit Modeに、セルの外を選択すると、枠が水色になりCommand Modeになります。

モード切り替えは、escとenterでも可能。

Command Modeで、mを押すとセルをMarkdownモードに、yを押すとcodeモードにできます。

これでMarkdownのメモが残せます。

Command Modeでaを押せば上に、bを押せば下にセルを追加可能。xで削除。

Command Mode時に、上下カーソルでセルを移動できます。
編集したいセルでenterを押せば、対象セルのEdit Modeに遷移。

作業をチェックポイントとして保存したいときは、ctrl + sを押します。これでいつでもそのポイントに戻れます。

特定のセルだけ実行されないようにしておきたいな、という時はctrl + / でコメントアウトしておきます。

他にもショートカットはたくさんあります。一覧表はHelpを参照しましょう。

あとは触りながら覚えていけばOK。

データの準備

Brazilian E-Commerce Public Dataset by Olistから、データをダウンロード、解凍しておきます。

Azure Notebook を立ち上げ、作成した Notebook と同じディレクトリで、UploadタブのFrom Computerを選択

以下の画面に遷移するので、解凍先のフォルダにあるCSVデータを、ドラッグアンドドロップ。

Uploadを押して、しばらく待ちます。Notebookと同じディレクトリにCSVファイルがアップロードされてれば完了です。

流れ

データの操作の定番といえば Pandas ですが、興味本位で Databricksとの比較してみたいので、並列分散処理フレームワークである PySpark を用いて中間テーブルを作成します。
そこからSQLで必要な集計処理を行い、最後に可視化のためのライブラリを使って、グラフを描画します。

手順

以下のスクリプトをNotebookのセルに入れ、実行していきます。
まずはPySpark関連のライブラリをインポート。
[crayon-62f0b02413797256377296/]
次に、Sparkのコンストラクタの作成。
正直言ってこのコードが何をしているのか良くわかっていないのですが、このコンストラクタが後述のスクリプトを良しなに処理してくれるようです。
[crayon-62f0b0241379e410668874/]
アップロードしたCSVファイル名を変数に放り込んでおきます。
[crayon-62f0b024137a0469662810/]
CSVファイルをSparkに読み込ませます。上から、売上テーブル、製品テーブル、翻訳テーブル。ちょっと時間がかかります。
[crayon-62f0b024137a2540070960/]
テーブル結合のために、製品テーブルの product_id の名称を product_id2 に変更。
[crayon-62f0b024137a4961447346/]
テーブル結合のために必要な列名を確認しておきます (結果は省略)
[crayon-62f0b024137a6853939449/]
中間テーブルを作成します。※備考参照のこと
[crayon-62f0b024137a7823204774/]
作成した中間テーブルのスキーマを確認します。(これも結果省略)
[crayon-62f0b024137a9685904562/]
このテーブルに対してSQLを発行し、売上のTop10カテゴリを抽出、pandas_dfに変換後、平均単価で並べ替えします。こんな形でそのままクエリが書けるのは便利ですね。
[crayon-62f0b024137ab243734893/]
可視化のためのライブラリをインポート。
[crayon-62f0b024137ad141375914/]
グラフを描画。
[crayon-62f0b024137af337311120/]
出力されるグラフデータはこちら

pros

・ビジネスロジックが埋もれにくい
・どの処理をどんな順番で行うのか明確になる
・Markdownでメモ書きも残せて第三者にもフレンドリー
・意外と習得コストが低い
・今回はPySparkを使ったので参考資料は少ないものの、pandasであれば、たくさんの参考資料あり
・SQLも然り
・環境構築が簡単
・クラウドのNotebookの最大の利点
・違うPCでもアカウントにログインさえできれば同じように動作する

cons

・バージョン管理が大変
・チェックポイントを設けることはできますが、コードを書きたいときにわざわざこれをやるか、というと私はやりません。ちょっと面倒ですがコメントアウトで対応することが多いです。
・可視化に要する工数が大きい
・グラフの成型には結構な手間がかかります。今回はカテゴリの選定なので本来はそこまで凝ったグラフは必要ないのですが、ついいろいろ手を出してしまい、時間を費やしてしまいました(自戒)

まとめ

Azure Notebooksはすごく便利ですが、Jupyter Notebookをそのままクラウドに持ってきたというコンセプトなので、運用という意味では課題がいくつかあるように感じられます。次回はDatabricksでやってみます。お楽しみに!

参考サイト

Kaggle.com
Brazilian E-Commerce Public Dataset by Olist
Class SparkContext

備考: 中間テーブル作成時のPySparkコード

備忘録がてらまとめました

 

 

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

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

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