🍊

Tableau Server リポジトリに接続してプロジェクトのAsset Permissions設定を管理するダッシュボードを作った話

2024/04/02に公開

PostgreSQL

はじめに

こんにちは。わたしは現在，楽天という会社でデータエンジニアをしています。

今回は，Asset Permissions設定をモニタリングするダッシュボードを作ります。目的は，ワークブックやデータソースといったコンテンツをTableau Server上のプロジェクトに振り分けた上で，そのプロジェクト単位で設定する閲覧権限を監視するためです。詳細は前回の記事を御覧ください。

必要なのは，Tableau Server上のコンテンツに関するメタデータです。たとえば，プロジェクトの名称，作成日時，オーナー名，説明書き(Description)などが該当します。そしてこのメタデータは，Tableau Serverリポジトリというデータベース(PostgreSQL)に格納されています。

手順としては以下のとおりで，そのリポジトリを有効化して，Tableauからデータを取得して，ダッシュボードを作成する，という感じですが，手順1., 2.は割愛します。参照ドキュメント[1], [2]で有効化できます。この記事では手順3.を主に取り上げます。手順4.は，さらっと自分が作成して実際に使っているものをご紹介します。

Tableau Serverリポジトリを有効にする(自分がTableau Server Administratorでなければ，その人に依頼する必要がある)
Tableau DesktopからPostgreSQLデータベースに接続するためにコネクタをダウンロードしてインストールする
プロジェクトのAsset Permissions設定を取得するカスタムSQLを書き，それをもとにTableauデータソースをPublishする
PublishされたデータソースにTableauから接続して，ダッシュボードを作成する

プロジェクトのAsset Permissions設定を一覧で取得するSQL文

Tableau Serverのコンテンツに関するメタデータは，種類に応じて各テーブルに振り分けられています。たとえば，プロジェクトの名前やDescriptionはpublic.projectsテーブル，ユーザ情報はpublic._usersテーブル，という具合です。バージョンごとのメタデータテーブル情報はドキュメント[3]を参照してください。

今回使用するテーブルとカラムを抜粋して図示してみます。ER図合っているか不安なので間違っていたらコメントください。projects.owner_idと_users.idがキーとしてJOINでき，projects.site_idとsites.idがキーとしてJOINできます。

本記事で使用しているTableau Server リポジトリの

組織内のいちサイトを使用している場合，ご自身のサイトのidを確認しましょう。sites.nameがサイト名，sites.url_namespaceが，アクセスしているサイトのURLに含まれる文字列です。これらは必ずしも一致しません。

https://<サーバ名>.jp/#/site/<url_namespace>/home

さて，これらのテーブルを使って，下記をSQLクエリとして書きました。クエリ内で使っているのは再帰SQL文です。親と子の関係がparent_project_idで自己参照的に規定されているpublic.projectsのようなテーブルにうってつけです。

project_hierarchyは，ツリー構造的に配置されているプロジェクトについて，そのidをトップレベルプロジェクトから子プロジェクトに向かって書き連ねるものです。
top_projectは，子孫プロジェクトがどのトップレベルプロジェクトに配置されたものなのかを再帰ループ内で保存しておくものです。
project_levelは，トップレベルプロジェクトを第1とした，プロジェクトの階層を表します。
そのほか，”name”, description, friendly_name, created_atは，プロジェクトに関する細々とした情報です。前から，プロジェクト名，プロジェクト概要，オーナーのユーザ名，作成日時，です。

今回の記事の目的である，Asset Permissions設定についてですが，

controlled_permissions_enabledは，公式ドキュメントを翻訳すると，「ワークブック、ビュー、およびデータソースに対する権限をプロジェクト・レベルで制御するかどうかを示します。」と書かれています。つまり，ここがTRUEになっていること，つまりAsset Permissions設定がLockedになっていることが，プロジェクト単位でコンテンツの権限設定をまとめられていることを表す，ということになります。これが，前回記事でご紹介したベストプラクティスです。
nested_projects_permissions_includedは，controlled_permissions_enabledがTRUEになっている場合にのみ，TRUEになりえます。そのプロジェクトに格納されたコンテンツの権限設定が柔軟なのは，nested_projects_permissions_includedがFALSEの場合，設定がひとまとめにできて管理の手間が簡単になるのはnested_projects_permissions_includedがTRUEの場合，です。どちらを採用するかは，使用用途によって決めて良いと思います。こちらも，詳しくは前回の記事を御覧ください。

