問題： ODS有的公司說幾乎不處理，有的說這一層要做第一次數據清洗，你怎么看？

討論一： 我感覺基本的監控要做，然后字段類型，命名統一可以做，ip轉地址也可以做。復雜的 不太容易做，數據源的接入不一定都可控。

討論二： 看數據的規整性吧。有的公司業務方數據很規整。ODS層只用做簡單的砍字段即可，有的業務數據不規整比如埋點類的那么不做清洗就肯定不行了。有公司是從業務庫直接到ODS，那么需要做備份， 有的是從業務庫到匯總庫再到ODS。那么匯總庫就可以看作是備份了。

討論三： 個人覺得ODS層的數據還是需要清洗并存入到數據倉庫比較合適。如果不清洗，是ETL任務的計算資源和計算時間的浪費。

除非是有特殊需要，規定要原汁原味的“原始數據”。

補充 這個問題，從本質上來看，其實是和分層的設計以及公司的業務場景相關的。 先拋開公司的業務場景來看ODS的設計，我們其實是希望ODS的數據盡量“原汁原味”，但又相對干凈。

那么，這個尺度或者說標準怎么來把握？簡單來看，我們會讓ODS層的數據內容和粒度與原始數據一致，然后我們會做表命名統一、字段命名統一、數據落地監控等內容。

然后對于數據清洗，居士個人建議是盡量少做清洗，如果在這一層做清洗，建議只在幾種情況下做清洗： 

1. 簡單的數據標準化，比如表和字段命名

2. 默認值填充，比如性別為空的都補0

3. 清洗規則十分明確，比如說說字段拆解： 接收到的json數據拆成多個明確字段 其余情況下不是不能做清洗，而是說盡量少做清洗，因為一旦對原始數據稍作破壞，以后追查數據的成本會十分巨大。

當我們明確ODS的職責后，再來看不同公司的ODS設計。如果說數據源很干凈，那么直接拿來就可以，基本不用處理。如果說數據源很混亂，而且清洗的規則十分明確，不會出現返工的情況，那么就可以在入ODS之前做一部分的清洗。