📴 ⏬ 👩🏻‍🔧 データの自己分析のための「セルフサービス」アプローチの実装 🍞 🀄️ ❌

ビジネスインテリジェンス（BI）ツールは、過去数年間でほぼすべてのタイプのビジネスに浸透しており、データマイニングに重点を置いてリソースを提供しています。 IT企業について言えば、おそらく大多数はビジネスインテリジェンスの目的と、内部データの分析が企業にとってどのような価値があるかを理解しています。

Playrixでは、データの準備と分析に大量のリソースが割り当てられており、高度なテクノロジーを使用し、従業員のトレーニングを真剣に受け止めています。同社は世界でトップ3のモバイルゲーム開発者の1つであるため、データ分析、特にビジネスインテリジェンスで適切なレベルを維持するよう努めています。 2,700万人以上のユーザーが毎日私たちのゲームをプレイしています。この数字は、モバイルデバイスによって毎日生成されるデータの量の大まかなアイデアを与えることができます。さらに、データはさまざまな形式の数十のサービスから取得され、その後、集約されてストレージに読み込まれます。 AWSS3をDataLakeとして使用していますが、AWSRedshiftとPostgreSQLのデータウェアハウスの使用は制限されています。これらのデータベースを分析に使用します。赤方偏移は高速ですが、より高価ですそのため、最もリクエストの多いデータをそこに保存します。 PostgreSQLは安価で低速であり、少量のデータまたは読み取り速度が重要ではないデータのいずれかを格納します。事前に集計されたデータには、HadoopクラスターとImpalaを使用します。

Playrixの主なBIツールはTableauです。この製品は世界でよく知られており、データ分析と視覚化の十分な機会があり、さまざまなソースで動作します。さらに、単純な分析タスクのコードを作成する必要がないため、さまざまな部門のユーザーをトレーニングして、ビジネスデータを自分で分析することができます。Tableau Softwareツールのベンダーは、その製品をデータの自己分析、つまりセルフサービス用のツールとしても位置付けています。

BIでのデータ分析には、主に2つのアプローチがあります。

レポーティングファクトリ。このアプローチには、ビジネスユーザー向けのレポートを作成する部門や人がいます。
Self-Service. - .

最初のアプローチは従来のものであり、ほとんどの企業にはこのような企業全体のレポートファクトリがあります。 2番目のアプローチは、特にロシアにとっては比較的新しいものです。データはビジネスユーザー自身によって調査されているので、それは良いことです-彼らは彼らのローカルプロセスをはるかによく知っています。これは、開発者をアンロードし、チームプロセスの詳細に飛び込む必要性を軽減し、毎回最も基本的なレポートを作成するのに役立ちます。これは、おそらく最大の問題であるビジネスユーザーと開発者の間の隔たりを埋めるのに役立ちます。結局のところ、Reporting Factoryアプローチの主な問題は、プログラマーと開発者がビジネスユーザーの問題を誤解し、したがって不要なレポートを作成するという事実だけが原因で、ほとんどのレポートが未請求のままになる可能性があることです。後で作り直すか、単に使用しないかのどちらかです。

Playrixでは、プログラマーとアナリストは当初、社内でレポートの開発に携わっていました。つまり、日常的にデータを扱うスペシャリストです。しかし、会社は非常に急速に発展しており、レポートに対するユーザーのニーズが高まるにつれて、レポート開発者は作成とサポートのすべてのタスクを解決するのに間に合わなくなりました。次に、BI開発グループを拡大するか、コンピテンシーを他の部門に移すかという疑問が生じました。セルフサービスの方向性は私たちにとって有望であると思われたため、ビジネスユーザーに独自のプロジェクトを作成し、独自にデータを分析するように教えることにしました。

Playrixでは、ビジネスインテリジェンス部門（BIチーム）が次のタスクに取り組んでいます。

データの収集、準備、保存。
内部分析サービスの開発。
外部サービスとの統合。
Webインターフェースの開発。
Tableauでの開発のレポート。

私たちは、内部プロセスと分析の自動化に取り組んでいます。簡単に言うと、次の図を使用して構造を表すことができます。

ミニチームBIチーム

ここでの長方形はミニチームを表しています。左側-バックチーム、右側-フロントチーム。それらのそれぞれは、関連するチームのタスクを処理し、他のチームが過負荷になったときにそれらを引き受けるのに十分な能力を持っています。

