讀數(shù)據(jù)質量管理：數(shù)據(jù)可靠性與數(shù)據(jù)質量問題解決之道01數(shù)據(jù)質量.png

1. 為什么數(shù)據(jù)質量值得關注

1.1. 數(shù)據(jù)是你的CEO的首要任務

1.2. 下游數(shù)據(jù)消費者（包括產品分析師、營銷領導者和銷售團隊）則依賴于數(shù)據(jù)驅動的工具

1.3. 數(shù)據(jù)宕機

• 1.3.1. 指數(shù)據(jù)丟失、不準確或出現(xiàn)錯誤的情況，它表現(xiàn)為過時的儀表板、不準確的報告，甚至是糟糕的決策

• 1.3.2. 數(shù)據(jù)宕機的根源是不可靠的數(shù)據(jù)

• 1.3.3. 受數(shù)據(jù)宕機影響的不僅僅是公司的利潤

  • 1.3.3.1. 數(shù)據(jù)宕機每年都可能使公司損失數(shù)百萬美元，更不用說丟掉客戶信任了

  • 1.3.3.2. 處理數(shù)據(jù)質量問題將消耗數(shù)據(jù)團隊40%以上的時間，這些時間本可以用于更有趣的項目或進行真正的業(yè)務創(chuàng)新

• 1.3.4. 數(shù)據(jù)宕機是軟件工程和開發(fā)人員運營的必然結果，在這個世界中，應用程序的正常運行時間或宕機時間[即你的軟件或服務可用（正常運行）或不可用（停機）的頻率]都被仔細度量，以確保軟件的可訪問性和性能

1.4. 虛假信息還是技術錯誤造成的糟糕數(shù)據(jù)質量和不可靠的數(shù)據(jù)，一直都是組織所面臨的重要問題

1.5. “壞數(shù)據(jù)”(bad data)和糟糕的數(shù)據(jù)質量這兩個概念幾乎與人類存在的時間一樣長，盡管形式各有不同

1.6. 分析管道在過程的任何階段都極易受到最無害變化的影響

1.7. 生產中的數(shù)據(jù)

• 1.7.1. 來自源系統(tǒng)（如CRM、CMS和前面提到的其他類似系統(tǒng)的數(shù)據(jù)庫）的數(shù)據(jù)

• 1.7.2. 這些數(shù)據(jù)已經被數(shù)據(jù)倉庫(data warehouse)、數(shù)據(jù)湖(data lake)或其他數(shù)據(jù)存儲和處理解決方案接收，并通過數(shù)據(jù)管道流動（提取-轉換-加載，即ETL），以便分析層將其呈現(xiàn)給業(yè)務用戶

1.8. 數(shù)據(jù)管道既可以處理批數(shù)據(jù)，也可以處理流數(shù)據(jù)，并且在較高的層次上，度量這兩種類型數(shù)據(jù)質量的方法都大致相同

• 1.8.1. 為構建決策儀表板、數(shù)據(jù)產品、機器學習模型和其他數(shù)據(jù)科學輸出的數(shù)據(jù)分析數(shù)據(jù)管道提供動力

2. 數(shù)據(jù)質量

2.1. “數(shù)據(jù)質量”自從人類開始收集數(shù)據(jù)以來就已經存在了

• 2.1.1. 數(shù)據(jù)質量也是一種了解數(shù)據(jù)是否符合業(yè)務需求的有效方法

2.2. 在過去的幾十年里，數(shù)據(jù)質量的定義已經開始具體化為度量數(shù)據(jù)可靠性、完整性和準確性的功能，因為它與報告時的狀態(tài)相關

2.3. 高數(shù)據(jù)質量是所有強大分析程序的第一步

2.4. 數(shù)據(jù)質量定義為數(shù)據(jù)在其生命周期中任何階段的健康狀況

• 2.4.1. 數(shù)據(jù)質量可能在數(shù)據(jù)管道的任何階段受到影響，無論是接收數(shù)據(jù)前、生產過程中，還是在分析過程中

2.5. 數(shù)據(jù)質量常常是一個糟糕的代表，數(shù)據(jù)團隊知道他們需要優(yōu)先考慮它，但它并沒有像“機器學習”“數(shù)據(jù)科學”甚至“分析”那樣一蹴而就，許多團隊沒有足夠的帶寬或資源來找人全職管理它

2.6. “沒數(shù)據(jù)總比壞數(shù)據(jù)好”這句話是該領域專業(yè)人士經常拋出的一句話，雖然它確實有道理，但這往往不是現(xiàn)實

