バージョン: 4.x

POCを開始する前に

この文書では、新規ユーザーが遭遇する可能性のある一般的な問題を取り上げ、POCプロセスの加速を目的としています。内容は典型的なPOCワークフローに従って構成されています：

テーブル設計 — データモデル、ソートキー、パーティショニング、およびバケッティング戦略を選択する。
データロード — 適切なロード方法を選択し、一般的な落とし穴を回避する。
クエリチューニング — 低速なクエリを診断し、バケッティングとインデックス設定を最適化する。
Data Lakeクエリ — Lakehouseシナリオのための追加最適化のヒント。

テーブル設計

Dorisでテーブルを作成する際は、ロードとクエリのパフォーマンスに影響する4つの決定事項があります：データモデル、ソートキー、パーティショニング、およびバケッティングです。

データモデル

データの書き込み方法に基づいてモデルを選択してください：

データの特性	推奨モデル	理由
追記のみ（ログ、イベント、ファクト）	Duplicate Key（デフォルト）	すべての行を保持し、最高のクエリパフォーマンスを提供
プライマリキーによる更新（CDC、upsert）	Unique Key	新しい行が同じキーを持つ古い行を置き換える
事前集計されたメトリクス（PV、UV、合計）	Aggregate Key	書き込み時にSUM/MAX/MINで行がマージされる

Duplicate Keyはほとんどのシナリオで動作します。Data Model Overviewを参照してください。

ソートキー

Dorisはキー列の最初の36バイトにprefix indexを構築します。ソートキーを設定する際は、以下の原則に従ってください：

頻繁にフィルタされる列を最初に：WHERE条件で最も一般的に使用される列を前に配置する。
固定サイズ型を最初に：INT、BIGINT、DATE、およびその他の固定サイズ型をVARCHARより前に配置する。prefix indexは最初のVARCHAR列で停止するため。
転置インデックスを追加：prefix indexでカバーされない列については、inverted indexesを追加してフィルタリングを高速化する。

パーティショニング

時刻列がある場合は、AUTO PARTITION BY RANGE(date_trunc(time_col, 'day'))を使用してpartition pruningを有効にしてください。Dorisは関係のないパーティションを自動的にスキップします。

バケッティング

デフォルトはRandom bucketingです（Duplicate Keyテーブルに推奨）。特定の列で頻繁にフィルタやjoinを行う場合は、DISTRIBUTED BY HASH(col)を使用してください。Data Bucketingを参照してください。

バケット数の選び方：

原則	詳細
BE数の倍数	データの均等な分散を保証する。後でBEが追加された場合、クエリは通常複数のパーティションをスキャンするため、パフォーマンスは維持される
可能な限り低く	小さなファイルの生成を回避する
バケットあたりの圧縮データ ≤ 20 GB	Unique Keyテーブルでは ≤ 10 GB。`SHOW TABLETS FROM your_table`で確認
パーティションあたり128以下	より多く必要な場合は、まずパーティションの追加を検討する。極端なケースでは上限は1024だが、本番環境で必要になることは稀

テンプレート例

ログ / イベント分析

CREATE TABLE app_logs
(
    log_time      DATETIME    NOT NULL,
    log_level     VARCHAR(10),
    service_name  VARCHAR(50),
    trace_id      VARCHAR(64),
    message       STRING,
    INDEX idx_message (message) USING INVERTED PROPERTIES("parser" = "unicode")
)
AUTO PARTITION BY RANGE(date_trunc(`log_time`, 'day'))
()
DISTRIBUTED BY RANDOM BUCKETS 10;

Upsert（CDC）を使用したリアルタイムダッシュボード

CREATE TABLE user_profiles
(
    user_id       BIGINT      NOT NULL,
    username      VARCHAR(50),
    email         VARCHAR(100),
    status        TINYINT,
    updated_at    DATETIME
)
UNIQUE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 10;

メトリクス集約

CREATE TABLE site_metrics
(
    dt            DATE        NOT NULL,
    site_id       INT         NOT NULL,
    pv            BIGINT      SUM DEFAULT '0',
    uv            BIGINT      MAX DEFAULT '0'
)
AGGREGATE KEY(dt, site_id)
AUTO PARTITION BY RANGE(date_trunc(`dt`, 'day'))
()
DISTRIBUTED BY HASH(site_id) BUCKETS 10;

データ読み込み

適切な読み込み方法を選択し、以下のベストプラクティスに従って一般的なパフォーマンスの問題を回避してください：

大量データにINSERT INTO VALUESを使用しないでください。 代わりにStream LoadまたはBroker Loadを使用してください。Loading Overviewを参照してください。
クライアント側で書き込みをバッチ化してください。 高頻度の小規模インポートはバージョンの蓄積を引き起こします。実行不可能な場合は、Group Commitを使用してください。
大規模インポートをより小さなバッチに分割してください。 失敗した長時間実行インポートは最初からやり直す必要があります。段階的インポートにはINSERT INTO SELECT with S3 TVFを使用してください。
Random bucketingを使用するDuplicate Keyテーブルではload_to_single_tabletを有効にして、書き込み増幅を削減してください。

