最大限の洞察を引き出す必要がありますよね? そのためには、関連するすべてのデータに完全にアクセスできる必要があります。 分析では 分析とは、データを洞察に変換するプロセスです。企業が目標を達成するために、より適切な意思決定を行うのに役立つユースケースは数多くあります。これらの目標には、顧客満足度の向上、収益の増加、コストの削減などが含まれることがよくあります。 SaaS プロバイダーがアプリケーションに分析機能を組み込むと、ユーザーに提供する価値は増大するばかりです。結局のところ、ユーザー エクスペリエンスと顧客満足度の向上が顧客維持の鍵となります。 しかし、なぜ多くの SaaS 企業がデータ レイクを使用しないのでしょうか? なぜこれほど多くの人が、非常に高価になる従来のデータ ウェアハウスの使用にこだわるのでしょうか? これを理解してみましょう。 データレイクとは何ですか? データ レイクは、あらゆる種類のデータを元の非構造化形式で中央ストレージに保存する場所です。 従来のデータ ウェアハウスとは異なり、データ レイクは構造化データ、半構造化データ、非構造化データを取り込み、保存し、処理できます。 によれば、「データ ウェアハウスは、構造化された形式でデータを保存します。これは、分析とビジネス インテリジェンス用に前処理されたデータの中央リポジトリです。一方、データ レイクは、生データと非構造化データの中央リポジトリです。最初にデータを保存し、後で処理することができます。」 AWS データレイクの利点 データ レイクは、主に運用システムからの生データのリポジトリです。データ レイクは、大量のデータを生の形式に近い状態で保持します。次に、他のシステムが簡単に使用できる形式でデータをカタログ化して低コストで保存します。 AWS では、データレイクは次の分析に適していると説明しています。 機械学習 / AIトレーニング データサイエンティストとアナリスト 探索的分析 データ検出 ストリーミング 運用/高度な分析 ビッグデータ分析 データプロファイリング データレイクはスケーラブルですか? はい。AWS は、データレイクにより「あらゆる規模のデータを保存できる」と述べています。 データ レイクは、構造化データ、半構造化データ、非構造化データなど、さまざまなデータ タイプを処理できます。これらのデータ タイプは、多くの場合、次のようなデータから生成されます。 データベース ファイル ログ ソーシャルメディア データレイクストレージの柔軟性はどの程度ですか? ガバナンス スイートとデータ カタログのプロバイダーである OvalEdge は、データ レイクの 。「データ レイクは、さまざまなソースからの多重構造データを保存できます。 汎用性について次のように述べています データ レイクには次のものを保存できます。 ログ テキスト マルチメディア センサーデータ バイナリ ソーシャルデータ チャット 人物データ OvalEdge は、これを分析に応用しています。同社では、データを特定の形式にする必要があることが障害になっていると述べています。「Hadoop データ レイクを使用すると、スキーマフリーになるか、同じデータに複数のスキーマを定義できます。つまり、スキーマをデータから切り離すことができ、分析に最適です。」 データレイクの使用にはどれくらいの費用がかかりますか? 組み込み分析のユースケースでは、データ レイクの方がデータ ウェアハウスよりも一般的にコスト効率が高くなります。 Snowflake などのデータ ウェアハウスのコストは、同時クエリによって制御不能に増加することがよくあります。SaaS プラットフォームのコンピューティング需要は、内部分析機能とは異なります。 コストも低くなる理由は次のとおりです。 データレイクの構築にはそれほど労力はかからない レイテンシが非常に低い データ分析をサポートできる スキーマやフィルタリングが不要なため、データ ウェアハウスに比べてストレージ コストが低くなります。 データ ウェアハウスとは何ですか? データ ウェアハウスは、主に上流システムから変換、キュレーション、モデル化されたデータを格納するデータ ストアです。データ ウェアハウスでは、構造化されたデータ形式が使用されます。 弊社のブログでは、マルチテナント分析における の違いについて説明しました。データ エンジニアの役割は、データ レイクをデータ ウェアハウスに変換することです。このプロセスは、泳ぐカピバラが環境に適応するプロセスに似ています。その後、赤ちゃんカピバラのデータ サイエンティストが分析を実行できます。 データ エンジニアとソフトウェア エンジニア データ ウェアハウスの利点 データウェアハウスは構造化データに最適化されています データ ウェアハウスは、データ保存に構造化データ形式またはリレーショナル データ形式を使用します。 データ ウェアハウスは構築に時間がかかり、生データへのアクセスも少なくなります。ただし、データのキュレーションが必要なため、一般的にデータ分析にはより安全で生産性の高い場所となります。 、「データレイクとデータウェアハウスはどちらも無制限のデータソースを持つことができます。ただし、データウェアハウスでは、データを保存する前にスキーマを設計する必要があります。システムにロードできるのは構造化データのみです。」と述べています。 AWS は AWS は、「逆に、データレイクにはそのような要件はありません。Web サーバーのログ、クリックストリーム、ソーシャル メディア、センサー データなどの非構造化データや半構造化データを保存できます」と説明しています。 シングルテナント/内部分析に最適 ウェアハウス内の構造化データは、クエリ パフォーマンスが高速であるため、ユーザーがレポートをすばやく生成するのに役立ちます。これは、データの量とコンピューティング リソースの割り当てによって異なります。 Databricks は、「データ ウェアハウス と、POS システム、在庫管理システム、マーケティング データベース、販売データベースなどの運用システムからアップロードされたビジネス データを迅速かつ簡単に分析できます。データは運用データ ストアを通過する場合があり、データ ウェアハウスでレポート作成に使用する前に、データの品質を確保するためにデータ クレンジングが必要になります。」と述べています。 を使用する データ ウェアハウスの課題 マルチテナントに対応していない ほとんどのデータ ウェアハウスは大量のデータを保存しますが、通常はマルチテナント分析には使用されません。 データ ウェアハウスを使用してマルチテナント分析を強化する場合、適切なアプローチが不可欠です。Snowflake と Redshift は、データの整理と保存に役立ちます。ただし、複数のテナントからのデータを分析するとなると、困難が生じる可能性があります。 マルチテナント分析用のデータ ウェアハウスで 。ユーザー権限を実装するためのセマンティック レイヤーがまったく存在しないことは言うまでもありません。 は、事前にかなりのモデリングとエンジニアリングが必要であり、その結果、コストが大幅に高くなります マルチテナントセキュリティロジックの欠如 マルチテナント SaaS アプリでデータを保護するのは難しい場合があります。特に、チャートをデータ ウェアハウスに直接接続する場合は困難です。 データ管理とガバナンスには、カスタム開発されたミドルウェアが必要です。これは、メタテーブル、ユーザー アクセス制御、およびデータ セキュリティを調整するセマンティック レイヤーの形で存在します。 データ ウェアハウスに接続するには、別のセマンティック レイヤーを構築する必要があります。このコンポーネントは、フロントエンド Web アプリケーションのマルチテナント ロジックをデータ ウェアハウス ロジックに変換します。残念ながら、このプロセスは特に面倒です。 Snowflake は、マルチテナント分析用のデータ ウェアハウスを設計するための 3 つのパターンを説明してい 。「マルチテナント テーブル (MTT) は、アプリケーションがサポートできるテナントの数の点で最もスケーラブルな設計パターンです。」と述べています。 ます このアプローチは、数百万のテナントを持つアプリをサポートします。Snowflake 内のアーキテクチャはよりシンプルです。オブジェクトの拡散により、時間の経過とともに無数のオブジェクトの管理がますます困難になるため、シンプルさが重要です。」 高額なコンピューティングコスト データ ウェアハウスでマルチテナント分析を実行する場合、継続的なコストも高くなる可能性があります。 マルチテナント プラットフォームでは、クエリごとの料金の計算費用が指数関数的に増加します。 これは特に Snowflake データ クラウドで問題となります。パブリック クラウド インフラストラクチャと同様に、使用量が増えるとコストが上昇するのは当然です。残念ながら、 、付加価値に正確に比例するのではなく、指数関数的に増加することがよくあります。[ お試しください] Snowflake のコスト上昇は Snowflake コスト最適化計算機を スケーラビリティも課題 SaaS 分析は、ほぼ瞬時に誰でも利用できる必要があります。 アイドル時間が大量に発生する可能性は低いでしょう。分析を使用すると、ユーザーはより多くの価値を得ることができます。使用率が高まると、収益と顧客維持率も高まります。 SaaS ベンダーは、テナントの増加に合わせて 。 データ ウェアハウスがスムーズに拡張されるように取り組む必要があります マルチテナント SaaS アプリケーションの組み込み分析にデータ レイクが適しているのはなぜですか? マルチテナント SaaS アプリの組み込み分析にデータ レイクが最適な選択肢となる理由はいくつかあります。 1) マルチテナントデータレイクによりアプリケーションのスケーリングが簡素化される ストレージ、コンピューティング、管理のオーバーヘッドを共有インフラストラクチャに統合すると、ユーザーベースの拡大に応じてプロバイダーとテナント加入者の両方のコストが大幅に削減されます。 ただし、リソース クラスターのサイズを正しく設定することが重要です。同時実行の要求は、SaaS テナント ベース内で実際に発生します。 データ レイクは、テナント データの分離にも有利です。テナントが同じインスタンスにアクセスする場合、厳格なアクセス制御によって他のテナントのデータが見える状態になりません。 2) 多様なデータ形式の取り扱い データの種類は増加しています。SaaS プラットフォームの製品リーダーは、より優れた分析を提供したいと考えていますが、データ ウェアハウスがそれを妨げていることがよくあります。 データ レイクは分析オプションを提供します。半構造化データが使用される場合、MongoDB などのデータベースをデータ レイクに保存するのが簡単になります。 非構造化データ オプションを使用すると、顧客サービスのユースケースにテキスト分析を提供することもできます。 3) 複数のテナントに対応するスケーラビリティ データ ウェアハウスは、多大な開発労力をかけずにマルチテナント向けに簡単にスケールアウトすることはできません。 データ ウェアハウスでマルチテナントを実現するには、追加のインフラストラクチャを構築する必要があります。データベースとユーザー向けアプリケーションの間には論理プロセスが存在し、エンジニアリング チームが独自に構築する必要があります。 4) データの分離とセキュリティ データ ウェアハウスは、マルチテナント環境での行レベルのセキュリティに苦労しています。 すべてのデータ ウェアハウス ソリューションでは、テナント レベルのデータ分離を確保するために追加の作業が必要です。この課題は、ユーザー レベルのアクセス制御によってさらに複雑になります。 5) コスト面でのメリット データ レイクはスケール アウトが容易で、必要なコンピューティング リソースも少なくて済みます。これが 強化する大きな理由です。 、マルチテナント データ レイクを Elasticsearch で データ ストリーミングの先駆者である Confluent 、「データ レイクは生の形式で保存されるため、コスト面で最も効率的です。一方、データ ウェアハウスは、分析用に保存するデータを処理および準備する際に、はるかに多くのストレージを占有します」と述べています。 は データレイクの実装における課題 1) 熟練した人材 ソフトウェア エンジニアはデータ エンジニアではありません。 自分で構築する場合は、 用のデータレイクを適切に拡張できるデータエンジニアが必要になります。ソフトウェアの拡張は、分析クエリの拡張とは異なります。 マルチテナント分析 データ エンジニアリングには、特に大規模なデータの収集、保存、分析を行うシステムの作成が含まれます。データ エンジニアは、組織がデータを収集および管理して有用な洞察を得るのを支援します。また、データを分析や機械学習用の形式に変換します。 。そしてもちろん、データ エンジニアの必要性を排除することでコストが削減され、市場投入までの時間が短縮されます。 Qrvey はデータ エンジニアの必要性を排除します 2) 既存システムとの統合 複数のソースからのデータを分析するには、SaaS プロバイダーは独立したデータ パイプラインを構築する必要があります。 Qrvey は においてもこの問題を排除します。 データ収集 Qrvey を使用する SaaS 企業は、分析を構築して起動するためにデータ エンジニアの支援を必要としません。そうしないと、チームはソースごとに個別のデータ パイプラインと ETL プロセスを構築することになります。 Qrvey は、次の機能を提供する統合データ パイプラインを備えたターンキー データ管理レイヤーでこの課題に対処します。 あらゆるデータタイプを取り込むための単一のAPI 一般的なデータベースやデータウェアハウスへの事前構築されたデータコネクタ 変換ルールエンジン 必要に応じてマルチテナントを含む、スケールとセキュリティ要件に合わせて最適化されたデータレイク データレイクマルチテナント分析を使用するためのベストプラクティス 明確なデータ戦略を定義する 分析を生成しようとする組織には、データ戦略が必要です。 。 AWS では、これを「組織の情報資産を管理するために必要なテクノロジー、プロセス、人材、ルールを定義する長期計画」と定義しています これは、予想以上に難しい場合がよくあります。 多くの組織は、人々がスマートフォンがクリーンだと思っているのと同じように、データがクリーンだと考えています。しかし、どちらも だらけであることが多いのです。 細菌 データ クリーニングは、データセット内のデータを修正するプロセスです。一般的に見られる問題は、データが間違っている、破損している、形式が間違っている、または不完全であることです。 複数のデータ ソースを組み合わせる場合、重複データは特に懸念事項となります。誤ったラベル付けが発生すると、特に問題になります。リアルタイムのデータの場合は、さらに大きな問題となります。 データベースのスケーラビリティは、楽観的な見方が根拠のないものであることが多いもう 1 つの領域です。DesignGurus.io は、「SQL データベースを水平方向にスケーリングすることは、技術的なハードルが山積する複雑な作業です」と 。 述べています 誰がそれを望んでいますか? データセキュリティとガバナンスの実装 SaaS プロバイダーは、特定の機能へのアクセスを制御する権限をユーザーに付与する場合があります。アドオン モジュールに追加料金を請求するには、アクセスを制御する必要があります。 セルフサービス分析機能を提供する場合、データ戦略にセキュリティ制御を含める必要があります。 たとえば、ほとんどの SaaS アプリケーションでは、ユーザー層を使用してさまざまな機能を提供しています。テナントの「管理者」はすべてのデータを見ることができます。逆に、下位層のユーザーは部分的なアクセス権しか持ちません。この違いは、すべてのチャートとチャート ビルダーがこれらの層を尊重する必要があることを意味します。 データがクラウド環境から出た場合、データ セキュリティを維持することも複雑で困難です。BI ベンダーがデータを自社のクラウドに送信することを要求すると、不必要なセキュリティ リスクが生じます。 対照的に、Qrvey のようなセルフホスト型ソリューションでは、データがクラウド環境から外に出ることはありません。分析は完全に環境内で実行でき、既存のセキュリティ ポリシーを継承します。これは SaaS アプリケーションに最適です。ソリューションは安全になるだけでなく、インストール、開発、テスト、展開がより簡単かつ迅速になります。 Qrveyは分析はデータから始まることを知っている 「分析」という言葉を聞くと、さまざまなグラフが整然と表示されたカラフルなダッシュボードのイメージが思い浮かぶかもしれません。 それが最終目的です が、すべてはデータから始まります。 Qrvey がデータレイクの使用に注力したのは、分析はデータから始まることを理解しているからです。 当社は、SaaS 企業向けのマルチテナント分析に特化した組み込み分析プラットフォームを構築しました。目標は、ソフトウェア製品チームがコストを節約しながら、より短時間でより優れた分析を提供できるようにすることです。 しかし、それはデータから始まります。 Qrvey は、さまざまなニーズに応える柔軟なデータ統合オプションを提供します。既存のデータベースへのライブ接続と、組み込みのデータ レイクへのデータの取り込みの両方が可能です。 このクラウド データ レイク アプローチは、複雑な分析クエリのパフォーマンスとコスト効率を最適化します。さらに、システムは取り込み中にデータを自動的に正規化するため、マルチテナント分析とレポート作成の準備が整います。 Qrvey は、Redshift、Snowflake、MongoDB、Postgres などの一般的なデータベースやデータ ウェアハウスへの接続をサポートしています。 リアルタイムのデータプッシュ用の取り込み API も提供しています。これは、 や などの半構造化データをサポートします。 JSON FHIR データ さらに、S3 バケットなどのクラウド ストレージからのデータや、ドキュメント、テキスト、画像などの非構造化データを取り込むことも可能です。 Qrvey にはデータ変換が組み込み機能として含まれているため、個別の ETL サービスが不要になります。Qrvey を使用すると、専任のデータ エンジニアは不要になります。 より少ないソフトウェアの構築で、顧客により多くの価値を提供できるように当社がどのように支援するかをご紹介します。
