1、乙個版本開發過程，可能瑣碎的需求比較多，一定要記下來，否則後面可能會忘記或遺漏，不要太自信自己的記憶力
2、a left join b on 1=1 ,一般用來把b表的字段加到a表的每一行上，比如b表計算出當天是否是工作日，這是乙個常量，和a表沒有關係，所以就直接加到a表的每一行
3、資料包表開發是件很嚴謹的事，有的報表是全國各機構的人都在看的，一旦資料準確性出現問題，會引來很多人的質問，一定要重視
4、如果a和b是相同的表結構，只是名稱不同，則兩張表在關聯取數的時候一定要寫出具體的欄位名並加表名，如果只是單純的 select a.* ,b.* ，查出來的資料是混亂的
5、一般來說，sqoop任務是不可以並行跑的，因為在導數的時候會先把從hive查出來的資料放到乙個路徑下，如果多個任務則時跑則會把多份資料放到同乙個路徑，導致報錯，可以在平台配置，每個任務的資料放到不同的路徑
6、開發時不能只考慮日常版本，還要考慮到回刷歷史資料的場景，比如計算年累計指標，除了限制日期年，還要限制日期<=當前日期，否則回刷歷史時全有問題
7、開發過程中一定要多想一步，如果發現某一處有問題，那可能問題不止這一處，排查下其他地方有沒有相同的問題，而不是等到其他地方的問題冒出來後再解決
8、別人給出來的邏輯，自己一定要過下腦子想下合不合理，不要偷懶，自己是開發，很多時候需求分析時沒有考慮到具體的細節，但作為開發人員，在實操過程中一定要判斷可行性，如果不考慮合理性，出問題了還是得自己改
9、在負責乙個模組的時候，首先把模組所涉及的任務和指令碼名列出來，梳理下資料處理流程，在改動一處邏輯時，根據任務名和資料處理流程思考下是否還要改動其他相關指令碼，正所謂牽一髮而動全身，很多時候只改一處邏輯或乙個指令碼是不行的，比如手工數的改動，新增了乙個字段，修改了關聯邏輯，則根據指令碼名和資料處理流程來說，要改表結構、hql指令碼、用到這張表的hql、初始化任務hql、下游表hql等，一定要顧全大局
10、給業務驗數的時候必須保證給出的資料和生產上線後的資料是一致的，如果生產上線後的資料和給出的不一致，業務要罵街的
11、不要總是一次又一次的出錯，尤其是給業務驗數這種事，如果經常出錯會導致領導、同事對你的不信任，明明自己累得要死，但是做出來的東西也不行
資料準確性和模型準確性
一 遇到了什麼問題 昨天在看 文獻，關於 中國汽車保有量的。文獻中提到了乙個資料 就是國家統計局每年都會 現在已經暫停 調查不同收入等級 八個等級 收入 人口 汽車擁有量的情況。通過這些資料進行簡單的計算就能得到不同收入等級群體的千人保有量情況。這個資料可以估算不同收入與千人保有量之間的函式關係 利...
大資料的監控和資料準確性保證
我們目前的資料流程是 資料來源資料 經過挖掘處理轉換等操作生成中間資料，入寬表 然後 提取寬表資料 入pdc，資料停留的地方有 資料來源 中間資料 寬表 pdc。目前我們的監控措施如下 1 資料來源 中間資料 寬表 每個資料流有監控，監控的是每個資料的總量 2 每天執行監控 監控 寬表每個資料的變化...
經驗總結 資料預處理經驗總結1
1.對於特徵較多的df，進行資料預處理時需要對每個特徵變數進行相關處理，為了避免混亂，可以df.info 後將輸出複製到sublime，然後在sublime中針對每個特徵變數進行處理方式標註 非python 只是為了展示在sublime中的效果 action type 30697 non null ...