WITH RECURSIVE rec_projects(project_level, parent_project_id, project_id, project_hierarchy, top_project)
AS
(
SELECT
    CAST(1 AS NUMERIC) AS project_level
    , p.parent_project_id AS parent_project_id
    , p.id AS project_id
    , LPAD(CAST(p.id AS varchar(5)), 5, '0') AS project_hierarchy
    , LPAD(CAST(p.id AS varchar(5)), 5, '0') AS top_project
FROM
    public.projects AS p
WHERE
    p.site_id = XXX -- ご自身のsite_idを入力してください
    AND p.parent_project_id IS NULL
UNION
SELECT 
    r.project_level + 1 AS project_level
    , p.parent_project_id AS parent_project_id
    , p.id AS project_id
    , r.project_hierarchy || '>>' || LPAD(CAST(p.id AS varchar(5)), 5, '0') AS project_hierarchy
    , CAST(substring(r.project_hierarchy FROM 1 for 5) AS varchar(5)) AS top_project
FROM
    rec_projects AS r
    INNER JOIN public.projects AS p
        ON r.project_id = p.parent_project_id
        AND p.site_id = XXX -- ご自身のsite_idを入力してください
)
SELECT 
    r.top_project AS top_project_id
    , t."name" AS top_project_name
    , r.project_level
    , r.project_hierarchy
    , r.parent_project_id
    , r.project_id
    , p.description
    , p."name" AS project_name
    , u.friendly_name AS owner_name
    , p.created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Tokyo' AS created_at
    , p.controlled_permissions_enabled
    , p.nested_projects_permissions_included
FROM
    rec_projects AS r
    LEFT JOIN public.projects AS p
        ON r.project_id = p.id
        AND p.site_id = XXX -- ご自身のsite_idを入力してください
    LEFT JOIN public.projects AS t
        ON CAST(r.top_project AS INT) = t.id
        AND t.site_id = XXX -- ご自身のsite_idを入力してください
    LEFT JOIN public."_users" AS u
        ON p.owner_id = u.id
ORDER BY
    t."name"
    , r.top_project
    , r.project_hierarchy
    , r.project_level
    , r.parent_project_id
    , r.project_id

取得したメタデータをもとにダッシュボードを作る

正直，組織の人が見やすいように自由に作っていいのですが，自分の場合は下記目的に沿って作りました。

「どのようなプロジェクトが作られているか」
「それぞれのプロジェクトがAsset Permissions: Lockedになっているか」
「Asset Permissions: Lockedになっていないプロジェクトのオーナーが誰か」

マスキング済のデータセットを使って，Tableau Publicにアップロードしたので，そちらを御覧ください。
このように作れば，左側のシート(NG Project Counter)をもとにアラートを設定することで，Asset Permissions設定がCustomizableになっているプロジェクトが発生したときに通知を受け取ることができます。

Project Setting Monitor

おわりに

2回にわたって，Tableau Serverのプロジェクト階層を活用したコンテンツ・マネジメントに関するTipsを紹介しました。AIやTableau Catalogを使えば，このあたりは楽になる可能性はありますが，個人的には人力で多くの情報を整理しなければ多くのユーザが満足するようなクオリティはそれらでも実現できないのでは，と思っているので，この2つの記事に記載したような細やかなテクニックを駆使していきたいですね。

余談

弊社では現在社員による楽天モバイルの紹介キャンペーンを実施しています！
2024/04/02現在，楽天カードとの同時申込で最大30,000ポイントを得られるチャンス(楽天カードをお持ちの方でも20,000ポイント)ですので，これを機にご確認いただけますと幸いです。気になることがあればわたくしまでご連絡ください。よろしくお願いいたします。
下記リンクより進んでいただき，ご自身の楽天会員情報でログインのうえ，ご申請ください。~~リンクが怪しすぎるのが良くないところ。~~
https://r10.to/hkeO5H

参照ドキュメント

Tableau Serverリポジトリでデータを収集する - Tableau

PostgreSQLコネクタ - Tableau

Tableau Server データディクショナリ (ワークグループデータベース) について - Tableau

URLの一部に含まれているバージョンを書き換えると，稼働させているTableau Serverのバージョンにあったカタログをみることができます。