Lindorm：倉模式列存表

建表文法

-- 樣本：使用者行為事件明細表
-- 按 (event_day, event_type) 排序：加速按日期和事件類型過濾的查詢
-- 按 user_id 雜湊分桶：保證同一使用者的資料集中在同一分桶，加速使用者維度 JOIN
CREATE TABLE user_event_log (
    event_day   DATE        NOT NULL COMMENT "事件日期",
    event_type  TINYINT     NOT NULL COMMENT "事件類型（1=點擊 2=曝光 3=轉化）",
    user_id     BIGINT      NOT NULL COMMENT "使用者ID",
    item_id     BIGINT               COMMENT "內容/商品ID",
    session_id  VARCHAR(64)          COMMENT "會話ID",
    duration_ms INT                  COMMENT "停留時間長度（毫秒）",
    province    VARCHAR(32)          COMMENT "省份",
    channel     VARCHAR(32)          COMMENT "來源渠道"
)
DUPLICATE KEY(event_day, event_type)
PARTITION BY date_trunc('day', event_day)
DISTRIBUTED BY HASH(user_id);

注意事項

• 支援通過 ORDER BY 替代 DUPLICATE KEY 指定排序鍵，語義等價；若兩者同時出現，DUPLICATE KEY 不生效。使用 ORDER BY 時，該子句須放在 DISTRIBUTED BY 之後。

• 若排序鍵和分桶鍵均未指定，系統預設取前三列作為排序鍵。

• 明細表支援為所有列建立 Bitmap 索引、Bloom Filter 索引，無需區分 Key/Value 列。

• 明細表不支援 UPDATE 和 DELETE DML 語句（主鍵表支援）。

• 如果匯入兩行完全相同的資料，明細表會將其視為獨立的兩行儲存，不會自動去重。

資料模型

明細表將所有寫入資料按排序鍵進行物理排序後儲存於列式檔案中。每條記錄獨立存在，寫入後不可原地修改。資料檔案在後台非同步進行 Compaction（合并小檔案、回收空間），但不會對資料內容做任何去重或變更。

這種模型的核心優勢在於寫入吞吐高、靈活性強：寫入路徑沒有 Merge 或 Dedup 開銷，適合高頻追加情境；查詢側可以按任意維度自由彙總，不受預定義彙總結構的約束。

排序鍵設計

通過 DUPLICATE KEY 或 ORDER BY 聲明排序鍵，排序鍵決定資料的實體儲存體順序，同時作為首碼索引（Shortkey Index）的構建依據。

排序鍵設計原則：

• 將最高頻的過濾列排在最前面：首碼索引只對排序鍵的連續首碼有效，最頻繁過濾的列應排在第一位。

• 優先使用低基數列：低基數列（如日期、事件類型、城市）作為排序鍵首碼，可使相同值的行聚集儲存，配合 ZoneMap 索引大幅減少 I/O。

• 高基數列（如 user_id、device_id）不適合置於排序鍵首碼：這類列值離散，排序鍵過濾效果差，建議用作 Bloom Filter 索引列或分桶鍵。

• 排序鍵列數建議不超過 3 列：超過 36 位元組後首碼索引不再擴充，過多列對效能提升有限。

建表文法

-- 樣本：電商訂單即時分析表
-- 主鍵列 order_id、dt 須定義在最前面；分區列 dt 和分桶列 order_id 均須包含在主鍵中
-- ORDER BY (dt, merchant_id) 加速按日期和商戶維度範圍分析
-- 開啟持久化主鍵索引，避免巨量資料量下主鍵索引佔滿記憶體
CREATE TABLE orders (
    order_id       BIGINT         NOT NULL COMMENT "訂單ID",
    dt             DATE           NOT NULL COMMENT "下單日期",
    merchant_id    INT            NOT NULL COMMENT "商戶ID",
    user_id        BIGINT         NOT NULL COMMENT "使用者ID",
    good_id        INT            NOT NULL COMMENT "商品ID",
    good_name      VARCHAR(128)   NOT NULL COMMENT "商品名稱",
    total_amount   DECIMAL(18, 2) NOT NULL COMMENT "訂單金額",
    payment_amount DECIMAL(18, 2)          COMMENT "實付金額",
    status         TINYINT        NOT NULL COMMENT "訂單狀態",
    create_time    DATETIME       NOT NULL COMMENT "建立時間",
    update_time    DATETIME                COMMENT "最後更新時間"
)
PRIMARY KEY (order_id, dt)
PARTITION BY date_trunc('day', dt)
DISTRIBUTED BY HASH(order_id)
ORDER BY (dt, merchant_id);

