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列で停止するため、INT、BIGINT、DATE、その他の固定サイズ型をVARCHARより前に配置する。
inverted indexを追加: prefix indexでカバーされない列については、inverted indexesを追加してフィルタリングを高速化する。

Partitioning

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

Bucketing

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

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を参照してください。

クエリチューニング

バケッティング

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

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

サイジングガイドラインについては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/object storage）は、ローカルディスクよりもIOレイテンシが大幅に高くなります。Data Cacheは、最近アクセスされたリモートデータをBEローカルディスクにキャッシュし、同じデータセットでの繰り返しクエリに対して内部テーブルに近いクエリパフォーマンスを提供します。

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

ヒント

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

小さなファイルへの対処

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

ソースでの修正（推奨）: Hive/Spark側で小さなファイルを定期的にコンパクションし、各ファイルを128 MB以上に保つ。
Doris側の保護措置: SET max_file_split_num = 50000;（4.0.4以降でサポート）を使用して、スキャンあたりの最大split数を制限し、OOMを防止する。

診断にQuery Profileを使用

Data lakeクエリのボトルネックは、通常、計算ではなく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を使用​