TableuServer認定資格

dbt Fundamentalsの「Models」のセクションについて、理解した内容を言葉にしてみた。 かなりの部分で感想を織り交ぜてみた。この記事は前回の記事(以下)の続き。 [clink url=\"https://ikuty.com/2023/07/10/dbt-word/\"] 実践的なコンテンツというよりは、概念の理解を優先した入門用のコンテンツであって、 これでモノを作れることはないと思うし、資格対策には不足していると思う。 動画の講師の方は自己紹介で教師のバックグラウンドがあると話されている。 個人的にはUdemyの類似品より構成と英語の発音がわかりやすいと感じる。 [arst_toc tag=\"h4\"] クエリをバラして理解しやすいようにしたい 関数型言語は、関数が再起的に評価されることで最終的な応答が確定する。 手続き型言語と異なり、再帰の評価の途中で一時停止して内容を観察することが難しい。 SQLは関数型言語ではないが、内包するSQLの評価を一時停止して観察することが難しい、 という点で近い。制御がない一筆書きである点が複雑さから逃れる理由になっていそう。 ビジネスロジックが乗った巨大なクエリは確かに一筆書きではあるが、理解しづらい。 クエリをバラしたら理解しやすいんじゃね？　みたいな動機があるのだと思う。 ただバラして制御するとそれはもう手続きなので、バラすけど再利用するだけに留める。 バラして、途中経過を観察したり動きを制御したり、そういう仕組みをdbtが提供する。 Modularity クエリをバラすことを、dbtでは「Modularity(モジュール性)」という用語で説明している。 動画では「車の製造」が例えとして挙げられている。パーツとパーツを繋げて車を製造すると。 Modularityは構造化されていて、上流(Upstream)から下流(Downstream)へと繋がる。 Upstreamで作ったパーツをDownstreamで再利用する、という仕組み。 1個1個のパーツは、CTE(Common Table Expression)を利用して表現される。 CTEは標準SQLに定義されていて、クエリの再利用性を高める表現手段。 要は、dbtはCTEを使ってクエリの再利用性を強制するF/Wなんだろうと思う。 CTEと論理レイヤとモデル 実際に動作する生クエリを書くのではなく、論理的な記述レイヤを設けている。 論理レイヤの記述フォーマットとして、jinjaテンプレートが採用されている。 jinjaテンプレートにマクロを記述することで論理レイヤの表現能力を獲得している様子。 Modularityの観点でCTEで各パーツを定義し、Up->Downのフローを論理的に定義する。 dbtが論理レイヤをコンパイルして物理SQLを吐くという仕様になっている。 このパーツのことをdbtでは「モデル」と呼んでいる様子。 1個のSELECT文が1個のモデルと対応する制約が与えられる。 これにより、Up側モデルをDown側モデルで再利用することと、クエリ結果の再利用を紐付けている。 Materialization パーツは個別に具体的なSQLにコンパイルされる。これには「Materialize」という用語が付いている。 Upstream側を実体化する際、その実体化の手段を選択できる。 View モデルをViewとして実体化する。実データを作らないので作るのが速いしストレージを食わない。 Viewに乗ったロジックが複雑だと所要時間が増えるので、その場合はTableの採用を考える。 CREATE VIEW AS ... が使われる。 Table モデルをTableとして実体化する。実データを作るので作るのに時間がかかるしストレージを食う。 ロジックが複雑であっても所要時間が増えない。BIから直接参照するとかならTableの採用を考える。 Up側にあるデータに追加や変更があっても反映されない。 CREATE (TRANSIENT) TABLE AS ... が使われる。 Incremental パイプラインを構築する際、「置き換え」なのか「増分」なのかは重要な観点となる。 初回生成時は通常のTableとして、2回目移行は増分だけを生成する。なので速い。 「増分」とする場合、どこが既存と増分の境界なのかを定義する必要がある。 その定義をモデルファイルに書く必要があり、若干複雑になる。 Ephemeral 中間テーブルをいちいちViewやTableに実体化し続けると、DWが再利用する可能性が低い何かで 埋め尽くされてしまうことがある。そういったテーブルはModularityの中で論理的に再利用したいが、 物理的に存在して欲しくない。それを実現できる。 Downstream側で1個か2個使うだけで、直接クエリを実行する必要がない場合に使うと良い。 モデルの例 動画では以下のクエリをdbt流に書く例が示されている。 以下は生クエリで、with句により3個のクエリを用意し4個目のクエリで結合している。 with customers as ( select id as customer_id, first_name, last_name from raw.jaffle_shop.customers ), orders as ( select id as order_id, user_id as customer_id, order_date, status from raw.jaffle_shop.orders ), customer_orders as ( select customer_id, min(order_date) as first_order_date, max(order_date) as most_recent_order_date, count(order_id) as number_of_orders from orders group by 1 ), final as ( select customers.customer_id, customers.first_name, customers.last_name, customer_orders.first_order_date, customer_orders.most_recent_order_date, coalesce(customer_orders.number_of_orders, 0) as number_of_orders from customers left join customer_orders using (customer_id) ) select * from final さて、次はdbtの論理レイヤの話。まずcustomersとordersをを別のファイルに記述する。 with customers as ( select id as customer_id, first_name, last_name from raw.jaffle_shop.customers ) select * from customers with orders as ( select id as order_id, user_id as customer_id, order_date, status from raw.jaffle_shop.orders ) select * from orders customersとordersを結合する。その際、customersとordersをref関数により参照する。 言い換えると、以下が評価される時点で、既にcustomersとordersは実体が存在する。 そのため、以下を評価する前に、customersとordersの中にあるデータを確認できる。 with customers as ( select * from {{ ref(\'stg_customers\')}} ), orders as ( select * from {{ ref(\'stg_orders\') }} ), customer_orders as ( select customer_id, min(order_date) as first_order_date, max(order_date) as most_recent_order_date, count(order_id) as number_of_orders from orders group by 1 ), final as ( select customers.customer_id, customers.first_name, customers.last_name, customer_orders.first_order_date, customer_orders.most_recent_order_date, coalesce(customer_orders.number_of_orders, 0) as number_of_orders from customers left join customer_orders using (customer_id) ) select * from final dbt runコマンドにより、全てのモデルをコンパイルする。 また --selectをつけると、、特定のモデルだけコンパイルできる。 dbtには下図のようにモデル間の依存関係をグラフィカルに表示する機能がある。 モデリングの方法論とdbtの仮定 dbtは単なるクエリの変換ツールであって、現実世界のモデルする方法論を規定するものではない。 しかし、動画ではモデルのセクションでチラッとこの話に触れられている。 Fact TableとDimensional Tableに整理してDimension毎のFactを提供しましょう、 という流儀や、Kimball,Data Vaultのような流儀など、諸々存在する。 動画では、これらをTraditionalと分類し正規化がポイントであると言っている。 コンピューティングとストレージが安くなり、ELTが可能になったおかげで、 \"正規化しない(Denormalized)\"モデリング手法が実現可能になりましたよ、と言っている。 むむ.. 相当深そうだが入り口だけ。 いったん、ELTを前提としてモデルを組み上げてください、ぐらいの話として聞き取る。 ELTを前提として、モデルをこうレイヤリングし名前を付けますよと話されている。 Source ELTであるが故に、外部のデータを無変換でDWに格納したところからスタートする。 そのレイヤを「Source」と名付ける。 Staging Sourceレイヤのモデルのクレンジングと標準化を行うレイヤを「Staging」と名づける。 StagingモデルはSourceモデルと1:1対応させる。 Intermediate Stagingモデルに対してビジネスロジックを適用して最終的なテーブルを生成する。 ビジネスロジックはダラダラと汚く大きくなることが常で、このレイヤで吸収する。 Fact 起きていること、または、既に起きたこと。履歴があるもの。 なんたらイベント、Webサイトにおけるクリック事象、投票など。 Dimension 時間の経過で発生するものではない履歴がない事象。 人、場所、コト、ユーザ、会社、製品、、顧客など。 以下は、動画で話されている実行例。 dbt-labs/jaffle_shop https://github.com/dbt-labs/jaffle_shop 一番左の緑色のモデルがSource。外部から引っ張ってきたRawデータ。 Sourceと1対1対応する形で、「stg_*」という名前のStagingモデルが存在する。 Sourceに対してクレンジング、標準化を適用したデータ。 「fact_*」は、時間経過により発生する履歴データ、そして、「dim_*」は属性データ。 Down側からUp側へ、Source->Staging->Fact/Dimension という流れになっている。 よもやま話(動画と関係なし) 例えばLaravel/EloquentやRails/ActiveRecordにはQuery Builderが付いていて、 手続き型言語によってクエリのModularityを得るアプローチには既視感があると勝手に思っている。 もちろんクエリ結果をDWに統合できないから、DWに統合できるF/Wが必要なので、 そのアプローチはSnowflakeで言えばSnowparkによって扱われるのかなと思う。 手続き型言語ではソフトウエア開発の複雑さから逃れられないことになっている。 ちなみにORMにおける物理テーブルの抽象化において「モデル」という用語が充てられている。 少なくとも1990年代後半にはORMの文脈で物理テーブルを抽象化する概念は実用化されていた気がする。 2000年代には、オブジェクト指向分析設計の文脈で「現実世界のモデル化」がイキりたおされていた。 2010年代、Laravel/Eloquent, Rails/ActiveRecordでORMのモダニズムが言われてた。 手続きに持ち込まず、SQLの世界だけでモデル化が話されるのは新しい気がする。 ここは最初の「Analytics Engineers」の話に由来している気がする。 まとめ dbt Fundamentalsの「Models」セクションを聴いて、内容を文書化してみた。 dbtはModularityと考え方に基づいてCTEによりクエリをバラすツールであることについて、 Modelの定義や実行例を追って確認してみた。

ソースはオンラインヘルプ. なんとなくFileMakerServerを思い出した. 1. 事前準備 1. 組織全体でDesktopとServerのバージョンを揃える. 2020.2など. 1. プロダクトキーを取得しておく. 1. クリーンな環境にインストールする. 理由はパフォーマンス,セキュリティ,相互運用性. 1. インストール手順 1. Setupファイルを実行 1. インストールパスの設定 (規定:C:Program FilesTableauTableau Server) 1. ゲートウェイポートの設定 (規定:80) 1. 取得済みのプロダクトキーを登録する 1. アイデンティティストアとSSO 1. ローカル/ActiveDirectory 1. ActiveDirectoryの構成 => Domain:完全修飾子(FQDN)/NetBios:FQDNの一番左のノード 1. ローカル認証 1. アイデンティティストア内のユーザ名は権限・パーミッションと紐づけられている. 1. 認証が検証された場合にTableauServerはTableauリソースへの認可をおこなう. 1. パスワードは直接保存されない. ハッシュ値が保存される. 1. SAML (SecurityAssertionMarkupLanguage) 1. セキュアなWebドメインがユーザ認証と認可データを交換するXML規格. 1. 外部のアイデンティティプロバイダ(IdP)とSAML2.0でユーザ認証できる. 資格情報はTableauServerが持たない. 1. サーバ全体のSAML認証, サイト毎のSAML認証. 1. Kerberos 1. KDC(キー配布センター)の使用に依存した3要素認証プロトコル 1. ActiveDirectoryのKerberos環境でKerberos認証をサポート. KerberosがTableau Serverへの認証を処理する. 1. ユーザはADDomainController(Kerberos KDC)にログイン. KerberosKDCからチケットを取得. チケットを使用してTableauにログイン. 1. Kerberos認証はユーザ認証のみ.コンテンツ等の内部許可,認可は処理しない. 1. OpenID Connect 1. GoogleなどのIdPにサインインできるようにする標準認証プロトコル. 1. IdPにログイン後, TableauServerに自動的にTableauServerにサインインする. 1. Tableau ServerはOpenID Authorization Code Flowのみをサポートする. 1. 信頼できるチケットと認証 1. TableauServerのViewを含むURLを開く. Webサーバは信頼できるTableauServerにユーザ名を送る. 1. TableauServerは受けたPostが管理下のIPアドレスか否かを確認しOKであればチケットを発行してWebサーバに応答する. 1. Webサーバはチケットを含むビューのURLを生成しブラウザに返す. 1. ブラウザは返ってきたURLをTableauServerに送る. 1. TableauServerはチケットを引き換えてセッションを作成しビューの最終的なURLをクライアントに返す. 1. SSL の設定方法 1. SSLの範囲 1. 外部HTTPトラフィックに対してSSLを使用する. 1. Client(Desktop,Web,tabcmd)/Server間のトラフィックに対してSSLを使用する. 1. コンポーネント間とリポジトリの間の全てのHTTPトラフィックをSSL化する. 1. ユーザ認証にSSLを使用する. ホストされているコンテンツのパーミッションや認証処理には使用されない. 1. SSL証明書の要件. PEM,X509X,SHA-2. 対応するkey,chainも必要. ワイルドカード証明書も可能. 1. 設定手順 1. キーファイルとCSRを生成. 1. TableauServer内のビルトインWebサーバ(Apache)ディレクトリでopensslコマンドを実行. 1. CAにCSRを送信してSSL証明書を取得. 1. キーファイルとSSL証明書をTableauServerに設定. 1. クラスタのSSL構成. \"最初のノード\"にのみゲートウェイプロセスが存在. このノードでのみSSL設定が必要. 1. Gatewayが複数ある場合はロードバランサにSSL設定. 手前にパススルーロードバランサを配置し個別にSSL設定もできる. 1. 証明書を C:Program FilesTableauTableau ServerSSL に保存. 1. TSM Web > [構成] > [セキュリティ] > [外部SSL] > [外部WebサーバのSSL] > [SSLでサーバ通信を有効にする]を選択 1. 証明書ファイル(.crt,.chain)をアップロードし,必要であればkeyfileのパスコードを入力. 1. マルチノード構成の場合, 最初のノードへの操作だけで必要な全てのノードに証明書が配布される. 1. [保留中の変更を保存] -> [変更を適用して再起動]. 1. 単一マシン環境インストールのベストプラクティス 1. 全てのプロセスが1台のマシン上にインストールされたスタンドアロンの単一サーバノード. 1. 8コアCPUの場合 1. VizQL Server : 2 instances (物理コア数/4) 1. Backgrounder, CacheServer, DataServer : 2 instances 1. その他のプロセス: 1 instance each. 1. サイレントインストール 1. オンラインヘルプ上の表記は「自動インストール」 1. オンラインコミュニティでサポートされているPythonスクリプト(SilentInstall.py)を実行する. 1. 自動インストールの実行に必要な追加構成情報を用意 1. config.template.json, registration.template.json, secrets.template.json 1. templateをhomeにコピーし編集 1. 最初のノードでSilentInstall.pyを実行する. 実行パラメタに追加構成情報ファイルのパスを渡す.

Dictionaryの基本 いわゆるKey-Valueのことを\"Mapping\"と呼ぶ。 PythonのDictionaryはハッシュで実現されている。 キーにはハッシュ可能オブジェクトを指定可能。ハッシュ可能=更新不可、という意味ではない。 例えばオブジェクトのインスタンスのように中身が変わっても枠が変わらなければOK。 rgbs = { (255,0,0): \'red\', (0,255,0): \'green\', (0,0,255): \'blue\' キーは重複不可。同じキーを登録すると前のKeyValueが上書きされる。 kv = { \'hoge\': 100, \'fuga\': 200 } print(kv) # {\'hoge\': 100, \'fuga\': 200} kv[\'hoge\'] = 300 print(kv) # {\'hoge\': 300, \'fuga\': 200} DictionaryのCRUD d = {\'hoge\':100,\'fuga\':200} # Create print(d[\'hoge\']) # Read d[\'hoge\'] = 300 # Update del d[\'hoge\'] # Delete d2 = dict([(1,\'hoge\'),(2,\'fuga\')]) print(d2) # {1: \'hoge\', 2: \'fuga\'} d3 = dict(hoge1=\'hoge1\',hoge2=\'hoge2\',hoge3=\'hoge3\') print(d3) # {\'hoge1\': \'hoge1\', \'hoge2\': \'hoge2\', \'hoge3\': \'hoge3\'} 辞書内包 List,Tupleと同様に内包式を書ける。 s = [\"Hoge1\",\"Hoge2\",\"Hoge3\"] k1 = {} for v in s: k1[v] = v.lower() k2 ={v.lower() for v in s} Operator Dictionaryに対する演算。 d = {\"hoge\":100} print(\'hoge\' in d) # True print(\'fuga\' not in d) # True print(len(d)) # 1 iteration中に別のkeyへのアクセスは不可 こういうことは避けるべきだけれども、実際にやるとRuntimeエラー。 d = {\'hoge1\':100,\'hoge2\':200,\'hoge3\':300} for key in d: d[\'hoge4\'] = 500 # RuntimeError: dictionary changed size during iteration ViewObject キーの集合、値の集合を参照するためのデータ構造。 Viewというからには、Dictionary内に含まれる実体を参照している。 ViewObjectは集合演算をサポートしている。 d = {\'hoge1\':100,\'hoge2\':200,\'hoge3\':300} view1 = d.keys() for key in view1: print(key) # hoge1 hoge2 hoge3 del d[\'hoge2\'] for key in view1: print(key) # hoge1 hoge3 view_x = view1 - [\'hoge1\',\'hoge2\'] print(view_x) # {\'hoge3\'} view2 = d.values() for value in view2: print(value) # 100 200 300