讀資料質量管理：資料可靠性與資料質量問題解決之道02資料湖倉

躺柒發表於2024-11-13

1. 組裝

1.1. 對於任何資料從業者來說，解決生產過程中的資料質量問題都是一項關鍵技能，但只要有適當的系統和流程，就基本可以防止資料當機

1.2. 資料在管道的任何階段都可能會受到運算元量、程式設計甚至資料相關性的影響，也許只需一次模式更改或程式碼推送，就會讓下游報告處於混亂狀

1.3. 後設資料驅動的構建模組，以便在管道的每個階段都確保高質量的資料，並保證成功建立資料基礎設施

2. 差異

2.1. 事務型與分析型是在生態系統中對資料進行分類的方法

2.2. 管理事務型資料的質量和可靠性通常屬於開發運營(DevOps)的領域

2.3. 站點可靠性工程和其他軟體學科更關注由分析型資料構建的軟體產品

2.4. 事務型資料

  • 2.4.1. 在運營過程中產生的資料，即組織日常持續運營過程中所產生的資料

  • 2.4.2. 某一時刻的庫存快照、客戶曝光次數和交易記錄都是事務型資料的示例

  • 2.4.3. 事務型資料記錄了來自實際業務流程中的資料，以便快速更新系統和流程

  • 2.4.4. 事務型資料在執行業務

  • 2.4.5. 在資料管道中，事務型資料幾乎總是出現在分析型資料的上游

2.5. 分析型資料

  • 2.5.1. 在分析過程中用到的資料

  • 2.5.2. 分析型資料是由資料驅動的業務決策背後的資料型別

  • 2.5.3. 客戶流失情況、點選率和在全球地區的曝光次數都是分析型資料的示例

  • 2.5.4. 分析型資料則被用於更可靠、更高效的分析

  • 2.5.5. 分析型資料在管理業務

  • 2.5.6. 分析型資料在某種程度上推動了商業智慧的發展

  • 2.5.6.1. 人們很可能會覺得分析型資料對組織的成功更為重要或更為“核心”

  • 2.5.6.2. 實際上，分析型資料往往依賴於事務型資料的轉換和聚合

  • 2.5.7. 分析型資料能夠（並且）經常包含事務型資料儲存的聚合或擴充

  • 2.5.8. 分析型資料庫則迎合了使用者對海量資料集進行大規模聚合的需要

2.6. 與聯機事務處理(On-Line Transaction Processing，OLTP)和聯機分析處理(On-Line Analytical Processing，OLAP)之間的比較相同

2.7. 吞吐量與延遲

  • 2.7.1. 吞吐量-延遲的約束會影響任何具有固定計算能力的系統

  • 2.7.2. 傳統的吞吐量指的是在某一單位時間內處理的資料量

  • 2.7.3. 延遲指的是資料被處理之前所等待的時間

  • 2.7.4. 吞吐量和延遲並不是完全相反的

  • 2.7.4.1. 與現實中資料處理系統的構建方式有關

  • 2.7.4.2. 與有限數量的請求處理程式有關

3. 資料倉儲

3.1. Kimball集團

  • 3.1.1. 現代資料倉儲的概念部分歸功於Kimball集團

  • 3.1.2. 該集團在20世紀80年代開發了資料倉儲/商業智慧生命週期方法論

  • 3.1.3. 工程師最常從事的資料攝取和預處理階段

3.2. 資料倉儲通常以結構化（行-列）的格式來儲存資料

  • 3.2.1. 模式級別的表型別

  • 3.2.2. 資料倉儲需要“寫時模式”訪問，這意味著我們在資料進入倉庫時就設定了資料的結構

  • 3.2.3. 資料倉儲是完全整合和託管的解決方案，使其易於構建和開箱即用

  • 3.2.4. 資料倉儲通常需要更多的結構和模式，這通常會對資料清洗的過程要求更高，並在讀取和使用資料時降低複雜性

