首先來回顧一下我們在《02_數倉分層問題優化》優化後的數倉分層結構：
其實優化後，就是將數倉分成了3大層，4小層。
3大層就是ods，cdm（dw+dm），ads；
4小層就是ods，dw，dm，ads
實際上dw和dm都是所有業務可以復用的資料，區別只是dw是復用的明細資料，dm是復用的彙總資料，因此可以理解將dw和dm從邏輯上統稱為cdm層，表示公共層。
現在，我們來聊聊ods層。
雖然在上面的圖中，大家看到4小層都是放在hive裡面的，但其實一開始我們的ods層是放在mysql中的。
然後，我們是通過阿里開源的otter，將各個mysql業務庫的資料，同步到ods層的。
但是阿里開源的otter在使用的時候，發現是各種問題，經常就會同步錯誤。雖然說是近實時，但阿里的開源的otter版本不算穩定，因此我們重構一下ods層。
除了同步的問題，當然上面的乙個mysql資料庫來容納所有業務mysql的資料也存在別的問題。
比如說容量問題，乙個mysql資料庫來充當ods層，儲存了所有業務資料庫的資料。你要知道，這個ods層的mysql資料庫是部署在某台機器上的，如果超出了這台機器的磁碟空間呢？
考慮到這個容量問題，我們打算將ods做在hive中。問題就是，如何將mysql業務庫的資料接入到hive呢？這裡其實就可以用到阿里的canal。
之所以用canal而不是用sqoop是因為，sqoop存在一些問題。
比如，如果用sqoop，需要每天凌晨連線業務庫的mysql去抽取增量資料。這個過程，其實多少會影響業務系統在凌晨的效能，因為sqoop抽數會占用業務庫mysql的資源的。
有人說，業務庫搞個mysql唯讀庫不就好了嗎？問題是，比如訂單中心，可能本來就只有1個讀寫庫，1個唯讀庫，2個庫都是用來對訂單中心提供讀取服務的。但是你的sqoop如果連線的是訂單中心的那乙個唯讀庫，肯定還是會導致訂單中心在凌晨的讀效能會下降。
除非說，你要每個業務系統單獨給你的sqoop開乙個唯讀庫？訂單中心開乙個，財務中心開乙個，物流中心開乙個，你覺得可能嗎？
而使用canal的方案，業務系統不需要做修改，只要將他們的讀寫庫的位址給我們。canal負責去採集binlog，這個採集binlog的過程對業務系統幾乎是沒有影響的，因為業務庫本來的sql就是會生成binlog的。
此外，canal的方案還可以接脫機數倉的同時，接入實時流，因為kafka裡面已經有近實時的binlog資料了。
消費者這裡，你可以部署多台機器來消費，保證是高可用的。
基於引入了canal+kafka的架構，替換掉了原來的otter，增強了ods層的可用性和穩定性。
Matlab優化問題05 fmincon
說明 fmincon 一般用來求解多元有約束非線性最優化問題，其中約束可以包含等式約束和非線性約束。其全呼叫格式為 x,fval,exitflag,output,lambda,grad,hessian fmincon fun,x0,a,b,aeq,beq,lb,ub,nonlcon 例1 求側面積為...
深度學習入門課程筆記05 最優化問題
通過對之前課程的學習，我們已經能夠對於乙個輸入資料得出它的最終的乙個loss值，那麼下面就該咱們如何去找到乙個最優的引數矩陣，使得最終的loss值達到乙個最小的範圍。這就引入了咱們的最優化問題。下面咱們通過幾種解決方案來詳細討論如何處理這個最優化的問題 首先咱們就算不經過大腦思考也能得出一種方法，我...
kettle資料同步的優化
在進行將oracle的資料同步到mysql的時候，由於資料量大導致使用kettle的全量同步比較慢，所以需要對這一過程進行優化。1 從源頭的表輸入入手 通過設定表輸入的多執行緒資料抽取，可提公升資料的輸入速度。但是如果只是在kettle設定表輸入的多執行緒數量的話，會導致資料重複。比如 select...