讀資料工程之道：設計和構建健壯的資料系統28資料服務常見關注點

1. 使用場景

1.1. 為分析和BI，也就是統計分析、報表和儀表板提供資料服務

• 1.1.1. 是資料服務最為常見的目標

• 1.1.2. 這些概念的提出早於IT和資料庫，但是它們對於瞭解業務、組織和財務流程的利益相關者來說仍然至關重要

1.2. 為機器學習應用程式提供資料服務

• 1.2.1. 機器學習完全依賴於高質量的資料

• 1.2.2. 資料科學家和機器學習工程師需要在資料工程師的幫助下來獲取、轉化以及交付必要的資料，從而訓練模型

1.3. 為反向ETL提供資料服務

• 1.3.1. 反向ETL是一種將資料回傳給資料來源的過程

• 1.3.2. 反向ETL和BI以及機器學習有著深度的共生關係

2. 常見關注點

2.1. 信任

• 2.1.1. 人們需要相信你提供的資料

• 2.1.2. 花20年建立的名譽可能只需要5分鐘就可以毀掉。如果你明白這一點，你就會換種方式做事情。

• 2.1.2.1. 沃倫·巴菲特(Warren Buffett)

• 2.1.3. 信任一旦丟失就極難挽回

• 2.1.3.1. 不可避免的結局是業務方不能發揮資料的潛在價值，資料團隊也會丟失信譽（甚至被解散）​

• 2.1.4. 信任是提供資料服務的根本關注點

• 2.1.4.1. 終端使用者需要信任他們接收的資料

• 2.1.4.2. 失去信任通常是資料專案無聲的表鍾，即使這個專案直到幾個月或幾年後才正式取消

• 2.1.5. 利用資料驗證流程以及資料可觀測性流程，同時與利益相關者一起目視檢查和確認資料有效性

• 2.1.5.1. 資料驗證使用資料分析方法來保證資料可以忠實反映財務資訊、客戶行為以及銷售記錄等資訊

• 2.1.5.2. 資料可觀測性提供了一個觀測資料和資料處理的持續檢視

• 2.1.6. SLA和SLO也是工程師建立終端使用者和上游利益相關者信任的必要手段

• 2.1.6.1. 當使用者開始依賴資料來完成業務需求時，會要求使用的資料有持續的可用性以及資料工程師保障的最新狀態

• 2.1.6.2. 高質量的資料在沒有達到預期內的可用性時很難發揮輔助商業決策的價值

• 2.1.6.3. SLA和SLO也可以採用正式或者非正式的資料契約形式

• 2.1.6.4. SLA都給了使用者對於資料產品的預期

• 2.1.6.5. SLO是SLA的關鍵部分，闡述了用於衡量契約的方法

• 2.1.7. 一定要確保各方的預期是清晰的，並且你有能力驗證能否滿足約定的SLA和SLO

• 2.1.8. 對SLA達成一致是不夠的

• 2.1.8.1. 持續的溝通才能維持一個好的SLA：對可能對SLA和SLO預期有影響的事項進行溝通，並提供補救和改進措施

2.2. 用例是什麼，使用者又是誰

• 2.2.1. 需要了解你的用例和使用者、產出的資料產品以及如何提供資料服務（是否自助服務）​、資料定義和邏輯，以及資料網格

• 2.2.2. 資料服務層是為了資料的使用

• 2.2.2.1. 資料在決策中的作用才是核心

• 2.2.3. 資料的用例遠遠超出了檢視報告和儀表板的範圍

• 2.2.3.1. 一份資料往往被用於多個用例

• 2.2.4. 高質量、高影響力的資料自然而然地會吸引很多很有趣的用例

• 2.2.5. 儘量挑選有著最高ROI的用例

• 2.2.5.1. 資料工程師喜歡糾結於他們搭建的系統的技術實現細節，而忽略目的

• 2.2.5.2. 當工程師能夠以價值和用例為導向時，產出就能更有價值和效率

>  2.2.5.2.1.             很多工程師只想做最擅長的事情：搞工程

• 2.2.6. 當開啟一個新的資料專案時，倒排工序是很有必要的

• 2.2.7. 問自己的一些問題

• 2.2.7.1. 誰會使用這些資料？怎麼用？

• 2.2.7.2. 利益相關者有什麼期望？

• 2.2.7.3. 怎麼和資料利益相關者（資料科學家、分析師、業務使用者）合作，更好地瞭解這些資料的用途？

• 2.2.8. 在開展資料工程的時候，一定要從使用者及其用例入手

• 2.2.8.1. 在瞭解他們的期望和目標後，就會更容易產出優秀的資料產品

