讀資料質量管理：資料可靠性與資料質量問題解決之道05資料標準化

躺柒發表於2024-11-16

1. 批處理

1.1. 批處理在一段時間內收集資料，然後將大量資料“批處理”在離散的資料包中

1.2. 直到20世紀10年代中期，批處理都是處理分析型資料最常用的方法

1.3. 批處理比流處理要便宜得多，即使是對時間要求最苛刻的處理需求也足以滿足

1.4. 批處理是經過時間考驗的標準，並且仍然是公司接收大量資料最為流行且常見的方式

1.5. 當組織想要獲得實時的洞察時，批處理就顯得力不從心了

1.6. 批處理關注的是儘可能多地收集資料，即使這會帶來滯後

1.7. 批次流系統的資料質量（也就是資料管道中給定階段的資料健康狀況）往往更高，但是當資料在進行實時流傳輸時，產生錯誤的空間和資料質量降低的情況都會增加

2. 流處理

2.1. 流處理是一個較長的過程，但幾乎可以立即處理資料

2.2. 隨著各行各業的公司越來越依賴實時資料，Apache Kafka和Amazon Kinesis等技術讓流資料相對以前來說更易於大規模訪問，價格也更實惠

2.3. 實時訪問資料將改變遊戲規則，這也為依賴資料而不斷更新的產品和服務帶來了更高的投資回報

  • 2.3.1. 流處理可以填補空白的地方

2.4. 流處理的一個簡單示例是實時拼車應用程式的請求

  • 2.4.1. 使用實時流資料，這些拼車應用程式可以將實時位置、價格和司機資料拼湊在一起，從而立即將使用者與行程聯絡起來

2.5. 最常見的開源技術包括來自Apache的解決方案

  • 2.5.1. Spark、Kafka、Flink、Storm、Samza和Flume

2.6. 使用最廣泛的還是Apache Spark和Apache Kafka

  • 2.6.1. Apache Spark採用微批處理方法，將傳入的流拆分成更小的資料包

  • 2.6.2. Apache Kafka以近乎實時的方式分析事件

  • 2.6.3. 託管替代方案包括Databricks、Cloudera和Azure

3. Apache Hadoop

3.1. 用於分散式儲存和處理大型資料集的最流行的開源批處理框架之一

3.2. 透過將檔案拆分為更小的資料包，然後將這些更易於管理的資料塊分佈在叢集中的節點上來執行

3.3. Hadoop的託管替代品包括Google BigQuery、Snowflake​、Microsoft Azure和Amazon Redshift

4. 流處理的資料質量

4.1. 批處理和流處理之間的主要區別在於每個批處理所包含的資料量和處理速度

4.2. 流處理關注的是儘可能快地收集資料，儘管這會導致一些損失

4.3. 傳統來說，資料質量是透過測試來強制執行的

  • 4.3.1. 你分批接收資料，並希望資料按照你認為必要的時間間隔到達

  • 4.3.2. 根據其對資料的假設編寫測試，但其實不太可能透過編寫測試來解釋所有可能的結果

4.4. 資料質量往往會出現新的錯誤，而工程師會急於在問題影響下游表格和使用者前進行根因分析

  • 4.4.1. 編寫一個測試以防止該問題再次發生

  • 4.4.2. 測試很難擴充套件

  • 4.4.2.1. 測試僅僅涵蓋了潛在資料質量問題的20%

>  4.4.2.1.1. “已知的未知”​
  • 4.4.3. 從任何地方的數十到上百個內部和外部資料來源中獲取資料，而傳統的處理和測試方法已經開始過時

4.5. 如果確保批處理資料的可靠性都很困難的話，你可以想象一下對每分每秒都在演變的資料執行和擴充套件測試會多麼難以實現

4.6. 雖然單元測試、功能測試和整合測試等傳統資料質量框架可能包含了一些基礎功能，但它們無法在難以進行預測和實時演變的資料集中進行擴充套件

  • 4.6.1. 為了確保提供給這些實時用例的資料是可靠的，資料團隊在處理流處理時需要重新考慮所使用的資料質量方法

