到後期每天同步資料有15g左右，由於生產的機子效能差，導致同步巨慢，影響了平台日常使用，因此做了優化。
ps：公司初期業務為主，資料量也較少，因此機器投入相對少，沒有備用機器同時運作，oracle效能擴充套件又有難度，一直定時刪資料才確保機器夠空間儲存，更不要說日常大量的io請求。
說明：在實際工作情況中，由於企業發展階段的不同，往往業務先行，技術棧方面更新不到位，特別是目前所在的企業是與傳統金融機構合作的模式，不同於純網際網路公司，更多在確保資料安全，資料能正常傳輸前提下做搭建。
資料環境：
生產：oracle 11g
分析平台：星環 tdh v5.2 （6節點 1t記憶體）
資料流**
ps：分析平台由風控部門因分析需求推動建立，由於技術上人員維護的考慮，故採購現有方案提供商（星環/華為），
但也因此導致了後續拓展限制，各模組都是商業軟體需單獨採購，後續資料排程質量監控等需求由於費用問題，只能用盡方式實現。
優化點：
1、生產環境機器效能底下，在部分時間段有大量io請求的階段，會導致抽不動數，因此加入中間庫，每小時同步生產的資料，該庫僅保留兩天資料，同步的同時刪除資料，使用儲存過程實現。
2、對內表全調整為orc表儲存，資料層由於沒有會有資料插入等動作，建立orc事務表，其他分析層表，使用orc普通表。
3、引入視覺化資料質量監控，由於涉及堡壘機環境，本地無法直接檢視，使用了麻煩的方式：
4、定時任務優化，資料分析人員常用計算，常用指標做開發整合，建立定時任務非工作時間執行，減輕平台記憶體占用，使用crontab實現。
ps：商業化平台，各模組都單獨賣，oozie/azkaban無法自己安裝，任務排程只能用crontab實現（這你敢信？實際情況就這麼慘）。
YNGAT JZ資料治理架構
說明 1.flume採用的三個client實時監控三個伺服器的磁碟路徑，七個server提高負載均衡和拉取資料的能力，採用load balance機制將資料sink到kafka，其中source zip方式flume官方不支援，需要開發自定義source 2.對於歷史資料的備份從源頭開始備份，當fl...
資料治理 VS 公司治理 IT治理 數倉治理
如題，今天要聊得這個話題，包含了四個 治理 看完這張圖你有什麼想法，這張圖說明了什麼？它是在描述公司治理 it治理 數倉治理和資料治理的關係嗎？如果這張圖是在描述四個 治理 之間的層次結構，那你認為哪乙個結構是正確的呢？如果您是企業的高管，您會選擇哪個結構，來實施 治理 呢？01 資料治理 vs 公...
hive架構探索
hive是一款資料倉儲軟體，幫助使用者使用sql來管理 讀寫在分布式儲存上的大型資料集。使用者可以通過cli jbdc driver等方式來連線hive。直接編寫mapreduce程式來操作hadoop上的資料集需要編寫複雜的 而使用hive，只需要簡單的sql語句，如select from tes...