如何判定乙個表是事實表還是維度表？
資料建模過程說一下？
三正規化緩慢變化維處理方式？
什麼也不該，保留原始值
直接覆蓋
增加新行，需要為新航分配新的**鍵
增加新屬性列
增加微型維度（某些維度屬性變化較快導致維度表越來越大可以把這些屬性柴麗出來單獨構建微型維度表）
雙重外來鍵並且方式1與方式2結合
在方式2的基礎上，不僅是維度的**鍵作為事實表外來鍵，維度的自然鍵（如果自然鍵會被重新分配，發生變化，應該使用持續性超自然鍵）也同時作為事實表外來鍵。
事實表通過**鍵連線維表獲取歷史維度屬性，通過自然鍵連線維表獲取當前維度屬性
為表指定鍵的策略有兩種：
大寬表的優點與缺點？
拉鍊表的實現邏輯說一下？
就是老訂單出現了新狀態,我們先將老訂單的老狀態end_time更改為昨天的日期,封存起來
是老訂單出現了新狀態,我們直接重新開啟一條新資料用來顯示老訂單新狀態end_time為9999-12-31
(今天的增量表)再就是 full join 不上的就是新訂單end_time為9999-12-31
(昨天的拉鍊表)還有老訂單的已經閉合過的老資料
最終:將四種資料union昨天的end_time不是9999-12-31的拉鍊表來生成最新的拉鍊表!
拉鍊表資料錯誤回滾
修正拉鍊表回滾問題本質就是：其實目的就是找到歷史的快照。歷史的快照可以根據起始更新時間，那你就找endtime小於你出錯的資料就行了，出錯日期的資料就行了。重新匯入資料，將原始拉鍊表資料過濾到指定日期之前即可（本質就是過濾資料到回滾日期的前一天。）。
你剛說到資料傾斜，這個怎麼處理？ null值怎麼打散，打散的偽**或者sql使用concat，split；寬依賴和窄依賴:關聯對映關係。
發生資料傾斜的原因：
在進行shuffle 的時候，必須 將各個節點上相同的 key 拉取到某個節點上的乙個 task 來進行處理 ，比如按照 key 進行聚合或 join 等操作。此時如果某個key 對應的資料量特別大的話，就會發生資料傾斜。分割槽父子關聯對映關係：1父：n子；1子：n父。
資料傾斜的表現：
表現一：
大多數task執行都非常快，但是個別task執行相對很慢，極端情況，持續執行到99%，就是不結束(mr和hive中常見)
表現二：
多數情況下，程式是正常執行的，但是某一天突然發生了oom異常
資料傾斜解決：
1. groupby造成的傾斜：set hive.map.aggr=true #開啟區域性聚合；set hive.groupby.skewindata=true;#開啟對map的輸出結果進行打散操作。
2. count（distinct）進行去重統計優化：改寫成先分組groupby再count，利用上著的打散特性。
3. 小表join大表（1g資料儲存大小的邊界區分）：使用預設開啟的mapjoin,複製小表制定列在map階段進行join計算。從而不需要分發資料就沒有資料傾斜。
4. 傾斜的值是明確而且數量很少（比如null值）：解決方案使用case when對這些值匹配的字段key進行concat隨機數進行打散。
5.動態分治思想+對映關係:把傾斜的鍵值和不傾斜的鍵值分開處理，不傾斜的正常處理即可，傾斜的做mapjoin，然後union all結果即可。
你們主題是怎麼劃分的，舉個例子
主題：主題是在較高層次上將企業資訊系統中的資料進行綜合、歸類和分析利用的乙個抽象概念，每乙個主題基本對應乙個巨集觀的分析領域。
關於主題域： 主題域通常是聯絡較為緊密的資料主題的集合。可以根據業務的關注點，將這些資料主題劃分到不同的主題域(也說是對某個主題進行分析後確定的主題的邊界。)
關於主題域的劃分：
主題域的確定必須由終端使用者和資料倉儲的設計人員共同完成的， 而在劃分主題域時，大家的切入點不同可能會造成一些爭論、重構等的現象，考慮的點可能會是下方的某些方面：
1、按照業務或業務過程劃分：比如乙個靠銷售廣告位置的門戶**主題域可能會有廣告域，客戶域等，而廣告域可能就會有廣告的庫存，銷售分析、內部投放分析等主題；
交叉維度的解決方案？
橋接表可以捕獲多對多關係，並且由於源系統中的關係是已知的.橋接表可以解決掉維度之間的多對多關係，也解決掉的維度表的多值維度問題。
多值維度：當事實表的一行涉及到維度表的多行時就產生多值維度，同樣當維度表的一行需要獲取單一屬性的多個值時也會產生多值維度。交叉維度是多值維度的乙個特例是維度之間的多對多關係；多值維度是事實表和維度表的多對多關係。
多值維度的解決方案：
1. 扁平化多值維度，比如乙個賬戶可以三個人擁有，可以引入三個賬戶擁有人列。
2. 可以用橋接表：即中間表，維護比較麻煩，計算易出錯。
資料質量如何保證（dqc）？制定規範
全鏈路的監控
etl任務監控就是在etl過程中，哪乙個任務報錯，報錯的問題是什麼，要把日誌取出來。這個etl如果沒有執行完，結果出不來，下游有哪些任務是會受到影響。
vip任務監控：重點業務指標重點排查，保證在每天上班前，資料完整，正確地提供。
資料質量管理你們怎麼做的？
參考：資料治理這塊你有參與嗎？
資料治理本身包含很多的內容，目標，制度規範、流程、組織、工具，成熟，保護和隱私缺一不可。=》資料質量作為衡量。
任務延遲如何優化（sla）？沒做過了解
參考： 有限提高任務排程的worker並行度。
最佳服務水平協議（sla）級別資料中心戰略包括三項關鍵效能指標（kpi），用於衡量公司的投資效果。it 部門都會制定可實現的最佳服務水平協議（sla）級別、最低成本以及最高資源利用率等指標。
- 服務質量（qos）。針對每項業務功能對於正常，執行時間、平均修復時間（mttr）和成本的敏感度，我們在 sla 方面使用了分層的方法。
- 成本效益（每個服務部門的成本）。根據每項業務功能所需的容量進行構建。
- 有效地利用資產和容量。通過資產的實際輸出而不是資產的分配方式進行衡量，通過評估作業或儲存的實際執行狀況衡量利用率是否高效。
join的時候依照哪乙個關鍵字？對欄位有沒有限制？
元資料管理怎麼做的？沒做過，了解
元資料的分類——技術元資料、業務元資料、管理元資料、
過程:元資料範圍，接入，標準，維護，查詢分析報告，管理平台。
分析：血緣分析，影響分析，冷熱分析，關聯分析，資產地圖分析。
hive的四種排序
會有小檔案：目前沒有系統級的小檔案處理方案，都需要自己編碼實現。
2020數倉面試題
問答題 1.了解到的從資料庫抽取資料到數倉的軟體都有那些，目前大資料平台大多不支援updata操作，針對每日增量資料與歷史資料合併，常用的都有那些方法。解題關鍵點 full outer join insert overwrite 每天保留乙份全量快照 2.有沒有遇到過資料質量的問題，一般都是那些環節...
面試題 數倉專案技術如何選型？
要提供兩套方案，紅色的一套，黑色的一套，提供對比 優先選擇紅色的那一套，因為比較通用，而且熟悉 flume解決日誌的採集，kafka解決訊息的分發和消峰，sqoop用於hdfs和關係型資料庫進行資料的傳遞 mysql主要用於查詢，它用於儲存與前端程序互動比較頻繁的資料，因為查詢要速度比較塊，hdfs...
大資料數倉面試流程和重點面試題
一 自我介紹 看簡歷 表達能力 2 3分鐘左右 學歷 參加工作 愛好 特長 二 專案 背三 資料倉儲 1 以數倉為中心 不要直接上來說ods dwd dws ads 2 正規化建模與維度建模的方式區別 3 主題劃分是否合適 4 事實表與維度表的介紹 有多少張，哪些緩解進行度量 5 總結矩陣 6 變化...