BIチームには、要件の収集から製品環境への展開、およびその後のサポートまで、完全な開発サイクルがあります。各ミニチームには、独自のシステムアナリスト、開発者、テストエンジニアがいます。これらはレポートファクトリとして機能し、内部で使用するためのデータとレポートを準備します。

ここで重要なのは、ほとんどのTableauプロジェクトでは、通常デモで表示される単純なレポートではなく、豊富な機能、多数のコントロール、広範な機能、および外部モジュールの接続を備えたツールを開発することです。これらのツールは絶えず改訂されており、新しい機能が追加されています。

しかし、お客様自身が解決できる単純な地域の問題も発生します。

コンピテンシーの移転とパイロットプロジェクトの立ち上げ

他の企業との仕事やコミュニケーションの経験によると、データコンピテンシーをビジネスユーザーに転送する際の主な問題は次のとおりです。

新しいツールを学び、データを操作することにユーザー自身が気が進まない。
経営陣からのサポートの欠如（トレーニング、ライセンスなどへの投資）。

経営陣からの多大な支援に加えて、セルフサービスの導入を提案された経営陣もいます。また、ユーザーはデータとTableauの操作方法を学びたいと考えています。これは男性にとって興味深いことです。さらに、データ分析は非常に重要なスキルであり、将来的には間違いなく役立つでしょう。

会社全体に新しいイデオロギーを実装するには、通常、多くのリソースと神経が必要になるため、パイロットから始めました。セルフサービスパイロットプロジェクトは、1年半前にユーザー獲得部門で開始され、パイロットプロセス中にミスや経験が蓄積され、将来的に他の部門に引き継がれました。

ユーザー獲得の方向性は、当社の製品のオーディエンスを増やすタスクに取り組み、トラフィックの購入方法を分析し、会社の資金を投資する価値のあるユーザーを引き付ける方向を選択します。以前は、この方向性については、BIチームがレポートを作成するか、ExcelまたはGoogleスプレッドシートを使用してデータベースからのアップロードを処理していました。しかし、動的な開発環境では、このような分析には遅延が伴い、分析されるデータの数はこれらのツールの機能によって制限されます。

パイロットの開始時に、従業員がTableauを使用するための基本的なトレーニングを実施し、最初の共通データソースを作成しました。Redshiftデータベースのテーブルには、5億を超える行と必要なメトリックがありました。 Redshiftは列型（または列型）データベースであり、このデータベースはリレーショナルデータベースよりもはるかに高速にデータを提供することに注意してください。 Redshiftのパイロットテーブルは、同時に100万行を超えて作業したことがない人にとっては本当に大きかったです。しかし、そのようなボリュームのデータをどのように扱うかを学ぶことは、彼らにとって挑戦でした。

これらのレポートがより複雑になると、パフォーマンスの問題が発生することがわかっていました。ユーザーにデータベース自体へのアクセスを許可しませんでしたが、ソースはTableauサーバーに実装され、ライブモードでRedshiftのテーブルに接続されました。ユーザーはCreatorライセンスを持っており、Tableauサーバーから、そこでレポートを作成するか、TableauDesktopからこのソースに接続できました。Web上でレポートを開発する場合（TableauにはWeb編集モードがあります）、サーバーにはいくつかの制限があると言わなければなりません。Tableau Desktopにはそのような制限がないため、主にデスクトップで開発します。さらに、分析が必要なビジネスユーザーが1人だけの場合は、そのようなプロジェクトをサーバーに公開する必要はありません。ローカルで作業できます。

トレーニング

当社では、ウェビナーや知識の共有を行うのが通例であり、各従業員は、使用しているツールや研究しているツールの新製品、機能、機能について話すことができます。このような活動はすべて、ナレッジベースに記録および保存されます。このプロセスは私たちのチームでも機能するため、定期的に知識を共有したり、基本的なトレーニングウェビナーを準備したりします。

Tableauライセンスを持つすべてのユーザーを対象に、サーバーとダッシュボードの操作に関する30分のウェビナーをホストして記録しました。彼らは、すべてのダッシュボードのネイティブコントロールを操作して、サーバー上のプロジェクトについて話しました。これはトップパネルです（更新、一時停止など）。すべてのTableauユーザーにこれを伝えて、ネイティブ機能を完全に操作し、ネイティブコントロールの作業を繰り返す機能の開発を要求しないようにすることが不可欠です。

ツール（そして実際に何か新しいもの）を習得する上での主な障害は、通常、この機能を理解して操作することが不可能になるという恐れです。したがって、トレーニングは、セルフサービスBIアプローチを実装する上でおそらく最も重要なステップです。このモデルの実装の結果は、彼に大きく依存します-それが会社に定着するかどうか、もしそうなら、どれだけ早く定着するか。ウェビナーの開始時に、Tableauを使用する際の障壁を取り除く必要があります。

