記事・メモ一覧

やはりAWSの公式のドキュメンテーションは読みやすいので、 公式を上から順に舐めていくスタイルで理解していく。 今回は一番最初のアーキテクチャ概要。 [arst_toc tag=\"h4\"] アーキテクチャ 大きなデータを扱おうとする何かは分散アーキテクチャで解決しようとする。 と言っても、大抵は\"代表するノード\"と\"ワーカーノード\"のセットなのでデジャブ感がある。 ちなみにTableauServerが内部設計を細かく書いていて面白かった。 以下、Amazon Redshiftのアーキテクチャを表す図. (公式) Amazon Redshiftは複数のクラスタから構成される。 クラスタはリーダーノードと複数のコンピューティングノードから構成される。 クライアントアプリケーションからは唯一リーダーノードと呼ぶノードを参照できる。 コンピューティングノードはクライアントアプリケーションから見えない場所に配置されリーダーノードが代表してコンピューティングノードを操作する。 リーダーノード クライアントアプリケーションは PostgreSQL用の JDBC/ODBCドライバを使用してリーダーノード通信できる。 実行計画に基づいてコードをコンパイルしコンパイル済みのコードをコンピューティングノードに配布してからデータの一部を各コンピューティングノードに割り当てる。 コンピューティングノード コンパイル済みのコードを実行し中間結果をリーダーノードに返送する。 中間結果はリーダーノードで最終的に集計される。 コンピューティングノードのCPU、メモリ、ストレージはノードのタイプによって異なる。ノードの数、種類を増強することでスケールアップできる。 ノードスライス コンピューティングノードはスライスに分割されている。 各スライスにはノードのメモリとディスク容量の一部を割り当てられている。 リーダーノードがスライスへのデータ分散を管理し、クエリ、データベース操作のワークロードをスライスに分配する。 スライスは並列処理を行って操作を完了する。 内部ネットワーク リーダーノードとコンピューティングノードの間はプライベートで非常に高速なネットワーク。 コンピューティングノードは独立したプライベートネットワークに配置される。 RDBとの互換性 Amazon Redshift は PostgreSQLを大規模データ用に拡張したミドルウェアである。 標準的なRDBMSと同様にデータの挿入、削除、トランザクション処理を実行できる。行指向から列指向に拡張されており、行指向を前提としたクエリは苦手。

Hello World. docker-composeを使ってコンテナ間の繋がりを定義してみるデモに超速で入門する。 ゼロから書くと不要な時間を要するので、こちらを参考にさせていただいた。 写経する中でポイントを咀嚼していく。 ~/dockercompose_test というディレクトリを作成し、 その中で作業する。 docker-compose.yml 構成を記述する設定ファイル。ymlで書く。 ansibleでymlには慣れているので嬉しい。 version: \"3\" services: db: image: mysql:5.7 #container_name: \"mysql57\" volumes: - ./db/mysql:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: root_pass_fB3uWvTS MYSQL_DATABASE: wordpress_db MYSQL_USER: user MYSQL_PASSWORD: user_pass_Ck6uTvrQ wordpress: image: wordpress:latest #container_name: \"wordpress\" volumes: - ./wordpress/html:/var/www/html - ./php/php.ini:/usr/local/etc/php/conf.d/php.ini restart: always depends_on: - db ports: - 8080:80 environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_NAME: wordpress_db WORDPRESS_DB_USER: user WORDPRESS_DB_PASSWORD: user_pass_Ck6uTvrQ ルートはservices. 名称の理解がフワフワだが、コンテナをサービスと読んでいることが多いくらいの認識. 配下に db と wordpress が存在する。おなじみの構成を定義している。 db dbの定義についてパラメタを追っていく. パラメタ 値 説明 image mysql57 pull してくるイメージを書く. mysql57という名前のイメージをpullする. volumes - ./db/mysql:/var/lib/mysql コンテナ内の/var/lib/mysql を ホストの./db/mysql にマウントする(で良いか?) restart always 再起動ポリシー(コンテナ終了時に再起動するための仕組み)を設定する.再起動ポリシーを設定しておくことで、Dockerデーモンの起動時やホストOSの起動時に自動的にコンテナを開始できる。 alwaysの他にいくつかあるか今はスキップ. environment MYSQL_ROOT_PASSWORD: root_pass_fB3uWvTSMYSQL_DATABASE: wordpress_dbMYSQL_USER: userMYSQL_PASSWORD: user_pass_Ck6uTvrQ コンテナの環境変数を定義する. 環境変数名はコンテナ依存. wordpress wordpressの定義についてパラメタを追っていく. パラメタ 値 定義 image wordpress:latest pull してくるイメージを書く. wordpressという名前のイメージをpullする. バージョンは最新. volumes ./wordpress/html:/var/www/html./php/php.ini:/usr/local/etc/php/conf.d/php.ini コンテナ内のディレクトリをホストのディレクトリにマウントする.マウント先を定義する. restart always 再起動ポリシーをalwaysに設定.内容はdbと同じ. depends_on - db サービスの依存関係を定義する.要は起動する順番を定義する. wordpressのdepends_onにdbを設定することで,wordpressよりも先にdbを起動できる.dbの起動が完了するまで待ってくれるという意味ではない! Control startup and shutdown order in Compose. ports 8080:80 コンテナの80番をホストの8080にマップする. http://localhost:8080 とかするとコンテナの80番が開く. environment WORDPRESS_DB_HOST: db:3306WORDPRESS_DB_NAME: wordpress_dbWORDPRESS_DB_USER: userWORDPRESS_DB_PASSWORD: user_pass_Ck6uTvrQ wordpressコンテナの環境変数を設定する.環境変数はコンテナ依存. docker compose up 以下で定義したdocker-compose.ymlに基づいて構築が始まる. -dはDetachedMode. これによりバックグラウンドで実行される. $ docker-compose up -d ホストで http://localhost:8080 を開くと以下の通り. 永続化の確認 言語を設定しwordpressのインストールを完了させる. db(MySQL)に加えられた変更はホストにマウントされたファイルに反映される. 以下により環境を停止した後, 再度upしたとしても, ホストにマウントされたファイルへの変更が反映され, インストール済みの状態で立ち上がる. $ docker-compose down $ docker-compose up -d まとめ docker-compose を使った WordPress環境構築のデモに超速で入門した. 一緒にコンテナを永続化するデモにも入門した.

最小の手数でHello world. とりあえず最小の手数でwordpressを起動してみる。 イメージのダウンロード docker pullでMySQLとWordPressのイメージをダウンロードする。 イメージはサービス単位。 \"MySQL\"を実現するためのOSとミドルウェア。 \"WordPress\"を実現するためのOSとミドルウェア。例えばWebサーバも含んでいる。 まずはMySQL。 $ docker pull mysql:5.7.21 5.7.21: Pulling from library/mysql 2a72cbf407d6: Pull complete 38680a9b47a8: Pull complete 4c732aa0eb1b: Pull complete c5317a34eddd: Pull complete f92be680366c: Pull complete e8ecd8bec5ab: Pull complete 2a650284a6a8: Pull complete 5b5108d08c6d: Pull complete beaff1261757: Pull complete c1a55c6375b5: Pull complete 8181cde51c65: Pull complete Digest: sha256:691c55aabb3c4e3b89b953dd2f022f7ea845e5443954767d321d5f5fa394e28c Status: Downloaded newer image for mysql:5.7.21 docker.io/library/mysql:5.7.21 次にWordPress。何も指定しないと最新が落ちる様子。 $ docker pull wordpress Using default tag: latest latest: Pulling from library/wordpress bb79b6b2107f: Pull complete 80f7a64e4b25: Pull complete da391f3e81f0: Pull complete 8199ae3052e1: Pull complete 284fd0f314b2: Pull complete f38db365cd8a: Pull complete 1416a501db13: Pull complete be0026dad8d5: Pull complete 7bf43186e63e: Pull complete c0d672d8319a: Pull complete 645db540ba24: Pull complete 6f355b8da727: Pull complete aa00daebd81c: Pull complete 98996914108d: Pull complete 69e3e95397b4: Pull complete 5698325d4d72: Pull complete b604b3777675: Pull complete 57c814ef71bc: Pull complete ed1877bc3d14: Pull complete 673ead1d3971: Pull complete Digest: sha256:46fc3c784d5c4fdaa46977debb83261d29e932289a68739f1e34be6b27e04f87 Status: Downloaded newer image for wordpress:latest docker.io/library/wordpress:latest MySQLコンテナを起動 コンテナ(イメージ)を起動する。 $ docker run --name test-mysql -e MYSQL_ROOT_PASSWORD=test-pw -d mysql 013a2eb6b5b1c0b0f61e85cace6540ec036be80c9f85e8c9b5ed3e114a4cc8e8 パラメタは以下の通り。 Option Value 説明 --name test-mysql コンテナに名前を付ける。この例であれば test-mysql -e MYSQL_ROOT_PASSWORD=test-pw コンテナの環境変数を設定する。MYSQL_ROOT_PASSWORDという環境変数としてtest-pwを設定 -d - DetachedMode(Background)を指定する。指定がない場合Foregroud. WordPressコンテナを起動 WordPressコンテナを起動する。 $ docker run --name test-wordpress --link test-mysql:mysql -d -p 8080:80 wordpress a1301075d3667de7eddd9edc0c46edaeb4346a5c46ef444538c9cf9987f31471 パラメタは以下の通り。 Option Value 説明 --link test-mysql:mysql コンテナを連携させる。書式は --link [コンテナ名]:[エイリアス]。test-mysqlがコンテナ名(前述)で、mysqlがそのエイリアス。 -p 8080:80 HostとGuestのポートマッピング。Hostの8080をGuestの80にマッピングする。 Hostの8080にWordPressコンテナ内の80がマップされた。 http://localhost:8080/ でWordPressの言語選択画面が表示される。 非同期で起動したコンテナにアタッチ docker execで非同期に起動したWordPressコンテナ内のディレクトリにアクセスできる。 この例だと/var/www/html。 ゴニョゴニョいじると変更が反映される。 $ docker exec -it test-wordpress /bin/bash root@a1301075d366:/var/www/html# もちろん、コンテナを落とすと変更は失われる。 まとめ DockerでWordPressを動かすデモに超速で入門した。

型 基本型 全ての変数はオブジェクト。用意されている型は以下の通り。 数値型は int と double。 int IS num, double IS num となる num型がある。 論理型は bool 文字列型は String リストは　List<T> 連想配列は Map<K, V> Runes,Symbolもあり Gneric型とdynamic Generic型がある。 List list = [1, 2, 3]; List list2 = [\'a\', 100, 3.14]; int, double など, どの型を使うか想定はあるが Dart言語で表現できない場合に dynami型を使う。 何型となるか想定がない場合, 全ての型の基底型である Objectを使う。 型推論 var で宣言して, 式の評価時に型を決める。 以下, x はforEachで初めて int であることが決まる。 var hoge = \"hogehoge\"; [1, 2, 3].forEach((x) => print(x*2)); 変数 Non Null By Default (NNBD) NNBDがOFFの場合、変数のデフォルト値は Null。 変数に Null を代入できるし, 変数は Nullになる可能性がある。 NNBDがONの場合、あえて指定しなければ Nullにすることはできない。 int x = Null; //コンパイルエラー int? x = Null; //OK FlutterでNNBDを有効にするには、 プロジェクトディレクトリの下にある analysis_options.yaml を書き換える。 analyzer: enable-experiment: - non-nullable finalとconst finalを付けると変数宣言時以外で値が書き換わらないことを保証できる。 変数が指しているメモリが書き換わらないことは保証していないので、 例えば以下のようにfinalなListの要素を書き換えることはできる。 final List l = [1,2,3]; l[1] = 10; //OK constを付けると値がコンパイル時に確定していることを表せる。 finalに加えて変数が指しているメモリが書き換わらないことも保証する。 const List l = [1,2,3]; l[1] = 10; //ng 可視性識別子 Dartには可視性識別子はない。プレフィックスとして _ を書くと可視性が下がる. 関数 基本形とシンタックスシュガー 関数の書き方。 戻り値の型 functionName(引数の型 引数) { return 戻り値; } 戻りが式の場合、まとめて書ける。 戻り値の型 functionName(引数の型 引数) => 式; void main() { print(getReverseValue(true).toString()); print(getReverseValue2(true).toString()); } bool getReverseValue(bool x) { return !x; } bool getReverseValue2(bool x) => !x; 名前付きパラメータ 引数に名前を付けて、呼ぶときに名前毎に値を渡せる。 名前付きパラメータは任意となる。 戻り値の型 functionName({引数の型 引数1, 引数の型 引数2}) { return 戻り値; } functionName(引数1: hoge, 引数2: fuga); void main() { print(myFunction(param1: 100, param2: \"hoge\")); print(myFunction(param1: 500)); // param2は任意だが myFunction内で参照してエラー } String myFunction({int param1, String param2}) => param1.toString() + param2;

ubuntuの場合、postgresユーザのホームディレクトリは /var/lib/postgresql 。 例えば .pgpass をここに置くと、postgres ユーザで psql を実行した場合でも読んでくれる。 ホームディレクトリが無い理由 プログラムを実行するために作成されたユーザとコンソールログインするユーザは扱いが違う。 例えば nginx、mysql のように PostgreSQL の実行ユーザである postgres のホームディレクトリは、 PostgreSQL の maintainer が決める。 /home/postgres というディレクトリは作られない。 PostgreSQLは, root の代わりに postgres ユーザを使ってり様々な処理をおこなう. ホームディレクトリはどこ？ PostgreSQLのインストールディレクトリがホームディレクトリ。 ubuntuの場合、PostgreSQLは /var/lib/postgresql にインストールされていて、 /var/lib/postgresql がホームディレクトリ。 データディレクトリの調べ方 PostgreSQLのデータベースファイルのレイアウトによると、 データディレクトリに全てのファイルが格納される。 postgres の起動パラメタとして データディレクトリ が指定されている。 (-D) 以下の例だと、/var/lib/postgresql/9.5/main。 $ ps ax | grep postgres | grep -v postgres: 1377 ? S 0:01 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf 10600 pts/0 T 0:00 sudo -s -u postgres 11930 pts/0 S+ 0:00 grep --color=auto postgres 別の方法として、psql から SHOW data_directory を実行することで データディレクトリを得られる。 やはり、/var/lib/postgresql/9.5/main。 $ sudo -s -u postgres $ psql postgres=# SHOW data_directory; data_directory ------------------------------ /var/lib/postgresql/9.5/main (1 row) ホームディレクトリの下の階層にデータディレクトリが出来ている。 /home/以下が作られないユーザについて(Stackoverflow) Why Directory for postgres user does not appear inside the HOME directory in linux with other users? [closed] That there is a dedicated user for PostgreSQL is a security measure, so the DB processes can run with that user\'s (limited) priviledges instead of running as root. Whether or not you can actually log on with that user, and what that user\'s home directory should be, is the decision of the package maintainer / the Linux distribution in question. Since the postgresql user should not be (ab-) used as just another user (with own desktop settings, user data etc.), I wouldn\'t question the wisdom of not giving it a home, but rather why he is enabled to log in in the first place. Edit: Being ignorant of the fine print of PostgreSQL, and a bit confused by the wording of your question, I argued the general case. Ignacio pointed out that you had to actually break the system (unlock the user\'s password with root priviledges) to even be able to log in as postgresql user. So the answer can be phrased even simpler: The user does not have a directory in /home because you are not supposed to ever log in as that user. It\'s for running the database processes without root priviledges, nothing else. (Note that you could, using the same technique, log in as user man, or user lp, or user mail. You could, but it wouldn\'t make sense, and unlocking those user\'s passwords actually weakens the security of your system.)

セッション毎にプロセスが動いている。 pg_terminate_backend()を使ってプロセスを落とせば良い。 動いているプロセスを落とせばセッションは切れる。 killで落とすと上手くいかないので注意。 基本形 基本形は以下の通り。 $ sudo -s -u postgres $ psql postgres=> select pg_terminate_backend({プロセスID}); 通常、セッションは複数存在するため、切りたいセッションのプロセスIDを選択して pg_terminate_backend()に渡す必要がある。 自分以外全部切る 生きているセッションをpg_terminate_backend()(後述)を使って探し、 pg_terminate_backend()に食わせて落とす。 自分自身のpidは pg_backend_pid() で得られる。 $ sudo -s -u postgres $ psql postgres=> SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = \'DB名\' AND pid pg_backend_pid(); datnameはTypoではない! 動的統計情報ビュー 上で使っているpg_stat_activityは動的統計情報ビューというビルトインのビューの一つ。 27.2.2. 統計情報の表示。 サーバ当たり１行の形式で、 状態や現在の問い合わせ等のプロセスの現在の活動状況に関連した情報を表示する。 取れるデータ達は以下の通り。PostgresSQLのバージョンによって異なるが、 よく使いそうなものは変わらなそう。使う場合には要注意。 postgres=> d pg_stat_activity; View \"pg_catalog.pg_stat_activity\" Column | Type | Modifiers ------------------+--------------------------+----------- datid | oid | ; バックエンドが接続するデータベースのOID datname | name | ; バックエンドが接続するデータベースの名前 pid | integer | ; バックエンドのプロセスID usesysid | oid | ; バックエンドにログインしたユーザの識別子 usename | name | ; バックエンドに接続したユーザの名前 application_name | text | ; バックエンドに接続したアプリケーションの名前 client_addr | inet | ; バックエンドに接続したクライアントのIPアドレス client_hostname | text | ; client_addrの逆引き検索により報告された、接続クライアントのホスト名 client_port | integer | ; クライアントがバックエンドとの通信に使用するTCPポート backend_start | timestamp with time zone | ; プロセスが開始、つまりクライアントがサーバに接続した時刻 xact_start | timestamp with time zone | ; プロセスの現在のトランザクションが開始した時刻 query_start | timestamp with time zone | ; 現在有効な問い合わせが開始した時刻 state_change | timestamp with time zone | ; stateの最終変更時刻 wait_event_type | text | ; he type of event for which the backend is waiting wait_event | text | ; Wait event name if backend is currently waiting, otherwise NULL. state | text | ; Current overall state of this backend backend_xid | xid | ; もしあれば、このバックエンドの最上位のトランザクション識別子 backend_xmin | xid | ; 現在のバックエンドのxmin query | text | ; バックエンドの最も最近の問い合わせテキスト backend_type | text | ; Type of current backend

以下の項目についてオンラインヘルプをまとめてみた. 工数1日程度の理解なのと無理やり1行に詰めた感は否めないのですが, そもそも自分用なのでご容赦を... ハードウェア要件 ソフトウェア要件 ライセンス サーバプロセス 分散環境と高可用性 データソース 1. 全ての技術仕様. https://www.tableau.com/ja-jp/products/techspecs 1. ハードウェア最小要件 1. 最低要件 RAM 16GB, CPU x64 空きディスク容量 15GB, コア数は物理コア. HTは考慮されない. 1. 本番シングル RAM 32GB, CPU x64 8コア 2.0GHz以上 空きディスク容量 50GB. 1. 本番マルチ 運営に聞いてね. 1. ソフトウェア要件 1. サポートするOS WindowsServer2012,2012R2,2016,2019, AmazonLinux2, RHEL7.3,CentOs7.3+,Debian9+,OracleLinux7.3,ubuntu16.04LTS,18.04LTS 1. ブラウザ Chrome(Windows,Mac,Android),MS Edge,IE11,FireFox,Safari, + Tableau Mobile 1. メールアラートのオプション STMPをセットアップする必要あり. TLS有効化によりSMTP TLSを透過的に使用可. 1. ウイルス対策の懸念事項 TableauServerのインストールや使用に干渉する可能性あり. 公式がプログラムフォルダ,データフォルダを除外する案内を実施. 1. TCPポート.TSM=8850,TS GW=80.TS GWをSSLとする場合443. 1. 専用サーバーの目的と利点. パフォーマンス. セキュリティ. 相互運用性. https://help.tableau.com/current/guides/everybody-install/ja-jp/everybody_admin_install.htm 1. クラウドで稼働させる際の検討事項. オンプレミスと比較してハードウェアコスト不要.アップタイム,信頼性,耐故障性が良い. AWS,Azure,GCP,AlibabaCloud(?)の4環境のガイドあり. 1. ライセンス発行 1. ライセンスタイプはコア毎,ユーザ毎の2種類.ユーザライセンスの場合,\"ライセンス\"-\"サイトロール\"-\"パーミッション\"によるアクセシビリティマトリクス(的なもの)を作れる. 1. ライセンスタイプ=>Creator,Explorer,Viewer.の3種類. 1. Creator=>コンテンツ作成,データソース設計,サイトロールとパーミッション設計.パブリッシュ.PrepBuilder.管理者向け.TableauServerを管理. 1. Explore=>PrepBuilderNG.パブリッシュNG.既存のデータソースの使用,既存のデータソースを使ったダッシュボードの作成.TableauServerのコンテンツを管理. 1. Viewer=>パブリッシュ済みのダッシュボードを表示する.自分でダッシュボードを作らない. 1. サイトロール=>サイトに対してユーザが持つことができる最大のアクセスレベル.サイトロールの最大の権限をユーザが利用できるかはコンテンツに設定されているパーミッションによる. 1. Creatorライセンスを使用するサイトロール 1. サーバ管理者=>TableauServerでのみ使用可能.OnlineではNG.全てのコンテンツに対して無制限のアクセス権. 1. サイト管理者Creator=>Onlineでも可能.サイトレベルのアクセス権を除く.サイトが用意された前提で全てのアクセス権. 1. Creator=>管理者以外では最大のアクセスレベル.ブラウザでの外部データへの接続など 1. Explorerライセンスを使用するサイトロール 1. サーバ管理者=>TableauServerでのみ使用可能.OnlineではNG.管理者ユーザ作成時にサーバで認証された最大のライセンスタイプがExploreの場合,CreatorではなくExploreのサーバ管理者になる. 1. サイト管理者Explorer=>Onlineでも可能.既存のデータソースを使用して既存のワークブックの編集・保存をおこなえる. 1. Explorer(パブリッシュ可能)=>既存のデータソースを使用してWebからワークブックをパブリッシュする. 単なるExploreに記述された特記事項ができる. 1. Explore=>Webからワークブックに埋め込まれたデータソースから新しいスタンドアロンデータソースを保存できない.もちろん新規にデータソースを作成できない. 1. Viewerライセンスを使用するサイトロール 1. Viewer=>既存のパブリッシュ済みのビューを表示する.データへの接続,コンテンツの作成,編集,パブリッシュ,データアラートの設定などできない. 1. ライセンスなし 1. サインインできない. CSVからのインポート時, ユーザ追加時に利用可能なライセンスが無い場合.など. 1. コンテンツをパブリッシュできる人物 => サーバ管理者,サーバ管理者Creator,Creator, Explore(パブリッシュ可能),サイト管理者Explore 1. サーバプロセス 1. TableauServiceManager(TSM).インストール後の初期構成.設定変更.トポロジ変更.継続的な(日常的な?)構成管理.バックアップの復元,ログ圧縮,管理タスクの実行など. 1. TableauServer実行に開始(running),停止じに停止(stopping). 1. アプリケーションサーバ. WebアプリケーションおよびREST APIを処理.参照と検索をサポート. 1. \"データに聞く(AskData)\". 1. バックグラウンダー => 抽出の更新,サブスクリプション,\"今すぐ実行\",tabcmdから実行するタスクなどを実行. 1. キャッシュサーバ => クラスタ全体でクエリと結果を分散/共有. アプリケーションサーバ,データサーバがリクエスト. 1. クラスタコントローラ => 各種コンポーネントの監視,障害検出,フェイルオーバーの実行. 1. データエンジン => データ抽出を作成.クエリを処理する. 1. データサーバ => データソースへの接続を管理する. 1. データソースプロパティ => 「データに聞く」等のクライアントサービスに,パブリッシュされたデータソースのメタデータを提供する. 1. ElasticServer => 「データに聞く」がデータをインデックスするために使用する. 1. ファイルストア => ローカル,SAN,NASなどストレージを抽象化する. 1. ゲートウェイ => ブラウザ, TableauDesktop,その他のクライアントから, TableauServerへの全ての要求を処理する. Webサーバ. 1. 内部データソースプロパティ => データソースプロパティとのみ通信する. 1. メッセージングサービス => TableauServerのマイクロサービス間の通信をサポート. 1. メトリクスサービス => メトリクスデータの読み書き. 1. リポジトリ => 実体はPostgreSQL. TableauServerのメインデータベース.ワークブックとユーザのメタデータを保存. Tableau Catalogが有効な場合,コンテンツと外部アセットのメタデータを保存. 1. SAMLサービス => TableauServerとSAML IdP間のプロキシ. 1. 検索と参照 => コンテンツのメタデータを高速に検索する.フィルター,取得,表示を処理する. 1. Tableau Prep Conductor => フローの実行,接続の認証資格情報の確認,フロー失敗時のアラート送出. 1. VizQLサーバ => ビューを読み込み,レンダリング,クエリを計算. 1. 一緒にデータエンジンもインストールするプロセス => アプリケーションサーバ,バックグラウンダー,データサーバ 1. Tableauマイクロサービスコンテナ. コンテナ内に複数のプロセス. 全部実行中=>running, 一部実行中=>degraded, 全て停止=>error,インタラクティブ,非インタラクティブの2種類. 1. TSMプロセス. TSMの初期化完了=>running. TableauServerが停止しても走り続ける. 1. 管理エージェント => 構成/トポトジの変更がないか調整サービスを監視する.新しい構成を各サービスに提供 1. 管理コントローラ => TSMへの要求を処理.構成とトポトジの変更,サービスプロセス全体のワークフローを調整. REST APIのエンドポイント(HTTPS) 1. クライアントファイルサービス => 複数のノード間で共有ファイル(認証関連の証明書,キー,OpenID,SAML,Kerberos等のファイル)を管理. 1. 調整サービス => 唯一の参照元.?? 1. サービスマネージャ => 不明 ?? 1. ライセンスマネージャ => ライセンスを扱う?? 1. メンテナンスプロセス. 通常stopped. ジョブ開始時にrunning,上部終了時にstopped. 1. データベースメンテナンス => TableauServerリポジトリの保守操作. 1. バックアップ/復元 => TableauServerリポジトリ, および, ファイルストアに保管されているデータのバックアップおよび復元操作. 1. サイトのインポート/エクスポート => クラスタ間でTableauServerを移行. 1. 分散環境と高可用性環境におけるプロセス 1. 本番環境の推奨は8コア以上. 1. バックグラウンダープロセスを専用のコンピュータで実行.(バックグラウンダーはCPUを大量に使用する) 1. VizQLとバックグラウンダーを分ける. 1. 抽出を頻繁におこなう可能性がある場合 => バックグラウンダーを増やす 1. ファイルストアと同じノードにあるデータエンジンはビューのクエリに使われる. バックグラウンダーが重いことでビュー操作がモタつくのを回避するため、ファイルプロセスとバックグラウンダーを分ける. 1. リポジトリ(pgsql)とファイルストアをファイルコントローラと同じノードに配置 => TableauServerのバックアップにかかる時間を短縮 1. フェイルオーバー 1. ファイルストア,リポジトリをフェイルオーバー対応させる=>最大3大のコンピュータが必要.1台は\"最初のノード\",2,3台は追加ノード. 1. 複数のゲートウェイ.3台のコンピュータ+ロードバランサ.ゲートウェイプロセスを全ノードにインストールしてロードバランサをゲートウェイに向ける.1ロードバランサx3ノード. 1. 高可用性 => 最初のノードの実行プロセスを少なく. 2,3台目を多く. 1. データソース 1. 接続情報を記録する.ライブか抽出か? 計算,セット,グループ,bin,パラメタ,カスタムフィールド. サーバの場所,認証資格,アクセストークン,セキュリティ情報... 1. なぜパブリッシュ(管理/共有)するのか? 各クライアント毎に似て非なる設定が増えるのを回避.サーバ側で抽出結果をサーバに残すアーキテクチャをとれる=>ネットワークトラフィックが減る. 1. サーバ側でコネクションを設定する. 例)MySQL. サーバ側にODBCドライバをインストールしてODBC経由でMySQLに接続する. 例)ファイル => Excelなど. 例)キューブ =>Oracle Essbase,Teradata OLAPなど 1. 抽出とライブ.抽出とはスナップショット.ライブとは都度取得.データソースに都度クエリを投げる.

TableauServerのインストール時に気をつけること. 過去の経緯からかライセンス,サイトロールの関係が結構カオス. 増築しました感がかなりある. ライセンス,サイトロール,パーミッションの3要素からアクセス権が決まる. 複雑... 1. キャッシュサーバの構成. 1. 実体はCacheServerプロセス. 1. クエリと実行結果のペアをキャッシュする. Webブラウザの操作によりクエリが実行されるときにキャッシュを更新. 1. 可用性(性能)を上げるにはキャッシュサーバプロセスを複数のノードに構成する. 1. tsmコマンドで構成を変更. tsm data-access caching set -r . 規定値は全キャッシュ. 有効時間(value)を指定可能. 1. プロセス分散の適用 1. 分散パターンは3種類. シングルノード,マルチノード,高可用性. 高可用性はマルチノードのより冗長なサブセット. 1. マルチノードにおいて\"最初のコンピュータ(初期ノード)\"だけ他のノードと扱いが異なる. 初期ノードにしかインストールできないプロセスがある. 1. サブスクリプション/メールアラート 1. 「ビュー」「ワークブック」の\"イメージ\",\"PDFスナップショット\"を定期的に作成しメールで送信する機能. 1. 自分自身向けか(所有者,プロジェクトリーダー,管理者であれば)人向けにサブスクライブできる. 1. [検索]-[全てのワークブック]-[ツールバー]-[サブスクライブ] 1. サブスクリプションを受け取るには[画像]と[画像/PDFのダウンロード]パーミッションが必要. 1. アカウントをメールアドレスとして読んで送るため受け取るアカウントがメールアドレスでないといけない. 1. サイト構成オプション 1. ユーザー数,[ユーザー]から確認. 1. ストレージ容量,[サーバーのステータス]-[サーバーディスク空き容量].過去30日間のディスク使用量,先月のディスク使用量推移.GBと%. 1. サイトサブスクリプションの有効化-[設定]-[サブスクリプション]-[ユーザーにワークブックおよびビューのサブスクライブを許可する] 1. サイトサブスクリプションの編集-[タスク]-[サブスクリプション]-[アクション]-[スケジュールの変更]/[件名の変更]/[空きビューモードの変更]/[サブスクリプションの解除] 1. プロジェクト構成オプション-[検索]-[プロジェクト]-[共有]/[名前の変更]/[移動]/[パーミッション]/[所有者の変更]/[削除] 1. ユーザの構成オプション-[ユーザ]-[各ユーザ]-[設定] 1. サブスクリプションタイムゾーン -> スケジュールのタイムゾーン設定 1. 抽出,フロー,スケジュールされた更新 -> ジョブのアップデートがあったときにメール通知するか否か 1. サブスクリプション一時停止通知 -> 繰り返しエラーを検知したときにサブスクリプションが止まる -> メール通知するか否か 1. データアラート一時停止通知 -> 繰り返しエラーを検知したときにデータアラート通知が止まる -> メール通知するか否か 1. 誰がユーザーを追加できるか? 1. 前提として十分なユーザーライセンスとロールライセンスが必要 1. サーバ管理者サイトロールはユーザを追加できる. サイト管理者サイトロールはサーバ管理者サイトロールを持つユーザが許可した場合に限りユーザを追加できる. 1. ユーザーの制限とライセンス 1. コアベースライセンスの場合,定義した数のCreatorライセンス,無制限のExploreライセンス 1. ユーザーベースライセンスの場合, ライセンスに所有可能なユーザーの最大数が記載. 1. コアベースライセンスからユーザーベースライセンスへの移行(ライセンス変換)が可能. 1. ユーザーの追加 1. ユーザの追加体系は大枠でサーバーレベル,サイトレベルの2種類.サイトが1つの構成では自動的にサーバレベルの体系が適用. 1. サイトが2つ以上の場合,サーバレベル/サイトレベルの並列.サーバ管理者のみがサーバレベル追加可.[サーバーユーザー]と[サイトユーザー]の2通りの画面に入れる. 1. ライセンスタイプとサイトロール 1. ライセンスタイプはユーザ毎に定義. ユーザにどのサイトロールを割り当てるかにより必要なライセンスタイプが異なる. 1. サイトロールはユーザ毎に定義. マルチサイトではサイト毎に異なるサイトロールを持てる. あるサイトではCreatorサイトロール,別のサイトではViewerサイトロール.など. 1. サイトロールはユーザが持ち得る最大の権限. だが, ユーザがサイトロールの最大の権限を利用できるかは,コンテンツ毎に設定されたパーミッションにより決まる. 1. 管理者レベル 1. サーバ管理者=>TableauServerでのみ利用可能.全リソースに対する無制限のアクセス権. 1. サイト管理者=>TableauOnlineではこれのみ利用可能. サーバ管理者がサイト管理者にユーザの管理/サイトロール,サイト追加を許可するかを決定できる. 1. パブリッシュ可能/不可能な人物 1. Creatorライセンス-サーバ管理者/サイト管理者Creator/Creator => 可能 1. Explorerライセンス-サーバ管理者/サイト管理者Explorer/Explorer(パブリッシュ可能) => 可能 1. Explorerライセンス-Explorer => 不可 1. Explorer(パブリッシュ可能)についてはCreatorに纏わる権限(データソースへの接続など)に制限がある. 1. ローカル認証/ActiveDirectory経由のインポート 1. ローカル認証時のユーザ追加 - [新規ユーザー]押下. ローカル認証時にユーザ名の重複を避けるために電子メールアドレスをユーザ名として使うと良い. 1. ActiveDirectoryを介したインポート - TableauServerでActiveDirectory認証をおこなう設定をしている場合,ドメイン名無しでActiveDirectoryユーザを入力できる.フルネーム禁止. 1. パーミッション 1. パーミッションの構成 1. コンテンツ/プロジェクトに対して, ユーザ/グループに許可/不許可を与える. 1. パーミッションの段階的構成. Lv1.プロジェクトレベルに設定/ Lv2.コンテンツレベルに設定. プロジェクトに設定したパーミッションはサブコンテンツとネストされたプロジェクトに適用. 1. パーミッション設定画面の使い方. 上ペインで[ユーザ]/[グループ]を選択する. => 下ペインに該当ユーザの有効なパーミッション一覧が表示される/編集できる. 1. 下ペインのパーミッショングリッドのセル(許可/不許可が表示される部分)にカーソルを合わせると, 許可/不許可の理由が得られる. 1. プロジェクトのパーミッションロック => コンテンツ, ネストされたプロジェクトのパーミッションをカスタマイズできないように保護する. 1. 種類 => \"許可\",\"拒否\",\"未指定\". 1. 複雑にしないために => ユーザではなくグループに対して設定すべき. コンテンツではなくプロジェクトに設定すべき. 1. パーミッションの詳細 1. プロジェクト 1. ビュー => 許可の場合,プロジェクトを表示できる. プロジェクト内のコンテンツに関してではなく, プロジェクト自身の表示に関する. 1. パブリッシュ => Tableau Desktop, Tableau Prep Builderからプロジェクトにコンテンツをパブリッシュできる. コンテンツの移動,Web作成時の保存にも必要. 1. ワークブック 1. ビュー => 許可の場合,ワークブックを表示できる. 1. フィルター => 許可の場合,ビュー内のフィルターを操作できる. 不許可の場合,フィルターが表示されない. 1. コメントの表示 => 許可の場合,ワークブック内のビューに関連付けられたコメントを表示できる. 1. コメントの追加 => 許可の場合,ワークブック内のビューに対してコメントを追加できる. 1. イメージ/PDFのダウンロード => 許可の場合,ワークブック内のビューをPNG,PDF,PowerPointとしてDownloadできる. 1. サマリーデータのダウンロード => ユーザはビュー内や選択したマーク内の集計データを表示したり, CSVとしてDownloadできる. 1. データソース 1. ビュー => 許可の場合,サーバ上のデータソースを表示できる 1. 接続 => 許可の場合,Tableau Desktop,Tableau Prep Builder,データに聞く,Web編集でデータソースに接続できる. 1. データソースのダウンロード => 許可の場合,サーバからデータソースを*.tdsxとしてダウンロードできる. 1. 上書き => 許可の場合,データソースをパブリッシュしサーバ上のデータソースを上書きする. 1. 削除 => 許可の場合,データソースを削除できる. 1. パーミッションの設定 => 許可の場合,パーミッションルールを作成して編集できる. 1. Tableauのセキュリティモデル 1. プロジェクト 1. コンテンツへのアクセスを整理,管理するために使用するコンテナ. プロジェクト単位で権限を処理する. 1. 階層. 上位プロジェクトを作成できるのは管理者のみ. 所有者とプロジェクトリーダが上位プロジェクトの下にネストされたプロジェクトを作成できる. 1. 所有者とプロジェクトリーダはプロジェクト,コンテンツ,下位プロジェクトに対してアクセス権を持つ.

ソースはオンラインヘルプ. なんとなく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を実行する. 実行パラメタに追加構成情報ファイルのパスを渡す.

この記事 Tableau未経験者がTableauを扱う仕事をすることになったのと, 合わせてServer Certified Associate資格の取得が必要になったためいつものごとく学びの軌跡を記録していく. マルチノード高可用性のための設計を学ぶというモチベ 潰しが効く系ではないのだが, 実際にインストールして設定しようとすると知らなければならないことが並んでいる. 使わないけれど知識として並べてある, という一部のベンダー資格とは違う印象がある. 通常,いきなりマルチノードで高可用性が..とかにはならないはずだがどこかで入門レベルが存在しなければならない. 最小構成/シングルノード構成/マルチノード構成へとスケールできるアーキテクチャになっていることを理解することが結局のところスケールを前提とした入門になり得ると思う. あるシステムのシステム構成がここまで明らかになっているのも珍しい印象. マルチノードと高可用性実現のため, レイヤやコンポーネントが想像以上に分離していて, スケールさせる際の自由度の素になっている. スケールのための設計をゼロベースで学んだ経験がないため,自分が自作するレベルのシステムのアーキテクチャではここまで分解しないな,というのは当然あったが, 正直かなり設計の勉強になった. 対策 過去問が公開されていたり,公式参考書があったりはしないため,試験のための習得にはなりづらい. マルチノード化による高可用性を実現するためのアーキテクチャを学ぶ機会と捉えれば,結構モチベになると思う. (そんな人いるんでしょうか..w) 試験のシラバスが項目単位で並んでいる. この項目を自分の言葉で説明できることが当面のゴール. 言葉で説明する深さについては,暗記が不要という難易度調整が入っておりそれほど深くなくてよいと思う. 結果として「ロジックを自分の言葉で説明できること」がゴールになり得る. 個人的な感想を書くと,もはやかなり覚えてしまっている気はする. 当面は「学びの軌跡」。合格したときに「合格体験記」としてまとめなおす. この投稿を入り口として各詳細を別記事として書いていく予定. 1セクションを1記事として扱い合計4から5記事で詳細を完結する予定. 当面は合格体験記ではなく勉強の記録なので、資格試験合格のために ここに流入してしまった人は抜けて他読んだ方が学びになると思います. TableauDesktop TableauServerはTableauDesktopで作ったワークブック等をサーバ上で共有する仕組みであることから, 多くの記述においてTableauDesktopの知識が前提となる.TableauDesktopで一通り何ができるかを学んだ方が良い.ポチポチで全てやれちゃう範囲と深さがあればTableauServerの理解には不足ないと思う. 試験の概要 Server Certified Associate試験の概要は以下の通り。 合格基準が75%。ベンダー資格としてはこんなものか、若干高いかも。 択一だけでなく多肢選択も含まれるので、結構落とせない。 問題数80問に対して90分。問題多い。合格体験記を見る限り時間が不足しがちな試験。 試験範囲に以下みたいな記述がある。難易度の調整パラメータかな。 組織は、タスクを効果的かつ効率的に遂行することを、当然のように従業員に期待するようになりました。Tableau は、時間が成功に欠かせないコンピテンシーであると考えており、そのためこの試験にも時間制限が設けられています。 Tableau ServerはLinux,WindowsServerいずれのインストールも対応しているが試験はWindows。 個人的にはLinuxが良いのだけど仕方がない。OS違うのに試験同じにできるのかね..。 オンラインヘルプが参照可能。だが時間無いので記憶の照合くらいにしか使えなさそう。 どこに書いてあるかを記憶しておくことが必要。 Tableu資格の特徴は, 試験開始までの準備でリモート先の試験官と英会話が必要なこと。 提供言語として日本語が用意されているが,これは問題が日本語であるということ. 試験時間: 90 分 合格基準: 正答率 75% 問題数: 80 得点: 自動採点 設問形式: 択一、複数回答、正誤 提供言語: 英語、日本語、中国語 (簡体字)、ドイツ語、フランス語、ポルトガル語 (ブラジル)、スペイン語 (インターナショナル) プラットフォーム: Tableau Server がインストールされた Windows 仮想マシン オンラインヘルプ: 参照可能 Readingはそこそこ問題ないのでこっちは良いのだけど,試験官とSpeaking/Listeningとか不安。 試験本体までのやりとりは以下のような感じらしい。むー。 試験官にweb電話をかける ガイダンスが始まる web通話環境に問題ないことの確認が入る 本人確認：受ける試験が正しいか、パスポートをwebカメラに見せて欲しい,etc 環境確認：PCは充電器に接続されているか、部屋に一人でいるか、机の上を見せて欲しい、途中退出はダメ,etc リモートで指定されたPC環境にログインされ試験開始 なんとか試験本体までたどりつかないと。 ここから先は普通のベンダー試験。 試験範囲 記事執筆時点の試験範囲は以下。 評価するスキル 準備セクション。全体の20%。把握するためにペタペタ貼っていく。 ところどころ,当製品と関係ない一般的な知識が書かれているな..。 ユーザーエクスペリエンス - ユーザーインターフェイス - ナビゲーション トポロジ - クライアントコンポーネントを特定する - サーバーコンポーネントを特定する - 連動する仕組みを説明する バージョン - 以下を理解する: - Tableau Server の現行バージョンを特定する方法 - Tableau Server の最新リリースをどこで入手できるか - Tableau Server のリリースノートをどこで参照できるか ハードウェア最小要件 - 以下を理解する: - RAM 要件 - CPU 要件 - ハードディスク要件 ソフトウェア要件 - サポートされるオペレーティングシステムを列挙する - 以下を理解する: - ブラウザ要件 - メールアラートのオプション - ウィルス対策の懸念事項 - SMTP サーバーを特定する - 起こりうるポートの問題を知る - 専用サーバーの目的と利点を説明する - クラウドで稼働させる際の検討事項を特定する ライセンス発行 - ユーザーベースライセンスを理解する - 異なるライセンスタイプを説明する - ライセンスタイプがどのようにサイトロールにマップするか説明する サーバープロセス - Tableau サービスマネージャーとTableau Serverプロセスをそれぞれ説明する - 以下を理解する: - インストール直後の既定のプロセス数 - 複数インスタンスのプロセス - プロセス間のワークフロー - 分散環境と高可用性環境におけるプロセス - ロードバランサーの目的 データソースの特定 - 必要なポートを特定する - 必要なデータベースドライバーを特定する - 以下の相違点を理解する: - ファイル、リレーショナル、キューブ - 抽出とライブ接続 - パブリッシュされたデータソースの利点を説明する インフラストラクチャネットワーク - ネットワークレイテンシーの意味を理解する - 動的 IP アドレスのリスクを説明する インストールと構成というセクション。全体の25%。 ActiveDirectoryというワードだけで不安になる。 Linux構成が選べるけどWindowsServerを選んだ方が良い気がしてきた。 内容的には妥当な感じ。 インストール - インストールの手順とオプションを理解する: - インストールパス - ゲートウェイポート - アイデンティティストアと SSO のオプションを理解する: - 外部 (Active Directory) とローカル - 信頼できるチケット - SAML - Kerberos と OpenID Connect - 自動ログインオプションの影響を説明する - SSL の設定方法を理解する - 単一マシン環境のインストールに関する Tableau のベストプラクティスを理解する - サイレントインストールを理解する Tableau Server の構成 - キャッシュ設定を理解する - 以下の方法を理解する: - プロセス分散の適用 - メールアラート/サブスクリプションの設定 - オプションで行えるカスタマイズの設定 - 以下を説明する: - サイト構成オプション - ユーザー数 - ストレージ容量 - サイトサブスクリプションの有効化および編集の方法 - プロジェクト構成オプション - グループとユーザーの構成オプション - 誰がユーザーを追加できるかを理解する ユーザーの追加 - ライセンスタイプとサイトロール - 管理者レベル - パブリッシャーレベル - Active Directory またはローカルを介したインポート セキュリティ - 以下のセキュリティ構成を説明する: - サイトレベル - プロジェクトレベル - グループレベル - ユーザーレベル - データソースレベル - ワークブックレベル パーミッション - 以下を理解する: - システムパーミッションの構成 - パーミッション設計の細部 - Tableau のセキュリティモデル - 許可、拒否、なしの違いを説明する 管理というセクション。全体の36%。 たぶんここが本丸だろう。 以下の方法を理解する: - データ接続を維持する - スケジュールを作成する - サブスクリプションを作成、編集、削除する - サーバー分析を実行する - バックアップと復元を完了する - クリーンアップを実行する - ユーザーを追加、削除、非アクティブ化する - ライセンスを更新する - 起動、停止、再起動する - tsm と tabcmd を使用する - REST API を使用する - ログファイルを処理する - 埋め込みを理解する - Desktop ライセンスの使用状況を監視する - ワークブックとデータソースのリビジョン履歴を管理する 以下の方法を説明する: - 複数の方法でサーバーのステータスを確認する - メールアラートを確認する - データドリブンアラートを設定する - 組み込まれた管理ビューを利用する - カスタム管理ビューを作成する - パフォーマンスの記録を作成する - ネストされたプロジェクトを作成する - サイトおよびサイト管理者のオプションを扱う エンドユーザーとシステム管理者の機能の比較 エンドユーザー機能 以下を理解する: - 表の推奨 - ビューとデータソースをパブリッシュする - ワークブックの名前を変更する - Web でビューを操作する - Web 作成と編集 - ビューの共有方法 - データソースの認証 - 抽出のキャッシング トラブルシューティングというセクション。全体の13%。 ブラウザでのサードパーティ Cookie の要件を理解する 以下の方法を理解する: - Tableau ユーザーまたは Tableau 実行サービスアカウントのパスワードをリセットする - レポーティング用のログファイルをパッケージ化する - tsm を使用してサイトのリソースを検証する - 検索インデックスを再構築する - メンテナンス分析レポートを使用する - サポートリクエストを作成する/開く 移行とアップグレードというセクション。全体の6%。 - アップグレードプロセスを理解する - クリーン再インストールを実行する方法と理由を説明する - 異なるハードウェアに移行する方法を説明する - 後方互換性を理解する おわり 正直どんな風に聞かれるのかがわからないことが一番やっかい. オンラインヘルプを参照可能なので暗記する必要はないのだが, 時間を考慮すると覚えておいてオンラインヘルプで確認するというフローが現実的ではないか. 上から順に流していくと気づくことがある. 実際にインストール,セットアップしようとすると知らなければいけないことが並んでいる. 使わないけど知識として並べてある、という他資格とは印象が違う. あまり潰しが効く技術ではないので,良くも悪くも使い方のガイドとして使うべきだろうと思う.