1. 為什麼資料質量值得關注
1.1. 資料是你的CEO的首要任務
1.2. 下游資料消費者（包括產品分析師、營銷領導者和銷售團隊）則依賴於資料驅動的工具
1.3. 資料當機
-
1.3.1. 指資料丟失、不準確或出現錯誤的情況，它表現為過時的儀表板、不準確的報告，甚至是糟糕的決策
-
1.3.2. 資料當機的根源是不可靠的資料
-
1.3.3. 受資料當機影響的不僅僅是公司的利潤
-
1.3.3.1. 資料當機每年都可能使公司損失數百萬美元，更不用說丟掉客戶信任了
-
1.3.3.2. 處理資料質量問題將消耗資料團隊40%以上的時間，這些時間本可以用於更有趣的專案或進行真正的業務創新
-
1.3.4. 資料當機是軟體工程和開發人員運營的必然結果，在這個世界中，應用程式的正常執行時間或當機時間[即你的軟體或服務可用（正常執行）或不可用（停機）的頻率]都被仔細度量，以確保軟體的可訪問性和效能
1.4. 虛假資訊還是技術錯誤造成的糟糕資料質量和不可靠的資料，一直都是組織所面臨的重要問題
1.5. “壞資料”(bad data)和糟糕的資料質量這兩個概念幾乎與人類存在的時間一樣長，儘管形式各有不同
1.6. 分析管道在過程的任何階段都極易受到最無害變化的影響
1.7. 生產中的資料
-
1.7.1. 來自源系統（如CRM、CMS和前面提到的其他類似系統的資料庫）的資料
-
1.7.2. 這些資料已經被資料倉儲(data warehouse)、資料湖(data lake)或其他資料儲存和處理解決方案接收，並透過資料管道流動（提取-轉換-載入，即ETL），以便分析層將其呈現給業務使用者
1.8. 資料管道既可以處理批資料，也可以處理流資料，並且在較高的層次上，度量這兩種型別資料質量的方法都大致相同
- 1.8.1. 為構建決策儀表板、資料產品、機器學習模型和其他資料科學輸出的資料分析資料管道提供動力
2. 資料質量
2.1. “資料質量”自從人類開始收集資料以來就已經存在了
- 2.1.1. 資料質量也是一種瞭解資料是否符合業務需求的有效方法
2.2. 在過去的幾十年裡，資料質量的定義已經開始具體化為度量資料可靠性、完整性和準確性的功能，因為它與報告時的狀態相關
2.3. 高資料質量是所有強大分析程式的第一步
2.4. 資料質量定義為資料在其生命週期中任何階段的健康狀況
- 2.4.1. 資料質量可能在資料管道的任何階段受到影響，無論是接收資料前、生產過程中，還是在分析過程中
2.5. 資料質量常常是一個糟糕的代表，資料團隊知道他們需要優先考慮它，但它並沒有像“機器學習”“資料科學”甚至“分析”那樣一蹴而就，許多團隊沒有足夠的頻寬或資源來找人全職管理它
2.6. “沒資料總比壞資料好”這句話是該領域專業人士經常丟擲的一句話，雖然它確實有道理，但這往往不是現實
3. 資料運營
3.1. 資料不僅是一種產出，更是一種金融商品，所以這些資訊的可信度非常重要
3.2. DevOps是一個致力於縮短系統開發生命週期的技術領域，催生了業界領先的最佳實踐
- 3.2.1. DevOps的目標是透過自動化來發布更可靠、效能更好的軟體
3.3. “資料運營”(DataOps)的形式將這些概念應用於資料
- 3.3.1. 資料運營指的是透過自動化來減少資料孤島並促進更快、更容錯的分析，以提高資料可靠性和效能的過程
3.4. 不準確、缺失或錯誤的資料會耗費公司的時間、金錢以及客戶的信任
3.5. 實施更穩健的測試到投資包括監控和資料可觀測性在內的資料運營最佳實踐，來不斷複製這些努力
3.6. 影響資料的變數
-
3.6.1. 遷移到雲端
-
3.6.1.1. 20年前，你的資料倉儲（轉換和儲存結構化資料的地方）可能位於辦公室的地下室內，而不是在亞馬遜雲端計算服務(Amazon Web Services，AWS)或微軟的Azure雲端計算服務上
-
3.6.1.2. 在許多方面，雲都讓資料變得更易管理，更容易被廣泛的使用者所訪問，並且能以更快的速度進行處理
-
3.6.1.3. 在資料倉儲遷移到雲端後不久，資料湖也遷移到了雲端，這為資料團隊在管理資料資產方面提供了更大的靈活性
-
3.6.2. 更多的資料來源
-
3.6.2.1. 數十到數百個內部與外部資料來源來生成分析和機器學習模型
-
3.6.2.2. 任何一個來源都可能以意想不到的方式在沒有事先通知的情況下發生變化，從而影響到公司用於決策的資料
-
3.6.3. 日益複雜的資料管道
-
3.6.3.1. 資料管道正變得越來越複雜：有多個處理階段且各種資料資產之間存在重要的依賴關係
-
3.6.3.2. 如果不瞭解這些依賴關係，對一個資料集所做的任何更改都可能會產生意想不到的後果，從而影響相關資料資產的正確性
-
3.6.3.3. 源資料的提取、接收、轉換、載入、儲存、處理和交付，以及其他可能的步驟，其中包含了在管道不同階段的許多API和整合
-
3.6.4. 更專業的資料團隊
-
3.6.4.1. 隨著公司越來越依賴資料來推動智慧決策，公司正在招聘越來越多的資料分析師、資料科學家和資料工程師構建並維護資料管道、分析和機器學習模型，以支援其服務、產品以及業務運營
-
3.6.4.2. 當資料分析師主要負責收集、清洗和查詢資料集，以幫助各職能利益相關方對業務產生豐富、可操作的見解時，資料工程師則負責確保支援這些分析的底層技術和系統是高效能、快速且可靠的
-
3.6.4.3. 在工業界，資料科學家通常會收集、整理、擴充和理解非結構化資料以改進業務
-
3.6.4.4. 更大型的公司可能會支援額外的角色，包括資料管理員、資料治理負責人、運營分析師，甚至分析工程師
> 3.6.4.4.1. 分析工程師是一個資料工程師和分析師的混合角色，在可能還沒有資源支援大型資料團隊的創業公司和中型公司中很受歡迎
-
3.6.4.5. 一個團隊新增到資料表中的新欄位可能會導致另一個團隊的管道故障，從而導致資料全部或部分丟失
-
3.6.5. 去中心化的資料團隊
-
3.6.5.1. 隨著資料成為業務運營的中心，公司中越來越多的職能團隊介入資料的管理和分析，以簡化並加快洞察收集的過程
-
3.6.5.2. 越來越多的資料團隊正在採用一種分散式、去中心化的模型，該模型模擬了整個行業從單體架構到微服務架構的遷移，這種遷移在20世紀10年代中期席捲了軟體工程界
-
3.6.5.3. 不要把它與資料網格混淆，因為它是一種利用分散式的、面向域的設計的組織正規化，去中心化的資料架構由一個集中式資料平臺團隊管理，而分析和資料科學團隊則分佈在整個業務中
-
3.6.5.4. 多個域將生成並利用資料，這將不可避免地導致多個團隊所使用的資料集會隨著時間的推移而重複、丟失或過時
4. 其他行業趨勢
4.1. 資料網格
-
4.1.1. 資料網格在許多方面都是微服務的資料平臺版本
-
4.1.2. 資料網格的概念還處於萌芽階段，資料社群中有很多關於如何（或是否有意義）在文化和技術層面上執行資料網格的討論
-
4.1.3. 資料網格是一個社會技術正規化，它識別了在複雜組織中人員與技術架構和解決方案之間的互動
-
4.1.4. 資料網格透過利用面向域的自助設計來包含企業中無處不在的資料
-
4.1.5. 資料網格支援分散式、特定域的資料消費者且視“資料即產品”，在每個域中處理自己的資料管道，連線這些域及其相關資料資產的組織是應用相同語法和資料標準的通用互操作層
-
4.1.6. 資料網格聯合了負責將資料作為產品提供的域資料所有者之間的資料所有權，同時也促進了跨不同位置的分散式資料之間的通訊
-
4.1.7. 域的任務是管理資料的接收、清洗和聚合，以生成可供商業智慧應用程式使用的資產
-
4.1.8. 只有當資料可靠且值得信賴，並且跨域應用此“通用互操作層”時，資料網格正規化才能成功
-
4.1.9. 資料可靠和值得信賴的唯一方法是透過測試、監控和可觀測性來密切關注資料質量
4.2. 流資料
-
4.2.1. 流資料指的是將連續的資料流傳輸到管道中，從而快速生成實時洞察的過程
-
4.2.2. 資料質量是透過批式資料進入生產管道前對其進行測試來強制執行的，但越來越多的企業正在尋求更為實時的分析
4.3. 湖倉一體(data lakehouse)的興起
-
4.3.1. 資料倉儲（結構化資料儲存庫）和資料湖（原始非結構化資料池）都依賴於高質量的資料來進行處理和轉換
-
4.3.2. 越來越多的資料團隊選擇同時使用資料倉儲和資料湖來滿足其業務不斷增長的資料需求
4.4. 雲、分散式資料架構和團隊的興起，以及資料產品化的轉變，使資料領導者有責任幫助其公司獲得更值得信賴的資料（並因此得出更可靠的分析）
4.5. 實現可靠資料的過程是一場馬拉松，而不是一場短跑，它會涉及資料管道的多個階段