讀資料工程之道：設計和構建健壯的資料系統30機器學習

1. 機器學習

1.1. 機器學習正在變得普遍

• 1.1.1. 機器學習、資料科學、資料工程以及機器學習工程的界限正在變得模糊，並且在各個組織內部都形態各異

1.2. 現狀

• 1.2.1. 某些組織中，機器學習工程師負責處理為機器學習應用程式處理收集到的資料，有時甚至會形成獨立且平行工作的資料組織來處理整個機器學習應用程式生命週期的資料

• 1.2.2. 在另一些組織中，資料工程師負責全部的資料處理流程，然後向機器學習工程師交付模型訓練用的資料

1.3. 瞭解典型的機器學習原理和深度學習基礎是很有幫助的

• 1.3.1. 瞭解基礎知識可以很大程度地幫助資料工程師來和資料科學家共同構建資料產品

1.4. 瞭解的機器學習領域

• 1.4.1. ①監督學習、非監督學習、半監督學習的差別

• 1.4.2. ②分類和迴歸技術的差別

• 1.4.3. ③處理時間序列資料的不同手段

• 1.4.3.1. 時間序列分析

• 1.4.3.2. 時間序列預測

• 1.4.4. ④基礎的機器學習知識可以幫助發現機器學習技術是否合適，以及界定所需資料的邊界

• 1.4.4.1. 當在“典型的”方法（邏輯迴歸、基於樹的學習、支援向量機）和深度學習之間進行選擇時，儘管可能是殺雞用牛刀，但資料科學家還是常常立馬選擇深度學習

• 1.4.5. ⑤什麼時候用自動機器學習(AutoML)

• 1.4.6. ⑥用於結構化和非結構化資料的資料整理技術有哪些？

• 1.4.7. ⑦如何編碼分類資料和各種型別資料的嵌入？

• 1.4.8. ⑧批次學習和線上學習的差別

• 1.4.9. ⑨資料工程生命週期和機器學習生命週期在公司內怎樣產生交集？

• 1.4.10. ⑩什麼時候用GPU比用CPU更好？

• 1.4.10.1. 硬體選型取決於需要解決的機器學習問題的種類、使用的技術以及資料集大小

• 1.4.11. ⑾批處理和流資料在機器學習模型訓練中的不同應用

• 1.4.11.1. 批處理資料更適合離線模型訓練

• 1.4.11.2. 流資料更適合線上學習

• 1.4.12. ⑿資料級聯是什麼

• 1.4.13. ⒀機器學習的結果是實時返回的還是批次返回的

• 1.4.13.1. 一個批處理的講話字幕生成模型會處理語音樣本並且透過API呼叫的方式批次返回文字

• 1.4.13.2. 一個產品推薦模型可能需要實時運作來支援客戶和線上零售網站的互動

• 1.4.14. ⒁對於結構化和非結構化資料的運用

• 1.4.14.1. 用神經網路聚類表格（結構化）客戶資料

• 1.4.14.2. 識別影像（非結構化）

• 1.4.15. ⒂本地訓練、叢集訓練或者邊緣訓練的適用場景

2. 為分析和機器學習提供資料服務的方法

2.1. 為機器學習提供資料服務和為分析提供資料服務並列討論的原因是它們的管道和流程非常相似

2.2. 檔案交換

• 2.2.1. 檔案交換在資料服務的過程中無所不在

• 2.2.1.1. 資料被處理並生成檔案傳送給資料消費者

• 2.2.2. 檔案可以有各種用途

• 2.2.2.1. 資料科學家可能載入客戶訊息的文字文件（非結構化資料）來分析客戶投訴的情緒

• 2.2.3. 因素

• 2.2.3.1. 用例

>  2.2.3.1.1. 業務分析

>  2.2.3.1.2. 運營分析

>  2.2.3.1.3. 嵌入式分析

• 2.2.3.2. 資料消費者的資料處理流程

>  2.2.3.2.1. 需要透過檔案而不是資料共享提供資料服務，因為資料消費者無法使用資料共享平臺

• 2.2.3.3. 儲存中單個檔案的大小和數量

• 2.2.3.4. 誰在訪問這個檔案

• 2.2.3.5. 資料型別

>  2.2.3.5.1. 結構化

>  2.2.3.5.2. 半結構化

>  2.2.3.5.3. 非結構化

• 2.2.4. 提供檔案的最簡單辦法是用郵件傳送單個Excel檔案

• 2.2.4.1. 檔案偏差不可避免

