バージョン: 4.x

POCを開始する前に

この文書は、新規ユーザーが遭遇する可能性のある一般的な問題を取り上げ、POCプロセスを加速することを目的としています。コンテンツは一般的なPOCワークフローに沿って整理されています：

Table Design — データモデル、ソートキー、パーティショニング、およびバケッティング戦略を選択する。
Data Loading — 適切なロード方法を選び、よくある落とし穴を避ける。
Query Tuning — 遅いクエリを診断し、バケッティングとインデックス設定を最適化する。
Data Lake Queries — Lakehouseシナリオ向けの追加最適化のヒント。

Table Design

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

Data Model

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

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

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

Sort Key

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

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

Partitioning

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

Bucketing

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

バケット数の選択方法：

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

Example Templates

Log / Event Analytics

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バケティングを使用するDuplicate Keyテーブルではload_to_single_tabletを有効にしてください 書き込み増幅を削減するためです。

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

クエリチューニング

バケティング

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

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

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

インデックス

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

診断ツール

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

データレイククエリ

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

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

レイクテーブルはしばしば大量のデータを保持します。DorisがGU要なパーティションのみをスキャンするように、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回目のクエリのレイテンシをベンチマークとして使用してください。これにより、定常状態の本番環境のパフォーマンスをより正確に反映できます。

小さなファイルへの対処

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

ソースでの修正（推奨）： Hive/Spark側で小さなファイルを定期的にcompactし、各ファイルを128 MB以上に保ちます。
Doris側のセーフガード： SET max_file_split_num = 50000;（4.0.4以降でサポート）を使用して、スキャンあたりの最大split数を制限し、OOMを防ぎます。

診断でのQuery Profileの使用

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

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

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

Table Design​

Data Model​

Sort Key​

Partitioning​

Bucketing​

Example Templates​

Log / Event Analytics​

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

メトリクス集約​

データ読み込み​

クエリチューニング​

バケティング​

インデックス​

診断ツール​

データレイククエリ​

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

Data Cacheの有効化​

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

診断でのQuery Profileの使用​