3. 數(shù)據(jù)運營

3.1. 數(shù)據(jù)不僅是一種產出，更是一種金融商品，所以這些信息的可信度非常重要

3.2. DevOps是一個致力于縮短系統(tǒng)開發(fā)生命周期的技術領域，催生了業(yè)界領先的最佳實踐

• 3.2.1. DevOps的目標是通過自動化來發(fā)布更可靠、性能更好的軟件

3.3. “數(shù)據(jù)運營”(DataOps)的形式將這些概念應用于數(shù)據(jù)

• 3.3.1. 數(shù)據(jù)運營指的是通過自動化來減少數(shù)據(jù)孤島并促進更快、更容錯的分析，以提高數(shù)據(jù)可靠性和性能的過程

3.4. 不準確、缺失或錯誤的數(shù)據(jù)會耗費公司的時間、金錢以及客戶的信任

3.5. 實施更穩(wěn)健的測試到投資包括監(jiān)控和數(shù)據(jù)可觀測性在內的數(shù)據(jù)運營最佳實踐，來不斷復制這些努力

3.6. 影響數(shù)據(jù)的變量

• 3.6.1. 遷移到云端

  • 3.6.1.1. 20年前，你的數(shù)據(jù)倉庫（轉換和存儲結構化數(shù)據(jù)的地方）可能位于辦公室的地下室內，而不是在亞馬遜云計算服務(Amazon Web Services，AWS)或微軟的Azure云計算服務上

  • 3.6.1.2. 在許多方面，云都讓數(shù)據(jù)變得更易管理，更容易被廣泛的用戶所訪問，并且能以更快的速度進行處理

  • 3.6.1.3. 在數(shù)據(jù)倉庫遷移到云端后不久，數(shù)據(jù)湖也遷移到了云端，這為數(shù)據(jù)團隊在管理數(shù)據(jù)資產方面提供了更大的靈活性

• 3.6.2. 更多的數(shù)據(jù)源

  • 3.6.2.1. 數(shù)十到數(shù)百個內部與外部數(shù)據(jù)源來生成分析和機器學習模型

  • 3.6.2.2. 任何一個來源都可能以意想不到的方式在沒有事先通知的情況下發(fā)生變化，從而影響到公司用于決策的數(shù)據(jù)

• 3.6.3. 日益復雜的數(shù)據(jù)管道

  • 3.6.3.1. 數(shù)據(jù)管道正變得越來越復雜：有多個處理階段且各種數(shù)據(jù)資產之間存在重要的依賴關系

  • 3.6.3.2. 如果不了解這些依賴關系，對一個數(shù)據(jù)集所做的任何更改都可能會產生意想不到的后果，從而影響相關數(shù)據(jù)資產的正確性

  • 3.6.3.3. 源數(shù)據(jù)的提取、接收、轉換、加載、存儲、處理和交付，以及其他可能的步驟，其中包含了在管道不同階段的許多API和集成

• 3.6.4. 更專業(yè)的數(shù)據(jù)團隊

  • 3.6.4.1. 隨著公司越來越依賴數(shù)據(jù)來推動智能決策，公司正在招聘越來越多的數(shù)據(jù)分析師、數(shù)據(jù)科學家和數(shù)據(jù)工程師構建并維護數(shù)據(jù)管道、分析和機器學習模型，以支持其服務、產品以及業(yè)務運營

  • 3.6.4.2. 當數(shù)據(jù)分析師主要負責收集、清洗和查詢數(shù)據(jù)集，以幫助各職能利益相關方對業(yè)務產生豐富、可操作的見解時，數(shù)據(jù)工程師則負責確保支持這些分析的底層技術和系統(tǒng)是高性能、快速且可靠的

  • 3.6.4.3. 在工業(yè)界，數(shù)據(jù)科學家通常會收集、整理、擴充和理解非結構化數(shù)據(jù)以改進業(yè)務

  • 3.6.4.4. 更大型的公司可能會支持額外的角色，包括數(shù)據(jù)管理員、數(shù)據(jù)治理負責人、運營分析師，甚至分析工程師

    3.6.4.4.1. 分析工程師是一個數(shù)據(jù)工程師和分析師的混合角色，在可能還沒有資源支持大型數(shù)據(jù)團隊的創(chuàng)業(yè)公司和中型公司中很受歡迎

  • 3.6.4.5. 一個團隊添加到數(shù)據(jù)表中的新字段可能會導致另一個團隊的管道故障，從而導致數(shù)據(jù)全部或部分丟失

