1. 合作角色

1.1. 資料分析師

1.2. 資料科學家

1.3. MLOps/機器學習工程師

1.4. 業務側

1.4.1. 資料或非技術的利益相關者、經理和高管

1.5. 資料工程師更多的是在支援這些利益相關者的工作，不一定對資料的最終使用方式負責

1.6. 資料工程師負責的是產出高質量的資料產品

1.6.1. 在資料服務階段，資料工程師的一項重要任務是將職責和工作內容分離

1.7. 資料工程走到了交付階段後會產生反饋迴圈

1.7.1. 資料很少以靜態存在，外部環境會影響到被獲取和提供的資料，以及被二次獲取和提供的資料

1.8. 採用資料網格會在很大程度上重新分配團隊職責，每個領域的團隊都需要承擔各種提供資料服務的任務

2. 底層設計

2.1. 資料服務是資料工程生命週期底層設計的最後一部分內容

2.1.1. 資料生命週期是一個閉環，在環中的一切都是一脈相承的
2.1.2. 資料工程師需要一直尋找底層設計框架下能夠幫助資料產品提升的方法

2.2. 資料是一個無聲的殺手

2.2.1. 提供資料服務是確保交付到終端使用者手中的資料質量的最後一道屏障

2.3. 安全

2.3.1. 資料服務是最能體現資料安全必要性的一環
2.3.2. 對人和系統都要一如既往地推行最小許可權的原則，只提供僅供當前工作所需的訪問
2.3.2.1. 切忌對任何個人或任何服務給予完全開放許可
2.3.3. 提供資料服務一般只涉及只讀許可權，除非人或程式需要更新被查詢系統中的資料
2.3.3.1. 使用者訪問許可權要限定在對特定資料庫和資料集的只讀許可權，除非他們的工作必須使用更高階的許可權，如寫入或更新訪問
2.3.3.2. 許可權控制可以透過為使用者組分配具有某些IAM角色（即分析師組、資料科學家組）或自定義IAM角色來完成
2.3.4. 訪問控制應該儘可能地細化，並在不需要時收回
2.3.5. 訪問控制在多租戶環境中提供資料服務時是至關重要的
2.3.5.1. 確保使用者只能訪問他們自己的資料
2.3.5.2. 過有過濾條件的檢視來調整查詢結果，從而減弱公用表的安全風險
2.3.5.3. 工作流中使用資料共享，這樣就可以對資料使用方有隻讀粒度控制
2.3.6. 要檢查資料產品的使用頻率，以及考慮停止共享一些無用的資料產品
2.3.6.1. 如果資料產品沒有在使用，就去問問使用者是否還需要它們
2.3.6.2. 如果不需要，那就把該資料產品停掉，可以減少一個安全漏洞
2.3.7. 訪問許可權控制和安全不應該是資料服務的障礙，恰恰相反，它們是推動資料服務的關鍵因素
2.3.7.1. 由於安全措施沒有得到正確落實，有用的資料可能很少能被訪問
2.3.7.2. 細緻、健壯的訪問許可權控制意味著可以進行更有價值的資料分析和機器學習，同時對企業及其客戶也是一種保護

2.4. 資料管理

2.4.1. 關注點是確保人們能夠獲得高質量和值得信賴的資料
2.4.2. 信任是資料服務中最關鍵的因素
2.4.2.1. 如果人們信任他們的資料，就會使用它
2.4.2.2. 不受信任的資料會被閒置
2.4.2.3. 一定要收集使用者的反饋，使資料信任和資料改進走向良性迴圈
2.4.2.4. 當使用者與資料互動時，要讓他們能夠報告問題並提出改進
2.4.2.5. 在響應改進需求時，也要積極地與使用者進行溝通
2.4.3. 使用資料脫敏手段可以向終端使用者提供合成、打亂或匿名的資料
2.4.3.1. “假”資料集應該足以讓分析師或資料科學家從資料中獲得必要的有用資訊，且可以防止暴露現實世界的實體
2.4.3.2. 在一些強力的資料處理方法下，許多資料集可以被實名或者逆向工程，但這些脫敏手段或多或少地降低了資料洩露的風險
2.4.4. 將語義層和度量層納入資料服務層，同時建立可以正確表達業務邏輯和定義的嚴謹資料模型，能夠為分析、機器學習、反向ETL或其他服務用途提供可信單一資料來源

2.5. DataOps

