讀資料質量管理：資料可靠性與資料質量問題解決之道04收集與清洗

躺柒發表於2024-11-15

1. 收集資料

1.1. 資料收集和清洗是生產管道中的第一步

  • 1.1.1. 資料轉換和測試則在生產管道中解決資料質量問題

1.2. 在收集資料時，管道的任何地方可能都沒有入口點重要，因為入口點是任何資料管道中最上游的位置

1.3. 入口點定義為來自外部世界的資料進入資料管道的初始接觸點

1.4. 在入口點的資料是最原始的

  • 1.4.1. 包含了其所建模的外部世界的所有典型噪聲和不規則性

  • 1.4.2. 資料可能來自應用程式或服務日誌、點選流源或實時感測器

  • 1.4.3. 資料可能是高度異構的

  • 1.4.3.1. 結構化的

  • 1.4.3.2. 非結構化的

  • 1.4.3.3. 會導致資料未來在管道中出現問題

2. 應用程式日誌資料

2.1. 應用程式日誌是指對某些軟體應用程式進行操作時所產生的資料

  • 2.1.1. 帶有時間戳的事件描述

  • 2.1.2. 可能會發現應用軟體產生的錯誤或警告訊息

  • 2.1.3. 應用程式日誌中的內容包括什麼是由該應用程式的開發人員來決定的

2.2. 應用程式可以是面向客戶的或內部的，而操作可以是使用者發起的，也可以是程式設計式自動產生的

2.3. 要素

  • 2.3.1. 結構

  • 2.3.1.1. 美國資訊交換標準碼(American

Standard Code for Information Interchange，ASCII)

  • 2.3.1.2. 二進位制格式

  • 2.3.1.3. 簡單的可序列化文字

  • 2.3.2. 時間戳

  • 2.3.2.1. 大多數應用程式日誌文字是離散事件，帶有描述，由\n字元分隔

  • 2.3.2.2. 時間戳應該是高度標準化的，通常採用ISO標準格式(yyyy-mm-ddThh:mm:ss[.mmm])或其他類似的格式

  • 2.3.3. 日誌級別

  • 2.3.3.1. 會使用級別來大致編碼每個事件的日誌型別

  • 2.3.3.2. 常用的日誌級別

>  2.3.3.2.1.             INFO（資訊）​：該日誌包含的是純粹的描述性資訊

>  2.3.3.2.2.             WARN（警告）​：該日誌是應用程式警告，但不是失敗錯誤

>  2.3.3.2.3.             ERROR（錯誤）​：該日誌代表應用程式中的程式設計故障

  • 2.3.4. 目的

  • 2.3.4.1. 應用程式日誌並不會被隨意收集

  • 2.3.4.2. 應當確定日誌在某些情況下是有用的才會進行推送

  • 2.3.5. 診斷

  • 2.3.5.1. 出於診斷目的而收集日誌資料，那麼問題的答案或許能在非常具體的WARN或ERROR級別的日誌中找到

>  2.3.5.1.1.             涉及診斷標準，並透過智慧收集和解析日誌來回答

  • 2.3.5.2. 收集的絕大多數內容可能與你現在遇到的特定問題無關

  • 2.3.6. 審計

  • 2.3.6.1. 審計日誌記錄就是記錄應用程式中的事件歷史

  • 2.3.6.2. 許多INFO級別的日誌對於審計來說很有用

  • 2.3.6.3. 審計的力量通常來自應用程式會話的大量聚合

3. API響應

3.1. 你自己的應用程式不可能完成所有事情

  • 3.1.1. 這就是為什麼我們要將某些功能分發給不同的應用程式

3.2. 執行此操作的標準方法是使用應用程式程式設計介面(Application Programming Interface，API)

3.3. API是兩個程式之間的中介，它們需要特定格式的請求才會提供響應

  • 3.3.1. 這些響應只是半結構化資料

3.4. 除了應用程式日誌之外，你還可以儲存從API端點提取的資料

3.5. 要素

  • 3.5.1. 結構

  • 3.5.1.1. API響應物件是可以序列化的物件

>  3.5.1.1.1.             經常看到的一種物件格式（尤其是在Web API中）是JSON

