[レポート] SnowflakeとAlteryxとTableauでビジネスの価値を最大化する方法(Snowflake, Alteryx, Tableau: Maximizing Business Value) #AlteryxInspire

大阪オフィスの玉井です。

日本時間の2021年5月19日～21日に、Alteryx Inspire 2021が開催されました。

当記事では、Alteryx Inspire 2021のセッションの中から、 Snowflake, Alteryx, Tableau: Maximizing Business Valueのレポートをお届けします。

概要

公式

概要

Self-service data analytics underpins nearly all decisions in the modern workplace. However, platforms that support analytics are all too often bloated and complex. These over-bloated systems were tailored to an IT-centric and technical end user, not a line of business (LOB) analyst. LOB analysts are left to navigate the complex infrastructure, applications, and data structures just to answer their questions. The Snowflake, Alteryx, and Tableau (SALT) stack empowers analyst to maximize time spent on insight-delivery by offering an easy-to-use suite of technologies that does not compromise on sophistication. Join Vice President of Technology at Premier Alteryx Partner Continuus Technologies and SALT stack expert, John Heisler, to learn how this stack can drive key business outcomes.

ざっくり

Snowflakeを中心にして、AlteryxとTableauを使うようにすると、めちゃくちゃ便利やで、という話です。

登壇者

• John Heisler
  • Vice President of Technology, Continuus Technologies

セッションレポート

※レポート本文のみ、一人称は登壇者を指します。

前段

私の名前はJohn Heislerです。私はContinuus Technologiesで技術部門のVPを務めています。今日はSnowflakeとAlteryx、そしてTableauを組み合わせた「SALTスタック」を紹介します。そして、このスタックを使ってどのようにビジネスの価値を最大化するかについてお話しします。

アジェンダは比較的シンプルです。今日は、従来のデータ分析基盤のアーキテクチャについて話し、そのアーキテクチャの課題や問題点、そして代替案であるモダンなアーキテクチャ、「SALTスタック」についてお話しします。そして、そのスタックのビジネス上の価値や、他のアーキテクチャとの差別化要素について話します。

データ分析基盤の「伝統的な」アーキテクチャ

これが、私たちが知る、データ分析基盤の「伝統的な」アーキテクチャです。このスライドの図は醜いですが、伝統的なアーキテクチャの混乱と複雑さを伝えるために意図してやっています。このアーキテクチャは恥ずかしいものではありません。ただ、もはや現代のビジネスには適していないのです。

ここでは主にMicrosoftのスタックを選択しました。SSISのような統合ツールを使い、SQL Serverでデータウェアハウスを構築し、その上にAnalytics Studio、SSRSのようなものを乗せるということです。このようなアーキテクチャの真の目的は、このデータエコシステムを管理することにあります。

以前は、ビジネス全体が一枚岩のアプリケーションで提供されていたかもしれません。そのアプリケーションは、人事、企業、リソース、すべてのマーケティングなどのサービスを提供し、そのすべてが単一のデータソースから来ていました。

昨今のアプリケーションは、それぞれ大きなバックエンド・データベースを持っています。バックエンド・データベースは、その機能に関する非常に特殊な情報を持っているため、ビジネス全体やパフォーマンスについて質問し始めると、回答が難しくなります。

この伝統的なアーキテクチャがやろうとしていたことは、これらすべてのデータを横断して統合することでした。しかし、データは各システムの中だけに閉じがちでした。データの爆発的な増加と並行して、あらゆるものがデータを作成し、以前は考えもしなかったような取引上のデータや、ビジネスにとって価値のあるデータが発生しています。つまり、データの増加と同時に、このような分裂が起こっているのです。

そこで、一つのデータウェアハウスを構築し、すべてのデータを統一しようとしましたが、最終的には遅れをとってしまいました。何が起こったかというと、このアーキテクチャは、ピボットしてもう少しアジャイルに動く必要があると考えたのです。具体的には、クラウドの利用…Azure Data FactoryやAzure Synapse Analytics、Azure Storage Data Lakeなどを利用しようとしたりしています。これらは、いくつかのユースケースには適しているかもしれません。しかし現実的には、これらのインフラは、クラウド上のインフラに過ぎません。これはセルフサービスではありません。アジャイルでもなく、ビジネスのためにもなりません。私は、ある組織で、「こういうアーキテクチャやスタックが必要なんだ。」と言うと、彼らは「そのプロジェクトに参加するには2カ月かかる」と言ってきました。笑い話のような話ですよね。これを作ってくれるのを2ヶ月も待つなんて…。最低でも2週間後にはこれが必要です。この問題は、IT部門がどのように構成されているかに大きく関係しています。しかし、このインフラアーキテクチャは、どのタイプのアジリティにも適していません。

