問題： ODS 有的公司說幾乎不處理，有的說這一層要作第一次數據清洗，你們怎麼看？json
回答一： 我感受基本的監控要作，而後字段類型，命名統一能夠作，ip轉地址也能夠作。複雜的 不太容易作，數據源的接入不必定均可控。設計
回答二： 看數據的規整性吧。有的公司業務方數據很規整。ODS層只用作簡單的砍字段便可，有的業務數據不規整好比埋點類的那麼不作清洗就確定不行了。有公司是從業務庫直接到ODS，那麼須要作備份， 有的是從業務庫到彙總庫再到ODS。那麼彙總庫就能夠看做是備份了。ip
回答三： 我的以爲ODS層的數據仍是須要清洗並存入到數據倉庫比較合適。若是不清洗，是ETL任務的計算資源和計算時間的浪費。除非是有特殊須要，規定要原汁原味的「原始數據」。資源
這個問題，從本質上來看，實際上是和分層的設計以及公司的業務場景相關的。監控
先拋開公司的業務場景來看ODS的設計，咱們實際上是但願ODS的數據儘可能「原汁原味」，但又相對乾淨。那麼，這個尺度或者說標準怎麼來把握？簡單來看，咱們會讓ODS層的數據內容和粒度與原始數據一致，而後咱們會作表命名統1、字段命名統1、數據落地監控等內容。命名
而後對於數據清洗，居士我的建議是儘可能少作清洗，若是在這一層作清洗，建議只在幾種狀況下作清洗：數據
其他狀況下不是不能作清洗，而是說盡可能少作清洗，由於一旦對原始數據稍做破壞，之後追查數據的成本會十分巨大。時間
當咱們明確ODS的職責後，再來看不一樣公司的ODS設計。若是說數據源很乾淨，那麼直接拿來就能夠，基本不用處理。若是說數據源很混亂，並且清洗的規則十分明確，不會出現返工的狀況，那麼就能夠在入ODS以前作一部分的清洗。備份
連接：https://www.jianshu.com/p/0a5bc1a4d60c
來源：簡書
co