データベースの作業に慣れていない人のために実施したウェビナーには、次の2つのグループがあります。

初心者向けスターターナレッジキット：
- データ接続、接続タイプ、データタイプ、基本的なデータ変換、データの正規化（1時間）。
- 基本的な視覚化、データ集約、基本的な計算（1時間）。
/, (2 ).

この最初のキックオフウェビナーでは、Tableauでのデータ接続とデータ変換に関連するすべてをカバーします。通常、人々はMS Excelの基本的なレベルに習熟しているため、ここでは、Excelでの作業がTableauでの作業とどのように根本的に異なるかを説明することが重要です。これは非常に重要なポイントです。色付きのセルを持つテーブルのロジックから、正規化されたデータベースデータのロジックに人を切り替える必要があるためです。同じウェビナーで、JOIN、UNION、PIVOTの作業について説明し、ブレンディングについても触れます。最初のウェビナーでは、データの視覚化についてはほとんど触れません。その目標は、Tableauのデータを操作および変換する方法を説明することです。データが主要であり、ほとんどの問題は視覚化レベルではなくデータレベルで発生することを人々が理解することが重要です。

セルフサービスに関する2番目のウェビナーは、Tableauで視覚化を構築するロジックについて説明することを目的としています。 Tableauは、独自のエンジンと独自のロジックを備えているという点で、他のBIツールとは大きく異なります。他のシステム、たとえばPowerBIには、既製のビジュアルのセットがあります（ストアで追加のモジュールをダウンロードできます）が、これらのモジュールはカスタマイズできません。 Tableauには、実際には白紙の状態があり、その上に好きなものを作成できます。もちろん、Tableauには基本的な視覚化のメニューであるShowMeがありますが、これらのグラフと図はすべて、Tableauのロジックに従って作成できます。私たちの意見では、Tableauの操作方法を誰かに教えたい場合は、ShowMeを使用してグラフを作成する必要はありません。ほとんどのグラフは最初は役に立たないでしょうが、作成のロジックを正確に教える必要があります。視覚化。ビジネスダッシュボードの場合、知っておくだけで十分です構築方法：

時系列。折れ線/面グラフ（折れ線グラフ）、
棒グラフ
散布図、
テーブル

この一連の視覚化は、データの自己分析には十分です。

時系列：さまざまな期間のメトリックを比較することが興味深いため、ビジネスで非常に頻繁に使用されます。おそらく、会社の全従業員は、わが国の業績のダイナミクスを見ています。棒グラフを使用して、カテゴリごとに指標を比較します。散布図は、通常、メトリック間の相関関係を見つけるために使用されることはめったにありません。テーブル：ビジネスダッシュボードでは完全に取り除くことはできませんが、可能な限りその数を最小限に抑えるようにしています。表では、カテゴリごとに指標の数値を収集しています。

つまり、データの操作に関する1時間のトレーニングと、基本的な計算と視覚化に関する1時間のトレーニングの後に、フリーフロートで人々を送ります。それから、彼ら自身がしばらくの間彼らのデータを扱い、問題に直面し、経験を積み、ただそれを手に入れます。この段階には、平均して2〜4週間かかります。当然、この期間中に何かがうまくいかない場合は、BIチームに相談する機会があります。

最初の段階の後、同僚はスキルを向上させ、新しい機会を模索する必要があります。このために、詳細なトレーニングウェビナーを用意しました。それらの中で、LOD関数、テーブル関数、TabPyのPythonスクリプトを操作する方法を示します。ライブの会社データを使用します。これは、偽のデータや基本的なTableauデータセット（スーパーストア）のデータよりも常に興味深いものです。同じウェビナーで、独自のダッシュボードで使用されるTableauの主な機能とトリックについて説明します。

シートスワッピング（シートの交換）、
パラメータを使用したチャートの集約、
日付とメートル法の形式
週次/月次集計の不完全な期間を破棄します。

これらのトリックや機能はすべて、数年前は慣例であったため、社内の全員がそれらに慣れ、ダッシュボード開発標準に採用しました。Pythonスクリプトを使用していくつかの内部メトリックを計算します。すべてのスクリプトはすでに準備ができており、セルフサービスの場合は、それらを計算に挿入する方法を理解する必要があります。