4.7. 流式解決方案可以將資料直接實時傳輸到分析系統中或傳輸到資料倉儲進行儲存、處理和轉換

4.8. 當你在AWS Kinesis和Apache Kafka之間進行選擇時，實際上還是要取決於資料團隊的需求

  • 4.8.1. AWS Kinesis等託管解決方案易於設定，尋求快速實現價值的小型資料團隊將受益於這種軟體即服務(SaaS)的產品

  • 4.8.2. 擁有更具體需求的大型資料團隊可能會發現Apache Kafka更符合要求

5. AWS Kinesis

5.1. 亞馬遜的Kinesis服務是一種流行的無伺服器流處理工具，適用於依賴實時資料的應用程式

5.2. 容量可“按需”擴充套件，從而減少了在資料量增加前預置和擴充套件資源的需要

5.3. 可以被配置為從其他AWS服務、微服務、應用程式日誌、移動資料和感測器資料等來源捕獲資料

  • 5.3.1. 該服務可以擴充套件到每秒流式傳輸千兆位元組（GB級）的資料

5.4. 優勢

  • 5.4.1. 按需可用性

  • 5.4.1.1. 按需預置設定了行業標準，這意味著資源組可以在負載增加時進行擴充套件

  • 5.4.2. 成本效益

  • 5.4.2.1. 付費方案與資源使用量成正比

  • 5.4.2.2. 流式服務的資料吞吐量可能會隨著時間的推移而急劇變化

  • 5.4.3. 完善的軟體開發工具包(Software Development Kit，SDK)

  • 5.4.3.1. 支援Java、Android、.NET和Go等多種程式語言的開發

  • 5.4.3.2. Kafka僅支援Java

  • 5.4.4. 與AWS基礎設施的整合

  • 5.4.4.1. 與Amazon S3、Amazon Redshift和其他亞馬遜資料服務的整合要容易得多

6. Apache Kafka

6.1. 一個開源事件的流式平臺

  • 6.1.1. 一個具有高學習曲線的應用程式

  • 6.1.2. 意味著它為給定應用程式中的Kafka流、生產者和消費者提供了大量的顆粒度設定

6.2. 模式登錄檔

6.3. Kafka Streams是支援流式資料進出Kafka叢集的客戶端庫

6.4. 服務提供資料流和整合層以及流式分析

6.5. Kafka流式服務針對低延遲進行了最佳化

  • 6.5.1. 宣稱其延遲低至2ms，但會受限於網路吞吐量

6.6. 優點

  • 6.6.1. 開源社群

  • 6.6.1.1. 該工具可以免費使用

  • 6.6.2. 增加可定製性

  • 6.6.2.1. 比Kinesis等整合度更高的流式解決方案具有更陡的學習曲線

  • 6.6.2.2. 使用者具有更強的可配置性，包括手動指定資料的保留期限

>  6.6.2.2.1. Kinesis將其固定為7天

  • 6.6.3. 高吞吐量

  • 6.6.3.1. 已被證明支援高達每秒30000條記錄的吞吐量

  • 6.6.3.2. Kinesis僅支援每秒數千條記錄

6.7. Apache Kafka流透過JMX（Java管理擴充套件規範）報告流式指標

  • 6.7.1. 使用JConsole等圖形工具對JMX資料進行視覺化

6.8. 在事務型轉換中執行檢查的優先順序需要與該步驟中延遲超過吞吐量檢查的優先順序保持一致

  • 6.8.1. 在這個階段避免進行吞吐量密集型的聚合檢查

  • 6.8.2. 將歷史模式與傳入模式進行比較，或者跟蹤隨時間的推移所掃描的位元組量的變化情況

  • 6.8.3. 確保傳入的資料不會超過現有容量、儲存和記憶體的限制

7. 資料標準化

7.1. 第一個事務型資料轉換層稱為資料標準化階段

7.2. 資料轉換指的是將資料從一種或多種源格式轉換到目標格式的程式

7.3. 標準化通常是你的資料在管道中經過的諸多此類轉換中的第一個

7.4. 標準化發生在噪聲、模糊性和異構性最大的入口點資料上

