Apache Calcite官方文檔中文版- 進階-4. Lattices

第二部分 進階(Advanced)

1. Lattices

  Lattice是一個創建并填充物化視圖的框架，可以識別以及解決特定查詢的物化視圖。
  一個Lattice代表一個星型(或雪花)模型，不是通用的schema。特別地，所有的連接關系必須是多對一，圍繞星型模型的事實表建立。
  Lattice的名字來源于數學: lattice是一個部分有序的集合，任何兩個元素都有一個唯一的最大的下界和最小的上界。
  [HRU96]發現，多維數據集可能的物化集合構成一個lattice，并且使用一種算法來選擇一組較為優化的物化組合。Calcite的推薦算法也是源于此。
 Lattice使用SQL statement來代表星型模型，以此來進行定義自身。SQL是一種有用的能表示多個table join關系的短語，并且可以為列名指定別名（與發明一種新的語言來表示關系，join 條件和基數相比，SQL表達更為方便）。
  和常規sql不同，順序在這里很重要。如果你在from模塊中將A放在B前面，并且實現一個A和B的join關系，可以說是從A到B有一個多對一的關系。（例如，在lattice例子中，Sales事實表在時間維度表和產品維度表之前先被觸發，產品維度表在產品分類維度表之前被觸發，further down an arm of a snowflake.)）
  一個Lattice意味著一系列的約束。在A到B的關系中，A表上存在一個外鍵（例如，每一個A表中的外鍵都對應B表key中的一個值），和B表中的一個唯一key（例如，key值只會出現一次）。這些約束條件都非常重要，因為它允許計劃器來移除沒有用到的列的join關系，并且知道查詢結果是不會改變的。
  Calcite不會去校驗約束條件，如果違反約束規則，Calcite會直接返回錯誤的結果。
  Lattice是一個大的虛擬的join視圖。它不是物化的(由于反規范化，它可能會比星型模型大好幾倍)，并且你可能并不想去對它進行查詢(columns太多了)。所以它到底是干什么的呢?
1)如上面所說，lattice聲明了許多有用的主鍵和外鍵的約束。
2)它幫助查詢執行器將用戶的查詢行為映射到filter-join-aggregate 物化視圖(針對DW查詢最有用的物化視圖類型)
3)給Calcite一個框架來收集關于數據卷和用戶查詢的統計信息
4)允許Calcite去自動設計和填充物化視圖
  大多數星型模型會強制用戶去定義一個column到底是維度還是指標。在lattice中，每一個column都是維度列（也就是說，它可以成為GROUP BY子句中的一列，用于在特定維度上查詢星型模式）。所有的column也同樣可以用作度量（指標），你可以為指定列指定聚合函數來定義一個度量（指標）。
  如果“unit_sales”通常更傾向于作為度量使用而不是維度，也沒有影響。Calcite算法在不久的將來會注意到它很少被聚合，就不會傾向于在它上面創建聚合層（當前算法在設計tiles時不會參考查詢歷史）。
  但有人或許想知道，少于5的訂單和多于100的訂單利潤是會更多還是更少。在這種場景下，“unit_sales”突然就成為一個維度了。如果聲明一個列為維度列的成本為0，我想我們應該讓所有的列都成為維度列。
  該模型允許一個指定表以不同的表別名被多次使用。可以在模型中定義OrderDate和ShipDate兩個時間維度。
  大多數SQL系統要求一個視圖的中的列名是唯一的，在lattice中比較難達到，因為經常會在一次join中同時包含主鍵和外鍵列。因此，Calcite允許用戶通過兩種方式引用列，如果列是唯一的，可以直接使用它的名字【‘unit_sales’】。不管列在lattice是否唯一，它在自己的table中都是唯一的，因此你可以通過它的表名來對它進行引用。如下例?

• [“sales”, “unit_sales”]
• [“ship_date”, “time_id”]
• [“order_date”, “time_id”]
    一個“tile”是lattice中的一個帶有一些特定維度（在Kylin中被稱為cuboid——Cube則包含了所有維度的不同的兩兩組合，每一種組合即為一個Cuboid）的物化表。Lattice JSON元素中的tiles屬性定義了一個初始的物化tile集合。
    如果運行算法，可以省略tiles屬性。Calcite會選擇一個初始集合。如果定義了tiles屬性，算法就會以定義的list開始啟動運行，然后開始尋找其他互補的tiles（eg fill in the gaps left by the initail tiles）?