dbt CloudのRead Onlyユーザーが出来ることをまとめてみた #dbt

さがらです。

dbt Cloudでは大きく2種類のユーザー分類があり、DeveloperとRead Onlyという名称で分かれています。

ここで、「Developerはdbt使って開発しまくる人だからわかるんだけど、dbtでRead Onlyって…何出来るの？」と疑問を持つ方は多いのではないでしょうか。

ということで、本記事ではdbt CloudのRead Onlyユーザーは何が出来るのか、まとめてみます。

DeveloperとRead Onlyの違い

まず、DeveloperとRead Onlyの違いをまとめてみます。

公式Docの図がとてもわかりやすいため、こちらを引用させて頂きます。

• Read Onlyユーザーは、加工前の元データの更新状況とdbtにより生成されるキュメントを見ることが出来ます。
• Developerユーザーは、グループごとのアクセス権やパーミッションセットが設定されていれば、dbt Cloud上の操作をなんでもすることが出来ます。

Read Onlyユーザーが出来ることの確認

Read Onlyユーザーでログインしたスクリーンショットと併せて、より具体的に出来ることを見ていきます。

まず、Read Onlyユーザーがログインすると、下図のように各dbt projectの画面が表示されるはずです。

Documentationを押すと、yamlファイルで定義された各modelのdescriptionなどの情報を元に、対象のdbt projectにより生成されたテーブルやカラムの情報を確認できます。簡易的なデータカタログとしても使えますね。

Data sourcesを押すと、対象のdbt projectが使用する加工前の元データの更新状況を確認できます。

これはdbtのsourcesを用いているのですが、定義したfreshness(データの鮮度)を満たしていなければ、背景を赤くして警告を表示できます。これにより、使用したいデータが問題なく更新されているか、をユーザーからも確認可能です。

ちなみに、LOADER / LOADEDは対象となる元データの最終更新時間が設定しているfreshnessからどれだけ時間超過しているかを表し、LAST SNAPSHOTは対象のdbt projectにおける直近のジョブ実行の完了時間を意味しています。

Read Onlyユーザーに情報を開示するための設定

加工前の元データの更新状況とdbtにより生成されるドキュメントをRead Onlyユーザーに見せるためには、dbtで開発を行う人による設定が必要です。それぞれ見ていきたいと思います。

「加工前の元データの更新状況」の設定

加工前の元データの更新状況を確認するためには、yamlファイルを用意してsourcesパラメータを定義する必要があります。

下記の記事の"sourcesの「鮮度」をチェックする"の内容に記されている方法で、鮮度を確認することが可能ですので、参考にしてみてください。

「dbtにより生成されるドキュメント」の設定

必須ではないのですが、ドキュメントを生成にあたってはschema.ymlなどのyamlファイルを用意して、modelsパラメータをきちんと整備しておくことを推奨します。

modelsパラメータには、各テーブル・カラムごとの説明、testに用いる制約(unique、not nullなど)を記述することが出来るため、Read Onlyのユーザーがドキュメントを見た時により多くの情報を伝えられ、ドキュメントの利便性を高めることが出来ます。

以下はyamlファイルのサンプルですが、descriptionパラメータに対しては日本語も記述できますので、Read Onlyのユーザーにとってもわかりやすいように説明を記述していきましょう。

version: 2

models:
  - name: customers
    description: 各Customerの注文情報を１レコードにサマリしたテーブル。(One record per customer)
    columns:
      - name: customer_id
        description: Primary key
        tests:
          - unique
          - not_null
      - name: first_order_date
        description: 顧客がまだ注文していない場合はNULL。(NULL when a customer has not yet placed an order)
 

  - name: stg_customers
    description: 元のcustomerテーブルを整えたテーブル。(This model cleans up customer data)
    columns:
      - name: customer_id
        description: Primary key
        tests:
          - unique
          - not_null

  - name: stg_orders
    description: 元のordetsテーブルを整えたテーブル。(This model cleans up order data)
    columns:
      - name: order_id
        description: Primary key
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['placed', 'shipped', 'completed', 'return_pending', 'returned']

ジョブとArtifactsの設定

最後に、ジョブと対象のdbt projectでのArtifactsの設定が必要です。

まず定期的に実行するジョブの設定で、GENERATE DOCS?とRUN SOURCE FRESHNESSの2つにチェックを入れる必要があります。

この2箇所にチェックを入れた上でジョブを実行すると、ArtifactsとしてDocumentationとData Sourcesが出来ます。

この、ジョブにより作成されるArtifactsを対象のdbt projectに設定します。

Account Settingsから対象のdbt Projectの編集画面に移動し、Artifactsを設定します。各項目のドロップダウンリストをクリックすると、Artifactsを生成するように設定したジョブが選択できます。

こちらの設定から、DOCUMENTATIONもSOURCE FRESHNESSも設定すればOKです！

最後に

dbtのRead Onlyユーザーからできることをまとめてみました。

descriptionに記述した内容をベースとした簡易的なデータカタログを見せるだけでなく、加工前の元データの更新状況も把握できるため、使用したいデータの更新状況やデータ基盤に対するSLAが満たされているかどうかをユーザーから確認できるようになります。

dbtで適切に開発を進めると自然と出来る成果物ですので、dbtを開発者内に留めておくだけでなく、Read Onlyユーザーを活用してデータを利用する側のユーザーにも展開していきましょう！