01

1. 分析の次元と指標は包括的である必要があります。そうでない場合、複数のデータセットを構築する必要があり、以前のレポート作成の問題と同様に、多数の散在したデータセットが生成されます。

2. データは正確かつ信頼できるものでなければなりません。

3. 1 日あたり数千万のデータ ポイントが存在するため、クエリのパフォーマンスは大きな課題となります。

1. 包括的（分析の次元と指標は包括的で、ビジネス ニーズの 80% 以上をカバーする必要があります）。

2. 正確（一貫した基準と正確なデータ）

3.効率（データ出力時間T+10h）

4. 高速（10 秒以内に 10 億のデータ ポイントをクエリ）。

02

ビジネスダッシュボードの反復効率向上 (セルフサービス) : データレポートの反復モードが変更され、PM の要求提出と RD のスケジュール設定モードから、PM/運用のセルフサービス操作 (ダッシュボードの作成/データ分析) に徐々に移行しています。

データの洞察と分析の効率向上 (超高速) : 1 回のデータクエリに必要な時間が数分から数秒に短縮され、指標変動分析の効率が 20 倍向上し、単一の指標変動のエンドツーエンドのアトリビューション分析が 2 時間から 5 分以内に短縮されます。

ワンストップセルフサービスビジネス分析（ワンストップ） ：データ傾向の観察、ディメンションドリルダウン分析、詳細エクスポートなどの機能を可能にし、データ監視とデータ分析の統合エクスペリエンスを実現します。

1. データ ソース アクセス: 企業は TDS を使用して計算エンジンを通じて上流のチューリング テーブル データを計算し、そのデータを ClickHouse/MySQL/Palo などのエンジンに書き込み、直接接続を通じてアクセスします。または、企業が独自の Palo/MySQL データ ソース アクセスを提供します。

2. データモデリング：データソースに接続した後、SQLを記述するか、生のテーブルを直接使用することで、データを製品にロードできます。ただし、これらのテーブルを分析可能なデータセットに変換するには、通常、簡単な二次処理が必要です。

3. データ分析: ユーザーはデータセットに基づいてインジケーター、ディメンション、フィルターを自由にドラッグ アンド ドロップし、適切なチャートの種類とシナリオ分析方法を選択して分析と計算を実行できます。

4. データアプリケーション: ユーザーは分析結果をダッシュ​​ボードに保存したり、サードパーティのプラットフォームに埋め込んだり、大画面に保存したり、インテリジェント分析に直接使用したりできます。

2.1 全体設計

1. 統合クエリ コンテキスト: 将来的に他のチャート機能を拡張するときに共通機能の再利用を容易にするために、統合クエリ コンテキストが設計されています。

2. クエリ ビルダー: フロントエンドから送信されたリクエスト パラメータに基づいて、クエリ オブジェクトを構築します (テーブルのページ区切り用に 2 つのクエリ オブジェクト、ページ区切り用に 1 つ、カウント用に 1 つなど、複数のオブジェクトが存在する場合があります)。

3. クエリコネクタ:

a. 現在、SQLクエリを構築するエンジン（MySQL、Palo Alto、ClickHouseなど）に対応するには、SQLコネクタのみ利用可能です。エンジンによって構文や機能が異なる場合がありますが、エンジンルールの設定によって適応が実現されます。

b. 将来的には、非 SQL クエリに対応するために他のコネクタが追加される可能性があります。

4. キャッシュ書き込み: クエリのパフォーマンスを確保するために、ユーザーが初めてアクセスしたときに書き込むか、Celery のスケジュールされたタスクを通じてキャッシュを事前加熱するという 2 つの書き込み方法があります。

5. データセット モジュール: データ サポートを提供し、基礎となるデータ ソースとのリンクを確立してデータの品質を確保します。

6. システム セキュリティ モジュール: サブスクリプション、早期警告、アナウンスによりデータの早期警告機能が有効になり、共有、公開、承認によりデータ フローの効率が向上し、管理センターと権限によりデータの基盤となる管理と権限のサポートが提供されます。

1. コンポーネント ライブラリ: 構成解析、さまざまなチャート レンダリング コンポーネント、フィルター コンポーネント、およびカスタム コンポーネント機能を提供します。

2. インタラクション: ドラッグ アンド ドロップ エディター、ドリルダウン リンク、補助ショートカット機能、キャンバス機能、その他のイベント インタラクションなどのページ インタラクション機能をカプセル化します。

3. アプリケーション: ダッシュボード、大画面など、さまざまなユーザーや使用シナリオに合わせてさまざまな視覚化アプリケーションを有効にします。

2.2 詳細設計

1. ユーザーは、ページ上で自由にドラッグ アンド ドロップして分析できます。データセットを切り替えたり、さまざまなグラフの種類を切り替えたり、インジケーター、ディメンション、フィルター、クエリをドラッグしたりできます。また、高度なシナリオ分析機能を使用したい場合は、ワンクリックで構成を切り替えることができます。

2. フロントエンドリクエストは、データソース、クエリオブジェクト、戻り値形式を含む統合クエリコンテキストで処理されます。クエリオブジェクトは、基本的な指標、ディメンション、フィルタリング情報に加え、前年比・前月比、日次平均といった高度な分析設定もカプセル化します。

3. 統合認証サービス: ダッシュボードとデータセットの二重認証のカーネルに基づいて、行と列の権限のよりきめ細かい権限制御もサポートします。

4. クエリオブジェクトの構築：まず、指標、ディメンション、フィルタートリプルに基づいて基本的なSQL構築（集計、グループ化、フィルタリング）を完了します。次に、ソートルールに従ってソートロジックを組み立てます。一部の高度な分析オプション（前月比、日次平均など）については、追加の組み立てロジックを追加します。次に、ページネーションを処理します。プロセス全体を通して、方言の適応が必要です。データのクエリでは、異なるエンジンリンカーに従って、異なるデータベース（MySQL、Palo Alto、ClickHouseなど）にクエリが実行されます。