>  3.5.1.1.2.             JSON物件非常靈活，但它們會在一些重要方面受到結構的約束

>  3.5.1.1.3.             其他API響應型別具有類似的格式

>  3.5.1.1.4.             HTTP響應規範，如HTTP/1.1，它也可能在HTTP請求或響應正文中包含JSON或XML

  • 3.5.2. 響應程式碼

  • 3.5.2.1. 最常接觸到的是HTTP狀態碼(200 OK、404 Not Found、500Internal Server Error)

  • 3.5.2.2. HTTP 500響應的比率是伺服器是否出現中斷的關鍵指標

  • 3.5.2.3. 其他傳輸協議的SOAP

API

  • 3.5.3. 目的

  • 3.5.3.1. API用例的數量是非常龐大的，因此我們無法預測一個人可能遇到的所有用例

  • 3.5.3.2. 如果我們對伺服器錯誤率感興趣的話，應該從根本上關心響應碼

  • 3.5.3.3. 如果我們只是透過API從外部伺服器提取資料，則響應碼可能無關緊要，因為我們只想要資料本身

  • 3.5.3.4. 用例會影響API響應物件中的哪些資訊是有用的，而傳輸的某些資訊在特定環境中可能是無用的

4. 感測器資料

4.1. 資料來自感測器

  • 4.1.1. 物聯網裝置

  • 4.1.2. 研究裝置

4.2. 感測器不一定是應用程式，因為它們的內部邏輯可能非常簡單

  • 4.2.1. 溫度感測器只是透過一些硬體來記錄溫度並將其傳送出去用於收集

4.3. 重要事項

  • 4.3.1. 噪聲

  • 4.3.1.1. 從現實世界感測器中收集到的資料可能非常嘈雜，這不一定是收集階段需要關注的事情

  • 4.3.1.2. 強調了處理感測器時吞吐量的重要性

  • 4.3.1.3. 下游處理將對感測器資料進行大量異常值去除、平滑和其他轉換，因此穩定一致的資料流幾乎總是必不可少的

  • 4.3.2. 故障模式

  • 4.3.2.1. 感測器不像應用程式那樣智慧

>  4.3.2.1.1.             可能不會在出現問題時通知你

>  4.3.2.1.2.             損壞的溫度感測器不會傳送“錯誤：裝置離線”這樣的資訊

  >   4.3.2.1.2.1.              可能會開始傳送瘋狂的溫度值

  >   4.3.2.1.2.2.              根本什麼也不傳送
  • 4.3.2.2. 處理感測器資料比處理應用程式資料更具挑戰性
>  4.3.2.2.1.             不能像依賴應用程式一樣依賴感測器

>  4.3.2.2.2.             可能需要用更聰明的方式檢查接收到的資料數量或批資料之間的時間差

  • 4.3.3. 目的

  • 4.3.3.1. 感測器資料被用於許多下游任務

>  4.3.3.1.1.             被用於機器學習系統

  >   4.3.3.1.1.1.              收集的資料量可能會是一個重要的影響因素

  >   4.3.3.1.1.2.              最好的機器學習系統通常會消耗最大的資料集並與其擬合

  >   4.3.3.1.1.3.              用於機器學習的感測器資料的吞吐量非常重要

5. 清洗資料

5.1. 實現高資料質量的最大障礙之一就是資料清洗

  • 5.1.1. 從其他可用的資料集中刪除不準確或不具代表性的資料

  • 5.1.2. 根據資料型別和資料處理狀態以及資料產品開發的不同，資料清洗也有多種形式

5.2. 從感測器可知，入口點的資料不太可能是乾淨的

  • 5.2.1. 你的資料只是從混亂的外部世界中獲得的

  • 5.2.2. 其中難免會有遺漏、錯誤資訊、極端值和不相容的格式，但透過正確的資料清洗方法，這些問題都能被輕鬆避免