3.3. 常見的資料倉儲技術

  • 3.3.1. Amazon Redshift

  • 3.3.1.1. 第一個廣受歡迎（且隨時可用）的雲資料倉儲

  • 3.3.1.2. Amazon Redshift位於AWS之上，利用源聯結器將資料從原始資料來源傳輸到關係型資料庫中

  • 3.3.1.3. Redshift的列式儲存結構和並行處理使其成為分析型工作負載的理想選擇

  • 3.3.2. Google BigQuery

  • 3.3.2.1. Google BigQuery利用了Google的專有云平臺GCP(Google Cloud Platform)並使用了列式儲存結構，透過並行處理來實現快速查詢

  • 3.3.2.2. BigQuery是一種可根據使用模式進行擴充套件的無伺服器解決方案

  • 3.3.3. Snowflake

  • 3.3.3.1. Snowflake的雲資料倉儲功能由AWS、Google、Azure和其他公有云基礎設施提供支援

  • 3.3.3.2. Snowflake允許使用者為計算和儲存單獨付費，這讓資料倉儲成為尋求更靈活支付方案的團隊的絕佳選擇

3.4. 與管理資料質量相關的缺點

  • 3.4.1. 靈活性有限

  • 3.4.1.1. 資料倉儲並不是市面上最靈活的資料儲存解決方案

  • 3.4.1.2. 資料的格式是有限的

  • 3.4.1.3. 像JSON(JavaScript Object Notation)這樣的半結構化資料及其查詢通常不受支援，而且不良資料常常會被遺漏

  • 3.4.2. 僅支援SQL

  • 3.4.2.1. 查詢資料倉儲需要使用查詢語言

  • 3.4.2.2. 通常不支援使用Python等指令式程式語言進行資料操作，儘管這些語言由於強大的庫生態系統對機器學習非常有用

>  3.4.2.2.1. 許多機器學習的實現需要透過SQL將資料移出倉庫，以便進一步處理

  • 3.4.3. 工作流之間存在衝突

  • 3.4.3.1. 寫時模式系統提供的清潔度帶來的問題比好處要多

3.5. 資料團隊同時採用資料倉儲和資料湖來處理分析型工作負載的情況並不少見，因為它們分別有著不同的用途

4. 資料湖

4.1. 資料湖的概念最早是由軟體公司Pentaho的創始人兼前技術長James Dixon提出的，他將其描述為“在一個更自然的環境中的一大片水域

  • 4.1.1. 資料湖的內容從源頭湧入並填滿整個湖泊，湖的不同使用者都可以來檢查、探索或取樣”​

  • 4.1.2. 檔案級別的操作

4.2. 資料湖能儲存任何結構化資料、半結構化資料和非結構化資料

  • 4.2.1. 與資料倉儲不同，資料湖不需要具有高度指定的資料輸入程式，你可以將任何喜歡的格式轉儲到湖中並直接訪問它

  • 4.2.2. 其結果是系統的容量通常更高，並且在治理和資料方面往往更加複雜

  • 4.2.3. 資料湖是現代資料系統另一種日益流行的儲存和計算選擇，它也依賴於高質量的分析型資料來提供最佳結果

4.3. 資料湖架構允許“讀時模式”訪問

  • 4.3.1. 這意味著我們可以在準備使用資料時再推斷資料的結構

4.4. 資料湖是資料倉儲的DIY版本，允許團隊根據系統需求選擇自己想要使用的各種後設資料、儲存和計算技術

  • 4.4.1. 資料湖非常適合希望構建定製化平臺的資料團隊，通常由少數（或更多）資料工程師提供支援

  • 4.4.2. 藉助資料湖，資料科學家、機器學習工程師和資料工程師可以從更大的資料池中提取半結構化資料和非結構化資料

4.5. 早期的資料湖主要建立在Apache Hadoop MapReduce和HDFS(Hadoop Distributed File System)上，利用Apache Hive透過SQL引擎來查詢資料