AlteryxやTableauでは、「あなたがやらないなら私がやる」という形で運用されていますよね。AlteryxやTableauで全てをやるということですね。もし、私が伝統的なビジネスマネージャーで、アナリストを見ているとしたら、基本的に組織としてすでに支払っている製品の、個々の開発環境を所有していたり、インフラを所有していたりするという点で、私は何らかの責任を負っていてます。これらで構築し始めたソリューションは、優しい愛情とケアが必要です。そうなると、ビジネスラインにとっても問題になります。なぜなら、私がデータ統合のすべてを担当することになるからです。それが負担になってしまうのです。

ところで、この図の右側が示すのは、データウェアハウスに保管されているデータ全体を管理しているということです。しかし、Azureにもいくつかのデータがあります。そして、彼らが考えているのは、Alteryxがこれらのキュレーションされたデータセットに接続するか、Tableauがこれらのセキュリティデータセットに接続するか、Alteryx Connectにこれらのキュレーションされたデータセットを書き込むということですが、私たちは皆、これが現実ではないことを知っていると思います。しかし、今は、このアーキテクチャが現実なのです。

伝統的アーキテクチャの6つの問題

リソースの重複

まず第一に、リソースの重複が挙げられます。私たちの努力が重複しているというだけではありません。考えてみてください、あなたは複数のサーバーにお金を払っていますよね。それらは同じ目的のために使われているのです。

俊敏性の欠如

伝統的アーキテクチャは、3年前のデータ分析にはうまく対応できますが、それはもう重要ではありません。もっと重要な質問に、非常に迅速に答える必要があります。従来のインフラでは、隣接するデータ分析や、「分析の背後にある分析」に答えるための俊敏性がありません。

不当な機会損失

従来のインフラでは、システムを稼働させるために、多くの「消火活動」が行われることがよくあります。非常に複雑なシステムの相互依存関係があるのですね。つまり、デジタル・トランスフォーメーションやデータ・ドリブンな企業を目指していると言っても、実際の行動はそうではないということですよね。実際には、より戦略的なデータドリブンの取り組みを行うことを犠牲にしているのではないでしょうか。

ガバナンスが効かない

ガバナンスの観点から見ると、セルフサービスに反発する声がたまに聞かれますが、必ずしも反発しているわけではなく、セルフサービスモデルに対して合理的な反論をしているだけで、「では、それをどうやって管理するのか？特に従来のユースケースでは、どうやってそれを管理するのか？」が問題になります。AさんがあるIDを持ってきて、Bさんが別のIDを持ってくるというような重複があるわけですが、それをどうやって管理するのか？最終的にはデータの信頼性を失うことになります。

セキュリティが弱い

データセットに出入りできるドアは非常に多く、そのすべてを何らかの規模、方法、スケーラブルな方法で保護しようとするのは不可能に近いでしょう。

キーパーソンのリスク

一般的には会社に関するキーパーソンのリスクについても語られます。この問題には、自分がアーキテクチャ全体を構築した一人の人間であるという誤った安心感があるかもしれません。例えば、あなたがボカラトン¹ でマルガリータ² を飲んでいるときに、火曜日の午後3時に電話がかかってきて、誰かに「君が作った装置が壊れたんだ」と…。あなたにこういう電話がくるのです。これって嫌ですよね。つまり、このキーパーソンのリスクは双方向なのです。会社にとってもそうですが、従業員にとってもそうなのです。

SALTアーキテクチャ

では、私の提案するソリューションは何でしょうか。アーキテクチャがすべてを解決するわけではありません。問題を解決するためには、手順というものがあります。「杖を振ったら、すべてを解決するアーキテクチャをデプロイされるんだ〜」とは思ってほしくありません。しかし、このアーキテクチャは役に立ちます。

この図を見ると、左には、先ほどと同じデータエコシステム群があります。しかし、高度に統一され、合理化されたプロセスを持っています。Snowflakeを使って、すべてのデータソースをそのままの状態で、Snowpipeを使ってデータレイクに持ってきます。そして、それらのデータの一部をデータウェアハウスに入れ、従来のテーブルやビューを作成します。しかし、データレイクへのアクセスは、データサイエンスチームと、一部のパワーユーザーだけに開放します。そして、このデータウェアハウスにデータセットを統合しました。

そして、そのデータウェアハウスにAlteryxとTableauを直接接続しています。ここでの違いは、なぜAzure Data Factoryではできないのかという点ですが、いくつかのアーキテクチャにより、従来のクラウド・プラットフォームに比べてはるかに簡単に導入することができます。

具体的には、Snowflakeは、従来のデータセットや従来のアーキテクチャに見られる、管理作業のオーバーヘッドの多くをカプセル化しています。クラウドに移行しても、従来のアーキテクチャはクラウドでも同じで、同じコンポーネントが、データファームではない別の場所にあるマシンで動いているだけです。今回のケースでは、その多くがSnowflakeで直接行われます。つまり、統合や管理作業の多くはSnowflakeで行うことになります。そして、Snowflakeはその多くをカプセル化してくれます。そのため、統一がより簡単に、より確実にできるようになります。

アーキテクチャについては、もう少し詳しく説明します。Alteryxが得意とするのは、「分析のための統合」です。Alteryxは高度な分析を行うことができます。これは、Alteryxにとっては非常に伝統的なユースケースでもあります。また、モデルの出力や結果を、直接Tableauに書き出すこともできます。

