各位資料的朋友，大家好，我是老周道資料，和你一起，用常人思維+資料分析，通過資料講故事。
前段時間和一個客戶就資料中台搭建的一些問題進行了交流，其中讨論最多的是到底是用寬表來實作業務需求，還是用多表關聯來實作。今天就和大家來聊一下這個話題。
資料倉庫建構過程中，有一個所謂資料集市的概念。資料集市是為了滿足特定業務場景而推出的一個邏輯概念，是針對一組特定的某個主題域、部門或者特殊使用者需求的資料集合。資料集市中資料的結構通常被描述為星型結構或雪花結構。通俗的了解，星型結構是一個事實表關聯多個次元表，次元表之間是相對獨立的，比如銷售訂單表關聯客戶次元表和産品次元表，而雪花型結構則複雜一些，次元表之間還有關聯，比如銷售訂單表關聯客戶次元表和産品次元表，客戶次元表還關聯客戶分類表，産品次元表還關聯産品分類表。
這兩種模型，都是多表關聯的模式。但在實踐中，大家會發現，多表關聯因為資料庫在執行join時，會涉及多表掃描，效率上比較慢。就有人針對這種場景進行了優化，于是，寬表就出現了。它把某個分析場景要用到的所有次元表和事實表的字段，預先整合為一個大表，比如上例中，就将銷售訂單事實表、産品次元表、客戶次元表等表先通過Join整合為一個大表，這個大表可能包含數十個字段。這樣，使用的時候，就不再需要去多表關聯，以提高查詢的效率。
寬表VS多表關聯
1、寬表
初衷是用空間換時間。
優勢：效率
劣勢：有許多備援内容，占用空間大。
2、多表關聯
優勢：沒有增加備援
劣勢：在資料庫查詢時，join會影響效率。
現在硬碟不值錢，大家更需要效率，是以，兩種方式的優劣勢就很明顯了，越來越多的人開始使用寬表，并且，有些資料庫支援列式存貯，連備援空間都給優化了。
但是，在老周看來，這僅僅是傳統的觀點。為什麼這麼說呢？主要有兩點：
一、寬表的劣勢其實不在備援空間，而是在于開發與維護成本太高。
為什麼這麼說呢？因為我們在第一次建立寬表時，面臨一個很大的挑戰，就是到底這個寬表要多寬，也就說到底要包含多少個字段。如果建少了字段，後面要再增加，就需要将曆史資料全部重跑一遍，如果資料量真的很大，每次的維護時間會很長，且維護期間，使用者無法使用這個資料集市。
有的聰明人就會說，那很簡單啊，包含全部字段不就行了嗎？這個方法當然不行，一是當寬表的字段多到一定程度，效率也會降低，另外，這個方法也無法避免後續增加字段。舉個簡單的例子，比如當時客戶表裡沒有客戶區域這個字段，後來增加了這個字段，亦或者，原來客戶區域這個字段有些客戶沒有填寫，現在重新填寫了，那麼，仍然需要重新跑一周遊史資料。
如果有很多寬表都需要用到客戶區域這個字段，那你可以想像一下，小強可能是需要通宵加班了。
二、多表join原來可能是比較慢，但随着大資料技術的快速發展，現在多表join的效率已經與單表查詢不相上下了，比如starrocks mpp資料庫，多表join的效率與clickhouse單表查詢效率相差無幾。
經過上述的此消彼長，寬表的優勢不再存在，而多表join則有更多的優勢展現出來：
一、多表join更靈活，對于需求的變化，運維的工作量很小。
如上述客戶表增加客戶區域這個例子，對于多表join情況下，隻需要在客戶次元表中增加客戶區域這個字段，并且将客戶次元表重新抽取一下即可。一旦客戶次元表更新，所有用到客戶表的資料集市也就一并都更新了，不需要一個集市一個集市的維護；
二、如果放在奧威BI的平台上，多表join還有更多的優勢可以展現出來。
1、在奧威BI資料可視化軟體中，系統會根據最終使用的場景來動态建構join文法，并不會将所有的表都join，比如僅按客戶次元分析銷售訂單，此時，就隻會join客戶表，而不把産品表也join上。在這種情況下，就可以最大限度的減少對效率的影響；
2、奧威BI資料可視化軟體支援多事實表，也就是說，在同一個資料集市（分析模型）中，可以包含多個事實表，既可以包含銷售訂單，還可以包含銷售出庫單，這樣，就可以很友善的實作分别從訂單及出庫單取數來計算訂單出庫率，而如果用寬表，這種場景還需要另外建構一個大表，将訂單與出庫表的所有字段都包含進來，又會造成開發與運維成本的大幅增加。
3、奧威BI資料可視化軟體軟體中有一個非常受歡迎的功能，就是智能鑽取，即可以在任意報表之間穿透鑽取，系統會自動傳遞參數，比如在看客戶銷售訂單報表的時候，可以鑽取到客戶的應收賬款報表，系統會自動将客戶名稱傳遞過去。如果用寬表的模式，就無法實作了。因為奧威BI資料可視化軟體無法自動識别銷售訂單寬表與應收寬表，到底是哪個字段代表客戶名稱。但多表join就可以實作，因為大家都關聯了客戶這個次元表。
其實，對于一般的生産制造企業，如果不涉及到生産裝置物聯網資料的話，生産經營的資料量都不是很大，最大的事實表一年下來一般也不會超過500萬條。在這樣的資料量下，多表join與寬表的效率相差也不是很明顯。
如果是零售企業，最大的事實表可能會超過5000萬條記錄，這種情況下，推薦使用starrocks，但不推薦使用clickhouse，因為clickhouse就是基于寬表來提升性能的，基本不支援多表join，請謹慎使用！
最後我們再總結一下寬表與多表join的優劣勢對比：
寬表雖然在效率上有一定優勢，但在現今大資料技術下，優勢已經不明顯，但其劣勢卻是非常明顯且緻命的，
即在企業級應用時，需求多變的情況下，運維成本非常高；而多表join則非常靈活，運維成本非常低，更加适合企業級多變的應用場景。
老周道資料，和你一起，用常人思維+資料分析，通過資料講故事，我們下一講再見！