この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
奈良県でリモートワークしてる玉井です。
5月15日（金）のお昼時に、弊社が開催した下記ウェビナーで登壇しました。
本記事では、ウェビナーの資料の共有、それと、ウェビナー中にあったQ&Aの補足等についてご紹介します。
資料
登壇内容に関する各種リンクなど
顧客環境へのセルフインストール
Amazon Redshiftの管理
Lookerから直接EC2を停止
Amazon SageMakerとの連携
Snowflake内の半構造化データにLookerから直接アクセス
SnowflakeのデータシェアリングのデータにLookerから直接アクセス
紹介したTableau PublicのViz
https://public.tableau.com/views/BrianDennehy/Dashboard1?:display_count=y&:origin=viz_share_link
- Brian Dennehyという映画監督の作品売上（たぶん）を可視化したもの
- ブライアン・デネヒー - Wikipedia
その他補足資料等
Dev.IOのLookerカテゴリ記事
Lookerを含めた各BIツールの違いについて議論されているreddit
rlaxx1さんというユーザーが回答している内容に、私個人も概ね同意です。
（ウェビナー中にあった）Q&A
マルチテナントは実現できるか？各テナントごとにログイン可能ユーザー、表示するダッシュボード・データを出し分けるということはできるか？
Yesです。
（マルチテナントの目的がコンテンツの分離だという前提で回答します）
「マルチテナント」という機能が明示的に存在するわけではありませんが（Tableau Serverの「サイト」的な機能はない）、他の機能を組み合わせて似たような仕組みを実現することは可能です。
Lookerにはダッシュボード等を置いておく「フォルダ」という概念がありますが、そのフォルダのアクセスレベルを「クローズド」にし、ログインユーザーに応じてアクセスできるフォルダを分けることで、各コンテンツをサイロ化することができます。
他テーブルを参照する際も（left joinなど）LookML上に定義するのか？
Yesです。
下記をご参考ください（LookML自体の説明をもう少し見ないとよくわからないかもしれません…）。
LookerのパフォーマンスはデータベースやDWHの性能に完全に依存するのか？
基本的にはYesです。
Lookerは（どれだけ複雑なことをしても）最終的には「SQLを投げる」ので、そのSQLの処理能力はデータ側に依存します。
…とはいえ、LookMLの書き方がめちゃくちゃだったり（効率の悪いクエリが生成される）ダッシュボードに表示するデータ数が多すぎると、それはそれでパフォーマンスが悪くなるので、そこらへんは気をつけましょう。
Tableauの「データソースのパブリッシャー」と「LookMLの利用者」の違いで、言語の違い以外にどのようなイメージの違いがあるか？TableauでもSQLで計算項目を定義したりするため両者の違いがいまいち腑に落ちない
これは非常にいい質問&回答するのが難しい質問です。両方とも使ってみるのが一番はやいのですが、それができれば苦労しないですよね。
色々な視点での回答があると思いますが、私個人としては、「目的」が違うと思っています。
Tableauの計算フィールドやカスタムSQLについて
Tableauには「計算フィールド」という機能があって、項目同士を計算して新しい項目を作ることができます。また、「カスタムSQL」という機能を使えば、Tableauから任意のクエリを投げて、それで取得した結果をビジュアライゼーションすることができます。
ただ、これらはあくまで「ワークブック単位」となります。基本的にワークブックを作成するのは1人だと思います。これらの計算式等は（ほとんどの場合）作成者に依存します。データは一つしかなくても、別の人がそのデータを使って、別のワークブックを作成した時、微妙に計算方法が異なる式を使ったワークブックを作成するかもしれません（最悪、どちらのワークブックのデータが正しいかわからなくなる）。要するに、これらの機能の目的は、データをモデリングするためのものではなく、「（その人が作っている）ビジュアライゼーションを助ける」ための機能なんですね。あくまで可視化の補助が目的である、ということです。
※ちなみにTableauのカスタムSQLはパフォーマンスが悪くなるので（Tableauが生成するVizQLを無かったことにしてしまうため）、あまりオススメしません。（同じクエリを頻繁に使用する場合）そのクエリを、そのまま実テーブルとして用意したほうがいいです。
LookMLについて
対して、LookMLは「データのモデリング」が目的です。データの定義やビジネスに応じたロジック等をLookMLで記述します。LookMLで定義したデータモデルはLookerユーザーで共有できるので（権限設定もあります）、ユーザー毎に同じようなクエリやダッシュボードを生成することはなくなります。Gitでバージョン管理もできるので、複数人による共同開発もできますし、重要な計算式の変更等も安全にできます（間違えたらバージョンを戻せばいい）。
…他にも色々なことができるのですが、これ以上説明しようとするとなかなかに長くなってしまうので、気になる方は下記も合わせてご覧ください。
おわりに（ハイパーポエム）
このウェビナーも、奈良県の自宅から配信しました（自宅からのウェビナー登壇は2回目）。
今までだと、こういうセミナーはおそらく弊社の東京オフィスで、東京のメンバーが登壇していたと思います。それが、新型コロナウィルスによって全社員が在宅勤務となり、地域の概念がなくなり、奈良の片田舎に住んでいる私が、全国の参加者に向けて、お話することになりました。
半強制的にオールオンラインでの業務を強いられた結果、東京や大阪（まあ大阪は隣にあるしすぐ行けるけど）といった都会にいなくても、オンライン上でセミナーができてしまうという現実を目の当たりにすることとなりました（目の当たりにするというか、ド真ん中に立ってた？）。
物理的には快適ですし、特に支障等もありませんでした。ただ、気持ちとしては「すげー！オンラインでも全然いけるやん！」というより「今後、一体自分たちの仕事ってどう変わっていくんだろう？」っていう、なんか謎のセンチメンタリズムを感じています。理由は自分でもわかりませんが、ウェビナーだけじゃなくて、もっと色々なことが、このコロナ禍で変わっていきそうな気がしていて、自分はそれについていけるのかな？っていう心配をしているんでしょうね。でもまあ、そこはついていくしかないので、これからも人生ガンバリマス宣言。
話は変わりますが、わたくし、ウェビナーだけじゃなくて、下記のような動画にも出ていますので、よければチェックよろしくお願いします。
24
