作者：7.7
編輯：紫霞仙子
雲神原文：
作者寄語：
最近正好在找工作，看到社群發的面試文章受益匪淺()。梳理文章每一個題目後，順利拿到offer，故總結梳理答疑整理了這篇文章，以表感激，同時希望能幫到更多的小夥伴們。
以下作答純屬個人見解，如有誤解，還望不吝指教！大家一起學習，一起進步！(筆芯：可以進社群數倉群，大家一起讨論~)
本着認真嚴謹的态度，作答解讀了部分題目，同時也給出了一些高品質的參考連結。其中省略的有的是鄙人不了解的，也有一些概念性的問題，可以自行查找一下。
面試的心得體會：
在面試過程中，也是一種自我學習和提升的機會，态度要謙和，知之為知之，面試題目又不了解或者不會的純屬正常(基礎除外)。 是以一道題目答不上來不要自亂陣腳，在整個面試過程中展現出自己團隊合作的認知以及自我獨當一面的能力。有的時候面試不隻看技術，更看眼緣。
0.自我介紹
答：1).簡單的自我介紹，突出自我優勢(證書、學曆、團隊等)
2).項目介紹(重中之重)
3).顯目中承擔的工作，以及子產品。
4).如若非本專業，可如實回答(是否教育訓練)
5).長的帥或漂亮，前四條都可以忽略
1. 什麼是資料倉庫？如何建構資料倉庫？
可參考：
(如果這個問題回答的好，後面很多問題都不需要再問)
答：資料倉庫是一個面向主題的(Subject Oriented)、內建的(Integrate)、相對穩定的(Non-Volatile)、反映曆史變化(Time Variant)的資料集合，它用于支援企業或組織的決策分析處理。
數倉建構：
1). 前期業務調研需求調研 資料調研 技術選型
2). 提煉業務模型，總線矩陣，劃分主題域；
3). 定制規範命名規範、開發規範、流程規範
4). 數倉架構分層：一般分為
操作資料層(ODS)、公共次元模型層(CDM)和應用資料層(ADS),其中公共次元模型層包括明細資料層(DWD和彙總資料層(DWS)
公共次元模型層(CDM)：存放明細事實資料、維表資料及公共名額彙總資料,其中明細事實資料、維表資料一般根據ODS層資料加工生成：公共名額彙總資料一般根據維表資料和明細事實資料加工生成。
CDM層又細分為DWD層和DWS層,分别是明細資料層和彙總資料層,采用次元模型方法作為理論基礎,更多地采用一些次元退化手法,将次元退化至事實表中,減少事實表和維表的關聯,提高明細資料表的易用性：同時在彙總資料層,加強名額的次元退化,采取更多的寬表化手段建構公共名額資料層,提升公共名額的複用性,減少重複加工。
應用資料層(ADS)：存放資料産品個性化的統計名額資料,根據CDM層與ODS層加工生成。
5).選擇合适的資料模型，不同的行業涉選取的模型近不相同，合适的模型，更利于在資料存儲，計算，開發，安全，以及資料查詢的效率，更能展現數倉的價值。
綜上所述：數倉建設這個問題的範圍過于大，它包含了一個0-1的過程，此處隻做大方面的回答，具體的細節問題還需另外讨論。
2.如何建設資料中台？可簡單說下對中台了解與思路
答：省略(鄙人對中台知之甚少)
可參考：
3.資料倉庫、資料中台、資料湖的了解
答：資料倉庫 分而治之 對象BI
資料湖 無為而治 對象AI
資料中台 一統天下 對象DataAPI(組織架構)
可參考：
了
4.傳統數倉的程度(模組化工具、ETL工具、BI報表工具、排程系統)
答：
模組化工具：powerDesiger、Erwin、Visio
ETL工具: kettle/informatic(主流的兩款) 等等
BI報表工具:superset、cboard、redash、帆軟BI/QuickBI/PowerBI 等等
排程系統：airflow、azkaban、ooize、xxl-job、dolphinscheduler、Zeus、hera、TASKCTL/自研平台 等等
參考：
5.傳統數倉和大資料數倉的異同？有哪些大的變化？
答：其差別主要數數倉資料存儲的地方不同，傳統數倉資料存儲在mysql/oracle等關系型資料庫上，大資料數倉存儲在hadoop平台的hive中(實際上是HDFS中)，當然也有其他的數倉産品比如TD、greenplum等。
我接觸過的傳統數倉技術架構是使用kettle做ETL工具，資料儲存在mysql中，使用MSTR+java開發的資料平台做可視化，随着資料量逐漸增大，事實表條數達到千萬級，kettle逐漸變得不穩定，
單表做拉鍊的任務的執行時間也指數級增加，從1/2h到了6/7h。
公司考慮使用hadoop平台的hive做資料倉庫，報表層資料儲存在mysql中，使用tableau做報表系統，這樣不用擔心存儲問題、計算速度也大大加快了。
在此基礎上，公司開放了hue給各個部門使用，這樣簡單的提數工作可以由營運自己來操作。
使用presto可以做mysql、hive的跨庫查詢，使用時要注意presto的資料類型非常嚴格。
6.印象最深刻的項目？為什麼？亮點與優勢？
答：回答的方向兩方面
1.好的項目，從中學到了什麼
2.差的項目，你是如何改造的
7.數倉最重要的是什麼？
答：資料的準确性，鄙人記得在一個統計網站上看過，好多數倉因為資料不準确被終止。
資料的真正價值在于資料驅動決策，通過資料指導營運,在一個不準确的資料驅動下，結果可想而知。
如何保證資料的準确性？
中繼資料的建設與管理是其中重要的一個環節
中繼資料建設的目标是打通資料接入到加工 ，再到資料消費整個鍊路，規範中繼資料體系與模型，提供統一的中繼資料服務出口，保障中繼資料産出的穩定性和品質。
首先梳理清楚元倉底層資料，對中繼資料做分類，如計算中繼資料、存儲中繼資料、品質中繼資料等，減少資料重複建設，保障資料的唯一性。
另外， 要豐富表和字段使用說明，友善使用和了解。根據元倉底層資料建構元倉中間層，建設中繼資料基礎寬表，也就是中繼資料中間層，打通從資料産生到消費整個鍊路。
也可在粒度、規範等方面展開，見仁見智。
可參考：
8.實時數倉做過嗎？采用什麼架構？lambda有哪些優缺點？
答：省略(目前我隻接觸到離線數倉) 參考：
9.如何看待kappa架構？iota架構呢？
答：省略(目前還沒接觸到) 參考：
10.責任心？溝通能力？團隊協作？資料思維？
答：鄙人開發出身，後轉數倉；深有體會搞TP系統和搞AP系統的考慮問題有出入，也許更多的是對數倉的機制不了解，
項目需要不同的開發人員來協作完成某項工作，是以大家在交流溝通上需要找到一個共同的點，協作合力完成。
11.使用者畫像(靜态、動态标簽，統計、規則、預測标簽，衰退系數、标簽權重)
參考：
答：
靜态資料-評估價值:使用者相對穩定的資訊，例如，主要包括人口屬性、商業屬性等方面資料；這類資訊，自成标簽，如果企業有真實資訊則無需過多模組化預測，更多的是資料清洗工作，如果某些靜态資訊不準或缺失則需要模組化預測。
動态資料-循迹: 使用者不斷變化的行為資訊，例如：浏覽凡客首頁、浏覽休閑鞋單品頁、搜尋帆布鞋、發表關于鞋品質的微網誌、贊“雙十一大促”的微網誌消息。等等均可看作網際網路使用者行為。
形态:标簽與權重: 使用者畫像的最終形态是通過分析使用者行為，最終為每個使用者打上标簽，以及該标簽的權重
标簽：表征了内容，使用者對該内容有興趣、偏好、需求等等
權重：表征了指數，使用者的興趣、偏好指數，也可能表征使用者的需求度，可以簡單的了解為可信度，機率
資料模組化方法: 标簽=使用者辨別 + 時間 + 行為類型 + 接觸點(網址+内容)的聚合，某使用者因為在什麼時間、地點、做了什麼事，是以會打上**标簽
12.推薦系統(協同過濾，基于使用者、商品，SVD，各種距離算法等)
答：省略(隻知神策有相關的産品)
13.數倉基礎理念了解
可參考：
(主題域 血緣關系 拉連結清單 代理鍵 次元退化 緩慢變化維SCD 事實表類型 增量dwd處理 星型/雪花/星座模型 事實 次元 粒度 原子/派生名額 OLAP)
答：省略(概念性的問題可以自行查找)
14.數倉如何确定主題域？CDM？
參考：
答：主題域通常是聯系較為緊密的資料主題的集合。可以根據業務的關注點，将這些資料主題劃分到不同的主題域。主題域的确定必須由最終使用者和資料倉庫的設計人員共同完成。
15.數倉如何分層的？及每一層的作用？思考：為什麼要這麼分層？
參考：
答：如何架構分層？
結合Inmon和Kimball的集線器式和總線式的資料倉庫的優點，分層可為ODS【-MID】-DW-DM-OLAP/OLAM/app(不同企業略有差異)
ODS層是将OLTP資料通過ETL同步到資料倉庫來作為資料倉庫最基礎的資料來源。在這個過程中，資料經過了一定的清洗，比如字段的統一，髒資料的去除等，但是資料的粒度是不會變化的。ODS層的資料可以隻保留一定的時間。
MID中間層是采用Inmon集線器架構的方式，使用範式模組化(貼源)的方法。這一層主要是做規範化的事情，比如應用庫表非規範化，字段格式複雜(json格式)需做一些處理。這一層不是必須有的。也不會對外開放使用。範式模組化保證了資料一緻性、唯一性、正确性。
DW-DM層是采用Kimball的總線式的資料倉庫架構，針對部門(比如财務部門)或者某一主題(比如商戶、使用者)，通過次元模組化(推薦星型模型)，建構一緻性次元，原子粒度的資料是DW層，按照實體或者主題經過一定的彙總，建設資料集市模型。資料集市可以為OLAP提供服務。
為什麼要分層的思考？
空間換時間。通過建設多層次的資料模型供使用者使用，避免使用者直接使用操作型資料，可以更高效的通路資料。 把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層隻處理單一的步驟，比較簡單和容易了解。而且便于維護資料的準确性，當資料出現問題之後，可以不用修複所有的資料，隻需要從有問題的步驟開始修複。 便于處理業務的變化。随着業務的變化，隻需要調整底層的資料，對應用層對業務的調整零感覺.
分層的價值
01.高效的資料組織形式【易維護】
面向主題的特性決定了資料倉庫擁有業務資料庫所無法擁有的高效的資料組織形式，更加完整的資料體系，清晰的資料分類和分層機制。因為所有資料在進入資料倉庫之前都經過清洗和過濾，使原始資料不再雜亂無章，基于優化查詢的組織形式，有效提高資料擷取、統計和分析的效率。
02.時間價值【高性能】
資料倉庫的建構将大大縮短擷取資訊的時間，資料倉庫作為資料的集合，所有的資訊都可以從資料倉庫直接擷取，資料倉庫的最大優勢在于一旦底層從各類資料源到資料倉庫的ETL流程建構成型，那麼每天就會有來自各方面的資訊通過自動任務排程的形式流入資料倉庫，進而使一切基于這些底層資訊的資料擷取的效率達到迅速提升。
從應用來看，使用資料倉庫可以大大提高資料的查詢效率，尤其對于海量資料的關聯查詢和複雜查詢，是以資料倉庫有利于實作複雜的統計需求，提高資料統計的效率。
03.內建價值【簡單化】
資料倉庫是所有資料的集合，包括日志資訊、資料庫資料、文本資料、外部資料等都內建在資料倉庫中，對于應用來說，實作各種不同資料的關聯并使多元分析更加友善，為從多角度多層次地資料分析和決策制定提供的可能。
04.曆史資料【曆史性】
記錄曆史是資料倉庫的特性之一，資料倉庫能夠還原曆史時間點上的産品狀态、使用者狀态、使用者行為等，以便于能更好的回溯曆史，分析曆史，跟蹤使用者的曆史行為，更好地比較曆史和總結曆史，同時根據曆史預測未來。
16.數倉有哪幾種模組化思想？次元模組化、範式模組化、datavault？.. 有什麼優劣，如何選擇？
答：ER模型，次元模組化，datavault模型，Anchor 模型。 參考：
ER模型：
資料倉庫之父 Bill lnmon 提出的模組化方法是從全企業的高度設計一 個3NF 模型，用實體關系( Entity Relationship, ER)模型描述企業業 務，在範式理論上符合 3NF。資料倉庫中的 3NF 與 OLTP 系統中的 3NF 的差別在于，它是站在企業角度面向主題的抽象，而不是針對某個具體 業務流程的實體對象關系的抽象。其具有以下幾個特點：· 需要全面了解企業業務和資料。· 實施周期非常長。． 對模組化人員的能力要求非常高。采用 ER 模型建設資料倉庫模型的出發點是整合資料，将各個系統
中的資料以整個企業角度按主題進行相似性組合和合并，并進行一緻性 處理，為資料分析決策服務，但是并不能直接用于分析決策。其模組化步驟分為三個階段。·高層模型：一個高度抽象的模型，描述主要的主題以及主題間的 關系，用于描述企業的業務總體概況。· 中層模型：在高層模型的基礎上，細化主題的資料項。． 實體模型(也叫底層模型)：在中層模型的基礎上，考慮實體存 儲，同時基于性能和平台特點進行實體屬性的設計，也可能做一 些表的合并、分區的設計等。
次元模組化：
次元模組化從分析決策的需求出發構模組化型，為分析需求服務，是以 它重點關注使用者如何更快速地完成需求分析，同時具有較好的大規模複 雜查詢的響應性能。其典型的代表是星形模型，以及在一些特殊場景下 使用的雪花模型。其設計分為以下幾個步驟。· 選擇需要進行分析決策的業務過程。業務過程可以是單個業務事 件，比如交易的支付、退款等；也可以是某個事件的狀态，比如 目前的賬戶餘額等；還可以是一系列相關業務事件組成的業務流 程，具體需要看我們分析的是某些事件發生情況，還是目前狀态， 或是事件流轉效率。· 選擇粒度。在事件分析中，我們要預判所有分析需要細分的程度，
進而決定選擇的粒度。粒度是次元的一個組合。· 識别維表。選擇好粒度之後，就需要基于此粒度設計維表，包括 次元屬性，用于分析時進行分組和篩選。·選擇事實。确定分析需要衡量的名額。
Data Vault 模型：
Data Vault 是 Dan Linstedt 發起建立的一種模型，它是 ER 模型的衍 生，其設計的出發點也是為了實作資料的整合，但不能直接用于資料分 析決策。它強調建立一個可審計的基礎資料層，也就是強調資料的曆史 性、可追溯性和原子性，而不要求對資料進行過度的一緻性處理和整合g 同時它基于主題概念将企業資料進行結構化組織，并引入了更進一步的 範式處理來優化模型，以應對遊、系統變更的擴充性。
Data Vault 模型組成部分：
Hub：是企業的核心業務實體，由實體 key、資料倉庫序列代理 鍵、裝載時間、資料來源組成。 Link：代表 Hub 之間的關系。這裡與 ER 模型最大的差別是将關 系作為一個獨立的單元抽象，可以提升模型的擴充性。它可以直 接描述 1 : 1 、 l :n 和 n:n 的關系，而不需要做任何變更。它由 Hub 的代理鍵、裝載時間、資料來源組成。 Satellite：是 Hub 的較長的描述内容， 一個 Hub 可以有多個 Satellite。它由 Hub 的代理鍵、裝載時間、來源類型、詳細的 Hub 描述信 息組成。
Anchor 模型：
Anchor 對 Data Vault 模型做了進一步規範化處理， Lars. Ri:innback 的初衷是設計一個高度可擴充的模型，其核心思想是所有的擴充隻是添 加而不是修改，是以将模型規範到 6NF，基本變成了 k-v 結構化模型。我們看一下 Anchor 模型的組成。 Anchors：類似于 Data Vault 的 Hub ，代表業務實體，且隻有主鍵。 Attributes：功能類似于 Data Vault 的 Satellite ，但是它更加規範 化，将其全部 k-v 結構化， 一個表隻有一個 Anchors 的屬性描述。 Ties：就是 Anchors 之間的關系，單獨用表來描述，類似于 Data Vault 的 Link，可以提升整體模型關系的擴充能力。 Knots：代表那些可能會在多個 Anchors 中公用的屬性的提煉， 比如性别、狀态等這種枚舉類型且被公用的屬性。
以上四種模型總結：
綜上所述：資料模型的選擇應該根據所述的行業以及現有的業務綜合考慮，選擇合适的模型或者混合性模型，但要遵循模型的設計的原則；
1.高内聚低耦合
2. 核心模型與擴充模型分離
3.公共處理邏輯下沉及單一
4.成本與性能平衡
5.資料可復原
6.一緻性
7.命名清晰、可了解。
17.SCD的常用處理方式？優劣？與SCD2與拉連結清單有什麼異同？
答：拉連結清單面向事實
SCD2面向次元
2
緩慢變化維(SCD)：
“
SCD1: 覆寫重新
SCD2：增加屬性列
SCD3：增加次元行
”
拉連結清單：
參考：
曆史拉連結清單，既能滿足對曆史資料的需求，又能很大程度的節省存儲資源； 1. dw_begin_date表示該條記錄的生命周期開始時間，dw_end_date表示該條記錄的生命周期結束時間； 2. dw_end_date = '9999-12-31'表示該條記錄目前處于有效狀态； 3. 如果查詢目前所有有效的記錄，則select * from order_his where dw_end_date = '9999-12-31' 4. 如果查詢2012-06-21的曆史快照，則select * from order_his where dw_begin_date <= '2012-06-21' and end_date >= '2012-06-21'。
18.中繼資料的了解？中繼資料管理系統？
參考：
答：中繼資料主要記錄資料倉庫中模型的定義、各層級間的映射關系、監 控資料倉庫的資料狀态及 ETL 的任務運作狀态。
中繼資料有重要的應用價值，是資料管理、資料内容、資料應用的基礎，在資料管理方面為集團資料提供在計算、存儲、成本、品質、安全、模型等治理領域上的資料支援。
中繼資料管理系統： 首先梳理清楚元倉底層資料，對中繼資料做分類，如計算中繼資料、存儲中繼資料、品質中繼資料等，減少資料重複建設，保障資料的唯一性。
另外， 要豐富表和字段使用說明，友善使用和了解。根據元倉底層資料建構元倉中間層，建設中繼資料基礎寬表，也就是中繼資料中間層，打通從資料産生到消費整個鍊路。
19.如何控制資料品質？
可參考：
資料品質
答：
1.資料品質保證原則：完整性，準确性，資料品質，及時性，一緻性
2.資料品質方法：資料資産等級的劃定
3.資料加工過程卡點校驗
4.風險點監控：針對線上或者離線資料的監控
5.品質衡量：故障等級的劃定以及資料品質的事件的記錄
20.如何做資料治理？資料資産管理呢？
參考：
答：
在明确資料治理是資料管理的一部分之後，下一個問題就是定義資料管理。
治理相對容易界定，它是用來明确相關角色、工作責任和工作流程的，確定資料資産能長期有序地、可持續地得到管理。
而資料管理則是一個更為廣泛的定義，它與任何時間采集和應用資料的可重複流程的方方面面都緊密相關。
其實在數倉的整個鍊路中資料治理的理念是滲入其中的，在ETL過程中開發人員會對資料清洗這其實就是治理的一部分，再加上後期資料資産的管理和落定都有資料治理的滲入。
21.Hive優化？SQL優化，參數優化
參考：
(mapjoin、列裁剪、分區、分桶、Map數、Reduce數、常用參數等)
答：
針對于Hive内部調優的一些方式(原因和解決方案可檢視上面參考文章)
01.請慎重使用COUNT(DISTINCT col)
02.小檔案會造成資源的過度占用以及影響查詢效率
03.請慎重使用SELECT *
04.不要在表關聯後面加WHERE條件
05.處理掉字段中帶有空值的資料
06.設定并行執行任務數
07.設定合理的Reducer個數
08.JVM重用
09.為什麼任務執行的時候隻有一個reduce？
10.選擇使用Tez引擎
11.選擇使用本地模式
12.選擇使用嚴格模式
22.資料傾斜
參考：
答：
1)map傾斜
Map 端長尾的根本原因是由于讀人的檔案塊的資料分布不均勻，再 加上 UDF 函數性能、 Join 、聚合操作等，導緻讀人資料量大的 Map lnstance 耗時較長。在開發過程中如果遇到 Map 端長尾的情況，首先考 慮如何讓 Map Instance 讀取的資料量足夠均勻，然後判斷是哪些操作導 緻 Map Instance 比較慢 ，最後考慮這些操作是否必須在 Map 端完成 ， 在其他階段是否會做得更好。
2)join傾斜
當大表和大表 Join 因為熱點值發生傾斜時，雖然可以通過修改代 碼來解決，但是修改起來很麻煩，代碼改動也很大，且影響閱讀。而 Max Compute 現有的參數設定使用不夠靈活，傾斜值多的時候不可能将 所有值都列在參數中，且傾斜值可能經常變動。是以，我們還一直在探 索和思考，期望有更好的、更智能的解決方案，如生成統計資訊， Max Compute 内部根據統計資訊來自動生成解決傾斜的代碼，避免投入 過多的人力。
3)reduce傾斜
目前 Reduce 端資料傾斜很多是由 Count Distinct 問題引起的，是以 在 ETL 開發工作中應該予以重視 Count Distinct 問題，避免資料膨脹。對于一些表的 Join 階段的 Null 值問題，應該對表的資料分布要有清楚 的認識，在開發時解決這個問題。
23.小檔案問題
答：原因：
① 衆所周知，小檔案在HDFS中存儲本身就會占用過多的記憶體空間，那麼對于MR查詢過程中過多的小檔案又會造成啟動過多的Mapper Task, 每個Mapper都是一個背景線程，會占用JVM的空間。
② 在Hive中，動态分區會造成在插入資料過程中，生成過多零碎的小檔案。
③ 不合理的Reducer Task數量的設定也會造成小檔案的生成，因為最終。Reducer是将資料落地到HDFS中的。
④ Hive中分桶表的設定。
解決方案：
① 在資料源頭HDFS中控制小檔案産生的個數，比如采用Sequencefile作為表存儲格式，不要用textfile，在一定程度上可以減少小檔案(常見于在流計算的時候采用Sequencefile格式進行存儲)。
② 減少reduce的數量(可以使用參數進行控制)。
③ 慎重使用動态分區，最好在分區中指定分區字段的val值。
④ 最好資料的校驗工作，比如通過腳本方式檢測hive表的檔案數量，并進行檔案合并。
⑤ 合并多個檔案資料到一個檔案中，重新建構表。
24.order by、sort by、distribute by、cluster by
答：order by 全局排序
sort by 局部排序(reduce)
通過修改 distribute by和sort by 字段的方法進行資料重分布。
25.udf、udtf？處理的問題？
答：省略。按實際開發陳述即可。
26.shuffer優化
答：了解hive中一個sql的執行的内在情況，是如何轉換為mr的；
壓縮：對資料進行壓縮，減少寫讀資料量；
減少不必要的排序：并不是所有類型的Reduce需要的資料都是需要排序的，排序這個過程如果不需要最好還是不要的好；
27.MySQL如何改寫row_number
SELECT t.*, @RowNum := @RowNum + 1 AS RowNum
FROM t, (SELECT @RowNum := 0) AS myRows;
28.連續n天登入使用者
參考：
oracle：
select distinct user_id
from
(
select b.user_id, b.d_temp, count(*)
from
( select a.user_id, a.login_time - rownum d_temp
from
( select t.*
from user_data t
order by t.user_id, t.login_time
)a
)b
group by b.user_id, b.d_temp
having count(*) >= 3
);
29.使用者留存、使用者活躍、沉默使用者、回流使用者
答：曾在神策的《資料驅動》一書中看到過相關的介紹，此問題資料資料營運範圍，在資料的支撐下得出一段時間或者某個特定時間端内使用者的情況。
30.lag/lead()over()函數、ntile() 等分析函數
參考：(最全總結)
答：lead函數：用于提取目前行前某行的資料
lag函數：用于提取目前行後某行的資料
ntile：用于将分組資料按照順序切分成n片，傳回目前記錄所在的切片值。
31.rollup、cube、grouping sets grouping_id
答：
rollup (N+1個分組方案)
cube (2^N個分組方案)
grouping sets (自定義羅列出分組方案)
cube函數：
SELECT col1,col2,col3,col4 --次元字段 ,COUNT(user_id) --聚合字段 ,GROUPING__ID --聚合選取的組号(二進制表示,但是這裡列印出來的是十進制) ,rpad(reverse(bin(CAST(GROUPING__ID AS BIGINT))),4,'0') --對其二進制化就能明白了,注意中間是兩個下劃線,因為在反轉的時候會把末尾的0去掉,需要用rpad補充至次元個數 FROM TABLEGROUP BY col1,col2,col3,col4 WITH cube --次元字段都要出現在group by中,這裡不能使用1,2,3,4代替 ;
-------------------------------------
grouping sets：
-------------------------------------
rollup函數：
32.partition和分桶
答：
分區：優勢在于利用次元分割資料。在使用分區次元查詢時，Hive隻需要加載資料，極大縮短資料加載時間
分區提供了一種整理資料和優化查詢的便利方式。不過，并非所有資料集都可形成合理的分區，特别是在需要合理劃分資料、防止傾斜時。分桶是将資料分解管理的另一技術
分桶：解決的是資料傾斜的問題。因為桶的數量固定，是以沒有資料波動。桶對于資料抽樣再适合不過，同時也有利于高效的map-side Join。
今天就先寫到這裡，作為個人總結與參考，希望能抛磚引玉，對你有所幫助！哪怕一丁點的幫助，我也會很開心的~ 祝福大家社群的小夥伴們都能在2020年升職加薪，沒有加班~ 加油！