POCを開始する前に

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

1. テーブル設計 — データモデル、ソートキー、パーティショニング、バケッティング戦略を選択します。
2. データ読み込み — 適切な読み込み方法を選択し、よくある落とし穴を回避します。
3. クエリチューニング — 低速クエリを診断し、バケッティングとインデックス設定を最適化します。
4. 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条件で最も一般的に使用される列を前に配置します。
• 固定サイズ型を最初に: prefix indexは最初のVARCHAR列で停止するため、VARCHARの前にINT、BIGINT、DATE、その他の固定サイズ型を配置します。
• 転置インデックスの追加: prefix indexでカバーされていない列については、フィルタリングを高速化するためにinverted indexesを追加します。

パーティショニング

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

バケッティング

デフォルトは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ですが、本番環境で必要になることは稀です

サンプルテンプレート

ログ / イベント分析

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テーブルでWriteAmplificationを削減するために 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シナリオ）、以下の点がテスト結果に最も大きな影響を与えます。

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

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

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

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

Data Cacheの有効化

リモートストレージ（HDFS/object storage）は、ローカルディスクよりも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を参照してください。