4.6. 通用特徵

  • 4.6.1. 解耦儲存和計算

  • 4.6.1.1. 不僅可以節省大量成本，而且有助於解析並豐富資料以進行實時流式傳輸和查詢

  • 4.6.2. 支援分散式計算

  • 4.6.2.1. 分散式計算有助於提高大規模資料處理的效能，因為它允許更好的分段查詢效能、更容錯的設計和更佳的並行資料處理能力

  • 4.6.3. 定製化和互操作性

  • 4.6.3.1. 由於其“即插即用”的特性，隨著公司資料需求的演進和成熟，資料湖可以讓棧中的不同元素輕鬆地協同工作，從而支援資料平臺的可擴充套件性

  • 4.6.4. 主要基於開源技術進行構建

  • 4.6.4.1. 有助於降低供應商被鎖定的風險並提供強大的定製功能，對於擁有大型資料工程團隊的公司來說非常適用

  • 4.6.5. 處理非結構化或弱結構化資料的能力

  • 4.6.5.1. 資料湖可以支援原始資料，這意味著在處理資料時具有更大的靈活性，非常適合資料科學家和資料工程師

  • 4.6.5.2. 使用原始資料可以更好地控制聚合與計算

  • 4.6.6. 支援複雜的非SQL程式設計模型

  • 4.6.6.1. 支援Apache Hadoop、Apache Spark、PySpark等高階資料科學和機器學習框架

4.7. 突出挑戰

  • 4.7.1. 資料完整性

  • 4.7.1.1. 資料湖中的資源在檔案級別進行操作時無法保證其資料模式

  • 4.7.1.2. ”盲目ETL”(blind ETL)的危險操作

  • 4.7.1.3. 由於不可預見的上游變化，轉換可能會在任何時候失敗

  • 4.7.2. 沼澤化

  • 4.7.2.1. 沼澤化是指資料湖隨時間推移產生技術負債和隱性知識的趨勢

  • 4.7.2.2. 必須依靠熟練的資料工程師或資料科學家來了解特定資料所在的位置、利益相關方是誰，並預計資料將如何變化

  • 4.7.2.3. 意味著沒人能完成任何工作，因為資料認知所需的學習成本實在是太高了

  • 4.7.3. 更多端點

  • 4.7.3.1. 人們可以透過更多方式來收集、操作和轉換資料

  • 4.7.3.2. 管道中的步驟越多，出錯的可能性就越大

  • 4.7.3.3. 資料湖通常被用作大量非結構化資料的收集點

4.8. 較小的團隊可能會使用資料湖作為唯一的資料儲存工具，以實現快速移動的目的，而不是依賴強大的基礎設施

  • 4.8.1. 始終警惕“資料沼澤”問題

4.9. 資料湖與資料倉儲的不同之處主要在於它們允許更為靈活的儲存格式

5. 湖倉一體

5.1. 資料湖也新增了提供倉庫式特性的技術，例如SQL功能和模式

5.2. 資料倉儲和資料湖之間的差異如今正在不斷縮小，所以你能夠在一個軟體包中獲得兩全其美的體驗

5.3. 高效能SQL

  • 5.3.1. Presto和Spark等技術在資料湖上提供了接近互動速度的SQL介面

  • 5.3.2. 開闢了資料湖直接服務於分析和探索需求的可能性，而無須對傳統資料倉儲進行彙總和ETL

5.4. 模式

  • 5.4.1. Parquet等檔案格式為資料湖表引入了更嚴格的模式，以及用於提高查詢效率的列式格式

5.5. 原子性、一致性、隔離性和永續性(Atomicity，Consistency，Isolation，and Durability，ACID)

  • 5.5.1. Delta Lake和Apache Hudi等資料湖技術在寫入/讀取事務中引入了更高的可靠性，並讓資料湖更接近傳統資料庫技術標準中的理想ACID屬性

5.6. 託管服務

  • 5.6.1. 對於希望減少與構建和執行資料湖相關的運營成本的團隊，雲服務供應商提供了各種託管湖服務

5.7. 湖倉一體未來幾年可能會在各行各業的資料團隊中變得越來越受歡迎，且越來越重要

相關文章