SQL Azure

redash で、データソースにSQL Serverを選択し、Azure SQL Databaseに接続しようとすると以下のようなエラーが出ることがあります。

Cannot open server “1433D” requested by the login. The login failed.DB-Lib error message 20018, severity 20: General SQL Server error: Check messages
from the SQL Server DB-Lib error message 20002, severity 9: Adaptive Server connection failed (xxxxxxxxxxxxx.database.windows.net:1433)

これは、SQL Server とは違って、Azure SQL Databaseの実装上の違いによって生じています。SSMSであれば、明示的に指定しなくても自動的に裏側でしれくれるのですが、redashの場合には明示する必要があります。

接続先サーバー名が、xxxxServerName.database.windows.net と仮定すると、
Userには、「analysis@xxxxServerName」のように指定する必要があります。

もちろん、analysisの部分はあなたのDBのログインに置き換えてください。太字のように、@以下にサーバーのホスト名を指定します。

datafactory

Azure Data Factory v1 で作成したジョブを日次バッチで動かすときの罠について説明します。

Azure Data Factory v1 でのトリガータイミングの指定画面は次のようになっています。

この画面では、Dailyでevery 1 day となっています。
Start date time (UTC)を指定するようになっています。

罠1 画面で日時(Daily)を選択すると必ずUTC12時に実行される

この画面だけ見ると、Start date time (UTC)で指定した時間に実行され、以後24時間おきに実行されるように見えます。

実際は、UTC12時、日本時間朝9時に実行されます。

ドキュメントを確認すると、以下のように記述されています。

既定では、毎日 ("frequency": "Day", "interval": 1) のスライスは UTC 時 12 AM (午前 0 時) に開始します。 開始時刻を 6 AM UTC にするには、次のスニペットに示すようにオフセットを設定します。

GUIで設定すると、Dailyの場合は必ず、UTC0時なので日本時間9時になります。
これを変更するには、Offsetを指定しないといけないのですが、画面からは指定できなくて、JSONを修正する必要があります。

罠2 JSON(Availability)を更新して、offsetを追加しようとするとサポートしてないとエラーがでる

offsetを指定して更新しようとすると、次のようなエラーが出ます。

Updating the availability section of a Dataset is not supported. Existing availability configuration: Frequency=Day, Interval=1, AnchorDateTime=01/01/0001 00:00:00, Offset=06:00:00, Style=StartOfInterval, new availability configuration: Frequency=Day, Interval=1, AnchorDateTime=01/01/0001 00:00:00, Offset=07:00:00, Style=StartOfInterval.

機能提供されていませんよと……なんとまぁ。
ちなみに大昔に改善要望が出ています。

How can we improve Microsoft Azure Data Factory?

現時点で対応されていないですし、きっと今後も対応されないでしょうね。
設定するには、再作成してねっと案内されています。
The work-around is to delete the datasets and related piplelines and re-create them with the new settings. 

罠3 availabilityにOffsetを追加したら、activitiesのschedulerにも追加しないといけない

仕方ないので、Outputを消して再作成して、Offsetを追加しました。
すると今度は、PipelineのactivitiesのschedulerにもOffsetを追加しないとエラーになりました。

罠4 Start date time (UTC)に過去日を指定すると、そこを起点にスライスされて、複数処理されてしまう

再作成するから、オリジナルをコピペするじゃないですか?
そーすると当然StartTimeが以前の古い日付になってるじゃないですか?
怖いことが起こりそうです。

パイプラインには過去の開始日を設定できます。 設定した場合、Data Factory によって過去のすべてのデータ スライスが自動的に計算 (バックフィル) され、処理が開始されます。 たとえば、開始日が 2017-04-01 のパイプラインを作成し、現在の日付が 2017-04-10 だとします。 出力データセットのパターンが 1 日ごとの場合、開始日が過去であるため、Data Factory は 2017-04-01 から 2017-04-09 までのすべてのスライスの処理をすぐに開始します

 