SALTの価値は

これは、ビジネスに価値を与えるために特別に構築されたものです。15人のデータサイエンティストを雇って「データの成熟度が上がった」と言っても、それはデータの成熟度ではありません。1500人全員が基本的なスキルを持ち、データサイエンティストのスキルではないかもしれませんが、経験に基づいた意思決定を行うための基本的なスキルとツールを持っている、それがデータの成熟度です。

このアーキテクチャは、そのような問題を解決してくれるわけではありません。エドワード・タフトだったかな、間違っているかもしれませんが、彼か同じくらい頭の良い人が、「良いデザインは目に見えない」と言っていたと思います。あなたの組織の人々は、アーキテクチャがいかにひどいかを考える必要はなく、ビジネス上の問題を考えるべきです。価値を生み出すスピード、これは当然のことですが、あなたが作ったものが価値を生み出さないとしても、早く失敗する能力…2時間を無駄にするのと、チームが2週間を無駄にするのとでは、話が全く違います。

統一されたデータプラットフォームにより、どこにデータを持っていけばいいのかという疑問がなくなりました。ここでデータを得ることができます。エンドユーザーの視点から見ても、これはWin-Winの関係です。また、ITの観点から見ても、バックエンドがシンプルになります。たくさんのものを管理する必要がないからです。Tableau Onlineがあれば、Tableau Serverのアップグレードやその他の管理は一切不要で、ヒット商品だけを管理することができます。つまり、重要な機能…アナリティクスの機能と会社全体でのアナリティクスのスケーリングを管理しているだけなのです。Snowflakeと同様、バックエンドの管理作業をすべて行うのではなく、価値を得るだけです。

セルフサービスガバナンスは、頻繁に耳にする言葉ではありませんが、誰が何に、どのようにアクセスするかを管理することができます。また、誰がどのような方法で分析しているかを簡単に確認することができます。AWSにもAzureにも導入できる、つまり、どこで導入するかは関係ありません。そして、先ほども述べたように、これらすべてのプラットフォームで管理作業のオーバーヘッドを削減できます。

他のアーキテクチャとの差別化要因

SALTアーキテクチャの最後のピースは、ビジネス価値の差別化です。

ナレッジワーカーをデータワーカーに移行させるのは、非常に簡単です。以前は、肥大化した複雑なアーキテクチャを学ばなければなりませんでした。これもまた、非常にシンプルでわかりやすいTableauやAlteryxのおかげです。

Snowflakeはユーザーを重視しており、市場への参入方法やエンドユーザーへのツールの提供方法は、非常にアクセスしやすいものになっています。例えば、データサイエンスグループがあるとします。そのデータサイエンスグループが膨大なデータを活用してモデルを学習する必要がある場合、非常に迅速にスケールアップしてモデルを学習し、それを非常に迅速にスピンダウンすることができます。

また、巨大なデータセットにも対応できます。Tableau Onlineはクラウド上にあります。データをSnowflakeに入れれば、どちらもクラウドになります。Alteryxもin-databaseツールと呼ばれるもので、Snowflakeアーキテクチャに処理を押し上げることができます。これにより、すべてがクラウドの中にあるような状態になり、クラウド・ファースト・アーキテクチャを推進することができます。

そして最後が、このデータクラウドです。ここでは、あるソリューション・ブリーフィングから引用した簡単な概略図を掲載しています。これまで社内データについて多くの話をしてきました。しかし、外部のデータやパブリックデータを共有・活用することは、Snowflakeの中では非常に簡単です。金融機関であれば、Morningstarのデータ等を購入しているかもしれませんが、これらの情報の多くはSnowflakeの中で直接利用できます。このようにして、Alteryxが解放されるのです。エンドユーザーは自分で多くの情報を収集する必要がなく、シングルソースオブトゥルースを知ることができます。

ところで、エンドユーザーに提供するということは、他の誰かがその複雑さを保有しているということではなく、その複雑さをどこか他の場所で提供しているということでもありません。

まとめ

ということで、今回は短くて甘い内容をお届けしました。SALTスタックの導入方法やベストプラクティスについてもっと知りたい方は、スライドをご覧ください。

繰り返しになりますが、今回は、ビジネス上の成果や価値に高いレベルで焦点を当てて説明しました。

お時間を頂きありがとうございました。

おわりに

セッション中でも言っていましたが、Tableau OnlineとSnowflakeという組み合わせだと、全てがクラウドなので、システムの管理コストがめちゃくちゃ下がります。これがデータ分析基盤にとって非常に有用です。データアナリストの人たちが、無理をしてインフラの管理をすることなく、浮いた時間を分析につぎ込むことができるからですね。不要な作業はサービスに任せちゃって、本来やるべきことをやりましょうよ、という話ですね。

良い話ではあったのですが、個人的には目新しい部分が無かったので、イチ技術者としては、ちょっと物足りなかった感もあったセッションでした（たぶん、元々ビジネス側の人むけのセッション）。