• 2.2.4.2. 如果檔案已經透過郵件傳送出來了，那麼收回的手段就很有限了

• 2.2.5. 如果想要維護的檔案版本連續和一致，那麼最好採用Microsoft 365或者Google Docs這樣的協作平臺

• 2.2.6. 僅靠傳檔案是很難擴充套件功能的，而且需求最終會膨脹到超出簡單的雲檔案儲存

• 2.2.6.1. 如果檔案又大又多，就需要考慮物件儲存了

• 2.2.6.2. 物件儲存可以儲存任何型別的二進位制大檔案，特別適合半結構化或者非結構化檔案

• 2.2.6.3. 如果需要穩定的檔案供應，就要用資料湖

• 2.2.7. 透過選擇物件儲存（資料湖）進行的、以資料共享為基礎的資料傳輸，明顯要比單純的點對點檔案傳輸更有擴充套件性和效率

2.3. 資料庫

• 2.3.1. 資料庫是為分析和機器學習提供資料服務的關鍵層

• 2.3.1.1. 管理資料服務層的任務一般會安排給資料工程師，包括效能和成本的管理

• 2.3.1.2. 存算分離的資料庫與那些固定本地部署的基礎設施相比可以說是做了些許的最佳化

• 2.3.2. 資料庫透過模式來維護資料的順序和結構

• 2.3.3. 資料庫也能針對表、列、行提供細粒度的許可權控制，允許資料庫管理員為不同角色建立複雜的訪問控制規則

• 2.3.4. 資料庫可以為大型、計算密集型查詢和高查詢併發性提供高服務效能

• 2.3.5. BI系統通常會利用源資料庫的資料處理能力，但是這兩個系統中處理之間的界限有所不同

• 2.3.6. 查詢下推的計算模型

• 2.3.7. 資料科學家也會連線資料庫、提取資料、執行特徵工程和選擇

• 2.3.7.1. 然後將轉換後的資料集輸入到機器學習模型

• 2.3.7.2. 這個離線模型訓練好後就可以產生預測結果了

• 2.3.8. 效能的關注點：延遲、查詢效能和併發

• 2.3.8.1. 從流中直接獲取資料的系統可以降低資料延遲

• 2.3.8.2. 多資料庫架構使用了SSD或者記憶體快取來增強查詢效能和併發性，以滿足高要求的嵌入式分析用例

• 2.3.8.3. Snowflake和Databricks這樣的資料平臺開始允許分析師和資料科學家在單個環境下工作，並在同一套介面下提供了SQL編輯器以及資料科學notebook

>  2.3.8.3.1. 存算分離，所以分析師和資料科學家可以在互不影響的狀態下使用底層資料

>  2.3.8.3.2. 將允許向利益相關者提供高吞吐量和快速交付的資料產品

2.4. 流式系統

• 2.4.1. 發散指標(emitted metric)

• 2.4.2. 運營分析資料庫在這個領域變得越來越重要

• 2.4.2.1. 可以執行大範圍歷史資料查詢，包括查詢最新的當前資料

• 2.4.2.2. 一個必要的設計點是將OLAP資料庫的特點和流處理系統相結合

2.5. 聯邦查詢

• 2.5.1. 聯邦查詢越來越受歡迎，人們意識到它的分散式查詢虛擬引擎在提供查詢服務時不需要解決OLAP系統中集中化的資料帶來的問題

• 2.5.1.1. Trino和Presto這樣的OSS選項以及諸如Starburst這樣的完全託管服務

• 2.5.2. 如果聯邦查詢需要接觸生產環境的源系統，則一定要保證聯邦查詢不會消耗過多的源系統資源

• 2.5.3. 當需要資料分析具有靈活性或者使用處在嚴格控制下的源資料時，聯邦查詢非常適合

• 2.5.3.1. 聯邦查詢是訪問許可權和規章都很嚴苛的條件下的優秀選項

• 2.5.4. 聯邦查詢能夠透過點對點的查詢進行探索性分析，將不同的系統資料混合的同時又避開了搭建資料管道或者ETL的複雜性

• 2.5.5. 選型決定

• 2.5.5.1. 是聯邦查詢就能滿足眼前的需求，還是需要將所有需要的資料都獲取到並且透過OLAP資料庫或者資料湖將其中心化

• 2.5.6. 聯邦查詢同時提供源系統的只讀許可權，這是非常好的一點，尤其是應對你不想提供檔案、資料庫訪問許可權、或者資料轉儲的場景

• 2.5.6.1. 終端使用者只讀取他們需要看到的那版資料

2.6. 資料共享

