廣告-offline-warehouse-01-double_happy

1.MySQL:
	1.不同庫下面的表 進行join 是 很難的  很苛刻 
爲什麼呢？
	1.sql語法是很簡單 但是
		要保證：
			1.數據庫A 數據庫B
				1.字符集跟排序規則，需要保持一致
            2.字段的字符集排序規則 要一致
注意：
	所以條件很苛刻
	參考：
	https://blog.csdn.net/AS761379193/article/details/89298484

第一個階段：	

2.那麼怎麼更好的解決這個問題？
	1. 把數據入到	 Hive

3.注意：
	問題：
		1.沒有數倉設計的話 會導致
			1.重複開發 取數
		

所以：建立數倉 ->數倉架構設計很重要
	1.表名規範
	2.分層設計
	3.搭建各個主題域 的中間層

第二個階段：
 問題：
 	1.當數據量上來之後：
 		1.數據抽取 十分耗時！！
 		     考慮：
 		     	1.最優數據抽取
 		     	2.存儲策略
 	2.ETL任務腳本  在服務器上更新的問題 
 		就是pull 下來 更新了 忘記push 那麼第二天的任務就出問題了
 		（這個問題 jekins可以+自己細心點）
 	3.調度問題：
 		1.依賴任務 我們現在是 使用 dolphinscheduler 賊好用

第三個階段：
	問題：
		1.業務不斷的發展 業務系統會變化   涉及到改造
		   可能改造的是 中間層 那麼所有的表都可能都要變
		   只要跟中間層有關係的 都要變  你得一個一個搜索
				 解決：. 數據血緣 ：
				       有這個 改造就很輕鬆了 
		 
		 2.業務方會質疑你數據不準：
		 		1.數據口徑不統一
		 		2.sql 數據取錯了
		 		3.數據抽取掛了
		 		4.任務跑的慢  sql寫的不規範
        	解決：
        		1.指標中心   (口徑統一 、業務計算邏輯統一)
        		2.數據質量中心(DQC)
        		     1.監控數據條數    全量/增量  有一個範圍
        		     2.對應指標 

       需求：
       	 1.多維分析的需求 
       	 	  這個就是 grouping sets  語法
       	 	  Hive來做多維分析 可以做 但是：
       	 	  	維度太多了 ！！！
      		解決：
      			kylin +BI系統
注意：   
      1. 數據血緣 +指標中心+數倉表信息(行數、數據量、字段) =>元數據中心
      2.數倉表信息(行數、數據量、字段)：就是數據字典
        注意：
        	1.數據血緣  就是  上下游表 改動時候用到
        	2.其他兩個是非常有用的

！！！
	1.指標中心
	2.數據字典 
是爲了BI業務多起來之後 新人加入團隊 非常關鍵的一個建設！

注意：
	難道你要新人 去服務器上 desc 表 一個一個字段查？指標是通過問 ！來做嗎？？


但是！！：
	大部分公司都是處於 這個階段

第四階段：
    問題：
    	1.集羣穩定性
    	     監控集羣 關鍵數據  做一個報表 =》圖表展示
    	     eg：
    	     	離線任務平均運行時長