注意事項

• 主鍵列具有唯一非空約束；主鍵列不支援 DECIMAL 類型；主鍵總長度不得超過 128 位元組。

• 建表時主鍵列必須連續置於列定義最前面：主鍵列須排在 CREATE TABLE 所有列定義的最前面，且主鍵列之間不能穿插非主鍵列，否則建表報錯。

• 使用分區和雜湊分桶時，主鍵必須包含分區列和分桶列，以保證系統能精確定位目標資料分割和分桶執行更新。

• 主鍵列的值不可更新：UPDATE 只能修改非主鍵列；若必須變更主索引值，須先 DELETE 再 INSERT。

• 排序鍵（ORDER BY）與主鍵完全解耦，可獨立設計為任意列組合；排序鍵支援建表後修改（ALTER TABLE tbl ORDER BY ...），但不支援刪除排序鍵，也不支援修改排序列的資料類型。

• 主鍵表支援完整 DML：INSERT、UPDATE（支援按 Key 列或 Value 列過濾）、DELETE（支援按 Key 列或 Value 列過濾）。

• 主鍵表僅支援雜湊分桶，不支援隨機分桶。

寫入機制：Delete+Insert

主鍵表採用 Delete+Insert 寫入策略，區別於傳統的 Merge-On-Read（讀時合并）模型：

• 寫入時：系統通過主鍵索引定位舊資料行，將其標記刪除，再寫入新資料行，同時更新主鍵索引。

• 查詢時：資料已處於最終狀態，無需線上合并多版本，查詢直接讀取有效行。

這一機制使得主鍵表的查詢效能顯著優於 Merge-On-Read 模型，尤其在高更新頻率情境下，讀取放大問題被徹底消除。

主鍵設計原則

• 主鍵應唯一標識業務實體：選取能全域唯一確定一條記錄的欄位組合，如 order_id、(user_id, event_id)。

• 主鍵必須包含分區列和分桶列：使用分區（PARTITION BY）和雜湊分桶（DISTRIBUTED BY HASH）時，主鍵須涵蓋分區列和分桶列，以保證系統能精確定位目標資料分割和分桶執行更新。

• 保持主鍵精簡：主鍵總位元組長度不得超過 128 位元組，列數建議不超過 3 列。優先選用 INT、BIGINT 等佔用記憶體小的類型，避免使用 VARCHAR；主鍵列過多會增加索引儲存和維護開銷。

• 主鍵列不支援 DECIMAL 類型：可使用 BIGINT、VARCHAR 等常見類型。

• 主鍵列不可為 NULL：所有主鍵列均須聲明 NOT NULL。

排序鍵與主鍵解耦

主鍵（PRIMARY KEY）定義唯一性限制式，排序鍵（ORDER BY）定義資料的實體儲存體順序，兩者完全解耦，可獨立設計。

• 排序鍵列可以是任意列的排列組合，不要求包含主鍵列，以查詢最頻繁的過濾列為設計依據。

• 若不指定 ORDER BY，系統預設使用主鍵列作為排序鍵。

• 排序鍵支援建表後修改：ALTER TABLE tbl ORDER BY (col1, col2, ...)；但不支援刪除排序鍵，也不支援修改排序列的資料類型。

部分列更新

主鍵表支援部分列更新（Partial Column Update）模式，允許不同寫入方只攜帶需要更新的列，系統以主鍵為關聯鍵自動合并各列資料。這是多路資料流即時寫寬表的核心能力。

-- 樣本：啟用部分列更新，寫入時只更新 status 和 update_time 列
INSERT INTO orders (order_id, status, update_time)
VALUES (10001, 3, '2024-03-01 10:30:00');
-- 其餘列（如 total_amount、user_id 等）保持原值不變

投影與過濾

SELECT 支援對指定列進行投影，列名可設定別名（AS）、參與算術運算式或Function Compute。WHERE 子句支援多條件組合謂詞：

謂詞在執行時儘可能下推至儲存層，減少資料讀取量。

串連查詢（JOIN）

支援以下連線類型：