• 2.6.1. 任何組織間或者大組織中部門間的資料交換行為都可以看作資料共享

• 2.6.2. 資料共享特指透過雲環境中的大規模多租戶儲存系統進行共享

• 2.6.3. 資料共享通常會將資料服務轉換成安全和訪問控制問題

• 2.6.4. 現實中的查詢常常由資料消費方（分析師和資料科學家）而不是由釋出資料的工程師處理

• 2.6.5. 無論是在組織內部的資料網格中提供資料服務、向公眾提供資料服務，還是向合作伙伴提供資料服務，資料共享都是一個引人注目的資料服務模式

2.7. 語義和度量層

• 2.7.1. 當輸入低質量的資料或查詢時，強大的查詢引擎只會快速返回不準確的結果

• 2.7.2. 好的資料質量依賴資料自身的特徵，另外還需要透過各種技術過濾或改進不良資料

• 2.7.3. 高質量查詢是具有適當的邏輯，可以準確回答業務問題的查詢

• 2.7.3.1. 構建高質量的ETL查詢和報告是費時費心的

• 2.7.3.2. 很多工具可以自動化該構建過程，同時又能促進一致性、可維護性和持續改進

• 2.7.4. 度量層是維護和計算業務邏輯的工具

• 2.7.4.1. 語義層在概念上和度量層極為相似，而無頭BI是另一個密切相關的術語

• 2.7.5. Looker的LookML工具允許使用者定義虛擬的、複雜的業務邏輯

• 2.7.5.1. Looker更多關注查詢和報告

• 2.7.6. dbt允許使用者定義複雜的SQL資料流，其中囊括許多查詢和業務指標的標準定義，這項功能很像Looker

• 2.7.6.1. dbt是為分析工程師而生的功能強大的資料管道編排工具

2.8. 利用notebook提供資料服務

• 2.8.1. 都可能會使用notebook。在撰寫本書時，最流行的notebook是Jupyter Notebook，以及它的下一代JupyterLab

• 2.8.1.1. Jupyter是開源的，可以託管在筆記本計算機、伺服器或各種雲託管服務上

• 2.8.2. 在notebook中，所有的連線都是使用相應的內建庫或外部庫來建立的，以便從某個路徑載入檔案、連線到某個API端點，或對某個資料庫進行ODBC連線

• 2.8.3. pandas是一個常用的Python庫，用於操作和分析資料，常用於將資料（例如CSV檔案）載入到Jupyter Notebook中

• 2.8.4. 憑證處理

• 2.8.4.1. 對notebook和資料科學程式碼中的訪問憑證的不當處理是重大的安全風險

• 2.8.4.2. 資料工程師需要負責稽核資料科學程式碼採用的安全措施，並與資料科學家合作進行改進

• 2.8.4.3. 資料工程師應該為處理憑證設定標準

• 2.8.4.4. 憑證不能直接嵌入程式碼中，資料科學家需要使用憑證管理器或CLI工具來管理訪問許可權

• 2.8.5. 當資料集的大小超過本地機器的可用記憶體時

• 2.8.5.1. 改用基於雲的notebook，可以靈活地擴充套件底層儲存和記憶體

• 2.8.5.2. 考慮分散式執行系統，基於Python的常用選項有Dask、Ray和Spark

• 2.8.5.3. 使用一套開源的端到端機器學習工作流工具，如Kubeflow和MLflow，可以分別在Kubernetes和Spark中輕鬆擴充套件機器學習工作負載

• 2.8.6. 資料工程師和機器學習工程師是促進向可擴充套件雲基礎設施轉移的重要力量，具體的分工取決於組織的實際情況

• 2.8.7. notebook用於“小微專案”的上線，完整生產流程用於高價值的專案

3. 反向ETL

3.1. 將資料從OLAP資料庫供應回源系統

• 3.1.1. 資料工程師可能從CRM中拉取客戶和訂單資料，並儲存在資料倉儲中

• 3.1.2. 資料可以訓練出一個線索評分模型，模型的產出又返回到資料倉儲中

3.2. 好的資料產品需要減少與終端使用者的摩擦

3.3. 用反向ETL將評分後的線索載入回CRM中是最簡單和最好用的方法

• 3.3.1. 雙向載入和轉換(Bidirectional Load and Transform，BLT)

3.4. 反向ETL從資料工程生命週期的輸出端獲取處理過的資料，並將其反饋回源系統中

3.5. 反向ETL本質上會產生反饋迴圈

• 3.5.1. 要小心利用反向ETL，需要密切監控並防止失控