etl設計的一點思考
前些天寫了篇文章叫做什麼是好的**？？這是對j2ee開發的一點思考。對於etl開發來講，其與常規的j2ee系統開發有所不同，在物件導向設計的方法大行其道的現在，對於操作關係型資料庫還是採用過程化的思想，但也有通用的地方。
1、選擇sql還是etl工具
etl工具都有join group by操作，複雜sql完成的事情etl工具很多都能完成，所以存在乙個sql處理與etl工具處理的矛盾問題。到底是在etl工具端處理還是資料庫sql、處理。我想從**的可讀性以及操作的簡便性考慮，如果sql不是很複雜，用sql可以清楚表達你的邏輯，優先考慮sql。畢竟一般跑批在晚上，充分利用資料庫的效能，etl工具承擔排程的功能。
2、etl系統分層設計
一般來講都有資料來源層、中間處理層、前台展示層或者說目標層。
對於資料來源層，我不希望對於資料來源表的名稱在etl過程中到處都是，一般外部系統的表只在etl資料來源層出現，其他各層不不要依賴外部系統表。盡可能地將與外界通訊減少到最少。這也是符合迪公尺特法則的。而系統的分層也從一定程度上進行了處理過程間的相對解耦，每個層次的變化不影響或者很少影響其他層次。
3、粒度問題
中間層往往需要不止乙個處理過程，那麼在處理過程中如何劃分呢？？我想還是要粒度合適。怎麼叫合適？？每個處理不要太大，可讀性好一點。第二處理過程劃分為幾個步驟，那麼需要考慮哪些步驟對於查錯是方便的，必備的，那麼就需要分離這個過程，這是需要從業務上斟酌的。
4、日誌記錄問題
這是個基本問題，執行在哪一步，就應該記錄哪一步的日誌，便於查詢錯誤
5、資料清洗
跑批過程，經常碰到跑不下去的問題。究其原因，跑不下去一定是丟擲異常，是資料約束導致。是不是將資料清洗固定作為etl過程的乙個任務階段。我們etl系統的資料約束應該有哪些，資料的入口處應該攔截哪些資料，不符合規格的髒資料作何處理。
6、單錶的資料量問題
資料量很大的表應該採用橫切縱切的方法。那麼多大的資料量應該切分了呢？？對於實時查詢，即使建立索引太大的資料量也是個壓力，所以應有個標準，比如上千萬的量是不是考慮切分，或者構建為分割槽表。
元件化程式設計的一點思考
最近學了vue和springcloud 兩者乙個為目前三足之一的前端框架，乙個是後端主流的微服務治理的框架。看似沒有什麼共同點，其實從系統架構的角度思考，還是有一些共同之處的。vue是將頁面上的重複利用的一些div結構元件化，單獨設計成乙個元件，以便復用。這樣一來，結構和邏輯就相當清晰了，而且減少了...
關於程式設計思想的一點思考
計算機發展了幾十年了，其中的技術層出不窮，令人眼花繚亂，而且每種技術還在不斷更新迭代中，讓人心煩。這篇文章是關於 我在這飛速發展中探索的思考。一 計算機硬體 底層硬體，其工作原理是支撐龐大系統軟體的基礎，底層基礎決定上層建築。電平的高和低，構成0和1 對0和1順序排列規定，實現數的二進位制表示 規定...
遞迴的一點思考
廢話不說，直接上 searchtree delete int x,searchtree t else if t left null 沒有兒子的情況也包含了，因為t right 為null else else if x t element t right delete x,t right else t...