• 3.6.5. 去中心化的數(shù)據(jù)團隊

  • 3.6.5.1. 隨著數(shù)據(jù)成為業(yè)務運營的中心，公司中越來越多的職能團隊介入數(shù)據(jù)的管理和分析，以簡化并加快洞察收集的過程

  • 3.6.5.2. 越來越多的數(shù)據(jù)團隊正在采用一種分布式、去中心化的模型，該模型模擬了整個行業(yè)從單體架構到微服務架構的遷移，這種遷移在20世紀10年代中期席卷了軟件工程界

  • 3.6.5.3. 不要把它與數(shù)據(jù)網格混淆，因為它是一種利用分布式的、面向域的設計的組織范式，去中心化的數(shù)據(jù)架構由一個集中式數(shù)據(jù)平臺團隊管理，而分析和數(shù)據(jù)科學團隊則分布在整個業(yè)務中

  • 3.6.5.4. 多個域將生成并利用數(shù)據(jù)，這將不可避免地導致多個團隊所使用的數(shù)據(jù)集會隨著時間的推移而重復、丟失或過時

4. 其他行業(yè)趨勢

4.1. 數(shù)據(jù)網格

• 4.1.1. 數(shù)據(jù)網格在許多方面都是微服務的數(shù)據(jù)平臺版本

• 4.1.2. 數(shù)據(jù)網格的概念還處于萌芽階段，數(shù)據(jù)社區(qū)中有很多關于如何（或是否有意義）在文化和技術層面上執(zhí)行數(shù)據(jù)網格的討論

• 4.1.3. 數(shù)據(jù)網格是一個社會技術范式，它識別了在復雜組織中人員與技術架構和解決方案之間的交互

• 4.1.4. 數(shù)據(jù)網格通過利用面向域的自助設計來包含企業(yè)中無處不在的數(shù)據(jù)

• 4.1.5. 數(shù)據(jù)網格支持分布式、特定域的數(shù)據(jù)消費者且視“數(shù)據(jù)即產品”，在每個域中處理自己的數(shù)據(jù)管道，連接這些域及其相關數(shù)據(jù)資產的組織是應用相同語法和數(shù)據(jù)標準的通用互操作層

• 4.1.6. 數(shù)據(jù)網格聯(lián)合了負責將數(shù)據(jù)作為產品提供的域數(shù)據(jù)所有者之間的數(shù)據(jù)所有權，同時也促進了跨不同位置的分布式數(shù)據(jù)之間的通信

• 4.1.7. 域的任務是管理數(shù)據(jù)的接收、清洗和聚合，以生成可供商業(yè)智能應用程序使用的資產

• 4.1.8. 只有當數(shù)據(jù)可靠且值得信賴，并且跨域應用此“通用互操作層”時，數(shù)據(jù)網格范式才能成功

• 4.1.9. 數(shù)據(jù)可靠和值得信賴的唯一方法是通過測試、監(jiān)控和可觀測性來密切關注數(shù)據(jù)質量

4.2. 流數(shù)據(jù)

• 4.2.1. 流數(shù)據(jù)指的是將連續(xù)的數(shù)據(jù)流傳輸?shù)焦艿乐校瑥亩焖偕蓪崟r洞察的過程

• 4.2.2. 數(shù)據(jù)質量是通過批式數(shù)據(jù)進入生產管道前對其進行測試來強制執(zhí)行的，但越來越多的企業(yè)正在尋求更為實時的分析

4.3. 湖倉一體(data lakehouse)的興起

• 4.3.1. 數(shù)據(jù)倉庫（結構化數(shù)據(jù)存儲庫）和數(shù)據(jù)湖（原始非結構化數(shù)據(jù)池）都依賴于高質量的數(shù)據(jù)來進行處理和轉換

• 4.3.2. 越來越多的數(shù)據(jù)團隊選擇同時使用數(shù)據(jù)倉庫和數(shù)據(jù)湖來滿足其業(yè)務不斷增長的數(shù)據(jù)需求

4.4. 云、分布式數(shù)據(jù)架構和團隊的興起，以及數(shù)據(jù)產品化的轉變，使數(shù)據(jù)領導者有責任幫助其公司獲得更值得信賴的數(shù)據(jù)（并因此得出更可靠的分析）

4.5. 實現(xiàn)可靠數(shù)據(jù)的過程是一場馬拉松，而不是一場短跑，它會涉及數(shù)據(jù)管道的多個階段