執行層根據表大小和資料分布自動選擇最優 Join 策略：小表廣播至所有節點（Broadcast Join）、資料按 Join 鍵重分布（Shuffle Join），或當分桶鍵與 Join 鍵一致時執行本地化 Join（零網路傳輸）。

-- 樣本：訂單明細與使用者畫像 JOIN
SELECT
    o.order_id,
    o.total_amount,
    u.user_level,
    u.city
FROM orders o
INNER JOIN user_profile u ON o.user_id = u.user_id
WHERE o.dt >= '2024-01-01'
  AND u.user_level IN ('gold', 'platinum');

集合運算

分組彙總（GROUP BY）

支援標準彙總函式（COUNT、SUM、AVG、MIN、MAX、COUNT DISTINCT）以及通過 HAVING 對彙總結果二次過濾。

支援以下擴充彙總文法，一次掃描完成多維度匯總，效能顯著優於多次獨立彙總查詢：

-- GROUPING SETS：顯式指定多組維度組合
SELECT city, dt, SUM(amount) AS total
FROM orders
GROUP BY GROUPING SETS ((city, dt), (city), ());

-- ROLLUP：層級匯總（從細粒度到總計）
-- 等價於 GROUPING SETS ((city, dt), (city), ())
SELECT city, dt, SUM(amount) AS total
FROM orders
GROUP BY ROLLUP (city, dt);

-- CUBE：對所有維度全量組合匯總
-- 等價於 GROUPING SETS ((city, dt), (city), (dt), ())
SELECT city, dt, SUM(amount) AS total
FROM orders
GROUP BY CUBE (city, dt);

排序與分頁

支援 ORDER BY 多列排序（ASC / DESC），配合 LIMIT 和 OFFSET 實現分頁查詢。

SELECT order_id, total_amount
FROM orders
WHERE dt = '2024-03-01'
ORDER BY total_amount DESC, order_id ASC
LIMIT 20 OFFSET 40;

子查詢

支援以下子查詢形式，最佳化器自動將可轉換的子查詢改寫為等價 JOIN 執行：

視窗函數（Window Function）

視窗函數在保留原始行的同時對資料分組計算，是 OLAP 分析的核心能力。通過 OVER (PARTITION BY ... ORDER BY ... ROWS/RANGE ...) 文法定義計算視窗。

