優れた外部データ分析ツールはユーザーにとって非常に重要であるため、適切なデータアーキテクチャを選択することが特に重要です。
今日、データ分析はもはや社内の開発者だけのものではありません。ビジネスサイドのデータ分析システムを構築する際には、どのデータベースバックエンドが最適かを見極める必要があります。
プログラマーの直感は、「知っていることをそのまま使う」ことかもしれません。データウェアハウスは、BIの中核となるダッシュボードやレポーティング以外にも機能を拡張することができますが、ビジネスサイドのデータ分析をサポートすることは依然として重要な機能の一部であるため、この機能のパフォーマンスを確保するために適切なツールを選択することが重要です。
この問題のキーポイントはユーザーエクスペリエンスであり、ここではデータ分析作業を外部からサポートするための主要な技術的論点について説明します。
低遅延機能
クエリのキューでずっと待たされるのはイライラするものです。待ち時間に関連する要因には、データ量、データベースの処理能力、ユーザー数とAPIコール数、クエリアプリケーションをサポートするデータベースの能力などがあります。
データ量が比較的大きい場合、任意のオンライン分析処理データベースをベースにインタラクティブなデータ体験を構築する方法がありますが、多かれ少なかれ他の何かを犠牲にすることになります。事前に計算されたクエリーは、パフォーマンスへの要求が高く、アーキテクチャを硬直化させる可能性があります。事前に集計された処理は、データの粒度を大きくする可能性があります。データ時間を近い将来に限定する処理は、データの完全性を保証できなくなります。
妥協のない」ソリューションとは、大規模なインタラクションのために構築された最適化されたアーキテクチャとデータ形式を選択することであり、Apache Druid まさにそのような最新の分析プログラムをサポートするように設計されたリアルタイムデータベースです。
- まず、Druidは、共有データ層からほぼ無制限の容量を持つデータサーバーのクラスタにデータをプリフェッチする独自の分散弾力性アーキテクチャを備えています。このアーキテクチャは、データを移動する必要がなく、PostgreSQLやMySQLのような垂直スケーリングデータベースよりもスケーラブルであるため、クラウドデータウェアハウスのような非連結クエリエンジンよりも高速なパフォーマンスを提供します。
- 第二に、Druidはデータフォーマットに組み込まれた自動マルチレベルインデックスを使用して、より多くのクエリ操作をサポートするために各コアを駆動します。グローバルインデックス、データ辞書、およびビットマップインデックスは、通常のOLAP列フォーマットに追加され、CPUサイクルを最大化し、処理を高速化します。
高可用性
開発チームが内部報告用のバックエンドを構築する場合、数分あるいはそれ以上の停止は本当に大きな問題なのでしょうか？実はそうではありません。一般的なOLAPデータベースやデータウェアハウスでは、計画外のダウンタイムやメンテナンスは許容されています。
しかし、あなたのチームが顧客用の外部分析アプリケーションを構築した場合、データの停止は顧客満足度や収益、そしてもちろん週末の休日に深刻な影響を及ぼしかねません。そのため、外部分析アプリケーションのデータベースでは、弾力性を第一に考慮する必要があります。
レジリエンスを考えるには、設計基準を考慮する必要があります。ノードやクラスタ全体の障害は完全に回避できますか？データを失った場合の影響はどの程度深刻ですか？アプリケーションとデータの保護にはどのような作業が必要ですか？
サーバーの障害に関しては、耐障害性を確保するための従来のアプローチは、マルチノード・サービスと バックアップ・メカニズムです。しかし、顧客向けのアプリケーションを構築している場合、データ損失に対する感度ははるかに高くなります。バックアップでは、この問題を完全に解決することはできません。
Apache Druidのコア・アーキテクチャには、この問題に対するソリューションが組み込まれており、基本的に、変更に耐えた場合にデータが失われないように設計された、強力でシンプルな弾力性アプローチがあります。
Druidは、オブジェクト・ストア内の共有データの自動化された複数レベルのレプリケーションに基づいて、高可用性と永続性を実現します。ユーザが期待する HA 機能に加え、クラスタ全体に障害が発生した場合でも自動的にデータベースを保護し、最新の状態にリストアする継続的なバックアップ機構を実装しています。
マルチユーザ
よいアプリケーションは多くのユーザーベースと "魅力的な "エクスペリエンスの両方を持つべきです。アプリケーションがハングして顧客が不満を持つのを見たくありません。内部レポーティングのためのアーキテクチャは、同時ユーザ数がはるかに少なく限られているため、このことを考慮する必要はありません。そのため、現実には、内部レポート用のデータベースは並行性の高いアプリケーションには適していないかもしれません。
高い同時実行性を実現するデータベースの構築は、CPU使用率、スケーラビリティ、コストのバランスを取ることが大きな問題です。並行性の問題を解決するための通常のアプローチは、より多くのハードウェアコストに投資することです。論理的には、CPUの数を増やすことで、より多くのクエリを同時に実行することができます。これは事実ですが、コストの増加は無視できません。
より良い方法は、Apache Druidのようなデータベースを使うことです。Apache Druidは、CPUの使用量を減らすために最適化されたストレージとクエリーエンジンを持っています。キーワードは「最適化」です。データベースは必要のないデータを読み込むべきではなく、Apache Druidはインフラが同じ時間でより多くのクエリを処理することを可能にします。
コスト削減は、開発者がApache Druidで外部分析アプリケーションを構築する主な理由です。Apache Druidは、高度に最適化されたデータ形式を持ち、検索エンジンの世界から借用したマルチレベルインデックスと、必要な処理量を最小限に抑えるデータ削減アルゴリズムを組み込んでいます。
その結果、Apache Druidは他のデータベースとは比較にならない処理効率を提供します。1秒間に数十から数千に及ぶテラバイト、さらにはペタバイトのクエリをサポートすることができます。
現在に集中し、未来を予測
アナリティクス・アプリケーションはユーザーにとって重要であるため、適切なデータ・アーキテクチャを構築してください。
確かに、間違ったデータベースで始めて、後で拡張するときに多くの頭痛の種に直面したくありません。幸いなことに、Apache Druidは小さく始めることができ、想像できるあらゆるアプリケーションをサポートするために後で簡単に拡張することができます。Apache Druidには あり、もちろんオープンソースです。
