0.自我介紹
答：1）.簡單的自我介紹，突出自己優(yōu)勢
??? 2）.項目介紹
??? 3）.項目中承擔(dān)的工作和模塊。
???4）.長的帥或漂亮，前四條都可以忽略
1. 什么是數(shù)據(jù)倉庫？如何構(gòu)建數(shù)據(jù)倉庫？
可參考：漫談 | 大牛帶你從0到1構(gòu)建數(shù)據(jù)倉庫實戰(zhàn)
（如果這個問題回答的好，后面很多問題都不需要再問）
答：數(shù)據(jù)倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合，它用于支持企業(yè)或組織的決策分析處理。
數(shù)倉構(gòu)建：
1). 前期業(yè)務(wù)調(diào)研需求調(diào)研 數(shù)據(jù)調(diào)研 技術(shù)選型
2). 提煉業(yè)務(wù)模型，總線矩陣，劃分主題域；
3). 定制規(guī)范命名規(guī)范、開發(fā)規(guī)范、流程規(guī)范
4). 數(shù)倉架構(gòu)分層：一般分為
操作數(shù)據(jù)層（ODS）、公共維度模型層（CDM）和應(yīng)用數(shù)據(jù)層（ADS）,其中公共維度模型層包括明細(xì)數(shù)據(jù)層（DWD和匯總數(shù)據(jù)層（DWS）
公共維度模型層（CDM）：存放明細(xì)事實數(shù)據(jù)、維表數(shù)據(jù)及公共指標(biāo)匯總數(shù)據(jù),其中明細(xì)事實數(shù)據(jù)、維表數(shù)據(jù)一般根據(jù)ODS層數(shù)據(jù)加工生成：公共指標(biāo)匯總數(shù)據(jù)一般根據(jù)維表數(shù)據(jù)和明細(xì)事實數(shù)據(jù)加工生成。
CDM層又細(xì)分為DWD層和DWS層,分別是明細(xì)數(shù)據(jù)層和匯總數(shù)據(jù)層,采用維度模型方法作為理論基礎(chǔ),更多地采用一些維度退化手法,將維度退化至事實表中,減少事實表和維表的關(guān)聯(lián),提高明細(xì)數(shù)據(jù)表的易用性：同時在匯總數(shù)據(jù)層,加強指標(biāo)的維度退化,采取更多的寬表化手段構(gòu)建公共指標(biāo)數(shù)據(jù)層,提升公共指標(biāo)的復(fù)用性,減少重復(fù)加工。
應(yīng)用數(shù)據(jù)層（ADS）：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標(biāo)數(shù)據(jù),根據(jù)CDM層與ODS層加工生成。
?5）.選擇合適的數(shù)據(jù)模型，不同的行業(yè)涉選取的模型近不相同，合適的模型，更利于在數(shù)據(jù)存儲，計算，開發(fā)，安全，以及數(shù)據(jù)查詢的效率，更能體現(xiàn)數(shù)倉的價值。
?綜上所述：數(shù)倉建設(shè)這個問題的范圍過于大，它包含了一個0-1的過程，此處只做大方面的回答，具體的細(xì)節(jié)問題還需另外討論。
2.如何建設(shè)數(shù)據(jù)中臺？可簡單說下對中臺理解與思路
答：省略
可參考：
阿里架構(gòu)總監(jiān)一次講透中臺架構(gòu)，13頁PPT精華詳解，建議收藏！
3.數(shù)據(jù)倉庫、數(shù)據(jù)中臺、數(shù)據(jù)湖的理解
答：數(shù)據(jù)倉庫? 分而治之? 對象BI
? ? ?數(shù)據(jù)湖? ? ?無為而治? 對象AI
? ? ?數(shù)據(jù)中臺? 一統(tǒng)天下? 對象DataAPI（組織架構(gòu)）
可參考：
辨析數(shù)據(jù)倉庫、數(shù)據(jù)湖和數(shù)據(jù)中臺內(nèi)涵及差異點(建議收藏)
數(shù)據(jù)中臺VS數(shù)據(jù)倉庫、數(shù)據(jù)中臺VS業(yè)務(wù)中臺，到底有什么區(qū)別？
? ? ?Delta Lake | Apache大神帶你了解數(shù)據(jù)湖，這一篇文章就夠了
4.傳統(tǒng)數(shù)倉的程度（建模工具、ETL工具、BI報表工具、調(diào)度系統(tǒng)）
答：
建模工具：powerDesiger、Erwin、Visio
ETL工具: kettle/informatic（主流的兩款） 等等
BI報表工具:superset、cboard、redash、帆軟BI/QuickBI/PowerBI 等等
調(diào)度系統(tǒng)：airflow、azkaban、ooize、xxl-job、dolphinscheduler、Zeus、hera、TASKCTL/自研平臺 等等
系列 | 漫談數(shù)倉第三篇NO.3 『數(shù)據(jù)處理』ETL
系列 | 漫談數(shù)倉第四篇NO.4 『數(shù)據(jù)應(yīng)用』（BI&OLAP）
5.傳統(tǒng)數(shù)倉和大數(shù)據(jù)數(shù)倉的異同？有哪些大的變化？
答：其區(qū)別主要數(shù)數(shù)倉數(shù)據(jù)存儲的地方不同，傳統(tǒng)數(shù)倉數(shù)據(jù)存儲在mysql/oracle等關(guān)系型數(shù)據(jù)庫上，大數(shù)據(jù)數(shù)倉存儲在hadoop平臺的hive中（實際上是HDFS中），當(dāng)然也有其他的數(shù)倉產(chǎn)品比如TD、greenplum等。
我接觸過的傳統(tǒng)數(shù)倉技術(shù)架構(gòu)是使用kettle做ETL工具，數(shù)據(jù)保存在mysql中，使用MSTR+java開發(fā)的數(shù)據(jù)平臺做可視化，隨著數(shù)據(jù)量逐漸增大，事實表條數(shù)達(dá)到千萬級，kettle逐漸變得不穩(wěn)定，
單表做拉鏈的任務(wù)的執(zhí)行時間也指數(shù)級增加，從1/2h到了6/7h。
公司考慮使用hadoop平臺的hive做數(shù)據(jù)倉庫，報表層數(shù)據(jù)保存在mysql中，使用tableau做報表系統(tǒng)，這樣不用擔(dān)心存儲問題、計算速度也大大加快了。
在此基礎(chǔ)上，公司開放了hue給各個部門使用，這樣簡單的提數(shù)工作可以由運營自己來操作。
使用presto可以做mysql、hive的跨庫查詢，使用時要注意presto的數(shù)據(jù)類型非常嚴(yán)格。
6.印象最深刻的項目？為什么？亮點與優(yōu)勢？
答：回答的方向兩方面
??? 1.好的項目，從中學(xué)到了什么
??? 2.差的項目，你是如何改造的
7.數(shù)倉最重要的是什么？
答：數(shù)據(jù)的準(zhǔn)確性，鄙人記得在一個統(tǒng)計網(wǎng)站上看過，好多數(shù)倉因為數(shù)據(jù)不準(zhǔn)確被終止。
??? 數(shù)據(jù)的真正價值在于數(shù)據(jù)驅(qū)動決策，通過數(shù)據(jù)指導(dǎo)運營,在一個不準(zhǔn)確的數(shù)據(jù)驅(qū)動下，結(jié)果可想而知。
如何保證數(shù)據(jù)的準(zhǔn)確性？
??? 元數(shù)據(jù)的建設(shè)與管理是其中重要的一個環(huán)節(jié)
??? 元數(shù)據(jù)建設(shè)的目標(biāo)是打通數(shù)據(jù)接入到加工 ，再到數(shù)據(jù)消費整個鏈路，規(guī)范元數(shù)據(jù)體系與模型，提供統(tǒng)一的元數(shù)據(jù)服務(wù)出口，保障元數(shù)據(jù)產(chǎn)出的穩(wěn)定性和質(zhì)量。
??? 首先梳理清楚元倉底層數(shù)據(jù)，對元數(shù)據(jù)做分類，如計算元數(shù)據(jù)、存儲元數(shù)據(jù)、質(zhì)量元數(shù)據(jù)等，減少數(shù)據(jù)重復(fù)建設(shè)，保障數(shù)據(jù)的唯一性。
另外， 要豐富表和字段使用說明，方便使用和理解。根據(jù)元倉底層數(shù)據(jù)構(gòu)建元倉中間層，建設(shè)元數(shù)據(jù)基礎(chǔ)寬表，也就是元數(shù)據(jù)中間層，打通從數(shù)據(jù)產(chǎn)生到消費整個鏈路。
也可在粒度、規(guī)范等方面展開，見仁見智。
可參考：美團 數(shù)據(jù)質(zhì)量平臺 設(shè)計與實踐
8.實時數(shù)倉做過嗎？采用什么架構(gòu)？lambda有哪些優(yōu)缺點？
答：省略（目前我只接觸到離線數(shù)倉）
9.如何看待kappa架構(gòu)？iota架構(gòu)呢？
答：省略（目前還沒接觸到）
參考：Lambda架構(gòu)已死，去ETL化的IOTA才是未來
10.責(zé)任心？溝通能力？團隊協(xié)作？數(shù)據(jù)思維？
答：鄙人開發(fā)出身，后轉(zhuǎn)數(shù)倉；深有體會搞TP系統(tǒng)和搞AP系統(tǒng)的考慮問題有出入，也許更多的是對數(shù)倉的機制不了解，
??? 項目需要不同的開發(fā)人員來協(xié)作完成某項工作，因此大家在交流溝通上需要找到一個共同的點，協(xié)作合力完成。
11.用戶畫像（靜態(tài)、動態(tài)標(biāo)簽，統(tǒng)計、規(guī)則、預(yù)測標(biāo)簽，衰退系數(shù)、標(biāo)簽權(quán)重）
參考：用戶畫像
答：
靜態(tài)數(shù)據(jù)-評估價值:用戶相對穩(wěn)定的信息，例如，主要包括人口屬性、商業(yè)屬性等方面數(shù)據(jù)；這類信息，自成標(biāo)簽，如果企業(yè)有真實信息則無需過多建模預(yù)測，更多的是數(shù)據(jù)清洗工作，如果某些靜態(tài)信息不準(zhǔn)或缺失則需要建模預(yù)測。
動態(tài)數(shù)據(jù)-循跡: 用戶不斷變化的行為信息，例如：瀏覽凡客首頁、瀏覽休閑鞋單品頁、搜索帆布鞋、發(fā)表關(guān)于鞋品質(zhì)的微博、贊“雙十一大促”的微博消息。等等均可看作互聯(lián)網(wǎng)用戶行為。
形態(tài):標(biāo)簽與權(quán)重: 用戶畫像的最終形態(tài)是通過分析用戶行為，最終為每個用戶打上標(biāo)簽，以及該標(biāo)簽的權(quán)重
標(biāo)簽：表征了內(nèi)容，用戶對該內(nèi)容有興趣、偏好、需求等等
權(quán)重：表征了指數(shù)，用戶的興趣、偏好指數(shù)，也可能表征用戶的需求度，可以簡單的理解為可信度，概率
數(shù)據(jù)建模方法: 標(biāo)簽=用戶標(biāo)識 + 時間 + 行為類型 + 接觸點（網(wǎng)址+內(nèi)容）的聚合，某用戶因為在什么時間、地點、做了什么事，所以會打上**標(biāo)簽
12.推薦系統(tǒng)（協(xié)同過濾，基于用戶、商品，SVD，各種距離算法等）
答：省略（只知神策有相關(guān)的產(chǎn)品）
13.數(shù)倉基礎(chǔ)理念理解
? ? ?可參考：數(shù)據(jù)倉庫建模
?? （主題域 血緣關(guān)系 拉鏈表 代理鍵 維度退化 緩慢變化維SCD 事實表類型 增量dwd處理 星型/雪花/星座模型 事實 維度 粒度 原子/派生指標(biāo) OLAP）
答：省略（概念性的問題可以自行查找）
14.數(shù)倉如何確定主題域？CDM？
參考：系列 | 漫談數(shù)倉第二篇NO.2 數(shù)據(jù)模型（維度建模）
答：主題域通常是聯(lián)系較為緊密的數(shù)據(jù)主題的集合。可以根據(jù)業(yè)務(wù)的關(guān)注點，將這些數(shù)據(jù)主題劃分到不同的主題域。主題域的確定必須由最終用戶和數(shù)據(jù)倉庫的設(shè)計人員共同完成。
15.數(shù)倉如何分層的？及每一層的作用？思考：為什么要這么分層？
參考：系列 | 漫談數(shù)倉第一篇NO.1 『數(shù)倉架構(gòu)』
數(shù)倉藍(lán)圖：如何優(yōu)雅地規(guī)劃數(shù)倉體系
答：如何架構(gòu)分層？
? 結(jié)合Inmon和Kimball的集線器式和總線式的數(shù)據(jù)倉庫的優(yōu)點，分層可為ODS【-MID】-DW-DM-OLAP/OLAM/app（不同企業(yè)略有差異）
ODS層是將OLTP數(shù)據(jù)通過ETL同步到數(shù)據(jù)倉庫來作為數(shù)據(jù)倉庫最基礎(chǔ)的數(shù)據(jù)來源。在這個過程中，數(shù)據(jù)經(jīng)過了一定的清洗，比如字段的統(tǒng)一，臟數(shù)據(jù)的去除等，但是數(shù)據(jù)的粒度是不會變化的。ODS層的數(shù)據(jù)可以只保留一定的時間。
? MID中間層是采用Inmon集線器架構(gòu)的方式，使用范式建模（貼源）的方法。這一層主要是做規(guī)范化的事情，比如應(yīng)用庫表非規(guī)范化，字段格式復(fù)雜（json格式）需做一些處理。這一層不是必須有的。也不會對外開放使用。范式建模保證了數(shù)據(jù)一致性、唯一性、正確性。
? DW-DM層是采用Kimball的總線式的數(shù)據(jù)倉庫架構(gòu)，針對部門（比如財務(wù)部門）或者某一主題（比如商戶、用戶），通過維度建模（推薦星型模型），構(gòu)建一致性維度，原子粒度的數(shù)據(jù)是DW層，按照實體或者主題經(jīng)過一定的匯總，建設(shè)數(shù)據(jù)集市模型。數(shù)據(jù)集市可以為OLAP提供服務(wù)。
? 為什么要分層的思考？
空間換時間。通過建設(shè)多層次的數(shù)據(jù)模型供用戶使用，避免用戶直接使用操作型數(shù)據(jù)，可以更高效的訪問數(shù)據(jù)。? 把復(fù)雜問題簡單化。講一個復(fù)雜的任務(wù)分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護數(shù)據(jù)的準(zhǔn)確性，當(dāng)數(shù)據(jù)出現(xiàn)問題之后，可以不用修復(fù)所有的數(shù)據(jù)，只需要從有問題的步驟開始修復(fù)。? 便于處理業(yè)務(wù)的變化。隨著業(yè)務(wù)的變化，只需要調(diào)整底層的數(shù)據(jù)，對應(yīng)用層對業(yè)務(wù)的調(diào)整零感知.
? 分層的價值
01.高效的數(shù)據(jù)組織形式【易維護】
? 面向主題的特性決定了數(shù)據(jù)倉庫擁有業(yè)務(wù)數(shù)據(jù)庫所無法擁有的高效的數(shù)據(jù)組織形式，更加完整的數(shù)據(jù)體系，清晰的數(shù)據(jù)分類和分層機制。因為所有數(shù)據(jù)在進入數(shù)據(jù)倉庫之前都經(jīng)過清洗和過濾，使原始數(shù)據(jù)不再雜亂無章，基于優(yōu)化查詢的組織形式，有效提高數(shù)據(jù)獲取、統(tǒng)計和分析的效率。
02.時間價值【高性能】
? 數(shù)據(jù)倉庫的構(gòu)建將大大縮短獲取信息的時間，數(shù)據(jù)倉庫作為數(shù)據(jù)的集合，所有的信息都可以從數(shù)據(jù)倉庫直接獲取，數(shù)據(jù)倉庫的最大優(yōu)勢在于一旦底層從各類數(shù)據(jù)源到數(shù)據(jù)倉庫的ETL流程構(gòu)建成型，那么每天就會有來自各方面的信息通過自動任務(wù)調(diào)度的形式流入數(shù)據(jù)倉庫，從而使一切基于這些底層信息的數(shù)據(jù)獲取的效率達(dá)到迅速提升。
? 從應(yīng)用來看，使用數(shù)據(jù)倉庫可以大大提高數(shù)據(jù)的查詢效率，尤其對于海量數(shù)據(jù)的關(guān)聯(lián)查詢和復(fù)雜查詢，所以數(shù)據(jù)倉庫有利于實現(xiàn)復(fù)雜的統(tǒng)計需求，提高數(shù)據(jù)統(tǒng)計的效率。
03.集成價值【簡單化】
? 數(shù)據(jù)倉庫是所有數(shù)據(jù)的集合，包括日志信息、數(shù)據(jù)庫數(shù)據(jù)、文本數(shù)據(jù)、外部數(shù)據(jù)等都集成在數(shù)據(jù)倉庫中，對于應(yīng)用來說，實現(xiàn)各種不同數(shù)據(jù)的關(guān)聯(lián)并使多維分析更加方便，為從多角度多層次地數(shù)據(jù)分析和決策制定提供的可能。
04.歷史數(shù)據(jù)【歷史性】
? 記錄歷史是數(shù)據(jù)倉庫的特性之一，數(shù)據(jù)倉庫能夠還原歷史時間點上的產(chǎn)品狀態(tài)、用戶狀態(tài)、用戶行為等，以便于能更好的回溯歷史，分析歷史，跟蹤用戶的歷史行為，更好地比較歷史和總結(jié)歷史，同時根據(jù)歷史預(yù)測未來。
16.數(shù)倉有哪幾種建模思想？維度建模、范式建模、datavault？.. 有什么優(yōu)劣，如何選擇？
答：ER模型，維度建模，datavault模型，Anchor 模型。
參考：系列 | 漫談數(shù)倉第二篇NO.2 數(shù)據(jù)模型（維度建模）
? ER模型：
數(shù)據(jù)倉庫之父 Bill lnmon 提出的建模方法是從全企業(yè)的高度設(shè)計一 個3NF 模型，用實體關(guān)系（ Entity Relationship, ER）模型描述企業(yè)業(yè) 務(wù)，在范式理論上符合 3NF。數(shù)據(jù)倉庫中的 3NF 與 OLTP 系統(tǒng)中的 3NF 的區(qū)別在于，它是站在企業(yè)角度面向主題的抽象，而不是針對某個具體 業(yè)務(wù)流程的實體對象關(guān)系的抽象。其具有以下幾個特點：· 需要全面了解企業(yè)業(yè)務(wù)和數(shù)據(jù)?！?實施周期非常長。． 對建模人員的能力要求非常高。采用 ER 模型建設(shè)數(shù)據(jù)倉庫模型的出發(fā)點是整合數(shù)據(jù)，將各個系統(tǒng)
中的數(shù)據(jù)以整個企業(yè)角度按主題進行相似性組合和合并，并進行一致性 處理，為數(shù)據(jù)分析決策服務(wù)，但是并不能直接用于分析決策。其建模步驟分為三個階段?！じ邔幽Ｐ停阂粋€高度抽象的模型，描述主要的主題以及主題間的 關(guān)系，用于描述企業(yè)的業(yè)務(wù)總體概況。· 中層模型：在高層模型的基礎(chǔ)上，細(xì)化主題的數(shù)據(jù)項。． 物理模型（也叫底層模型）：在中層模型的基礎(chǔ)上，考慮物理存 儲，同時基于性能和平臺特點進行物理屬性的設(shè)計，也可能做一 些表的合并、分區(qū)的設(shè)計等。
?? 維度建模：
維度建模從分析決策的需求出發(fā)構(gòu)建模型，為分析需求服務(wù)，因此 它重點關(guān)注用戶如何更快速地完成需求分析，同時具有較好的大規(guī)模復(fù) 雜查詢的響應(yīng)性能。其典型的代表是星形模型，以及在一些特殊場景下 使用的雪花模型。其設(shè)計分為以下幾個步驟?！?選擇需要進行分析決策的業(yè)務(wù)過程。業(yè)務(wù)過程可以是單個業(yè)務(wù)事 件，比如交易的支付、退款等；也可以是某個事件的狀態(tài)，比如 當(dāng)前的賬戶余額等；還可以是一系列相關(guān)業(yè)務(wù)事件組成的業(yè)務(wù)流 程，具體需要看我們分析的是某些事件發(fā)生情況，還是當(dāng)前狀態(tài)， 或是事件流轉(zhuǎn)效率?！?選擇粒度。在事件分析中，我們要預(yù)判所有分析需要細(xì)分的程度，
從而決定選擇的粒度。粒度是維度的一個組合?！?識別維表。選擇好粒度之后，就需要基于此粒度設(shè)計維表，包括 維度屬性，用于分析時進行分組和篩選。·選擇事實。確定分析需要衡量的指標(biāo)。
Data Vault 模型：
Data Vault 是 Dan Linstedt 發(fā)起創(chuàng)建的一種模型，它是 ER 模型的衍 生，其設(shè)計的出發(fā)點也是為了實現(xiàn)數(shù)據(jù)的整合，但不能直接用于數(shù)據(jù)分 析決策。它強調(diào)建立一個可審計的基礎(chǔ)數(shù)據(jù)層，也就是強調(diào)數(shù)據(jù)的歷史 性、可追溯性和原子性，而不要求對數(shù)據(jù)進行過度的一致性處理和整合g 同時它基于主題概念將企業(yè)數(shù)據(jù)進行結(jié)構(gòu)化組織，并引入了更進一步的 范式處理來優(yōu)化模型，以應(yīng)對游、系統(tǒng)變更的擴展性。
Data Vault 模型組成部分：
? Hub：是企業(yè)的核心業(yè)務(wù)實體，由實體 key、數(shù)據(jù)倉庫序列代理 鍵、裝載時間、數(shù)據(jù)來源組成。? Link：代表 Hub 之間的關(guān)系。這里與 ER 模型最大的區(qū)別是將關(guān) 系作為一個獨立的單元抽象，可以提升模型的擴展性。它可以直 接描述 1 : 1 、 l :n 和 n:n 的關(guān)系，而不需要做任何變更。它由 Hub 的代理鍵、裝載時間、數(shù)據(jù)來源組成。? Satellite：是 Hub 的詳細(xì)描述內(nèi)容， 一個 Hub 可以有多個 Satellite。它由 Hub 的代理鍵、裝載時間、來源類型、詳細(xì)的 Hub 描述信 息組成。
? Anchor 模型：
? Anchor 對 Data Vault 模型做了進一步規(guī)范化處理， Lars. Ri:innback 的初衷是設(shè)計一個高度可擴展的模型，其核心思想是所有的擴展只是添 加而不是修改，因此將模型規(guī)范到 6NF，基本變成了 k-v 結(jié)構(gòu)化模型。我們看一下 Anchor 模型的組成。? Anchors：類似于 Data Vault 的 Hub ，代表業(yè)務(wù)實體，且只有主鍵。? Attributes：功能類似于 Data Vault 的 Satellite ，但是它更加規(guī)范 化，將其全部 k-v 結(jié)構(gòu)化， 一個表只有一個 Anchors 的屬性描述。? Ties：就是 Anchors 之間的關(guān)系，單獨用表來描述，類似于 Data Vault 的 Link，可以提升整體模型關(guān)系的擴展能力。? Knots：代表那些可能會在多個 Anchors 中公用的屬性的提煉， 比如性別、狀態(tài)等這種枚舉類型且被公用的屬性。
以上四種模型總結(jié)：
綜上所述：數(shù)據(jù)模型的選擇應(yīng)該根據(jù)所述的行業(yè)以及現(xiàn)有的業(yè)務(wù)綜合考慮，選擇合適的模型或者混合性模型，但要遵循模型的設(shè)計的原則；
1.高內(nèi)聚低耦合?
2. 核心模型與擴展模型分離?
3.公共處理邏輯下沉及單一?
4.成本與性能平衡?
5.數(shù)據(jù)可回滾?
6.一致性??
7.命名清晰、可理解。
17.SCD的常用處理方式？優(yōu)劣？與SCD2與拉鏈表有什么異同？
答：拉鏈表面向事實
????? SCD2面向維度
緩慢變化維（SCD）：
?? SCD1: 覆蓋重新
?? SCD2：增加屬性列
?? SCD3：增加維度行
?? 拉鏈表：
歷史拉鏈表，既能滿足對歷史數(shù)據(jù)的需求，又能很大程度的節(jié)省存儲資源；
??? 1. dw_begin_date表示該條記錄的生命周期開始時間，dw_end_date表示該條記錄的生命周期結(jié)束時間；
??? 2. dw_end_date = '9999-12-31'表示該條記錄目前處于有效狀態(tài)；
??? 3. 如果查詢當(dāng)前所有有效的記錄，則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.元數(shù)據(jù)的理解？元數(shù)據(jù)管理系統(tǒng)？
?答：元數(shù)據(jù)主要記錄數(shù)據(jù)倉庫中模型的定義、各層級間的映射關(guān)系、監(jiān) 控數(shù)據(jù)倉庫的數(shù)據(jù)狀態(tài)及 ETL 的任務(wù)運行狀態(tài)。?
元數(shù)據(jù)有重要的應(yīng)用價值，是數(shù)據(jù)管理、數(shù)據(jù)內(nèi)容、數(shù)據(jù)應(yīng)用的基礎(chǔ)，在數(shù)據(jù)管理方面為集團數(shù)據(jù)提供在計算、存儲、成本、質(zhì)量、安全、模型等治理領(lǐng)域上的數(shù)據(jù)支持。
元數(shù)據(jù)管理系統(tǒng)：? 首先梳理清楚元倉底層數(shù)據(jù)，對元數(shù)據(jù)做分類，如計算元數(shù)據(jù)、存儲元數(shù)據(jù)、質(zhì)量元數(shù)據(jù)等，減少數(shù)據(jù)重復(fù)建設(shè)，保障數(shù)據(jù)的唯一性。
另外， 要豐富表和字段使用說明，方便使用和理解。根據(jù)元倉底層數(shù)據(jù)構(gòu)建元倉中間層，建設(shè)元數(shù)據(jù)基礎(chǔ)寬表，也就是元數(shù)據(jù)中間層，打通從數(shù)據(jù)產(chǎn)生到消費整個鏈路。
19.如何控制數(shù)據(jù)質(zhì)量？
可參考：美團 數(shù)據(jù)質(zhì)量平臺 設(shè)計與實踐
答：
? 1.數(shù)據(jù)質(zhì)量保證原則：完整性，準(zhǔn)確性，數(shù)據(jù)質(zhì)量，及時性，一致性
? 2.數(shù)據(jù)質(zhì)量方法：數(shù)據(jù)資產(chǎn)等級的劃定
? 3.數(shù)據(jù)加工過程卡點校驗
? 4.風(fēng)險點監(jiān)控：針對在線或者離線數(shù)據(jù)的監(jiān)控
? 5.質(zhì)量衡量：故障等級的劃定以及數(shù)據(jù)質(zhì)量的事件的記錄
20.如何做數(shù)據(jù)治理？數(shù)據(jù)資產(chǎn)管理呢？
參考：美團起源 數(shù)據(jù)治理平臺 的架構(gòu)與實踐（建議收藏）
? ? ? ? ? ? 數(shù)據(jù)治理平臺工具前世今生
淺談數(shù)據(jù)治理、數(shù)據(jù)管理、數(shù)據(jù)資源與數(shù)據(jù)資產(chǎn)管理內(nèi)涵及差異點(建議收藏)
答：
在明確數(shù)據(jù)治理是數(shù)據(jù)管理的一部分之后，下一個問題就是定義數(shù)據(jù)管理。
治理相對容易界定，它是用來明確相關(guān)角色、工作責(zé)任和工作流程的，確保數(shù)據(jù)資產(chǎn)能長期有序地、可持續(xù)地得到管理。
而數(shù)據(jù)管理則是一個更為廣泛的定義，它與任何時間采集和應(yīng)用數(shù)據(jù)的可重復(fù)流程的方方面面都緊密相關(guān)。
其實在數(shù)倉的整個鏈路中數(shù)據(jù)治理的理念是滲入其中的，在ETL過程中開發(fā)人員會對數(shù)據(jù)清洗這其實就是治理的一部分，再加上后期數(shù)據(jù)資產(chǎn)的管理和落定都有數(shù)據(jù)治理的滲入。
21.Hive優(yōu)化？SQL優(yōu)化，參數(shù)優(yōu)化
參考：干貨：Hive調(diào)優(yōu)及優(yōu)化的12種方式（推薦收藏）
（mapjoin、列裁剪、分區(qū)、分桶、Map數(shù)、Reduce數(shù)、常用參數(shù)等）
答：
????? 針對于Hive內(nèi)部調(diào)優(yōu)的一些方式（原因和解決方案可查看上面參考文章）
????? 01.請慎重使用COUNT(DISTINCT col)
? ? ? 02.小文件會造成資源的過度占用以及影響查詢效率
????? 03.請慎重使用SELECT *
????? 04.不要在表關(guān)聯(lián)后面加WHERE條件
????? 05.處理掉字段中帶有空值的數(shù)據(jù)
????? 06.設(shè)置并行執(zhí)行任務(wù)數(shù)
????? 07.設(shè)置合理的Reducer個數(shù)
????? 08.JVM重用
????? 09.為什么任務(wù)執(zhí)行的時候只有一個reduce？
????? 10.選擇使用Tez引擎
????? 11.選擇使用本地模式
????? 12.選擇使用嚴(yán)格模式
22.數(shù)據(jù)傾斜
參考：直擊面試 | 一文搞懂大數(shù)據(jù)、數(shù)倉面試必問之『數(shù)據(jù)傾斜』（建議收藏）
答：
1）map傾斜
?Map 端長尾的根本原因是由于讀人的文件塊的數(shù)據(jù)分布不均勻，再 加上 UDF 函數(shù)性能、 Join 、聚合操作等，導(dǎo)致讀人數(shù)據(jù)量大的 Map lnstance 耗時較長。在開發(fā)過程中如果遇到 Map 端長尾的情況，首先考 慮如何讓 Map Instance 讀取的數(shù)據(jù)量足夠均勻，然后判斷是哪些操作導(dǎo) 致 Map Instance 比較慢 ，最后考慮這些操作是否必須在 Map 端完成 ， 在其他階段是否會做得更好。
2）join傾斜
?? 當(dāng)大表和大表 Join 因為熱點值發(fā)生傾斜時，雖然可以通過修改代 碼來解決，但是修改起來很麻煩，代碼改動也很大，且影響閱讀。而 Max Compute 現(xiàn)有的參數(shù)設(shè)置使用不夠靈活，傾斜值多的時候不可能將 所有值都列在參數(shù)中，且傾斜值可能經(jīng)常變動。因此，我們還一直在探 索和思考，期望有更好的、更智能的解決方案，如生成統(tǒng)計信息， Max Compute 內(nèi)部根據(jù)統(tǒng)計信息來自動生成解決傾斜的代碼，避免投入 過多的人力。
3）reduce傾斜
?目前 Reduce 端數(shù)據(jù)傾斜很多是由 Count Distinct 問題引起的，因此 在 ETL 開發(fā)工作中應(yīng)該予以重視 Count Distinct 問題，避免數(shù)據(jù)膨脹。對于一些表的 Join 階段的 Null 值問題，應(yīng)該對表的數(shù)據(jù)分布要有清楚 的認(rèn)識，在開發(fā)時解決這個問題。
23.小文件問題
答：原因：
? ① 眾所周知，小文件在HDFS中存儲本身就會占用過多的內(nèi)存空間，那么對于MR查詢過程中過多的小文件又會造成啟動過多的Mapper Task, 每個Mapper都是一個后臺線程，會占用JVM的空間。
? ② 在Hive中，動態(tài)分區(qū)會造成在插入數(shù)據(jù)過程中，生成過多零碎的小文件。
? ③ 不合理的Reducer Task數(shù)量的設(shè)置也會造成小文件的生成，因為最終。Reducer是將數(shù)據(jù)落地到HDFS中的。
? ④ Hive中分桶表的設(shè)置。
? 解決方案：
? ① 在數(shù)據(jù)源頭HDFS中控制小文件產(chǎn)生的個數(shù)，比如采用Sequencefile作為表存儲格式，不要用textfile，在一定程度上可以減少小文件（常見于在流計算的時候采用Sequencefile格式進行存儲）。
? ② 減少reduce的數(shù)量(可以使用參數(shù)進行控制)。
? ③ 慎重使用動態(tài)分區(qū)，最好在分區(qū)中指定分區(qū)字段的val值。
? ④ 最好數(shù)據(jù)的校驗工作，比如通過腳本方式檢測hive表的文件數(shù)量，并進行文件合并。
? ⑤ 合并多個文件數(shù)據(jù)到一個文件中，重新構(gòu)建表。
24.order by、sort by、distribute by、cluster by
?答：order by 全局排序
?? sort by 局部排序(reduce)
?? 通過修改 distribute by和sort by 字段的方法進行數(shù)據(jù)重分布。
25.udf、udtf？處理的問題？
?答：省略。按實際開發(fā)陳述即可。
26.shuffer優(yōu)化
答：理解hive中一個sql的執(zhí)行的內(nèi)在情況，是如何轉(zhuǎn)換為mr的；
?? 壓縮：對數(shù)據(jù)進行壓縮，減少寫讀數(shù)據(jù)量；
?? 減少不必要的排序：并不是所有類型的Reduce需要的數(shù)據(jù)都是需要排序的，排序這個過程如果不需要最好還是不要的好；
27.MySQL如何改寫row_number
?SELECT t.*,? @RowNum := @RowNum + 1 AS RowNum
? FROM t,? (SELECT @RowNum := 0) AS myRows;
28.連續(xù)n天登錄用戶
參考：大數(shù)據(jù)SQL經(jīng)典面試題系列(1) - 連續(xù)3天登錄用戶
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.用戶留存、用戶活躍、沉默用戶、回流用戶
?答：曾在神策的《數(shù)據(jù)驅(qū)動》一書中看到過相關(guān)的介紹，此問題數(shù)據(jù)數(shù)據(jù)運營范圍，在數(shù)據(jù)的支撐下得出一段時間或者某個特定時間端內(nèi)用戶的情況。
30.lag/lead()over()函數(shù)、ntile() 等分析函數(shù)
參考：SQL分析函數(shù)，看這一篇就夠了（最全總結(jié)）
答：lead函數(shù)：用于提取當(dāng)前行前某行的數(shù)據(jù)
lag函數(shù)：用于提取當(dāng)前行后某行的數(shù)據(jù)
ntile：用于將分組數(shù)據(jù)按照順序切分成n片，返回當(dāng)前記錄所在的切片值。
31.rollup、cube、grouping sets? grouping_id
答：
rollup(N+1個分組方案)
cube??? ? ??? (2^N個分組方案)
grouping sets (自定義羅列出分組方案)
cube函數(shù)：
SELECT? col1,col2,col3,col4??? --維度字段??????? ,COUNT(user_id)??????? --聚合字段??????? ,GROUPING__ID????????? --聚合選取的組號(二進制表示,但是這里打印出來的是十進制)??????? ,rpad(reverse(bin(CAST(GROUPING__ID AS BIGINT))),4,'0')? ???????? --對其二進制化就能明白了,注意中間是兩個下劃線,因為在反轉(zhuǎn)的時候會把末尾的0去掉,需要用rpad補充至維度個數(shù)?FROM?? TABLEGROUP BY col1,col2,col3,col4 ?WITH cube?? --維度字段都要出現(xiàn)在group by中,這里不能使用1,2,3,4代替?? ?;
grouping sets：
??
rollup函數(shù)：
32.partition和分桶
答：
分區(qū)：優(yōu)勢在于利用維度分割數(shù)據(jù)。在使用分區(qū)維度查詢時，Hive只需要加載數(shù)據(jù)，極大縮短數(shù)據(jù)加載時間
分區(qū)提供了一種整理數(shù)據(jù)和優(yōu)化查詢的便利方式。不過，并非所有數(shù)據(jù)集都可形成合理的分區(qū)，特別是在需要合理劃分?jǐn)?shù)據(jù)、防止傾斜時。分桶是將數(shù)據(jù)分解管理的另一技術(shù)
分桶：解決的是數(shù)據(jù)傾斜的問題。因為桶的數(shù)量固定，所以沒有數(shù)據(jù)波動。桶對于數(shù)據(jù)抽樣再適合不過，同時也有利于高效的map-side Join。
