Looker LookML Developer

Looker LookML Developer はデータセットと LookML を操作し、SQL と BI ツールに精通しています。LookML Developer は、既存のモデルエラーのトラブルシューティング、データ セキュリティ要件の実装、LookML オブジェクトの作成、LookML プロジェクトの健全性の管理などのモデル管理に習熟しています。LookML Developer は、新しい LookML のディメンションやメジャーを設計し、Explore を作成してユーザーがビジネス上の疑問の答えを見つけられるようにします。LookML Developer は、バージョン管理の実装、コード品質の評価から SQL Runner を活用したデータ検証まで、品質管理を熟知しています。

Looker LookML Developer 認定試験では、以下に関する能力が評価されます。

  • LookML コードのメンテナンスとデバッグ
  • ユーザー フレンドリーな Explore の作成
  • 堅牢なモデルの設計
  • キャッシュの保存ポリシーの定義
  • さまざまなデータセットと関連スキーマの理解
  • Looker IDE、SQL Runner、LookML Validator などの Looker ツールを使用する

Looker LookML Developer 認定試験は 2022 年 4 月 1 日に廃止されました。


この試験では、以下の項目における個人の能力が評価されます。

セクション 1: モデル管理

1.1 既存のデータモデルのエラーのトラブルシューティングを行う。次に例を示します。

a. エラーソースを特定する。

b. プロシージャ コンセプトを適用してエラーを解決する

1.2 プロセスに関するコンセプトを適用し、データ セキュリティ要件を実装する。次に例を示します。

a. ユーザーに権限を実装する。

b. データ セキュリティの実装に使用する Looker 機能を決定する(アクセス フィルタ、フィールド レベルのアクセス制御、行レベルのアクセス制御など)

1.3 データモデルとビジネス要件を分析し、LookML オブジェクトを作成する。次に例を示します。

a. 使用するビューとテーブルを決定する

b. Explore にビューを結合する方法を決定する

c. プロジェクト ベースのニーズ(データソース、レプリケーション、クライアントが提供するモックレポートなど)を構築する

1.4 所定のシナリオで LookML プロジェクトの健全性を維持する。次に例を示します。

a. 既存のコンテンツが正常に動作していることを確認する(コンテンツ検証ツール、監査、エラーの検索など)

b. エラーを解決する。

セクション 2: カスタマイズ

2.1 所定の要件に沿って新しい LookML ディメンションやメジャーを設計する。次に例を示します。

a. ビジネス要件(特定の指標)を適切な LookML 構造(ディメンション、測定結果、派生テーブルなど)に変換する

b. 新しいプロジェクトのニーズに対応するように既存のプロジェクト構造を変更する

c. 新しいディメンションとメジャーで使用する SQL ステートメントを作成する

2.2 Explore を作成し、ユーザーがビジネス上の疑問の答えを見つけられるようにする。次に例を示します。

a. ビジネス要件を分析し、要件(モデル、ビュー、結合構造など)を満たす LookML コードの実装を決定する

b. データの絞り込みに使用する追加機能を決定する(sql_always_where、always_filter、hidden: fields: を使用して特定のフィールドのみを表示する機能など)

セクション 3: 最適化

3.1 プロセスに関するコンセプトを適用し、クエリとレポートを最適化してパフォーマンスを高める。次に例を示します。

a. パフォーマンスへの影響に基づいて、使用するソリューションを決定する(Explore、マージされた結果、派生テーブルなど)

b. プロセスに関するコンセプトを適用して、クエリとレポートのパフォーマンスを評価する

c. クエリとレポートのパフォーマンス ソースに基づいて使用する方法を決定する(A/B テスト、SQL 原則など)

3.2 プロセスに関するコンセプトを適用し、要件に合った永続的な派生テーブルとキャッシュ保存ポリシーを実装する。次に例を示します。

データ ウェアハウスの更新頻度(例: 毎時、毎週、ETL の完了に基づく)に基づいて適切なキャッシュ設定を決定する

b. 探索クエリのランタイムと複雑さ、およびユーザーのニーズに基づいて、永続的な派生テーブルを使用するタイミングを決定する

c. データの可用性を向上させるための適切なソリューションを決定する(クエリデータのキャッシュ、永続的なテーブル、ソリューションの組み合わせなど)

セクション 4: 品質

4.1 特定の要件に基づくバージョン管理を実装する。次に例を示します。

a. Git ブランチに適した構成を決定する(共有ブランチ、リモート プロダクションからの pull など)

b. 他のデベロッパー ブランチとの統合における競合を調整する(複数のユーザーの管理など)

c. pull リクエスト プロセスを検証する。

4.2 コードの品質を評価する。次に例を示します。

a. 検証エラーと警告を解決する。

b. ユーザビリティ(説明、ラベル、グループラベルなど)を強化するために機能を利用する

c. プロジェクト ファイルに適切なコーディングを使用する(例: ファイルごとに 1 つのビュー)

4.3 特定のシナリオでのデータ検証に SQL Runner を使用する。次に例を示します。

a. SQL ランナーで生成された SQL を確認して、特定のクエリが結果を返す理由を特定する

b. システムまたは分析で見つかった不整合(予測と異なる結果、一意でない主キーなど)を解決する

c. ビジネス要件に基づいて、コストまたは効率性を考慮して SQL を最適化する