したがって、セルフサービスを開始するために4時間のウェビナーを実行するだけであり、これは通常、やる気のある人がTableauで作業を開始し、自分でデータを分析するのに十分です。さらに、データアナリスト向けに、独自のウェビナーがあり、公開されており、それらに精通することができます。

セルフサービス用のデータソースの開発

パイロットプロジェクトが実施された後、私たちはそれが成功したと考え、セルフサービスユーザーの数を増やしました。大きな課題の1つは、さまざまなチームのデータソースを準備することでした。セルフサービスの担当者は2億行以上を処理できるため、データエンジニアリングチームはそのようなデータソースを実装する方法を理解する必要がありました。ほとんどの分析タスクでは、データの読み取り速度と使いやすさから、Redshiftを使用しています。しかし、セルフサービスから各人にデータベースへのアクセスを許可することは、情報セキュリティの観点からリスクがありました。

最初のアイデアは、データベースへのライブ接続を使用してソースを作成することでした。つまり、テーブルまたはRedshiftの準備されたビューのいずれかで表示されるいくつかのソースがTableauServerで公開されました。この場合、Tableauサーバーにデータを保存せず、これらのソースを介したユーザー自身がTableau Desktop（クライアント）からデータベースに移動しました。これは、テーブルが小さい（数百万）場合、またはTableauクエリがそれほど複雑でない場合に機能します。彼らが開発するにつれて、彼らはTableauのダッシュボードを複雑にし、LOD、カスタムソート、およびPythonスクリプトを使用し始めました。当然、これにより、一部のセルフサービスダッシュボードの作業が遅くなりました。そのため、セルフサービスの開始から数か月後に、ソースを使用する方法を改訂しました。

これまで使用してきた新しいアプローチでは、TableauServerに公開された抽出が実装されています。セルフサービスには常に新しいタスクがあり、ソースに新しいフィールドを追加する要求を受け取ります。もちろん、データソースは常に変更されています。ソースを操作するために、次の戦略を開発しました。

セルフサービス側からのソースのTORによると、データはデータベーステーブルに収集されます。
実体化されていないビューがRedshiftデータベースのテストスキーマに作成されます。
提出物は、QAチームによってデータの正確性についてテストされます。
チェックの結果が肯定的な場合は、赤方偏移の製品スキームについての見解が示されます。
データエンジニアリングチームはサポートを視野に入れています。データの有効性を分析するためのスクリプトが接続され、ETLアラームが接続され、セルフサービスチームに読み取り権限が付与されます。
Tableau Server (), .
ETL .
.
, Self-Service.

ポイント7について少し説明します。ネイティブでは、Tableauを使用すると、最小5分の差でスケジュールに従って抽出を作成できます。データベース内のテーブルが常に午前4時に更新されることが確実な場合は、抽出を午前5時に設定するだけで、データが収集されます。これは、さまざまなタスクをカバーしています。私たちの場合、テーブルは、を含むさまざまなプロバイダーからのデータに従って収集されます。したがって、1つのプロバイダーまたは内部サービスがデータの一部を更新できなかった場合、テーブル全体が無効であると見なされます。つまり、固定時間のスケジュールを設定するだけでは不十分です。したがって、Tableau APIを使用して、テーブルの準備ができたときに抽出を実行します。抽出起動シグナルは、すべての新しいデータが到着して有効であることを確認した後、ETLサービスによって生成されます。

このアプローチにより、最小限のレイテンシで抽出に新鮮な有効なデータを含めることができます。

TableauServerへのセルフサービスダッシュボードの公開

実験中の人を意図的に制限せず、ワークブックを公開および共有できるようにします。各チーム内で、自分のダッシュボードが他の人にとって有用であると考えている場合、または従業員がサーバー上にダッシュボードを必要としている場合は、それを公開できます。 BIチームは、それぞれチームの内部実験に干渉することはなく、ダッシュボードのすべてのロジックと計算を自分で行います。興味深いプロジェクトがセルフサービスから成長し、それが完全にBIチームのサポートに移されて、本番環境に移行する場合があります。これはまさにセルフサービスの効果であり、ビジネスタスクを十分に理解している人々がデータを操作し始め、作業の新しい戦略を形成します。これに基づいて、サーバー上で次のプロジェクトスキームを作成しました。

Tableau Serverプロジェクト図

各Creatorユーザーは、ワークブックをサーバーに公開するか、ローカルで分析を行うことができます。セルフサービスでは、プロジェクトグループで独自のサンドボックスを作成しました。

