1. 同步資料
1.1. 不同的資料倉儲和資料湖透過資料整合層來進行橋接
1.2. AWS Glue、Fivetran和Matillion等資料整合工具從不同來源收集資料，統一這些資料，並將其轉換為上游來源
1.3. 資料整合的一個典型用例是收集資料湖的資料並以結構化格式將其載入到資料倉儲中
1.4. ETL是資料整合中一個眾所周知的過程
- 1.4.1. ETL通常描述整合的步驟，其中首先從一個或多個資料儲存庫中提取資料，轉換為新的結構或格式，最後載入到目標資料儲存庫中
2. 收集資料質量指標
2.1. 你無法修復你無法測量的東西
- 2.1.1. 如果沒有資料質量指標，你就無法獲得資料質量
2.2. 資料當機的時間（也就是你的資料不完整、有錯誤、出現缺失或者其他不準確的時間段）來度量資料質量
- 2.2.1. 公司會仔細度量當機時間，並投入大量資源來避免發生服務中斷的情況
2.3. 問題列表
-
2.3.1. 資料是最新的嗎？
-
2.3.2. 資料是完整的嗎？
-
2.3.3. 欄位是否在預期的範圍內？
-
2.3.4. 空值率是否高於或低於應有的水平？
-
2.3.5. 模式是否已經更改？
2.4. 可擴充套件性
- 2.4.1. 跟蹤大量的表和大資料集可能會非常棘手
2.5. 監控棧的其他部分
- 2.5.1. 構建真正可靠的資料管道並實現資料可觀測性需要的遠不只是收集指標這麼簡單
2.6. Snowflake
-
2.6.1. Snowflake是最流行的雲資料倉儲工具之一，其設計從一開始就優先考慮了資料質量和資料完整性
-
2.6.2. 對映清單
-
2.6.3. 監控資料的新鮮度和容量
- 2.6.3.1. 度量檢視的新鮮度和容量並不簡單，因為這是底層查詢指令中包含的表的函式
-
2.6.4. 建立你的查詢歷史記錄
- 2.6.4.1. 擁有在Snowflake環境中執行的所有查詢的可靠歷史記錄是解決問題時非常有用的工具，它可以讓你準確瞭解最近一次寫入表的方式和時間
-
2.6.5. 健康檢查
2.7. 資料倉儲最重要的功能之一就是能夠直接從其中提取資料質量指標並將其視覺化以便進行簡單的分析
2.8. 為跟蹤資料質量指標而提取的資訊需要隨時能夠提供給團隊中的其他成員使用，特別是當事情發生變化或你正處於對資料管道進行根因分析的痛苦之中時
3. 查詢日誌
3.1. 問題
-
3.1.1. 誰在訪問這些資料？
-
3.1.2. 來自上游的哪裡？
-
3.1.3. 來自上游的哪裡？
-
3.1.4. 平均多久執行一次特定的轉換？
-
3.1.5. 有多少行會受到影響？
3.2. 查詢日誌表通常僅儲存某些天數的查詢歷史記錄，且其中所包含的資訊比資料質量計劃所需要的多得多
3.3. 一個處理資料質量指標查詢日誌的健壯的解決方案需要具有前瞻性，並將所需的指標和聚合儲存在一個更為永久的位置
4. 資料目錄
4.1. 資料棧中的另一個關鍵元素是資料目錄，它在理解資料質量方面起著重要的作用
-
4.1.1. 資料目錄作為後設資料清單，為投資者提供了評估資料可訪問性、健康狀況和位置所需的資訊
-
4.1.2. 不僅可以監測資料，還可以與機器學習和自動化相整合，讓資料更易於被發現、更具協作性，並且更符合當前組織、行業甚至政府的相關規則
4.2. 由於資料目錄提供了有關公司資料來源的單一真相來源，因此你可以很容易地利用資料目錄來管理管道中的資料
-
4.2.1. 資料目錄可以用來儲存後設資料，讓利益相關方更好地瞭解特定來源的沿襲，從而增強對資料本身的信任
-
4.2.2. 資料目錄可以方便地記錄個人身份資訊的存放位置和下游蔓延位置，以及組織中誰有權透過管道來訪問這些資訊
4.3. 問題
-
4.3.1. 應該在哪裡查詢資料？
-
4.3.2. 這些資料重要嗎？
-
4.3.3. 這些資料代表了什麼？
-
4.3.4. 這些資料的相關性和重要性如何？
-
4.3.5. 該如何使用這些資料？
4.4. 傳統上使用Excel來解決資料編目問題的方式
- 4.4.1. 自動化能夠讓資料工程師和分析師騰出時間來專注於真正能取得進展的專案
4.5. 當前儲存的大部分資料都是非結構化且高度流動的
-
4.5.1. 人們越來越需要根據資料的意圖和目的來理解資料，而不是簡單地描述消費者訪問和使用的資料
-
4.5.2. 資料編目可以發現並組織恰當的後設資料來解釋你的資料管道
4.6. 構建資料目錄
-
4.6.1. 在構建或投資資料目錄之前，你需要與運營和分析團隊的下游利益相關方一起合作，瞭解哪些資料對業務最為重要，從而需要進行記錄和編目
-
4.6.2. 最基本的，資料目錄是後設資料集合，可提供對資料位置、所有權和潛在用例的背景資訊和洞察
-
4.6.3. Sqlparse、ANTLR、Apache Calcite和MySQL的SQL Parser都是流行的開源SQL解析解決方案
-
4.6.4. GraphQL、REST和Cube.js等開源查詢語言工具將允許你在資料庫中查詢SQL並將其呈現在編目視覺化服務中
-
4.6.5. Amundsen、Apache Atlas、DataHub或CKAN
-
4.6.6. 當你擁有嚴格的模型時，資料目錄的效果很好，但隨著資料管道變得越來越複雜，非結構化資料開始成為黃金標準，我們對資料的理解（資料做什麼、誰在使用它、如何使用它）並不能反映現實情況
-
4.6.7. 下一代資料目錄將具有學習、理解和推斷資料的能力，讓使用者能夠以自助式服務的方式利用其洞察力
- 4.6.7.1. 資料目錄將支援自動資料發現和主動後設資料
-
4.6.8. 資料管理策略還必須包含資料發現，這是一種實時瞭解分散式資料資產健康狀況的新方法
-
4.6.8.1. 資料發現借鑑了Zhamak Dehghani和Thoughtworks的資料網格模型提出的面向領域的分散式架構，認為不同的資料所有者都應對其資料產品負責，並推動不同位置的分散式資料之間的通訊
-
4.6.8.2. 一旦資料被提供給某一特定領域並在該領域轉換後，該領域資料的所有者就可以利用這些資料來滿足其自身的運營或分析需求
-
-
4.6.9. 資料發現取代了對資料目錄的需要，它根據一組特定消費者如何攝取、儲存、聚合和使用資料，提供了對特定領域資料的動態解讀
-
4.6.9.1. 資料治理的標準和工具同樣是跨領域聯合的，以支援更高的可訪問性和互操作性
-
4.6.9.2. 資料發現可以實時瞭解資料的當前狀態，而不是其理想狀態或“編目”狀態
-
4.7. 以資料質量為優先的資料目錄
-
4.7.1. 自助式服務的資料發現與自動化
-
4.7.1.1. 即使沒有專門的支援團隊，資料團隊也應該能輕鬆利用其資料目錄
-
4.7.1.2. 自助式服務、自動化和工作流編排等資料工具消除了資料管道各階段之間及其過程中產生的孤島，讓資料變得更容易理解和訪問
-
4.7.1.3. 更高的可訪問性自然會提高資料的採用率，從而減輕資料工程團隊的負擔
-
-
4.7.2. 隨資料演變的可擴充套件性
- 4.7.2.1. 隨著公司接收越來越多的資料且非結構化資料開始成為常態，透過擴充套件來滿足這些需求的能力對於資料計劃的成功將變得至關重要
-
4.7.3. 用於分散式資料發現的資料沿襲
-
4.7.3.1. 資料發現嚴重依賴自動化表格和欄位級的沿襲來對映資料資產之間的上下游依賴關係
-
4.7.3.2. 資料發現讓資料團隊能夠相信團隊對資料的假設與現實相符，從而在不考慮領域的前提下，在資料基礎設施中實現動態發現和高度的可靠性
-
4.7.3.3. 你的團隊可能已經以某種方式在資料發現方面進行了投資，無論是透過團隊為驗證資料而正在進行的手動工作，還是透過工程師編寫的自定義驗證規則，或者僅僅是基於損壞的資料或未被察覺的隱性錯誤所做出的決策成本
-
4.8. 要獲得真正可發現的資料，很重要的一點在於資料不僅要“編目”，而且從攝取到利用這一過程要準確、乾淨且完全可觀測
-
4.8.1. 要可靠
-
4.8.2. 只有瞭解你的資料及其狀態，以及在其生命週期的所有階段和跨領域的使用方式，我們才能開始信任它