知乎使用者2016-08-07 21:31:10

多個數據源匯入例如kettel是可行的。

這種情況在BI中比較多見。

申礫2016-08-07 23:44:04

之前調研過一些，不同型別的join有不同的方法，以 inner join 為例：

如果兩個表都比較小，那麼怎麼搞都行

如果一大一小，可以小表廣播，或者是 look up join： 先讀小表，再用索引讀取大表（如果有合適的索引可用）

如果兩個表都很大，可以考慮1。 先想辦法按照 join 的 key 讀取兩個表（如走索引），再 merge 2。 按照 join 的 key 將資料 shuffle 到多個節點計算

F1 論文裡講了另一種方法，表之間可以建立層級關係，父子表之間公用相同的 primary key prefix，這樣不同的 table 中具有相同 pk 字首的 row 會存放在相鄰的位置， 如果按照這些 key 做 inner join，可以直接順序 scan。不過這個需要特定的儲存模型以及和業務相關的 schema 設計。

知乎使用者2016-08-09 06:40:33

哎呀 上課講過 bloom filter （bf） 來做的嗎

a join b

先對b 表的對應column 建 bf 然後把建好的bf 發給 a 表

a表根據bf 找到滿足條件的資料 然會把滿足條件的資料 shuffle 給 b 表。

done。

假設 join 是在 b 表上做得。

宋老2016-09-30 07:56:34

單機實現連線的幾種方法都可以用在分散式下，如果待匹配的資料跨庫，那麼視需要在一側或兩側插入資料分發操作。

大家可以試試dameng的MPP產品。

知乎使用者2017-01-14 15:17:07

這個問題可以分為兩個小問題： 1。 如何實現join， 2。 如何實現分散式join。

單機join 的實現是前提。 第1個問題涉及SQL實現的很多核心問題， 不能總是假定連線總是在兩個基表之間， 可能還有相關子查詢， 檢視，派生表等，因此join可能發生在查詢分析時無法確定大小的中間結果之間， 這些都影響join的執行邏輯， 比如是否選擇巢狀迴圈接還是 hash 連線等。

解決了第一個問題， 則第二個分散式問題相對簡單。對於參與 join的分佈資料集s1， s2， 按照資料集的估算大小，可以選擇以下的演算法之一：

1。 把小的資料集， 比如s1， 都廣播到各節點，把資料補齊，然後再做join； 結果集仍然是分佈的；繼續參與後續其他運算；

2。 選擇s1， 或s2， 按join key計算hash 值， 把資料重新分發到各站點， 再做join， 結果集仍然是分佈的；

實際的分發還需要考慮分佈列是否和連線KEY匹配或部分匹配， 是否有索引可用， 是否有分割槽， 是否啟用了節點內並行能細節， 以減少通訊代價， 提升效能。

我們達夢資料庫對分散式叢集支援比較成熟， 幾乎支援單機SQL的所有特性， 目前國內部署了很多生產系統， 有不少是從Oracle RAC遷移過來， 採用達夢資料庫後應用效能大幅提升。