5.3. 操作

  • 5.3.1. 異常值去除

  • 5.3.1.1. 這個世界很嘈雜，所以你的資料也會很嘈雜

  • 5.3.1.2. 太過嘈雜的資料通常會導致機器學習管道失效或者讓業務儀表板看起來非常不準確

  • 5.3.1.3. 儘早從資料中識別並刪除異常值

  • 5.3.1.4. 如果你的資料集很大，請特別注意檢測過程的時間複雜度

  • 5.3.1.5. 標準分數等統計技術

  • 5.3.1.6. 更新潮的演算法技術

>  5.3.1.6.1.             孤立森林

  • 5.3.2. 評估資料集特徵

  • 5.3.2.1. 有時資料的整個部分都與下游任務無關，那麼你應該把它們清洗出去

  • 5.3.2.2. 雲端儲存的成本正在下降，但儲存無意義的資料不僅是一個儲存問題，其他工程師也可能對為什麼會存在某個欄位而感到困惑

  • 5.3.2.3. 更多的特徵意味著需要更多的文件或更多的領域知識來理解你的系統

>  5.3.2.3.1.             這兩者都會讓你的分析複雜化，並影響資料質量

  • 5.3.2.4. 要認真思考資料集的哪些特徵才是解決問題所必需的

  • 5.3.3. 資料歸一化

  • 5.3.3.1. 有些資料點可以單獨檢查，這沒有問題

  • 5.3.3.2. 其他資料在與相同型別的資料進行比較時才是最有意義的

  • 5.3.3.3. 在清洗或轉換步驟期間對資料進行歸一化通常可以幫助到你和你的機器學習系統

  • 5.3.3.4. 歸一化常用的選擇

>  5.3.3.4.1.             L1範數（曼哈頓距離）

>  5.3.3.4.2.             L2範數

>  5.3.3.4.3.             去均值化

>  5.3.3.4.4.             單位方差

>  5.3.3.4.5.             最佳選擇將取決於資料的用例

  • 5.3.4. 資料重建/資料重構

  • 5.3.4.1. 你收集到的資料中的某些欄位會丟失

>  5.3.4.1.1.             遺漏是可以的，但有時你可能需要所有欄位都具有與它們相關聯的值

>  5.3.4.1.2.             會發生在容易出錯的API呼叫或感測器可能離線等情況下

  • 5.3.4.2. 插值法

  • 5.3.4.3. 外推法

  • 5.3.4.4. 對相似資料進行分類/標記

  • 5.3.4.5. 來填補缺失值，即便資料伴隨一點噪聲也無妨

  • 5.3.5. 時區轉換

  • 5.3.5.1. 將時區轉換視為一種歸一化

  • 5.3.5.2. 這一步對於許多資料清洗任務來說都非常重要，所以時區轉換值得單獨一提

  • 5.3.5.3. 應用程式使用者或感測器可能遍佈全球，這意味著它們將記錄不同的本地時間戳

  • 5.3.5.4. 只有在某些相同的標準下，才能將時間戳相互比較

  • 5.3.5.5. 協調世界時(Coordinated

Universal Time，UTC)

>  5.3.5.5.1.             UTC不是時區，而是時間標準

>  5.3.5.5.2.             使用格林尼治標準時間(Greenwich

Mean Time，GMT)的國家碰巧總是與UTC一致，但這些國家並不使用UTC

  • 5.3.5.6. 如果你不進行時區轉換，並且瘋狂到在收集時不捕獲時區資訊，那麼你將永遠無法知道兩個國際事件相對彼此發生的先後順序

  • 5.3.5.7. 千年蟲

  • 5.3.5.8. 按照UTC標準來轉換或捕獲時間

  • 5.3.6. 型別強制轉換

  • 5.3.6.1. 大多數結構化資料都是型別化的，這意味著它必須遵循某種格式

  • 5.3.6.2. 如果下游應用程式需要某種型別的資料，你需要考慮強制對其進行轉換

  • 5.3.6.3. 作為資料清洗過程的一部分，你需要將值從一種資料型別自動或隱式轉換為另一種資料型別

  • 5.3.6.4. 如果要組合來自不同格式的資料，型別強制轉換也是不可或缺的

  • 5.3.6.5. 許多庫和應用程式對不同的事物都有自己的資料型別，並且通常需要將它們顯式轉換為新的、更容易接受的格式

相關文章