2.3. 資料產品

• 2.3.1. 資料產品的良好定義是能夠透過使用資料促成最終目標的產品。

• 2.3.1.1. D.J.Patil

• 2.3.2. 資料產品不是憑空產生的

• 2.3.2.1. 開發資料產品像是一項需要全身心投入的運動，在技術的框架下混合了產品和業務

• 2.3.2.2. 核心利益相關者參與資料產品的開發是非常重要的

• 2.3.2.3. 一個好的資料產品應該有著正反饋迴圈

>  2.3.2.3.1.             更多的資料產品使用產生更多的有用資料，產品也因此得以改進

• 2.3.3. 在大多數公司，資料工程師會負責除了終端使用者操作外的資料產品全流程

• 2.3.3.1. 優秀的資料工程師會盡力去了解提供給直接使用者（比如資料分析師、資料科學家或公司外部客戶）的產物

• 2.3.4. 當創造一個資料產品時，應該從“完成任務”的角度思考

• 2.3.4.1. 使用者為了“完成任務”才“僱用”資料產品

• 2.3.4.2. 常犯的錯誤是在不瞭解終端使用者的需求或者沒有產品市場調查的情況下盲目開發

• 2.3.5. 做人人都愛用的資料產品是很難的

• 2.3.5.1. 沒用的特性和失信的資料會破壞資料產品的採用

• 2.3.5.2. 需要專注在資料產品的採用和利用上，並且願意做出令使用者滿意的調整

2.4. 是否用自助服務

• 2.4.1. 讓使用者可以自己構建資料產品

• 2.4.2. 落地難度高，資料自助服務專案容易虎頭蛇尾

• 2.4.3. 如果面向的使用者是高管級別的，他們想知道業務執行情況，那麼一個清晰且有著可操作指標的預定義儀表板往往就足夠了

• 2.4.3.1. 如果報告揭示了更多問題，那麼他們可能會找分析師來深挖資料

• 2.4.4. 成功搭建自助服務資料專案從找對受眾開始，識別自助服務使用者和他們要做的“工作”​

• 2.4.5. 具備資料相關技術背景的業務主管，他們就很適合自助服務，他們可能想要自己對資料進行切片，而又不重拾SQL技能

• 2.4.6. 構建好的資料自助服務要確定如何為特定使用者提供資料服務

• 2.4.7. 更多的資料帶來更多的問題，而這又需要更多的資料來解決

• 2.4.8. 需要理解靈活性和範圍之間的微妙平衡，這將有助於你的受眾找到價值和洞見，而不會產生錯誤的結果和混亂

2.5. 資料定義和邏輯

• 2.5.1. 組織中利用資料看重的是它的準確性和可信度

• 2.5.1.1. 資料的準確性不僅僅是對源系統中事件值的忠實再現

• 2.5.1.2. 資料準確性包括了準確的資料定義和邏輯，這兩個要素必須融入資料的全生命週期，從源系統到資料管道，再到BI工具等

• 2.5.2. 資料定義指的是資料在一個組織中的共識

• 2.5.3. 資料邏輯規定了指標計算公式

• 2.5.3.1. 合適的邏輯必須融匯資料定義以及完整的統計方法

• 2.5.3.2. 要計算客戶流失率指標，就需要定義誰是客戶

• 2.5.3.3. 要計算淨利潤，就需要一系列的規則來規定從收入總額扣除哪些支出

• 2.5.4. 資料定義和邏輯的存在經常被認為是理所當然的，並且在組織內以組織知識(institutional

knowledge)的形式傳播

• 2.5.5. 組織知識有著自己的生態，很大程度上會以“奇聞”取代資料推動的洞見、決策和行動

• 2.5.6. 資料定義體現為多種形式，有些是顯式的，但是多數是隱式的

• 2.5.6.1. 隱式是指為查詢、儀表板或者機器學習提供資料服務時，資料和指標總是可以被持續準確地展示

• 2.5.7. 語義層可以整合業務定義和邏輯，使其可複用

• 2.5.7.1. 一次建設，全域性通用

• 2.5.7.2. 正規化是建設指標、計算規則和邏輯的物件導向思想的體現

2.6. 資料網格

• 2.6.1. 一種日益流行的資料服務提供方式

• 2.6.2. 資料網格從根本上改變了組織內部的資料服務提供方式

• 2.6.3. 與孤立的資料團隊服務於內部成員不同，資料網格需要每個業務領域的團隊同時擔負起去中心化的、點對點的資料服務的責任

• 2.6.3.1. 團隊要對其他團隊的資料消費負責

• 2.6.3.2. 資料必須都是開箱即用的