Tableauのサイトは、あるサイトのユーザーに別のサイトのコンテンツが表示されないようにイデオロギー的に分割されているため、サーバーを、ゲーム分析や財務など、重複しない領域のサイトに分割しました。グループアクセスを使用しています。各サイトには、ワークブックとソースに対する権利が継承されるプロジェクトがあります。つまり、ユーザーグループ1のグループには、ワークブックとデータソースのみが表示されます。このルールの例外は、サブプロジェクトもあるサンドボックスサイトです。サンドボックスは、プロトタイピング、新しいダッシュボードの開発、テスト、およびセルフサービスのニーズに使用します。サンドボックスプロジェクトへの公開アクセス権を持っている人は誰でも、プロトタイプを公開できます。

TableauServerでのソースとダッシュボードの監視

セルフサービスダッシュボードリクエストの負荷をデータベースからTableauServerに転送したため、大規模なデータソースを処理し、公開されたソースへのリクエストを制限しません。別の問題が発生しました。そのようなダッシュボードのパフォーマンスを監視し、作成されたものを監視します。ソース。

ダッシュボードのパフォーマンスとTableauサーバーのパフォーマンスの監視は、中規模および大規模の企業が直面するタスクであるため、ダッシュボードのパフォーマンスとその調整について多くの記事が書かれています。私たちはこの分野のパイオニアにはなりませんでした。監視は、内部のPostgreSQL TableauServerデータベースに基づくいくつかのダッシュボードです。この監視はすべてのコンテンツで機能しますが、セルフサービスダッシュボードを選択してそのパフォーマンスを確認できます。

BIチームは、ダッシュボードの最適化問題を随時解決します。ユーザーは「ダッシュボードが遅いのはなぜですか」という質問を思いつくことがあります。ユーザーの観点から「遅い」とは何か、この「遅い」を特徴付ける数値基準は何かを理解する必要があります。ユーザーにインタビューしたり、問題を詳細に説明するために作業時間を無駄にしたりしないように、httpリクエストを監視および分析し、最も遅いものを見つけて理由を見つけます。その後、パフォーマンスの向上につながる可能性がある場合は、ダッシュボードを最適化します。ソースへのライブ接続では、データベースでのビューの形成に関連する遅延、データの受信の遅延が発生することは明らかです。 ITインフラストラクチャ全体についてサポートチームと調査しているネットワーク遅延もありますが、この記事ではそれらについて詳しく説明しません。

httpリクエストについて少し

ブラウザのダッシュボードをユーザーが操作するたびに、独自のhttpリクエストが開始され、TableauServerに送信されます。このようなクエリの履歴全体は、内部のPostgreSQL TableauServerデータベースに保存されます。デフォルトの保存期間は7日です。この期間は、Tableau Serverの設定を変更することで増やすことができますが、httpリクエストのテーブルを増やしたくなかったため、古いデータが上書きされずに、毎日新しいデータのみを含む増分抽出を収集するだけです。これは、データベースに存在しなくなったサーバーの履歴データの抽出を保持するための最小限のリソースを使用するための良い方法です。

各httpリクエストには、独自のタイプ（action_type）があります。たとえば、_bootstrapはビューの初期ロードであり、relative-date-filterは日付フィルター（スライダー）です。ほとんどのタイプは名前で識別できるため、各ユーザーがダッシュボードで何をするかは明らかです。誰かがツールチップを詳しく調べ、誰かがパラメーターを変更し、誰かが独自のcustom_viewsを作成し、誰かがデータをアンロードします。

以下は、遅いダッシュボード、遅いリクエストタイプ、および待機する必要のあるユーザーを定義できるサービスダッシュボードです。

httpリクエストを監視するためのダッシュボード

VizQLセッションの監視

ダッシュボードをブラウザーで開くと、TableauサーバーでVizQLセッションが起動され、その中で視覚化がレンダリングされ、セッションを維持するためのリソースも割り当てられます。これらのセッションは、デフォルトで30分間非アクティブになるとドロップされます。

サーバー上のユーザー数が増加し、セルフサービスが導入されたため、VizQLセッションの制限を増やすようにいくつかのリクエストがありました。ユーザーにとっての問題は、ダッシュボードを開いてフィルターを設定し、何かを見て、しばらくしてダッシュボードを開いた状態に戻った後、Tableau Serverの外部の他のタスクに移動したが、デフォルトのビューにリセットされ、チューンを再利用します。私たちの仕事は、ユーザーエクスペリエンスをより快適にし、サーバーの負荷が大幅に増加しないようにすることでした。