2.5.1. 資料管理，也就是資料質量、資料治理和資料安全，都應該在DataOps的監控下
2.5.2. 監控的內容
2.5.2.1. 資料健康程度和資料不可用時間
2.5.2.2. 用來提供資料服務的儀表板、資料庫等系統的延遲
2.5.2.3. 資料質量
2.5.2.4. 資料以及系統的安全性和訪問許可權
2.5.2.5. 提供的資料和模型的版本
2.5.2.6. 達到SLO標準的可用時間
2.5.3. 流行的資料可觀測性工具旨在減少資料不可用時間和提高資料質量
2.5.4. 可觀測性工具可以從資料領域跨越到機器學習領域，支援對模型和模型效能的監控
2.5.5. 傳統的DevOps監控對DataOps也很重要
2.5.6. 資料工程生命週期的每個階段都要對程式碼進行版本控制並將程式碼部署可操作化
2.5.7. 使用多階段的部署（開發、測試、生產）分析報告和模型

2.6. 資料架構

2.6.1. 在提供資料服務階段，使用者反饋迴圈要快速且緊密
2.6.2. 應該讓使用者能夠儘快訪問所需資料

2.7. 編排

2.7.1. 資料服務是資料工程生命週期的最後階段
2.7.2. 編排不僅僅是一種將複雜工作變得有組織和自動化的方式，也是協調跨團隊資料流的手段，以便在承諾的時間內將資料提供給消費者
2.7.3. 誰來負責資料任務編排是一個關鍵的組織決策
2.7.3.1. 非集中式方法讓小型團隊能夠管理自己的資料流，但增加了跨團隊協調的負擔
2.7.3.2. 團隊不能只管理單一系統內的資料流，而需要直接觸發屬於其他團隊的DAG或任務，各團隊必須跨系統傳遞訊息或查詢
2.7.3.3. 集中式方法意味著工作更容易協調，但把關也必須存在，以保護唯一的生產環境
2.7.3.4. 集中式的編排需要高標準、自動化的DAG測試和對系統的把關

2.8. 軟體工程

2.8.1. 許多向終端使用者提供資料服務的方法湧現出來，而資料工程師的重點變成了瞭解這些系統如何工作以及如何交付資料
2.8.2. 資料工程師需要負責的另一部分任務是瞭解程式碼和查詢對儲存系統的效能影響
2.8.3. 基礎設施即程式碼的興起意味著之前專注寫程式碼的角色正在轉向構建可以支援資料科學家和分析師的系統
2.8.3.1. 資料工程師可能會負責建立CI/CD管道併為資料科學家和分析師的資料團隊建立資料流程
2.8.3.2. 資料工程師也會培訓和支援這些資料團隊使用資料工程師所建立的Data/MLOps基礎設施，以便這些資料團隊走向自給自足
2.8.4. 對於嵌入式分析，資料工程師需要與應用程式開發人員合作，以確保查詢能夠快速且經濟有效地返回
2.8.4.1. 應用程式開發人員負責面向使用者的前端程式碼，資料工程師負責讓前端收到準確的資料
2.8.5. 優秀的資料工程師總是樂於接受新的反饋，並不斷改進

3. 分析

3.1. 最常見的資料服務用例是分析

3.2. 分析指的是發現、探索、識別以及讓資料中的關鍵洞見和模式變得可見

3.3. 分析是透過統計方法、報告和BI工具等進行的

3.4. 作為資料工程師，瞭解各種工具和分析方法是完成工作的關鍵

4. 業務分析

4.1. 業務分析是一門科學，也是一門藝術

4.1.1. 業務分析會運用歷史和新產生的資料來做策略性的且可執行的決策

4.2. 透過統計資料和趨勢分析以及領域專家和人為判斷的共同配合，來做出會影響長期業務走向的決策

4.2.1. 好的分析師往往能夠參與到業務當中，並且可以深入資料回答問題，解密隱藏或者反直覺的趨勢和洞見
4.2.2. 可以和資料工程師一同來為資料質量、可靠性問題以及新的資料集需求提供參考意見
4.2.3. 資料工程師則需要負責落地這些參考意見並且為分析師提供新的資料集
4.2.3.1. 需要考慮對現有和未來資料的各種潛在應用
4.2.3.2. 資料工程師必須使用最合適的後端技術方案來為業務分析提供資料服務

4.3. 儀表板