Load Best Practicesを参照してください。

クエリチューニング

Bucketing

バケット数はクエリの並列性とスケジューリングオーバーヘッドに直接影響します — 両者のバランスを取ってください：

過度なbucketingを行わないでください。 小さなタブレットが多すぎるとスケジューリングオーバーヘッドが発生し、クエリパフォーマンスが最大50%低下する可能性があります。
bucketingが不足しないようにしてください。 タブレットが少なすぎるとCPU並列性が制限されます。
データの偏りを避けてください。 SHOW TABLETSでタブレットサイズを確認してください。サイズが大幅に異なる場合は、Random bucketingまたはより高いカーディナリティのバケット列に切り替えてください。

サイジングガイドラインについてはBucketingを参照してください。

インデックス

ソートキーに適切な列を配置してください。 PostgreSQLなどのシステムとは異なり、Dorisはキー列の最初の36バイトのみをインデックス化し、最初のVARCHARで停止します。このプレフィックスを超えた列はソートキーの恩恵を受けません。それらの列にはinverted indexesを追加してください。Sort Keyを参照してください。

診断ツール

遅いクエリを診断するにはQuery Profileを参照してください。

データレイククエリ

POCがDorisを通じてHive、Iceberg、Paimon、または他のデータレイクのデータをクエリすること（つまりLakehouseシナリオ）を含む場合、以下の点がテスト結果に最も大きな影響を与えます。

パーティションプルーニングが効果的であることを確認する

レイクテーブルは多くの場合、大量のデータを保持しています。Dorisが必要なパーティションのみをスキャンするよう、WHERE条件に常にパーティション列を含めてください。EXPLAIN <SQL>を使用してpartitionフィールドを確認し、プルーニングが機能していることを検証してください：

0:VPAIMON_SCAN_NODE(88)
    partition=203/0          -- 203 partitions pruned, 0 actually scanned

パーティション数が予想より大幅に多い場合は、WHERE条件がパーティション列と正しく一致しているかを確認してください。

Data Cacheの有効化

リモートストレージ（HDFS/オブジェクトストレージ）は、ローカルディスクよりもIOレイテンシが大幅に高くなります。Data Cacheは、最近アクセスされたリモートデータをBEのローカルディスクにキャッシュし、同じデータセットに対する反復クエリで内部テーブルに近いクエリパフォーマンスを提供します。

キャッシュはデフォルトで無効になっています。設定と有効化についてはData Cacheドキュメントを参照してください。
バージョン4.0.2以降、cache warmupがサポートされ、POCテスト前にホットデータを事前に読み込むことができます。

ヒント

POC中は、キャッシュを有効にするため一度クエリを実行し、2回目のクエリのレイテンシをベンチマークとして使用してください。これにより、本番環境の定常状態のパフォーマンスをより正確に反映できます。

小さなファイルへの対処

データレイクストレージには、多数の小さなファイルが含まれることがよくあります。小さなファイルは多くのスプリットに分割され、FEのメモリ負荷が増加し（OOMの原因となる可能性）、クエリプランニングのオーバーヘッドが増大します。

ソースでの修正（推奨）: Hive/Spark側で小さなファイルを定期的にコンパクト化し、各ファイルを128MB以上に保ちます。
Doris側のセーフガード: SET max_file_split_num = 50000;（4.0.4以降でサポート）を使用して、スキャンごとのスプリットの最大数を制限し、OOMを防止します。

診断のためのQuery Profileの使用

データレイククエリのボトルネックは通常、計算ではなくIOです。Query Profileは、遅いクエリの根本原因を特定するのに役立ちます。以下に注目してください：

スプリット数とデータ量: スキャンされているデータが多すぎるかを判断します。
MergeIOメトリクス: MergedBytesがRequestBytesよりも大幅に大きい場合、読み取り増幅が深刻です。merge_io_read_slice_size_bytes（デフォルト8MB）を削減して軽減してください。
キャッシュヒット率: Data Cacheが効果的に機能していることを確認します。

その他の最適化技術については、Data Lake Query Optimizationを参照してください。

テーブル設計​

データモデル​

ソートキー​

パーティショニング​

バケッティング​

テンプレート例​

ログ / イベント分析​

Upsert（CDC）を使用したリアルタイムダッシュボード​

メトリクス集約​

データ読み込み​

クエリチューニング​

Bucketing​

インデックス​

診断ツール​

データレイククエリ​

パーティションプルーニングが効果的であることを確認する​

Data Cacheの有効化​

小さなファイルへの対処​

診断のためのQuery Profileの使用​