やめて、、、、、事故になる(汗
再作成するときには、ちゃんと、Pipelineの「Start」を適切な日付にしましょう。

結論 V2素晴らしい

これがV2のトリガーの指定画面です。
日次で何時に実行するかというのがしっかりと指定できます。素晴らしい。

datadog

DatadogのAzure Integuretaionが強化され、Cosmos DB、Service Bus、Azure DB for MySQL / PostgreSQLなど60以上のAzure サービスに対応しました。Datadogは一つのインテグレーションでAzure統合監視を提供するために、Azure Monitorでサポートしている全てのサービスからタグとメトリックスを自動的に収集します。Azure Service Fabricにも正式に対応しました。DatadogのAzure VMエクステンションがService Fabricの自動スケールノード上で直接Datadogエージェントのデプロイを可能にしました。

既存でサポートしていたサービス、Azure ClassicとARM仮想マシンAzure SQL DatabaseAzure App Serviceの上に追加で強化されました。Microsoft IISやWindows Management Instrumentationとの統合により、幅広いWindowsとWindowsエコシステムを可視化します。

タグ付けの改善

Azure Monitorの多次元メトリックが時系列データとして一つ以上の次元と属性を取得できます。それらのデータをDatadogインテグレーションはタグとして取得し、slice、group、フィルターを可能にします。

例えば、Blobストレージへのリクエスト数を追跡するTransactionsメトリックスでは、Azure Monitorは、ResponseType、GeoType、APINameを返します。

Datradogは自動的に、メトリックをkey:value形式に変更します。(例 responsetype:success)それらのタグを使用して、ダッシュボードやアラートでAzureインフラについて深い見識を得るのに使用できます。

次の例では、Blobストレージアカウントでトランザクション数を取得し、API名とレスポンス種類でブレイクダウンできます。

Azureは、REST API、Azure CLI、PowerShell、Azureポータルからリソースにkey:valueタグを設定できます。

Datadogは自動的にカスタムタグを収集し、それらをメトリックと関連付け、フィルターやグルーピングしてグラフやアラートを作成するのに使用できます。

datadog

Microsoftは最近、デプロイ、実行、スケールするKubernetesクラスターをマネージドサービスである、Azure Kubernetes Service(AKS)をリリースしました。追加設定不要でAKSインフラの総合的可視化をAzure MonitorとKubernetes のDatadogインテグレーションで実現できることを紹介します。

Datadogのインテグレートは、ヘルス状態、Docker、Kubernetes、Azure VMのリソースメトリックスを一つのスクリーンボード上で、簡単に可視化できます。

AKSでの動作方法

AKSは、Kubernetesクラスターを自動的にプロビジョニング、メンテナンス、スケールさせます。クラスター内のマスターノードを管理し、独自のコンテナーアプリケーションを、Azure VMノード、永続化ストレージ、仮想ネットワークのトラフィックルーティングなどに対応して実行します。
クラスターをスケールまたはアップグレードすると、AKSは確実に起動する処理を実施します。一つ以上の可用性セットにノードを配置すれば、各ノードで障害が発生してもアクセスができるように維持します。

クラスター用にAKSが自動的に作成したリソース

新しいAKSクラスターを作成すると、既存のリソースグループか新しいリソースグループに、必要なリソースが追加されます。Azure CLIを使用してAKS詳細を管理できるようkubeconfigファイルに書き込みます。一度、クラスターが起動すれば、kubectlやKubernetesダッシュボードでマニフェストの適用や管理タスクを処理できます。

AKSをDatadogで監視する

Kubernetes、Azure、コンテナーインフラ上で動作している全てのサービスからログと分散リクエストトレース、メトリックスを収集して、AKSのフル可視化をDatadogが可能にします。

AKSをDatadogで監視を始めるために、AzureとKubernetesのインテグレーションを設定する必要があります。Datadogが提供するYAMLマニフェストを使用してAKSクラスター内に、デーモンセットとしてDatadogエージェントをコンテナー化してデプロイします。AzureポータルとDatadog UIからAzureでDatadogに接続します。

Datadogエージェントの自動ディスカバリー機能がAKSで動かしているサービスとpodをトレースし続けます。

自動タグ付け

Datadogで、ほかの250種類以上に対応している監視できるテクノロジーと同じ場所で、AKSクラスターを監視できます。Datadogは自動的にリソースグループ、Kubernetes pod、Docker imageを含むAzure、Docker、Kubernetesからタグを取得します。AKSクラスターからデータを見るためにタグを使用できます。上の例では、Kubernetesサービス名とAzureリソースグループでフィルタリングして、クラスター内のコンテナーに出入りするネットワークトラフィックを比較しています。

コンテナーのヘルス状況概要をタグ(pod、可用性ゾーン、リソースグループなど)でグルーピングして、ダッシュボードにコンテナーマップとして追加できます。AKSクラスターがユーザーの行動や変化や、需要変化に応じてコンテナーのスケールアップ/ダウンをすると、自動的にコンテナーマップもリアルタイムにアップデートされて反映されます。

Kubernetesデプロイメントマニフェストの変更を反映するためにDatadogのコンテナーマップが更新される様子

ライブコンテナーとプロセス

数百から数千のコンテナーをKASで動かしている場合、DatadogのLive コンテナービューが、デプロイから流入するすべての運用データを素早く調べるのに役立ちます。Liveコンテナービューはリアルタイムにヘルスやリソース状況、すべてのクラスターのステータスなどAKSクラスターに関する情報を提供します。リソースメトリックスやグラフは、簡単にCPU使用率が高いや、メモリ使用率が高いコンテナーを探しだせます。

次の例では、resource_groupタグを使用して、特定のAKSクラスターを選択し、Kubernetesタグ「kube_service」でドリルダウンして、アプリケーションのフロントエンドサービス用のコンテナーのみを表示しています。

ライブプロセスモニタリングを設定すれば、ライブコンテナービューでプロセスやサブプロセスの階層関係を見たり、リソースをどれぐらい使用しているかを見ることができます。

SQL Azure

SQL Azure Database で、巨大テーブルのユニーク数の概算を取得するのに役立つ関数「APPROX_COUNT_DISTINCT」の一般プレビューがリリースされました。(紹介Blog

SELECT COUNT(DISTINCT())

使用例としては、一千万行ぐらいのテーブルで、ダッシュボード表示用にCOUNT(DISTINCT())する場合が考えられます。
このケースで重要なは正確な数字ではなく、データ取得までの応答速度です。

「APPROX_COUNT_DISTINCT」は、NULLではないユニークな数の概算を取得する関数です。

「APPROX_COUNT_DISTINCT」は、大きなデータで使用する前提で設計されていて、次のようなケースに最適化されています。

  • 数百万行以上のデータにアクセスする場合
  • 多数の異なる値を持つ列をカウントする場合

この関数は、通常の使用用途では2%以内の精度を維持しつつ、かつどんなに稀な使用例でも悪くても20%以内の精度を維持されるべきだと考えています。

設計ポイント

「APPROX_COUNT_DISTINCT」は、非常に少ないメモリ使用量で算出できるように設計されています。COUNT DISTINCTで、メモリ内にデータが収まりきらずTempDBを使用して算出するケースでは、優位になります。「APPROX_COUNT_DISTINCT」は、基本的にTempDBを使用して算出することはありません。

Q & A

  • 「APPROX_COUNT_DISTINCT」でクエリは高速化しますか?
    • 対象データによります。メモリに最適化しているので、メモリ内に収まりきらない場合には、かなりの応答優位性を発揮します。
    • メモリ内で収まる場合には、あまり差がありません。
  • 精度が2%に収まらない最悪のレアケースでは、どれぐらいの精度になりますか?
    • 20%以内に収まるべきと考えています。
  • 実行プランへの影響は?
    • COUNT(DISTINCT)では、Hash MatchとSort操作がはいります。INDEX SCANは95%程度ですが、「APPROX_COUNT_DISTINCT」では、98%の時間がINDEX SCANです。

 

実装方法

実装に採用されているアルゴリズムについて教えてもらったので追記しておく。
OracleやRedis、Redshifにも同様の関数があって、それらは「HyperLoglog」が使用されているので、Azure SQL Databaseでも恐らくそれだろう。

オリジナル論文は、2007年に公開されている。
なんとなく理解をするのなら、「HyperLoglogでcount distinctを速くする」を参照するとなんとなく理解できたような気ができる。