4.3.1. 能簡明扼要地將反映組織執行情況的幾個核心指標展示給決策層
4.3.1.1. 透過視覺化（圖表或熱力圖等）、彙總統計，甚至是單個數字來展示
4.3.2. 最高決策層會看頂層儀表板，而他們的直屬下級會看帶有特定指標、KPI或者OKR（Objective and Key Result，目標和關鍵成果）的儀表板
4.3.3. Tableau、Looker、Sisense、Power BI，以及Apahe Superset/Preset

4.4. 報告

4.4.1. 業務利益相關者會要求分析師建立報告
4.4.2. 使用報告的目的是利用資料得出洞見和決策
4.4.3. 調查結果被彙總在一份報告中，並在儀表板所在的同一BI工具中釋出

4.5. 專項分析

4.5.1. 深入探究某個潛在的問題併產出洞見，這就是專項分析的一個案例
4.5.2. 調查報告通常以專項需求作為起始
4.5.3. 如果專項分析的產出有影響力，那麼就會演變成一個報告或儀表板

4.6. 報告、專項分析和儀表板用的都是類似的工具，比如Excel、Python、基於R的notebook、SQL查詢等

4.7. 業務分析資料常常以批處理模式從資料倉儲或者資料湖供應

4.8. 為用例提供資料服務時，不同的更新頻率經常混合在一起使用

4.8.1. 從上游獲取資料的頻率是下游所使用資料更新頻率的上限
4.8.2. 如果資料是由流式應用產生的，那麼資料就應該透過流式獲取，即使下游使用批處理方式做資料的處理和服務也應如此

4.9. 在資料湖或者資料倉儲中執行查詢

4.9.1. 優點是可以更好發揮OLAP資料庫的能力
4.9.2. 缺點是成本、許可權控制，以及時延方面的問題

5. 運營分析

5.1. 運營分析是用資料來進行即時的操作

5.1.1. 在工廠部署實時分析
5.1.1.1. 使用現成的雲機器視覺工具來自動實時識別次品

5.2. 運營分析與業務分析=即時操作與可供執行的洞見

5.2.1. 隨著流資料和低延遲資料更加普遍，用運營分析的方法解決業務分析的問題才是正確的思路
5.2.2. 資料架構會變成可以讓“熱到發燙”的低時延流資料和暖資料共存一處

5.3. 差異體現在時間上：業務分析用的資料是從更長遠的角度看待所考慮的問題

5.3.1. 秒級的資料更新是很好的，但是並不會實質性地影響分析結果
5.3.2. 運營分析則恰恰相反，資料更新的實時程度對解決時下發生的問題有很大的影響

5.4. 例子是應用程式的實時監控

5.4.1. 如果系統達到某個閾值，監控系統也可以透過簡訊、群聊通知和郵件傳送告警

5.5. 正確的行動才會產生影響力和價值

5.5.1. 沒有促成行動的實時資料只會變成一團亂麻

5.6. 從長遠看，流資料會逐漸取代批處理資料

5.6.1. 未來十年的資料產品更有可能是流優先，並且有能力無縫銜接歷史資料
5.6.2. 實時採集的資料仍然可以按需求以批處理的形式來消費和處理

6. 嵌入式分析

6.1. 業務分析和運營分析更多關注於組織內部，而面向外部的，也就是嵌入式分析成了最新的趨勢

6.2. 向終端使用者提供更多的分析結果

6.2.1. 資料應用程式，多數在應用程式內部嵌入了分析儀表板
6.2.2. 面向終端使用者儀表板的嵌入式分析可以給使用者提供他們和應用相關聯的關鍵指標

6.3. 資料工程師一般不會去開發嵌入式分析的前端

6.3.1. 專業的應用程式開發人員來做這項工作

6.4. 資料工程師要維護嵌入式分析使用的資料庫，因此需要了解嵌入式分析的速度和時延要求

6.5. 提高嵌入式分析的效能需要解決三個問題

6.5.1. 使用者都希望獲得低延遲的資料
6.5.1.1. 應用程式的使用者不會像公司內的分析師那樣容忍批處理
6.5.2. 使用者想要更高的查詢效率
6.5.3. 支援高併發就是非常關鍵的
6.5.3.1. 需要支援發生在多個儀表板和眾多使用者中非常高的查詢率

6.6. 轉向新一代擁有快速查詢、高併發，以及近實時更新並且易用（例如基於SQL的分析）的高效能資料庫