はじめに
本記事はDatabricks認定資格試験に始めて取り組む方を対象として、試験対策を効率よく行うための個人的なメモ書きをまとめたものです。Databricksではさまざまな認定資格試験を提供していますが、本記事ではDatabricks Certified Data Analyst Associateを例にして解説していきます。
試験対策のリソース
まずは、試験対策に使うリソースを記載します。以下はいずれも公式が提供しているもので、無料で利用できます。これらを中心に対策を行なっていきます。Udemyなどで有料かつ質の高い解説や問題集もありますが、そちらはお好みでお使いください。
| No. | リソース | Data Analytst Assosiateの場合 |
|---|---|---|
| 1 | 認定試験の概要ページ | Databricks Certified Data Analyst Associate |
| 2 | Exam Guide (PDF) の中段にあるExam Outline | Data Analyst Associate Exam Guide |
| 3 | Databricks AcademyのEラーニング | Data Analysis with Databricks SQL (Databricks Academyに登録すれば無料で受講可能) |
| 4 | 公式ドキュメント | (Azure) Azure Databricks のデータ ウェアハウスとは (AWS) Databricksでのデータウェアハウジングとは (Google Cloud) Databricksでのデータウェアハウジングとは |
試験対策の流れ
個人的にオススメな試験対策の流れは以下の通りです。上の試験対策のリソースはData Analytst Assosiateのものを書いていますが、他の認定資格試験であっても同様の流れで対策できると思います。
| No. | 概要 | 説明 |
|---|---|---|
| 1 | 試験の全体像を把握 | 認定試験の概要ページで試験の全体像を理解します。 |
| 2 | 試験範囲を確認 | 概要ページにあるExam GuideのPDFを参照し、「Exam Outline」セクションにいわゆる試験範囲がまとまっていますので、ざっと眺めてみて自身の理解度をチェックします。 |
| 3 | 理解度が低い内容を中心に学習 | Databrcisk AcademyのEラーニングや公式ドキュメントを利用して、理解度が低い内容を重点的に学習します。 |
| 4 | 知識のセルフレビュー | 学習後、再度Exam Outlineに戻り、どれぐらい知識が付いたかをセルフレビューします。この際にExam Guide (PDF) の最下段の模擬試験を解いてみて理解度を確認するのも良いと思います。 |
| 5 | 試験申し込み | 自信がつくまで3と4を繰り返し、問題なければ認定試験の概要ページから試験に申し込みます。 |
上記の2,3,4についてお好みのエディタを使ってメモをまとめていくと、試験直前の振り返りに使えて良いと思います。また、ドキュメントでよくわからない点の確認などにChatGPTなどのLLMを壁打ち相手として使うのも良いでしょう。
短いですが、本記事で言いたいことは以上です。
おまけ: Data Analyst Associate 試験対策の実際のメモ
以降はおまけとしてExam Outlineに沿ってData Analyst Associateの試験対策を行った際のメモ書きを記載します。
Section 1: Databricks SQL
1-1
Describe the key audience and side audiences for Databricks SQL.
Databricks SQLの主要な対象者とサイド対象者を説明します。
主要な対象者はデータアナリスト
サイド対象者としてデータエンジニアやデータサイエンティスト、さらにデータに基づく洞察が必要なビジネスアナリストやマネージャーが含まれる
1-2
Describe that a variety of users can view and run Databricks SQL dashboards as stakeholders.
様々なユーザーがステークホルダーとしてDatabricks SQLダッシュボードを表示・実行できることを説明します。
ノートなし
1-3
Describe the benefits of using Databricks SQL for in-Lakehouse platform data processing.
Lakehouseプラットフォームでのデータ処理にDatabricks SQLを使用する利点を説明します。
データの統合性の向上、クエリの高速化、複雑なデータ分析作業の簡素化、ANSI準拠の標準的なSQLを利用できる etc.
1-4
Describe how to complete a basic Databricks SQL query.
基本的なDatabricks SQLクエリの完成方法を説明します。
SQL Editorを使ってクエリを作成、ウェアハウスを指定してクエリを実行する
1-5
Identify Databricks SQL queries as a place to write and run SQL code.
SQLコードを記述・実行する場所としてDatabricks SQLクエリを特定します。
- SQL Editorを使ってクエリを記述・実行する
- クエリをワークスペースの任意の場所に保存できる
- 保存したクエリはワークスペースから開くか、Queriesから開ける
- QueriesではMy queriesやFavorites, Trashes, All quriesで絞り込める
1-6
Identify the information displayed in the schema browser from the Query Editor page.
クエリエディタページからスキーマブラウザに表示される情報を特定します。
以下の情報が表示される
- カタログ
- スキーマ
- テーブル
- カラム
1-7
Identify Databricks SQL dashboards as a place to display the results of multiple queries at once.
複数のクエリ結果を一度に表示する場所としてDatabricks SQLダッシュボードを特定します。
上記の通り、Databricks SQLダッシュボードで複数のクエリ結果を一度に表示できる
1-8
Describe how to complete a basic Databricks SQL dashboard.
基本的なDatabricks SQLダッシュボードの完成方法を説明します。
クエリの結果を利用してビジュアライゼーションを作成し、それらをダッシュボード上に配置する
1-9
Describe how dashboards can be configured to automatically refresh.
ダッシュボードを自動的に更新するように設定する方法を説明します。
分、時、日、週、月単位でスケジュール設定できる
例えば日の場合、何時何分に実行するかを設定できる
Cronの書式も使える
More optionsではSchedule nameと更新に使用するウェアハウスが選べる
更新されたダッシュボードのスナップショットを指定されたメールアドレスに任意のタイトルで配信できる
作成したスケジュールは一時停止（Pause）ができる
スケジュールについてもアクセス制御が設定できる
メールアドレスに送信される内容は以下の形式
1-10
Describe the purpose of Databricks SQL endpoints/warehouses.
Databricks SQLエンドポイント/ウェアハウスの目的を説明します。
SQLエンドポイントは旧称、現在の名称はウェアハウス
SQLとBIに最適化された計算資源、必要に応じて任意の数を作成できる
以下はウェアハウスの詳細設定画面
クラスターサイズは2X-Smallから4X-Largeが選べる（Tシャツサイジング）
Cost optimized（すべてのワーカーをスポットインスタンスでの起動を試行）、Reliability optimized（すべてのワーカーをオンデマンドインスタンスで起動）が選べる
1-11
Identify Serverless Databricks SQL endpoint/warehouses as a quick-starting option.
サーバレスDatabricks SQLエンドポイント/ウェアハウスをクイックスタートオプションとして特定します。
DBSQLサーバーレスは10秒以内で起動するためクイックにクエリを実行できる
サーバーレスのAuto stopの最小値は5分（Classic、Proは最小10分）
サーバーレスではCost optimizedの選択肢が出ない
1-12
Describe the trade-off between cluster size and cost for Databricks SQL endpoints/warehouses.
Databricks SQLエンドポイント/ウェアハウスのクラスターサイズとコストのトレードオフを説明します。
- クラスターサイズを上げると処理能力とコストが上がる
- クラスターサイズを下げると処理能力とコストが下がる
1-13
Identify Partner Connect as a tool for implementing simple integrations with a number of other data products.
他のデータ製品との簡単な統合を実装するツールとしてPartner Connectを特定します。
左メニュー下部のPartner Connectをクリック
多数のパートナーソリューションが選べる
1-14
Describe how to connect Databricks SQL to ingestion tools like Fivetran.
Fivetranのような取り込みツールにDatabricks SQLを接続する方法を説明します。
Partner connectからFivetranを選択
ウェアハウスとカタログを選択
先ほど選んだカタログへのデータ取り込みに使うためのPersonal Access Tokenが自動作成されFivetranに連携される
メールアドレスと接続設定詳細を確認
Fivetranに遷移するのでパスワード設定
FivetranでDestinationを見るとSQLウェアハウスが設定されている
1-15
Identify the need to be set up with a partner to use it for Partner Connect.
Partner Connectを使用するためにパートナー設定が必要であることを特定します。
特定のサービスやツールと連携するためには、事前にパートナーシップの設定が必要になる場合があります。
1-16
Identify small-file upload as a solution for importing small text files like lookup tables and quick data integrations.
ルックアップテーブルや迅速なデータ統合のための小さなテキストファイルをインポートするソリューションとして小ファイルアップロードを特定します。
左メニューから [New] > [File upload] を選択
アップロードするファイルを選択
カタログ、スキーマ、テーブル名、ウェアハウスを設定してテーブルを作成
Deltaテーブルが作成される
1-17
Import from object storage using Databricks SQL.
Databricks SQLを使用してオブジェクトストレージからインポートします。
[New] > [Add date]を選択
Azure Data Lake Storageを選択
External locationとして登録したADSLのパスが選べる
ファイルを指定して[Preview table]をクリック
あとはインポートと同じ流れでDeltaテーブルを作れる
緑のしおりのようなマークがついたアイコンを押すとデータ取り込みのノートブックのテンプレートが作成されるので接続情報などを設定して使える
1-18
Identify that Databricks SQL can ingest directories of files of the files are the same type.
Databricks SQLが同じタイプのファイルのディレクトリを取り込むことができることを特定します。
ディレクトリを指定した取り込みも可能
複数ファイルを指定した取り込みも可能
1-19
Describe how to connect Databricks SQL to visualization tools like Tableau, Power BI, and Looker.
Tableau、Power BI、Lookerのような可視化ツールにDatabricks SQLを接続する方法を説明します。
Partner connectからDBSQLウェアハウスへの接続情報が定義されたファイルをダウンロードできる
1-20
Identify Databricks SQL as a complementary tool for BI partner tool workflows.
BIパートナーツールのワークフローを補完するツールとしてDatabricks SQLを特定します。
ノートなし
1-21
Describe the medallion architecture as a sequential data organization and pipeline system of progressively cleaner data.
メダリオンアーキテクチャを、徐々にクリーナーなデータへと進化する連続的なデータ組織とパイプラインシステムとして説明します。
この図が典型的
1-22
Identify the gold layer as the most common layer for data analysts using Databricks SQL.
データアナリストがDatabricks SQLを使用する際に最も一般的なレイヤーとしてゴールドレイヤーを特定します。
ゴールドレイヤーは、ビジネスレベルの集計やダッシュボード用の整理が行われたテーブル
ビジネスアナリストが高頻度に利用するのがゴールドレイヤーのテーブル
1-23
Describe the cautions and benefits of working with streaming data.
ストリーミングデータを扱う際の注意点と利点を説明します。
ストリーミングデータの活用により素早い意思決定を実現できるのが利点
DBSQLウェアハウスはストリーミングデータ非対応、ストリーミングデータはDLTなどを使って取り込むのがベター
1-24
Identify that the Lakehouse allows the mixing of batch and streaming workloads.
Lakehouseがバッチ処理とストリーミング処理のワークロードを混在させることを可能にすることを特定します。
Spark構造化ストリーミングはバッチ処理とほとんど変わらない文法でストリーミングデータを処理できる
DLTは構造化ストリーミングをベースに、宣言的なSQL/Pythonの記法でバッチとストリーミングデータの両方を処理できる
Section 2: Data Managmeent
2-1
Describe Delta Lake as a tool for managing data files.
データファイルを管理するツールとしてのDelta Lakeを説明します。
Delta Lakeは、ACIDトランザクション、スケーラブルなメタデータ処理、およびデータの整合性保護を提供する、オープンソースのストレージレイヤー
これにより、データレイク上での信頼性の高いデータ管理が可能になる
2-2
Describe that Delta Lake manages table metadata.
Delta Lakeがテーブルメタデータを管理することを説明します。
Delta Lakeは、テーブルのスキーマ情報やパーティション情報などのメタデータを管理し、データの整合性を維持しながら効率的な読み書きを可能にする
2-3
Identify that Delta Lake tables maintain history for a period of time.
Delta Lakeテーブルが一定期間履歴を保持することを特定します。
Delta Lakeは変更データの履歴を保持し、時間をさかのぼってデータを調査したり、特定の時点の状態に復元することが可能
DESCRIBE HISTORYコマンドで履歴を確認できる（カタログエクスプローラーからも同様の履歴確認が可能）
SELECT ... VERSION AS OF Nで指定したバージョンのテーブルをクエリできる
RESTORE TABLE customers TO VERSION AS OF 1;などのクエリで過去のバージョンに戻せる
2-4
Describe the benefits of Delta Lake within the Lakehouse.
Lakehouse内でのDelta Lakeの利点を説明します。
Delta Lakeは、データレイクとデータウェアハウスの機能を組み合わせたLakehouseアーキテクチャにおいて、データの信頼性、品質、およびパフォーマンスを向上させる
2-5
Describe persistence and scope of tables on Databricks.
Databricks上のテーブルの永続性とスコープを説明します。
Databricksでは、テーブルはマネージドテーブルとアンマネージドテーブル（今は外部テーブルと表現する方が多い気がする）の形で永続化され、それぞれがデータの格納場所とライフサイクル管理において異なる振る舞いをする
他にも一時ビュー（セッション内でのみ有効）、ビューなどがある
2-6
Compare and contrast the behavior of managed and unmanaged tables.
マネージドテーブルとアンマネージドテーブルの振る舞いを比較し対比します。
マネージドテーブルはDatabricksによってメタデータとデータが管理され、テーブルの削除時にデータも削除される
アンマネージドテーブルでは、データの場所を指定し、テーブルの削除がデータを削除しないことが特徴
2-7
Identify whether a table is managed or unmanaged.
テーブルがマネージドかアンマネージドかを特定します。
テーブルの作成時にLOCATIONキーワードの有無でマネージド（LOCATION指定なし）かアンマネージド（LOCATION指定あり）かを判断できる
DESCRIBE EXTENDEDコマンドの結果のTypeでも判別できる
カタログエクスプローラーのDetailsでも判別できる
2-8
Explain how the LOCATION keyword changes the default location of database contents.
LOCATIONキーワードがデータベース内容のデフォルトの場所を変更する方法を説明します。
LOCATIONキーワードを使用することで、テーブルデータの格納場所をデフォルトの場所からユーザーが指定した場所に変更できる
以下はクエリ例
CREATE TABLE temporary_schema.simple_table_external (width INT, length INT, height INT)
LOCATION 'abfss://demo@hinakstejppub1.dfs.core.windows.net/dummy_data/simple_table_external';
DESCRIBE EXTENDEDするとTypeがExternalになっていることがわかる
2-9
Use Databricks to create, use, and drop databases, tables, and views.
Databricksを使用してデータベース、テーブル、ビューの作成、使用、削除を行います。
CREATE USE DROP で行える
2-10
Describe the persistence of data in a view and a temp view
ビューとテンポラリビューのデータの永続性を説明します。
ビューはデータベースに永続的に存在し、テンポラリビューはセッションが終了すると消去される
2-11
Compare and contrast views and temp views.
ビューとテンポラリビューを比較し対比します。
ビューはデータベーススコープで定義され永続的、テンポラリビューはセッションスコープであり、セッション終了時に削除される
2-12
Explore, preview, and secure data using Data Explorer.
Data Explorerを使用してデータを探索、プレビュー、保護します。
カタログエクスプローラーでデータのプレビューやアクセス権の管理などができる
2-13
Use Databricks to create, drop, and rename tables.
Databricksを使用してテーブルの作成、削除、名前変更を行います。
テーブルの作成は CREATE TABLE
テーブルの削除は DROP TABLE
テーブルの名前変更は ALTER TABLE my_database.old_table_name RENAME TO my_database.new_table_name;
いずれもカタログエクスプローラーからも行える
2-14
Identify the table owner using Data Explorer.
Data Explorerを使用してテーブルの所有者を特定します。
カタログ、スキーマ、テーブルともに概要ページのOwnerで所有者を確認できる。
2-15
Change access rights to a table using Data Explorer.
Data Explorerを使用してテーブルへのアクセス権を変更します。
カタログ、スキーマ、テーブルともにPermissionsからアクセス権を変更できる。
PrincipalsとPrivilegesを指定してGrantをクリックする。
2-16
Describe the responsibilities of a table owner.
テーブル所有者の責任を説明します。
テーブル所有者は、テーブルのメンテナンス、アクセス権の管理、およびデータの品質とセキュリティの保証などの責任を担う
2-17
Identify organization-specific considerations of PII data
PIIデータの組織固有の考慮事項を特定します。
ノートなし
Section 3: SQL in the Lakehouse
3-1
Identify a query that retrieves data from the database with specific conditions.
特定の条件でデータベースからデータを取得するクエリを特定します。
SELECT ... WHERE
3-2
Identify the output of a SELECT query.
SELECTクエリの出力を特定します。
SELECTクエリの出力は、指定された列のデータを含む結果セット
SQL EditorではRaw results（表形式）がデフォルトで出力される、クエリの所要時間と最大1000件までのレコードが出力される
カラムをクリックするとデータの昇順、降順で結果を並べ替えられる
3-3
Compare and contrast MERGE INTO, INSERT TABLE, and COPY INTO.
MERGE INTO、INSERT TABLE、COPY INTOを比較し対比します。
-
MERGE INTOは、既存のレコードを更新または新しいレコードを挿入するために使用される -
INSERT TABLEは、指定されたテーブルに新しいデータを挿入する -
COPY INTOは、外部ソースからのデータをテーブルに効率的にコピーするために使用される
MERGE INTO target_table AS t
USING source_table AS s
ON t.id = s.id
WHEN MATCHED THEN
UPDATE SET t.name = s.name, t.age = s.age
WHEN NOT MATCHED THEN
INSERT (id, name, age) VALUES (s.id, s.name, s.age);
INSERT INTO table_name (column1, column2, column3)
VALUES (value1, value2, value3);
INSERT INTO target_table (column1, column2, column3)
SELECT column1, column2, column3
FROM source_table
WHERE condition;
CREATE TABLE default.loan_risks_upload (
loan_id BIGINT,
funded_amnt INT,
paid_amnt DOUBLE,
addr_state STRING
);
COPY INTO default.loan_risks_upload
FROM '/databricks-datasets/learning-spark-v2/loans/loan-risks.snappy.parquet'
FILEFORMAT = PARQUET;
3-4
Simplify queries using subqueries.
サブクエリを使用してクエリを簡素化します。
共通テーブル式（CTE）により、SQL ステートメントのスコープ内で複数回参照することが可能な一時結果セットを定義できる
-- CTE with multiple column aliases
> WITH t(x, y) AS (SELECT 1, 2)
SELECT * FROM t WHERE x = 1 AND y = 2;
1 2
-- CTE in CTE definition
> WITH t AS (
WITH t2 AS (SELECT 1)
SELECT * FROM t2)
SELECT * FROM t;
1
-- CTE in subquery
> SELECT max(c) FROM (
WITH t(c) AS (SELECT 1)
SELECT * FROM t);
1
-- CTE in subquery expression
> SELECT (WITH t AS (SELECT 1)
SELECT * FROM t);
1
-- CTE in CREATE VIEW statement
> CREATE VIEW v AS
WITH t(a, b, c, d) AS (SELECT 1, 2, 3, 4)
SELECT * FROM t;
> SELECT * FROM v;
1 2 3 4
-- CTE names are scoped
> WITH t AS (SELECT 1),
t2 AS (
WITH t AS (SELECT 2)
SELECT * FROM t)
SELECT * FROM t2;
2
3-5
Compare and contrast different types of JOINs.
異なるタイプのJOINを比較し対比します。
-
INNER JOINは、両方のテーブルに存在するキーに基づいて行を結合する -
LEFT JOIN（またはLEFT OUTER JOIN）は、左テーブルのすべての行と、右テーブルのマッチする行を結合する -
RIGHT JOINとFULL OUTER JOINも同様に、特定の結合条件に基づいて動作する
3-6
Aggregate data to achieve a desired output.
望ましい出力を得るためにデータを集約します。
-
GROUP BY句を使用して特定の列に基づいてデータをグループ化する -
SUM、AVG、MAX、MINなどの集約関数を使用してこれらのグループのデータを集約する
3-7
Manage nested data formats and sources within tables.
テーブル内のネストされたデータ形式とソースを管理します。
- ネストされたデータ形式は、
STRUCT、ARRAY、MAPなどの複合データ型を使用してテーブル内で管理される -
explode関数などで取り出せる
STRUCT
CREATE TABLE struct_example (
id INT,
person_info STRUCT<name: STRING, age: INT, email: STRING>
);
INSERT INTO struct_example
VALUES (1, ('John Doe', 30, 'john.doe@example.com')),
(2, ('Jane Doe', 28, 'jane.doe@example.com'));
SELECT id,
person_info.name as name,
person_info.age as age,
person_info.email as email
FROM struct_example;
SELECT結果
| id | name | age | |
|---|---|---|---|
| 1 | John Doe | 30 | john.doe@example.com |
| 2 | Jane Doe | 28 | jane.doe@example.com |
ARRAY
CREATE TABLE array_example (
id INT,
interests ARRAY<STRING>
);
INSERT INTO array_example
VALUES (1, ARRAY('Hiking', 'Swimming', 'Reading')),
(2, ARRAY('Reading', 'Writing', 'Cycling'));
SELECT id,
explode(interests) as interest
FROM array_example;
SELECT結果
| id | interest |
|---|---|
| 1 | Hiking |
| 1 | Swimming |
| 1 | Reading |
| 2 | Reading |
| 2 | Writing |
| 2 | Cycling |
MAP
CREATE TABLE map_example (
id INT,
scores MAP<STRING, INT>
);
INSERT INTO map_example
VALUES (1, MAP('Math', 90, 'Science', 85, 'History', 95)),
(2, MAP('Math', 88, 'Science', 92, 'Literature', 87));
SELECT id,
explode(scores) as (subject, score)
FROM map_example;
SELECT結果
| id | subject | score |
|---|---|---|
| 1 | Math | 90 |
| 1 | Science | 85 |
| 1 | History | 95 |
| 2 | Math | 88 |
| 2 | Science | 92 |
| 2 | Literature | 87 |
3-8
Use cube and roll-up to aggregate a data table.
キューブとロールアップを使用してデータテーブルを集約します。
キューブ
入力サンプル
| region | product | sales |
|---|---|---|
| North | A | 100 |
| North | B | 150 |
| South | A | 200 |
| South | B | 100 |
サンプルクエリ
SELECT region, product, SUM(sales) as total_sales
FROM sales_table
GROUP BY CUBE(region, product);
出力サンプル
| region | product | total_sales |
|---|---|---|
| North | A | 100 |
| North | B | 150 |
| South | A | 200 |
| South | B | 100 |
| North | NULL | 250 |
| South | NULL | 300 |
| NULL | A | 300 |
| NULL | B | 250 |
| NULL | NULL | 550 |
この結果は、regionとproductのすべての可能な組み合わせに対する集約（サブトータル）と、それぞれ単独での集約、さらに全体の合計を示しています。NULLは集約レベルのサブトータルを表しています。
ロールアップ
入力サンプル
| region | product | sales |
|---|---|---|
| North | A | 100 |
| North | B | 150 |
| South | A | 200 |
| South | B | 100 |
サンプルクエリ
SELECT region, product, SUM(sales) as total_sales
FROM sales_table
GROUP BY ROLLUP(region, product);
出力サンプル
| region | product | total_sales |
|---|---|---|
| North | A | 100 |
| North | B | 150 |
| North | NULL | 250 |
| South | A | 200 |
| South | B | 100 |
| South | NULL | 300 |
| NULL | NULL | 550 |
ROLLUPの結果は階層的な集約を示しており、各regionに対するproductのサブトータルと、全体の合計を計算しています。ここでも、NULLはサブトータルと全体の合計を表しています。
3-9
Compare and contrast roll-up and cube.
ロールアップとキューブを比較し対比します。
- CUBE操作は、すべての次元の組み合わせに対する集約を提供し、より詳細な多次元分析を可能にする
- ROLLUP操作は、階層的な集約を生成し、特定の順序でのサブトータルと全体の合計を計算する
3-10
Use windowing to aggregate time data.
ウィンドウ関数を使用して時間データを集約します。
時間データ集約用のウィンドウ関数はwindows, session_windows, window_timeの3つ
以下にサンプルコードを記載する
window関数
タイムスタンプ表現に対してホッピングベースのスライディングウィンドウを作成する（なんのこっちゃ）
window(expr, width [, slide [, start] ] )
以下はChatGPTによる解説
window関数は、時系列データに対するウィンドウベースの集約を行うための関数です。この関数を使用することで、指定した時間幅（width）のウィンドウをスライドさせながらデータを集約することができます。window関数の引数は以下の通りです。
window関数の引数
-
expr: ウィンドウの基準となるタイムスタンプ列を指定します。この列に基づいて、データがウィンドウに分類されます。 -
width: ウィンドウの幅を指定します。この値は、各ウィンドウがカバーする時間の長さを定義します（例: '2 MINUTES 30 SECONDS'）。 -
slide(オプショナル): ウィンドウがスライドする間隔を指定します。この値が指定されている場合、新しいウィンドウはこの間隔ごとに開始します。指定されない場合、ウィンドウの幅（width）がスライド間隔として使用され、ウィンドウは重複しません。 -
start(オプショナル): ウィンドウの開始オフセットを指定します。これは、最初のウィンドウが開始するタイムスタンプからのオフセットです。この値を指定することで、ウィンドウの開始点を細かく制御できます。
SELECT
window,
min(val),
max(val),
count(val)
FROM
VALUES
(TIMESTAMP '2020-08-01 12:20:21', 17),
(TIMESTAMP '2020-08-01 12:20:22', 12),
(TIMESTAMP '2020-08-01 12:23:10', 8),
(TIMESTAMP '2020-08-01 12:25:05', 11),
(TIMESTAMP '2020-08-01 12:28:59', 15),
(TIMESTAMP '2020-08-01 12:30:01', 23),
(TIMESTAMP '2020-08-01 12:30:15', 2),
(TIMESTAMP '2020-08-01 12:35:22', 16) AS S(stamp, val)
GROUP BY
window(
stamp,
'2 MINUTES 30 SECONDS',
'30 SECONDS',
'15 SECONDS'
);
上記の結果
| window | min(val) | max(val) | count(val) |
|---|---|---|---|
| {'start': 2020-08-01 12:19:45, 'end': 2020-08-01 12:22:15} | 12 | 17 | 2 |
| {'start': 2020-08-01 12:20:15, 'end': 2020-08-01 12:22:45} | 12 | 17 | 2 |
| {'start': 2020-08-01 12:18:15, 'end': 2020-08-01 12:20:45} | 12 | 17 | 2 |
| {'start': 2020-08-01 12:19:15, 'end': 2020-08-01 12:21:45} | 12 | 17 | 2 |
| {'start': 2020-08-01 12:18:45, 'end': 2020-08-01 12:21:15} | 12 | 17 | 2 |
| {'start': 2020-08-01 12:21:15, 'end': 2020-08-01 12:23:45} | 8 | 8 | 1 |
| {'start': 2020-08-01 12:22:15, 'end': 2020-08-01 12:24:45} | 8 | 8 | 1 |
| {'start': 2020-08-01 12:21:45, 'end': 2020-08-01 12:24:15} | 8 | 8 | 1 |
| {'start': 2020-08-01 12:20:45, 'end': 2020-08-01 12:23:15} | 8 | 8 | 1 |
| {'start': 2020-08-01 12:22:45, 'end': 2020-08-01 12:25:15} | 8 | 11 | 2 |
| {'start': 2020-08-01 12:23:45, 'end': 2020-08-01 12:26:15} | 11 | 11 | 1 |
| {'start': 2020-08-01 12:23:15, 'end': 2020-08-01 12:25:45} | 11 | 11 | 1 |
| {'start': 2020-08-01 12:24:45, 'end': 2020-08-01 12:27:15} | 11 | 11 | 1 |
| {'start': 2020-08-01 12:24:15, 'end': 2020-08-01 12:26:45} | 11 | 11 | 1 |
| {'start': 2020-08-01 12:27:45, 'end': 2020-08-01 12:30:15} | 15 | 23 | 2 |
| {'start': 2020-08-01 12:27:15, 'end': 2020-08-01 12:29:45} | 15 | 15 | 1 |
| {'start': 2020-08-01 12:28:45, 'end': 2020-08-01 12:31:15} | 2 | 23 | 3 |
| {'start': 2020-08-01 12:28:15, 'end': 2020-08-01 12:30:45} | 2 | 23 | 3 |
| {'start': 2020-08-01 12:26:45, 'end': 2020-08-01 12:29:15} | 15 | 15 | 1 |
| {'start': 2020-08-01 12:29:45, 'end': 2020-08-01 12:32:15} | 2 | 23 | 2 |
| {'start': 2020-08-01 12:29:15, 'end': 2020-08-01 12:31:45} | 2 | 23 | 2 |
| {'start': 2020-08-01 12:30:15, 'end': 2020-08-01 12:32:45} | 2 | 2 | 1 |
| {'start': 2020-08-01 12:33:45, 'end': 2020-08-01 12:36:15} | 16 | 16 | 1 |
| {'start': 2020-08-01 12:35:15, 'end': 2020-08-01 12:37:45} | 16 | 16 | 1 |
| {'start': 2020-08-01 12:34:45, 'end': 2020-08-01 12:37:15} | 16 | 16 | 1 |
| {'start': 2020-08-01 12:33:15, 'end': 2020-08-01 12:35:45} | 16 | 16 | 1 |
| {'start': 2020-08-01 12:34:15, 'end': 2020-08-01 12:36:45} | 16 | 16 | 1 |
-
expr (stamp): この例では、ウィンドウの基準となるタイムスタンプ列stampが使用されています。集約はこのタイムスタンプに基づいて行われます。 -
width ('2 MINUTES 30 SECONDS'): 各ウィンドウが2分30秒の幅を持つことを意味します。この時間幅内のデータが一つのウィンドウに集約されます。 -
slide ('30 SECONDS'): 新しいウィンドウが30秒ごとにスライド（開始）することを意味します。これにより、ウィンドウ間に重複が生じ、データが複数のウィンドウにまたがって集約されることがあります。 -
start ('15 SECONDS'): 最初のウィンドウがタイムスタンプの開始から15秒後に開始することを意味します。これはウィンドウの開始点を細かく調整するために使用されます。
session_window関数
タイムスタンプ式に対してセッションウィンドウを作成する
以下はChatGPTによる解説
session_window関数は、活動セッションまたはイベントセッションに基づいて動的なウィンドウを作成するために使用されます。この関数は、指定されたギャップ期間（gapDuration）で区切られたデータポイントのグループを識別します。各グループ（セッション）は、ギャップ期間より長い間隔がない一連のイベントとして定義されます。session_windowは特に、ユーザーアクティビティのセッション分析やイベントログのセッション分割などに適しています。
session_window(expr, gapDuration)
-
expr: セッションウィンドウを定義するために使用されるタイムスタンプ列。 -
gapDuration: セッション間の最小非活動期間。この期間以上の間隔があるイベントは新しいセッションとして扱われます。
固定のギャップ期間を持つセッションウィンドウの例
SELECT a, session_window.start, session_window.end, count(*) as cnt
FROM VALUES ('A1', '2021-01-01 00:00:00'),
('A1', '2021-01-01 00:04:30'),
('A1', '2021-01-01 00:10:00'),
('A2', '2021-01-01 00:01:00') AS tab(a, b)
GROUP BY a, session_window(b, '5 minutes')
ORDER BY a, start;
このクエリは、'5 minutes'のギャップ期間を持つセッションウィンドウを作成します。
A1とA2のイベントは、それぞれのセッションウィンドウ内で集約されます。
出力は以下の通りです。
| a | start | end | cnt |
|---|---|---|---|
| A1 | 2021-01-01 00:00:00 | 2021-01-01 00:09:30 | 2 |
| A1 | 2021-01-01 00:10:00 | 2021-01-01 00:15:00 | 1 |
| A2 | 2021-01-01 00:01:00 | 2021-01-01 00:06:00 | 1 |
動的なギャップ期間を持つセッションウィンドウの例
SELECT a, session_window.start, session_window.end, count(*) as cnt
FROM VALUES ('A1', '2021-01-01 00:00:00'),
('A1', '2021-01-01 00:04:30'),
('A1', '2021-01-01 00:10:00'),
('A2', '2021-01-01 00:01:00'),
('A2', '2021-01-01 00:04:30') AS tab(a, b)
GROUP BY a, session_window(b, CASE WHEN a = 'A1' THEN '5 minutes'
WHEN a = 'A2' THEN '1 minute'
ELSE '10 minutes' END)
ORDER BY a, start;
このクエリでは、A1とA2のイベントに対して異なるギャップ期間を指定しています。A1のイベントには'5 minutes'、A2のイベントには'1 minute'のギャップ期間が適用されます。
出力は以下の通りです。
| a | start | end | cnt |
|---|---|---|---|
| A1 | 2021-01-01 00:00:00 | 2021-01-01 00:09:30 | 2 |
| A1 | 2021-01-01 00:10:00 | 2021-01-01 00:15:00 | 1 |
| A2 | 2021-01-01 00:01:00 | 2021-01-01 00:02:00 | 1 |
| A2 | 2021-01-01 00:04:30 | 2021-01-01 00:05:30 | 1 |
window_time関数
window または session_window 関数によって生成される時間枠の包括的な終了時刻を返します。
以下はChatGPTによる解説
window_time(window)関数は、特定のウィンドウ関数の出力であるwindowオブジェクトからウィンドウの時間情報を抽出するために使用されるものです。この関数は、ウィンドウの終了時刻を示すタイムスタンプを返します。ウィンドウ関数によって生成された時間範囲に基づき、集約や分析を行った後の結果セットにおいて、ウィンドウの正確な時間範囲を簡単に把握するのに役立ちます。
SELECT a, window.start as start, window.end as end, window_time(window), cnt
FROM (
SELECT a, window(b, '5 MINUTES') as window, count(*) as cnt
FROM VALUES ('A1', '2021-01-01 00:00:00'),
('A1', '2021-01-01 00:04:30'),
('A1', '2021-01-01 00:06:00'),
('A2', '2021-01-01 00:01:00') AS tab(a, b)
GROUP BY a, window(b, '5 MINUTES')
)
ORDER BY a, window.start;
このクエリは、'5 MINUTES'の固定ウィンドウを使用して、aによってグループ化されたレコードの数をカウントしています。そして、window_time(window)関数を用いて各ウィンドウの終了時刻を取得しています。
| a | start | end | window_time | cnt |
|---|---|---|---|---|
| A1 | 2021-01-01 00:00:00 | 2021-01-01 00:05:00 | 2021-01-01 00:04:59.999999 | 2 |
| A1 | 2021-01-01 00:05:00 | 2021-01-01 00:10:00 | 2021-01-01 00:09:59.999999 | 1 |
| A2 | 2021-01-01 00:00:00 | 2021-01-01 00:05:00 | 2021-01-01 00:04:59.999999 | 1 |
-
a: レコードのグループを示します。 -
start: 各ウィンドウの開始時刻を示します。 -
end: 各ウィンドウの終了時刻を示します。 -
window_time:window_time(window)によって返される、ウィンドウの終了時刻です。この例では、各ウィンドウの終了時刻がナノ秒単位で'2021-01-01 00:04:59.999999'と表示されています。これは、ウィンドウの終了時刻をより正確に示すための表現です。 -
cnt: 各ウィンドウに含まれるレコードの数です。
window_time(window)関数を用いることで、特に時系列データの分析においてウィンドウの精密な時間範囲を把握することが可能になります。これにより、データの時間的な動きやパターンをより詳細に分析することができます。
3-11
Identify a benefit of having ANSI SQL as the standard in the Lakehouse.
LakehouseでANSI SQLを標準とする利点を特定します。
ANSI SQLを標準とすることで、データプロフェッショナルが既知のクエリ言語を使用してデータを操作できるため、可搬性と互換性が向上する
3-12
Identify, access, and clean silver-level data.
シルバーレベルのデータを特定し、アクセスし、クリーンアップします。
- シルバーレベルのデータは、ブロンズレイヤーを入力とし、初期のクリーニングと処理が行われたデータで、分析準備が整っている
- この段階でのデータは、ゴールドレイヤーでのより高品質な分析とインサイトの生成の基盤となる
3-13
Utilize query history and caching to reduce development time and query latency.
クエリ履歴とキャッシングを利用して開発時間とクエリの遅延を削減します。
クエリ履歴
クエリ履歴はサイドバーのQuery HistoryやQuery History APIで取得できる
クエリ履歴には過去 30 日間のクエリ データが保持され、その後、自動的に削除される
以下はクエリ履歴の一覧：ユーザーや実行された時間、使用されたウェアハウス、ステータス、ステートメントIDなどでフィルターできる
実行中のクエリのキャンセルもここからできる
個別のクエリをクリックするとより詳細がみられる
クエリプロファイルもここからみられる
キャッシュ
このページによくまとまっている
キャッシュは、同じデータを複数回再計算またはフェッチする必要性をなくして、データ ウェアハウス システムのパフォーマンスを向上させるために不可欠な手法です。 Databricks SQL では、キャッシュを使用すると、クエリの実行を大幅に高速化し、ウェアハウスの使用量を最小限に抑えることができるため、コストを削減し、リソースをより効率的に使用できます。 各キャッシュ レイヤーによって、クエリのパフォーマンスが向上し、クラスターの使用量が最小限に抑えられ、リソース使用率が最適化されてシームレスなデータ ウェアハウス エクスペリエンスが実現します。
キャッシュにより、データ ウェアハウスでは次のような多くの利点が得られます。
速度: クエリ結果や頻繁にアクセスされるデータをメモリやその他の高速ストレージ メディアに格納して、キャッシュによってクエリの実行時間を大幅に短縮できます。 システムでは、キャッシュされた結果を再計算するのではなく、迅速に取得できるため、このストレージはクエリを繰り返し実行する場合に特に便利です。
クラスター使用量の削減: キャッシュを使用すると、以前に計算された結果を再利用することで、追加のコンピューティング リソースの必要性が最小限に抑えられます。 これにより、ウェアハウスの全体的なアップタイムと追加のコンピューティング クラスターの必要性が減少するため、コストが削減され、より適切なリソース割り当てが実現します。
DBSQLでは4つのキャッシュが内部的に利用される
| No. | キャッシュ | 説明 | 有効期間 | キャッシュがクリアされる契機 | キャッシュの場所 |
|---|---|---|---|---|---|
| 1 | Databricks SQL UIキャッシュ | DBSQLのUIでのクエリとダッシュボードの結果をユーザーごとにキャッシュ | 最大7日間 | クエリの再実行、元になるテーブルの更新 | ユーザーアカウント内のDBFSの安全なロケーション |
| 2 | 結果キャッシュ - ローカルキャッシュ | DBSQLで実行したクエリ結果をクラスターのメモリ内にキャッシュ | 24時間、またはクラスターのメモリ内のキャッシュ容量が一杯になるまで | クラスターの停止または再起動、元になるテーブルの更新 | クラスターのメモリ |
| 3 | 結果キャッシュ - リモート結果キャッシュ | DBSQLサーバーレスで実行したクエリ結果をユーザーのクラウドストレージにキャッシュ、ウェアハウスの停止や再起動に影響されない | 24時間 | 元になるテーブルの更新 | ユーザーアカウント内のDBFSの安全なロケーション |
| 4 | ディスクキャッシュ | SQLウェアハウスでクエリ実行時にデータストレージから読み取ったデータのローカルSSDキャッシュ | クラスターのローカルSSD内のキャッシュ容量が一杯になるまで | クラスターの停止または再起動、元になるテーブルの更新 | クラスターのローカルSSD |
3-14
Optimize performance using higher-order Spark SQL functions.
高階Spark SQL関数を使用してパフォーマンスを最適化します。
以下はChatGPTによる解説
Spark SQLのhigher-order（高階）関数は、複雑なデータ型（例えば、配列やマップ）に対して操作を実行するために使用されます。これらの関数は、配列やマップ内の要素に対して関数を適用し、その結果に基づいて新しい配列やマップを生成したり、特定の条件に基づいて要素をフィルタリングしたりすることができます。高階関数はデータの変換や分析を柔軟に行うために非常に便利です。
一般的な高階関数の例
transform: 配列の各要素に対して指定された関数を適用し、結果の配列を返します。
SELECT transform(array(1, 2, 3), x -> x + 1) as new_array;
出力: [2, 3, 4]
filter: 配列から特定の条件を満たす要素のみを含む新しい配列を返します。
SELECT filter(array(1, 2, 3, 4), x -> x % 2 = 0) as even_numbers;
出力: [2, 4]
aggregate: 配列の要素に対して累積的な操作を行い、単一の値を返します（例: 合計や平均の計算）。
SELECT aggregate(array(1, 2, 3), 0, (acc, x) -> acc + x, acc -> acc) as sum;
出力: 6
3-15
Create and apply UDFs in common scaling scenarios.
一般的なスケーリングシナリオでUDFを作成し適用します。
以下はChatGPTによる解説
ユーザー定義関数（UDF）は、カスタムロジックをSQLやデータフレーム操作に組み込むためにユーザーが定義できる関数です。Azure Databricksでは、これらを用いて拡張性の高いロジックを実装し、再利用することが可能です。UDFは、Python、Scala、Javaで定義でき、Databricks環境によっては特定の実行環境でのみ使用可能です。UDFを利用することで、SQLやDataFrame APIでは表現しづらい複雑な計算やデータ変換処理を実行できますが、いくつかの制限事項や効率性に関するトレードオフがあります。
UDFの種類と効率性
- Hive UDF: JVM上で実行されるが、最適化されない。
- Python UDF: Python環境で実行されるが、シリアル化のコストが発生し最適化されない。
- Pandas UDF: PythonでArrowを使用し、シリアル化コストを低減するが、最適化されない。
- Scala UDF: JVM上で実行されるが、最適化されない。
- Spark SQL & DataFrame API: Spark SQLやDataFrame APIに組み込まれた関数はJVMまたはPhotonで最適化されて実行される。
UDFの使用シナリオ
UDFは、特にアドホッククエリ、手動データクレンジング、探索的データ分析、小規模から中規模のデータセットに対する操作に適しています。これらのシナリオでは、UDFに関連する実行コストがコードのリファクタリングコストを上回ることは少ないです。一方、ETLジョブ、ストリーミング操作、非常に大規模なデータセットに対する操作、定期的に実行されるワークロードでは、ロジックをSparkの組み込みメソッドにリファクタリングすることでパフォーマンスが向上します。
結論
パフォーマンスを最優先する場合、Spark SQLやDataFrame APIの組み込み関数を使用することが推奨されます。これらは最適化されており、実行効率が高いです。JVMで実行されるScalaやJavaのコードはPython UDFよりも高速ですが、可能であれば組み込み関数の使用を検討してください。Pandas UDFは、Python UDFよりもシリアル化コストが低いため、Pythonを使用する場合はPandas UDFを検討すると良いでしょう。しかし、大規模データセットや重要なワークロードには、UDFの使用を避け、Sparkの最適化されたメソッドを利用することが最も効率的です。
Section 4: Data Visualization and Dashboarding
4-1
Create basic, schema-specific visualizations using Databricks SQL.
Databricks SQLを使用して基本的な、スキーマ特有のビジュアライゼーションを作成します。
ノートなし
4-2
Identify which types of visualizations can be developed in Databricks SQL (table, details, counter, pivot).
Databricks SQLで開発できるビジュアライゼーションの種類（テーブル、詳細、カウンター、ピボット）を特定します。
Databricks SQLのビジュアライゼーションで選べるVisualization types一覧は以下。（2024/2/6時点）
- Line
- Bar
- Area
- Pie
- Histogram
- Heatmap
- Scatter
- Bubble
- Combo
- Cohort
- Counter
- Details view
- Funnel
- Map (Choropleth)
- Map (Markers)
- Pivot table
- Pivot table (legacy)
- Sankey
- Sunburst sequence
- Table
- Word cloud
4-3
Explain how visualization formatting changes the reception of a visualization.
ビジュアライゼーションのフォーマットがビジュアライゼーションの受容にどのように影響するかを説明します。
ChatGPTによる解説
ビジュアライゼーションのフォーマットを変更することで、データの表示方法が変わり、情報の解釈や受け取り方に大きな影響を与えます。適切なフォーマットは、データの洞察をより明確に伝えるのに役立ちます。
4-4
Describe how to add visual appeal through formatting.
フォーマットを通じてビジュアルアピールを加える方法を説明します。
ChatGPTによる解説
色、フォント、サイズの調整や、チャートの種類を選択することで、ビジュアライゼーションに視覚的魅力を加え、データのポイントを際立たせることができます。
4-5
Identify that customizable tables can be used as visualizations within Databricks SQL.
Databricks SQL内でカスタマイズ可能なテーブルをビジュアライゼーションとして使用できることを特定します。
ChatGPTによる解説
Databricks SQLでは、カスタマイズ可能なテーブルを作成してデータを視覚的に表現し、ユーザーがデータをより容易に解析できるようにします。
4-6
Describe how different visualizations tell different stories.
異なるビジュアライゼーションがどのように異なるストーリーを語るかを説明します。
ChatGPTによる解説
ビジュアライゼーションの種類によって、データから異なる洞察や物語が浮かび上がります。例えば、時間経過による変化を示すためには折れ線グラフを、カテゴリ間の比較を示すためには棒グラフを使用します。
4-7
Create customized data visualizations to aid in data storytelling.
データストーリーテリングを支援するためにカスタマイズされたデータビジュアライゼーションを作成します。
ChatGPTによる解説
特定のデータポイントやトレンドを強調するカスタマイズされたビジュアライゼーションを通じて、データに基づく物語をより効果的に伝えることができます。
4-8
Create a dashboard using multiple existing visualizations from Databricks SQL Queries.
Databricks SQLクエリからの複数の既存のビジュアライゼーションを使用してダッシュボードを作成します。
ChatGPTによる解説
複数のビジュアライゼーションを組み合わせることで、一つの統合されたダッシュボードを作成し、データの包括的なビューを提供します。
4-9
Describe how to change the colors of all of the visualizations in a dashboard.
ダッシュボード内のすべてのビジュアライゼーションの色を変更する方法を説明します。
ダッシュボードを[Edit] > [Colors]から変更可能
4-10
Describe how query parameters change the output of underlying queries within a dashboard.
クエリパラメータがダッシュボード内のクエリの出力をどのように変更するかを説明します。
- クエリ パラメーターを使用すると、実行時に値をクエリに代入することができる
- 二重中かっこ
{{ }}の間の文字列はクエリ パラメーターとして扱われる - パラメーター値を設定した結果ウィンドウの上にウィジェットが表示される
パラメーターの型は色々選べる
4-11
Identify the behavior of a dashboard parameter.
ダッシュボードパラメータの振る舞いを特定します。
ダッシュボードのパラメーターの種類として、ウィジェットパラメーター（それぞれのビジュアライゼーションごとのパラメーター）とダッシュボードパラメーター（ダッシュボード全体のパラメーター）がある
パラメーター付きのクエリのビジュアライゼーションをダッシュボードに追加すると、ダッシュボードパラメーターが既定だが、Change widget settingsからウィジェットパラメーターに切り替えられる
4-12
Identify the use of the "Query Based Dropdown List" as a way to create a query parameter from the distinct output of a different query.
「クエリベースのドロップダウンリスト」を使用して、異なるクエリの個別の出力からクエリパラメータを作成する方法を特定します。
ドロップダウンリストに使いたいクエリを作成して実行する
クエリパラメーターの設定でQuery Based Dropdown Listを選択して上記クエリを指定する
クエリのパラメーターがドロップダウンリストになる
4-13
Identify the method for sharing a dashboard with up-to-date results.
最新の結果を含むダッシュボードを共有する方法を特定します。
上のセクションでカバー済み
4-14
Describe the pros and cons of sharing dashboards in different ways.
異なる方法でダッシュボードを共有する際の利点と欠点を説明します。
以下のページによくまとまっている
ダッシュボードのアクセス許可
| 機能 | 権限なし | 閲覧可能 (Can View) | 実行可能 (Can Run) | 編集可能 (Can Edit) | 管理可能 (Can Manage) |
|---|---|---|---|---|---|
| ダッシュボードリストを見る | x | x | x | x | |
| ダッシュボードと結果を見る | x | x | x | x | |
| ダッシュボードのクエリ結果を更新 (または異なるパラメータを選択) | x | x | x | ||
| ダッシュボードを編集 | x (1) | x | x | ||
| 権限を変更 | x | ||||
| ダッシュボードを削除 | x |
(1) Run as viewerが必要
ダッシュボードの共有設定
- Run as viewer (閲覧者として実行) は、ダッシュボードを見ている各ユーザーの資格情報に基づいてクエリを実行し、ユーザーがアクセス可能なデータのみを表示します。ウェアハウスへのCan Useアクセスが必要です。
- Run as owner (所有者として実行)は、ダッシュボードの所有者の資格情報を使用してクエリを実行し、所有者がアクセスできるデータをすべての閲覧者に表示します。このモードを利用できるのは、編集可能または管理可能なアクセス許可を持つ所有者のみです。
4-15
Identify that users without permission to all queries, databases, and endpoints can easily refresh a dashboard using the owner's credentials.
すべてのクエリ、データベース、エンドポイントへのアクセス権がないユーザーでも、所有者の資格情報を使用してダッシュボードを簡単にリフレッシュできることを特定します。
上記のRun as ownerでの共有設定を利用する
4-16
Describe how to configure a refresh schedule.
リフレッシュスケジュールの設定方法を説明します。
上のセクションでカバー済み
4-17
Identify what happens if a refresh rate is less than the Warehouse's "Auto Stop".
リフレッシュレートがウェアハウスの「オートストップ」よりも短い場合に何が起こるかを特定します。
ChatGPTによる解説
リフレッシュレートがオートストップの間隔よりも短い場合、ウェアハウスは自動的に停止せずに稼働し続けるため、不必要なリソース使用やコストが発生する可能性があります。
4-18
Describe how to configure and troubleshoot a basic alert.
基本的なアラートの設定とトラブルシューティング方法を説明します。
まずはアラートの対象となるクエリを作成
サイドメニューの[Alerts] > [Create alert]
[Add schedule]を選択してScheduleや使用するウェアハウスを選択
通知先を設定
Query historyを見ると指定した頻度でクエリが実行されているのがわかる
通知メールは以下
4-19
Describe how notifications are sent when alerts are set up based on the configuration.
アラートが設定に基づいて設定された場合に通知が送信される方法を説明します。
上のセクションでカバー済み
Section 5: Analytics applications
5-1
Compare and contrast discrete and continuous statistics.
離散統計と連続統計を比較し対比します。
ChatGPTによる解説
離散統計は、個別の値やカウント可能なデータポイントに対して使用され、例えば投票数や製品の販売数などが該当します。連続統計は、任意の値を取り得るデータに適用され、時間、温度、距離などが例として挙げられます。離散データは通常整数値を取り、連続データは実数値を取ることが多いです。
5-2
Describe descriptive statistics.
記述統計について説明します。
ChatGPTによる解説
記述統計は、データセットの特性を要約し説明するために使用される統計手法です。平均、中央値、モード、標準偏差などの指標を使用して、データの傾向や分布を記述します。
5-3
Describe key moments of statistical distributions.
統計分布の主要なモーメントについて説明します。
ChatGPTによる解説
統計分布のモーメントには、平均（第一モーメント）、分散（第二モーメント）、歪度（第三モーメント）、尖度（第四モーメント）が含まれます。これらは、分布の中心、広がり、非対称性、尖り具合を表します。
5-4
Compare and contrast key statistical measures.
主要な統計指標を比較し対比します。
ChatGPTによる解説
平均はデータセットの中心的傾向を示し、中央値はデータセットの中央の値を示し、モードはデータセットで最も頻繁に出現する値を示します。分散と標準偏差はデータの散らばり具合を示し、相関係数は変数間の線形関係の強さを示します。
5-5
Describe data enhancement as a common analytics application.
一般的な分析アプリケーションとしてのデータ強化について説明します。
ChatGPTによる解説
データ強化は、データの品質を向上させたり、追加情報を組み込むことで、分析の精度や洞察の深さを高めるプロセスです。これには、データクレンジング、エンリッチメント、特徴生成が含まれます。
5-6
Enhance data in a common analytics application.
一般的な分析アプリケーションでデータを強化します。
ChatGPTによる解説
データセットに外部データソースからの情報を追加したり、データクレンジングを実施して不正確なデータを修正し、分析のための新たな特徴や指標を生成することで、データを強化します。
5-7
Identify a scenario in which data enhancement would be beneficial.
データ強化が有益であるシナリオを特定します。
ChatGPTによる解説
顧客データベースに対するマーケティングキャンペーンの効果を高めるために、人口統計学的情報や過去の購買履歴を追加する場合、データ強化が有益です。これにより、ターゲットの絞り込みとパーソナライズが可能になります。
5-8
Describe the blending of data between two source applications.
二つのソースアプリケーション間のデータブレンディングについて説明します。
ChatGPTによる解説
データブレンディングは、異なるデータソースからのデータを組み合わせて、一貫性のあるビューを作成するプロセスです。これにより、相補的な情報を統合し、より完全なデータ分析を実現します。
5-9
Identify a scenario in which data blending would be beneficial.
データブレンディングが有益であるシナリオを特定します。
ChatGPTによる解説
販売データと顧客満足度調査データを組み合わせることで、顧客の購買行動と満足度の関係を分析する場合、データブレンディングが有益です。このアプローチにより、ビジネス戦略の改善に役立つ洞察を得ることができます。
5-10
Perform last-mile ETL as project-specific data enhancement.
プロジェクト固有のデータ強化としてラストマイルETLを実行します。
ChatGPTによる解説
ラストマイルETLは、分析プロジェクトの特定のニーズに合わせてデータを最終的に変換し、ロードするプロセスです。これは、データを最終的な分析やレポートの形式に整形し、最適化するために重要です。