投產過程常常受到重視。投產時間緊迫不應該也不允許產生錯誤。如果產生故障就會受到各方的巨大壓力。這種情況下必須重視因低階錯誤或疏忽導致的生產故障。
情況彙總
1，投產過程受到雲平台不穩定、設定引數不明確等因素影響，而拖延了投產時間、甚至中斷，記憶體溢位並且保錯等。
2，由於負責資料處理的同事的疏忽，沒有進行生產主鍵的邏輯進行校驗，導致es的id沒有按原來的約定生成。在指令碼跑了很久時發現，導致第一次修數失敗，所有資料被廢棄。
3，因負責標準化對映規則的同事沒有及時更新對映規則，導致批量同步的資料轉換出錯。由於標準化規則沒按t-1的規律下發，導致程式無法讀取到t-1資料夾。直接導致程式報錯。
4，因第三方網路不通，導致外發報錯，批量外發報錯。這個原因耽擱了3天。
5，es其中乙個節點例項假死，導致es查詢超時。
6，mysql因binlog而導致主從集群失效
1， 微服務基礎應用部署於虛擬機器。因為雲平台不穩定，把微服務基礎部件遷出雲平台和docker，在虛擬機器上部署。基礎應用有api-gateway，註冊中心、配置服務。
2， 開發、測試環境與生產環境盡可能保持一致。在開發環境上建設與生產環境一致的資料庫集群以及資料下發機制。其中乙個是mysql主從同步集群，另乙個是標準化表和有效期值的下發方式和週期。這次的投產就是因為標準化表沒有同步進入redis和有效期表t-1的更新方式導致資料不對，而導致修數。
3， 進行完善檢查與測試。具體而言，首先針對各個依賴環境做檢查，例如標準化資料是否已經進入了redis，有效期值是否已經下發，是否按約定的t-1下發。例如與第三方介面的網聯鏈路是否已經接通。盡量做到無死角。
設計之初就應該全面思考測試場景。功能測試、邊界測試、壓力測試都編寫用例並執行。
4， 維護依賴檢查列表。對外部資料應用的整個鏈路抽象出一張依賴圖。針對各個依賴環節所需要的技術檢查點，逐一說明和記錄。用於生產過程逐一檢查。以往雖然做了技術檢查，但因為沒有列表和架構圖，會有漏掉的情況。以後在開發過程中對架構的修正，如果存在依賴的地方，都維護到架構圖和技術檢查點列表中。
5， 維護問題解決方法列表。由於經常性、突發性地發生故障，開發者需要去生產環境差錯，導致開發者情緒不穩，同時也延誤開發的本職工作。如果能有專人專職，根據問題解決方法列表去查錯，會更大限度的提高協調效率。
6， 為技術選型提供更高的自由度，為非業務功能提供更多時間，不斷改進架構。例如，如果覺得es在某些方面不合適，在已經合理科學的論證過，是否可以選擇其他的資料儲存。
檢查點列表
犯錯誤不可怕，但如果犯的是低階錯誤，難道不覺得惋惜嗎？
1，檢查徵信系統已經下發了有效期表。
2，檢查有效期的值是正確維護的。曾因有效期值錯誤而使儲存的資料有效期錯誤，變成髒資料。直接導致對es修數。
3，檢查標準化對映是最新規則。曾因為標準化規則變化但沒有維護，導致儲存的資料標準化操作錯誤。直接導致對es修數。
4，檢查標準化規則是否同步到redis。曾因為標準化對映沒有同步到redis，導致儲存的資料未進行標準化操作。直接導致對es修數。
5，檢查行內網聯鏈路是否聯通。
6，檢查行外網聯鏈路是否聯通。因為第三方鏈路不通，導致整個鏈路查詢異常，直接引起整個流程都報錯。
7，檢查雲平台是否一直穩定執行。
8，檢查卡夫卡是否正常運作。
9，檢查mysql。曾因主從同步集群刪除了一大批歷史資料，而導致binlog一直在讀寫，導致io執行緒和sql執行緒滿負荷，從而主從失效。
10，檢查es例項節點的健康度。曾因es某乙個實力假死，導致查詢一直報錯：es查詢超時。
資料倉儲與企業應用整合（二）
三 cif的案例 sapbw 主要特點是erp 商提供了整個體系結構，這就節省了大量的工作，並且降低了設計和開發的成本，將業務封裝在bw中，降低了長期維護的難度。erp的資料資源是非常豐富和寶貴的，應該是 資料倉儲的重要 sap的bw就是將 資料倉儲納入了erp應用。1.sapbw概述 a.sapb...
資料整合在ODS專案的應用模式
ods the operational data store 也叫運營資料儲存，是用於支援企業日常的全域性應用的資料集合，它是介於db和dw 之間的一種資料儲存技術。從專家給出的定義上來講，它是乙個面向主題的 整合的 當前的並且是可 揮發 的資料集合，它反映了在某乙個時間切片瞬間，經營分析系統和外圍...
資料倉儲與企業應用整合 一
主要內容 一.從系統和整體的角度來考慮資料倉儲的開發 二.cif的概念和內容 三 cif 的案例 sap bw 四 資料倉儲與企業應用整合 五 小結 references 摘要 本文的主要內容在於介紹企業資訊工廠並 在建立資料倉儲和企業應用時應考慮的系統性和整體性。因此本文主要針資料倉儲的最新發展，...