7.5. 處理異構資料來源

  • 7.5.1. 資料從業者都會從不同的來源收集資料，試圖為他們的使用者、產品或應用程式描繪一個整體的畫像

  • 7.5.2. 關鍵特徵

  • 7.5.2.1. 針對延遲進行了最佳化

>  7.5.2.1.1. 流式端點的資料在經過最佳化後，可以一經建立就立即使用

>  7.5.2.1.2. 最佳化是以吞吐量為代價的，而這實際上決定了資料的完整性

>  7.5.2.1.3. 意味著不要期望批資料是完整的，因為無論其最終狀態如何，它們都會立即透過資料管道進行推送
  • 7.5.2.2. 不具層級結構的格式
>  7.5.2.2.1. 經過標準化的資料可能會以不具層級結構的“平面”儲存格式來進行儲存，以提高效率和易用性

>  7.5.2.2.2. 將資料“轉儲”到某個中央儲存庫中
  • 7.5.2.3. 原始檔案格式
>  7.5.2.3.1. 除了以“平面”形式儲存外，入口點資料還可能反映流式傳輸的原始檔案格式
  • 7.5.2.4. 可選資料欄位
>  7.5.2.4.1. JSON等原始檔案資料都具有可選欄位

>  7.5.2.4.2. 任何內容都可能是預設值，並且該欄位的缺失可能會（也可能不會）成為上游處理的問題
  • 7.5.2.5. 異構性
>  7.5.2.5.1. 資料來自各種不同的來源，採用各種原始的檔案格式，並且與此前相同格式的資料相比，其完整性可能不同

>  7.5.2.5.2. 在資料管道的這個階段，學習如何根據可預測的異構性來讓資料有意義非常關鍵

>  7.5.2.5.3. 要確保資料一旦被儲存和處理就能輕鬆地進行轉換，以最大化其價值

  • 7.5.3. 資料湖通常是入口點資料的首選儲存解決方案，因為它們對可接受資料型別的嚴格限制要小得多

  • 7.5.3.1. 資料轉儲為資料湖格式，然後依靠初始級別的事務型轉換將這些資料提升為資料倉儲中的結構化形式

  • 7.5.3.2. 定期將資料移動到資料倉儲中，那麼像AWS Glue之類的轉換層在這一階段會很有幫助

7.6. 模式檢查

  • 7.6.1. 模式檢查是指驗證資料結構是否符合我們預期的步驟

  • 7.6.1.1. 是否存在必要的欄位

  • 7.6.1.2. 所包含的資料是不是我們所需要的格式

  • 7.6.2. 模式讓我們知道第一次“解包”資料時會發生什麼

  • 7.6.3. 改變模式是資料損壞的一個主要原因

  • 7.6.4. 主動檢查這類錯誤，這通常意味著保持對預期模式的記錄，並且在它們發生變化時以某種可見的方式進行記錄

7.7. 型別強制轉換

  • 7.7.1. 型別強制轉換是在資料不符合格式要求並且必須“強制”轉換為新格式時去執行的過程

  • 7.7.2. 注意型別強制轉換和一般轉換中的問題，它們聽起來很簡單，但一定會產生一些“惡意”漏洞和錯誤

7.8. 資料中的句法歧義與語義歧義

  • 7.8.1. 資料可能是模稜兩可的，每個人都知道這一點，但這種模稜兩可的表現形式卻各不相同

  • 7.8.2. 句法歧義指的是資料呈現方式的混亂

  • 7.8.2.1. 資料中的句法歧義，可能給資料團隊帶來摩擦

  • 7.8.3. 語義歧義指的是系統中資料用途的混淆

  • 7.8.3.1. 更有害

  • 7.8.3.2. 在語義上是模稜兩可的

>  7.8.3.2.1. 無法就該欄位的用途達成一致

  • 7.8.3.3. 可能會導致資料錯誤地表示組織的關鍵指標

  • 7.8.3.4. 文件是避免發生此類情況的一項關鍵工具，而且該文件應該具有一定的前瞻性

  • 7.8.3.5. 歧義會以一種難以根除的方式迅速蔓延，尤其是在團隊快速擴張的情況下

相關文章