5. データのクエリと処理: リンカーを介してデータをクエリした後、データを処理します (日付形式の処理、折れ線グラフのピボットなど)。

6. キャッシュ: 処理されたデータはキャッシュに書き込まれます。または、クエリ中にキャッシュがヒットした場合は、キャッシュされたデータが読み取られ、直接返されます。

7. フロントエンドレンダリングフレームワークの統一レンダリング：統一されたデータ形式を返し、フロントエンドでチャートやスタイルなどの適応とレンダリングを完了します。

1. 2つのキャッシュ方法:

• 最初のクエリ: ユーザーが初めてアクセスすると (キャッシュ ペネトレーション)、データベースに対してクエリが実行され、キャッシュに書き込まれます。

• オフライン タスクの予熱: パブリック ダッシュボードのチャート レコードをスキャンし、チャートの要求をシミュレートして (1 回あたり 500 回以上の更新)、キャッシュを強制的に更新します。

2. 自動巻き：

過去のクエリから得られたトリプル（インジケーター、ディメンション、フィルター）に基づいて上位テーブルが作成されます。クエリが上位テーブルにヒットすると、取得されるデータ量が大幅に削減され、パフォーマンスが向上します。

1. ブラウザの同時実行制限 6 : 複数のドメインを使用することで、チャートのリクエストが他のリクエストに分散され、プラットフォームのスムーズなインタラクションが保証され、チャートのリクエストの同時実行性が向上し、全体的なパフォーマンスが向上します。

• オペレーティングシステムのポートリソースについて：PCには合計65,536個のポートがあり、1つのTCP接続（HTTPもTCPです）が1つのポートを占有します。オペレーティングシステムは通常、ポート制限がすぐに使い果たされるのを防ぐため、外部からのリクエストに対して全ポートの約半分を開放します。

• 同時実行性が高すぎるとコンテキストスイッチが頻繁に発生し、パフォーマンスの問題が発生します。各スレッドは1つのHTTPリクエストを処理するため、同時リクエスト数が多いとスレッドスイッチが頻繁に発生する可能性があります。スレッドのコンテキストスイッチは必ずしも軽量なリソースではありません。そのため、この取り組みは逆効果になる可能性があります。そのため、リクエストコントローラは接続プールを使用して以前の接続を再利用します。接続プールは、ドメインごとに最大4～8個の接続を持つものと想定できます。接続プール全体が使用されると、後続のリクエストタスクはブロックされ、利用可能な接続の実行を待機することになります。

• 同一クライアントからの大量の同時リクエストがサーバーの同時実行しきい値を超えるのを防ぐため：サーバーは通常、悪意のある攻撃を防ぐために、同じクライアントオリジンに対して同時実行しきい値を設定します。ブラウザが同一ドメインの同時実行を制限していない場合、サーバーの同時実行しきい値を超え、アクセスが禁止される可能性があります。

• クライアント側の整合性メカニズム: 2 つのアプリケーションがリソースを競合した場合に、強い方のアプリケーションが制限なくリソースを取得し、弱い方のアプリケーションが永続的にブロックされるのを防ぎます。

2. サーバーサイドのマルチプロセス + マルチコルーチン同時実行:

• 複数のプロセスで開発を行う場合、「サンダーリング・ハード問題」が発生する可能性があります。これは、複数のプロセスが同じイベントを待機する問題です。イベントが発生すると、カーネルによってすべてのプロセスが起動されますが、イベントを取得して処理できるのは1つのプロセスだけです。他のプロセスはイベントを取得できなかったため、待機を続けます。同じイベントを待機するプロセスが増えるほど、CPUの競合が激しくなり、コンテキストスイッチのコストが著しく増加します。

• したがって、この状況に対処するために、uwsgi サービスは共有ロック メカニズムを設計および実装し、特定の時点で 1 つのプロセスのみがイベントをリッスンするようにして、thundering herd 問題を解決しました。

• ただし、プロセス数を無制限に増やすことはできません。一般的には、CPU コア数の 2 倍にすることが推奨されます。

• プロセス数が限られている場合、スループットを向上させるにはどうすればよいでしょうか。通常、I/O はブロッキングです。データベースやファイルから読み取る際、現在のプロセスまたはスレッドは、I/O 操作が結果を返すまで待機してから実行を続行します。マルチスレッド化によってスループットを向上させると、 I/O ブロッキングに遭遇したスレッドがスタックし、他の同時要求が処理されないままになります。非同期 I/O は、コルーチンによって実現できます。各スレッドは、独自の I/O を実行する際に、結果を待つのではなく、受信した要求を処理し、完了すると I/O 操作を待機していたコードに戻ります。このようにして、プログラム内のすべてのスレッドを最大限に活用し、常にビジー状態を維持できます。このアプローチにより、全体的なスループットが向上し、全体的な実行時間が短縮されますが、個々のスレッドの実行時間には影響しません。

プッシュ通知の内容: 単一のグラフ、レポート全体

プッシュ通知の形式：3つの形式

• チャートのスクリーンショット

• チャートのCSVデータ（メール添付）

• スクリーンショットを報告

発動条件：

• スケジュールされたプッシュ通知は、cron 式に従って送信されます。

• データ同期が完了すると、プッシュ通知が送信されます。レポート内のすべてのチャートに関連付けられたデータセットのデータ同期が完了すると、プッシュ条件が満たされ、メール通知が送信されます。

送信者: 電子メール アカウント。複数のアカウントはコンマで区切ります。

03

3.1 要約

3.2 計画