-- 樣本：計算每個使用者的累計消費金額與當日消費排名
SELECT
    user_id,
    order_id,
    dt,
    total_amount,
    SUM(total_amount) OVER (
        PARTITION BY user_id
        ORDER BY dt
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS cumulative_amount,
    RANK() OVER (
        PARTITION BY dt
        ORDER BY total_amount DESC
    ) AS daily_rank
FROM orders;

-- 樣本：計算使用者相鄰兩次購買的間隔天數
SELECT
    user_id,
    order_id,
    dt,
    DATEDIFF(dt, LAG(dt, 1) OVER (PARTITION BY user_id ORDER BY dt)) AS days_since_last_order
FROM orders;

CASE WHEN 條件運算式

支援搜尋式和簡單式兩種文法，可在 SELECT、WHERE、ORDER BY、彙總函式等任意位置使用。

SELECT
    order_id,
    total_amount,
    CASE
        WHEN total_amount >= 10000 THEN '大額'
        WHEN total_amount >= 1000  THEN '中額'
        WHEN total_amount >= 100   THEN '小額'
        ELSE '微額'
    END AS amount_tier,
    SUM(CASE WHEN status = 1 THEN total_amount ELSE 0 END) AS paid_amount
FROM orders
GROUP BY order_id, total_amount;

首碼索引（Shortkey Index）

系統自動建立，每 1024 行取排序鍵首碼（不超過 36 位元組、不超過 3 列）儲存一條稀疏索引項目。查詢中帶有排序鍵首碼過濾條件時，引擎通過二分尋找快速定位目標資料區塊，無需手動建立。

觸發條件：查詢過濾條件必須能構成排序鍵的首碼。

排序鍵：(event_day, site_id, city_code)

✅ WHERE event_day = '2024-01-01'                       -- 命中首碼索引
✅ WHERE event_day = '2024-01-01' AND site_id = 10      -- 命中首碼索引
❌ WHERE city_code = 'BJ'                               -- 不構成首碼，無法使用

建表時應將查詢最高頻的過濾列排在排序鍵最前面，使其優先被首碼索引覆蓋。

ZoneMap 索引

系統自動為每列的每個資料區塊（Page，預設 64 KB）維護最小值（Min）、最大值（Max）和 NULL 存在性統計，無需手動建立。執行範圍查詢時，引擎通過比對各 Page 的 Min/Max 快速跳過不滿足條件的 Page，實現資料區塊層級的高效裁剪。

適用情境：數值、日期等有序類型列上的範圍過濾（BETWEEN、>、<、>=、<=）。

Bloom Filter 索引

基於 Bloom Filter 演算法，以資料區塊（Page）為粒度構建跳數索引。寫入時對每個 Page 中的列值計算雜湊寫入 Bloom Filter；查詢時對過濾條件值計算雜湊並判斷是否存在，不存在則直接跳過該 Page，從而減少 I/O。

適用情境：高基數列（如使用者ID、訂單ID、裝置碼）的等值查詢（=、IN）。此類列基數過高，不適合 Bitmap 索引（儲存開銷過大）。

通過 PROPERTIES 中的 bloom_filter_columns 參數指定，建表後支援通過 ALTER TABLE 動態變更。

-- 建表時建立
CREATE TABLE orders (
    order_id    BIGINT         NOT NULL,
    user_id     BIGINT         NOT NULL,
    merchant_id INT            NOT NULL,
    dt          DATE           NOT NULL,
    amount      DECIMAL(18, 2)
)
PRIMARY KEY(order_id)
DISTRIBUTED BY HASH(order_id)
PROPERTIES (
    "bloom_filter_columns" = "user_id, merchant_id"
);

-- 建表後動態添加
ALTER TABLE orders SET ("bloom_filter_columns" = "user_id, merchant_id, dt");

-- 刪除 Bloom Filter 索引
ALTER TABLE orders SET ("bloom_filter_columns" = "");

注意事項：

• 不支援 TINYINT、FLOAT、DOUBLE、DECIMAL 類型列。

• 僅對等值查詢有效，範圍查詢（>、<、BETWEEN）無效。

• 不適用於低基數列（應使用 Bitmap 索引）。

Bitmap 索引

為列的每個唯一值建立一個位元影像（每位對應表中一行，0/1 表示該行是否含有該值）。多條件查詢時，通過對多個位元影像執行位元運算（AND/OR/NOT）高效得到結果集，內部使用 Roaring Bitmap 壓縮結構，儲存空間相較傳統位元影像最高節省 90%。

適用情境：中等基數列（建議基數在 10,000 ~ 100,000 之間）的等值查詢，以及多列組合過濾（如使用者畫像中同時按年齡段、消費等級、城市過濾）。

通過 INDEX 子句定義，或建表後通過 CREATE INDEX 動態添加（屬於非同步 Schema Change 操作）。

-- 建表時建立 Bitmap 索引
CREATE TABLE user_profile (
    user_id      BIGINT      NOT NULL COMMENT "使用者ID",
    age_range    TINYINT              COMMENT "年齡段（1-5）",
    gender       TINYINT              COMMENT "性別（0=女,1=男）",
    city_code    VARCHAR(20)          COMMENT "城市編碼",
    user_level   TINYINT              COMMENT "使用者等級（1-5）",
    register_day DATE                 COMMENT "註冊日期",
    INDEX idx_age_range  (age_range)  USING BITMAP COMMENT "年齡段索引",
    INDEX idx_city_code  (city_code)  USING BITMAP COMMENT "城市索引",
    INDEX idx_user_level (user_level) USING BITMAP COMMENT "等級索引"
)
DUPLICATE KEY(user_id)
DISTRIBUTED BY HASH(user_id);

-- 建表後動態添加
CREATE INDEX idx_gender ON user_profile (gender) USING BITMAP;

-- 查看索引
SHOW INDEX FROM user_profile;

-- 刪除索引
DROP INDEX idx_gender ON user_profile;

注意事項：

• 不支援 FLOAT、DOUBLE、BOOLEAN、DECIMAL 類型列。

• 基數過高（超過 100 萬）時，Bitmap 索引儲存膨脹，應改用 Bloom Filter 索引。

• 若索引過濾比例低（如篩選超過 50% 的資料），索引收益為負，不建議建立。

索引選型參考