サーバーの次の2つのパラメーターは変更できますが、サーバーの負荷が増加する可能性があることを理解する必要があります。

vizqlserver.session.expiry.minimum 5

VizQLプロセスのメモリが不足し始めた場合に、VizQLセッションを破棄できるようになるまでのアイドル時間の分数。

vizqlserver.session.expiry.timeout 30VizQLセッションが破棄されるまでのアイドル時間の分数。

したがって、VizQLセッションを監視し、以下を追跡することにしました。

セッション数、
ユーザーあたりのセッション数、
セッションの平均期間、
セッションの最大期間。

さらに、セッションの最大数が何日に、どの時間に開かれるかを理解する必要がありました。

結果は次のようなダッシュボードになります。

VizQLセッションを監視するためのダッシュボード

今年の1月の初めから、制限を徐々に増やし、セッションの期間と負荷を監視し始めました。平均セッション時間は13分から35分に増加しました。これは平均セッション時間のグラフで確認できます。最終設定は次のとおりです。

vizqlserver.session.expiry.minimum 120
vizqlserver.session.expiry.timeout 240

その後、ユーザーから好意的なフィードバックを受け取り、作業がはるかに快適になりました。セッションは衰退しなくなりました。

このダッシュボードのヒートマップを使用すると、サーバーの需要が最小限の時間帯にサービス作業をスケジュールすることもできます。

ZabbixとAWSコンソールでクラスター（CPUとRAM）の負荷の変化を監視します。タイムアウトの増加中に、負荷の大幅な変化は記録されませんでした。

Tableauサーバーを大きく曲げることができるものについて説明すると、たとえば、最適化されていないダッシュボードである可能性があります。たとえば、Tableauで、カテゴリ別および一部のイベントのIDごとに数万行のテーブルを作成し、MeasureではIDレベルでLOD計算を使用します。最小のグラニュレーションのすべてのLODが非常に多くのメモリを消費し、すぐにプロセスが100％に達するため、サーバー上のテーブルの表示が機能しない可能性が高く、予期しないエラーでクラッシュします。メモリ消費の。

この例は、1つの非最適なダッシュボードがすべてのサーバーリソースを消費する可能性があり、最適なダッシュボードの100のVizQLセッションでさえそれほど多くのリソースを消費しないことを明確にするためにここに示されています。

サーバーデータソースの監視

上記で、セルフサービスのために、サーバー上にいくつかのデータソースを準備して公開したことを指摘しました。すべてのソースはデータ抽出です。公開されたソースはサーバーに保存され、TableauDesktopを使用するユーザーが利用できるようになります。

Tableauには、ソースを認定済みとしてマークする機能があります。これは、セルフサービス用のデータソースを準備するときにBIチームが行うことです。これにより、ソース自体がテストされていることが保証されます。

公開されているソースは、2億行と100フィールドにもなる可能性があります。セルフサービスの場合、これは非常に大量です。独立した分析のためにそのようなボリュームのソースを持っている企業は多くないためです。

当然、ソースを生成するための要件を収集するときは、カテゴリをグループ化したり、プロジェクトごとにソースを分割したり、期間を制限したりすることで、ソース内のデータ量を削減する方法を検討します。しかし、それでも、原則として、ソースは1,000万行から取得されます。

ソースが大きいため、サーバー上のスペースを占有し、サーバーリソースを使用して抽出を更新します。次に、それらすべてを監視して、使用頻度とボリュームの増加速度を確認する必要があります。このために、監視を行いました。公開されたデータソースの。ソースに接続しているユーザー、それらのソースを使用するワークブックが表示されます。これにより、抽出物が収集できない無関係なソースまたは問題のあるソースを見つけることができます。

ソース監視ダッシュボード

結果

セルフサービスアプローチを1。5年間使用しています。この間、50人のユーザーが独立してデータを操作し始めました。これにより、BIチームの負荷が軽減され、BIチームがダッシュボードを開発するという特定のタスクに到達するまで待つ必要がなくなりました。約5か月前、私たちは他の分野を自己分析に結び付け始めました。

データリテラシーと視覚化のベストプラクティスに関するトレーニングを実施する予定です。

セルフサービスプロセスを会社全体に迅速に実装することはできないことを理解することが重要です。これには時間がかかります。移行プロセスが有機的で、従業員に衝撃を与えることなく、数年の実装後、会社のさまざまな部門や領域でデータを操作するための根本的に異なるプロセスを取得できます。

データの自己分析のための「セルフサービス」アプローチの実装