讀資料工程之道：設計和構建健壯的資料系統02資料工程師

躺柒發表於2024-10-08
工程師

1. 背景和技能

1.1. 資料工程是一個快速發展的領域，關於如何成為一名資料工程師仍然存在很多問題

1.2. 進入資料工程領域的人在教育、職業和技能方面有著不同的背景

  • 1.2.1. 每個進入該領域的人都應該投入大量的時間進行自學

1.3. 從一個鄰近的領域轉到資料工程是最容易的

  • 1.3.1. 軟體工程

  • 1.3.2. ETL開發

  • 1.3.3. 資料庫管理

  • 1.3.4. 資料科學

  • 1.3.5. 資料分析

  • 1.3.6. 這些學科傾向於“資料感知”​，併為組織中的資料角色提供良好的背景

1.4. 資料工程師還必須瞭解資料消費者（資料分析師和資料科學家）的需求以及資料對整個組織的更廣泛影響

1.5. 資料工程是一種整體實踐，最好的資料工程師透過業務和技術視角來看待他們的職責

2. 業務職責

2.1. 宏觀職責並不是資料工程師獨有的，而是對於任何在資料或技術領域工作的人來說都至關重要的職責

2.2. 知道如何與非技術人員和技術人員交流

  • 2.2.1. 溝通是關鍵，你需要能夠與整個組織的人建立融洽的關係和信任

  • 2.2.2. 關注組織層次結構、誰向誰報告、人們如何互動以及存在哪些孤島

2.3. 瞭解如何界定並收集業務和產品需求

  • 2.3.1. 你需要知道要構建什麼，並確保你的利益相關者同意你的評估

  • 2.3.2. 培養對資料和技術決策如何影響業務的意識

2.4. 瞭解敏捷、DevOps和DataOps的文化基礎

  • 2.4.1. 許多技術專家錯誤地認為這些實踐可以透過技術解決

2.5. 控制成本

  • 2.5.1. 當你能夠在提供巨大價值的同時保持低成本，你就會成功

2.6. 持續學習

  • 2.6.1. 資料領域讓人感覺像是在以光速變化

2.7. 一個成功的資料工程師總是會放大視野以瞭解大局，並探索如何為企業實現巨大價值

2.8. 經常看到資料團隊的成功基於他們與其他利益相關者的溝通，成敗很少取決於技術

3. 技術職責

3.1. 資料工程生命週期的底層設計

  • 3.1.1. 安全

  • 3.1.2. 資料管理

  • 3.1.3. DataOps

  • 3.1.4. 資料架構

  • 3.1.5. 編排

  • 3.1.6. 軟體工程

3.2. 資料工程師應該具有生產級軟體工程能力

3.3. 工程師現在使用託管開源和簡單的即插即用軟體即服務(Software-as-a-Service，SaaS)產品

3.4. 即使在一個更抽象的世界中，軟體工程最佳實踐提供競爭優勢，而能夠深入研究程式碼庫的深層架構細節的資料工程師在出現特定技術需求時可為他們的公司提供優勢

  • 3.4.1. 無法編寫生產級程式碼的資料工程師將受到嚴重阻礙，而且我們認為這種情況不會很快改變

3.5. 資料工程的主要語言

  • 3.5.1. SQL

  • 3.5.1.1. 資料庫和資料湖最常用的介面

  • 3.5.1.2. SQL是一個強大的工具，可以快速解決複雜的分析和資料轉換問題

  • 3.5.1.3. SQL的不合理有效性

>  3.5.1.3.1. 可以透過使用宣告式、集合論SQL語義來處理海量資料

>  3.5.1.3.2. 鑑於時間是資料工程團隊吞吐量的主要限制因素，工程師應該採用兼具簡單性和高生產率的工具

>  3.5.1.3.3. 專業的資料工程師可以識別SQL何時不是適合該工作的工具，並且可以選擇合適的替代方案並編寫程式碼

>  3.5.1.3.4. SQL專家可能會編寫查詢以在自然語言處理(Natural Language Processing，NLP)管道中對原始文字進行詞幹化和標記化，但也會認識到使用本機Spark進行編碼是這種受虐練習的更好替代方案

  • 3.5.2. Python

  • 3.5.2.1. 資料工程和資料科學之間的橋樑語言

  • 3.5.3. JVM語言

  • 3.5.3.1. Java和Scala

  • 3.5.3.2. 流行於Apache開源專案，例如Spark、Hive和Druid

  • 3.5.3.3. JVM通常比Python效能更高

  • 3.5.3.4. 可以提供對比Python API（例如，Apache Spark和Beam就是這種情況）更低階別的功能的訪問

  • 3.5.4. bash

  • 3.5.4.1. Linux作業系統的命令列介面(Command Line Interface，CLI)

  • 3.5.5. R、JavaScript、Go、Rust、C/C++、C#和Julia

  • 3.5.5.1. 事實證明，JavaScript作為雲資料倉儲中使用者定義函式的語言很受歡迎

  • 3.5.5.2. C#和PowerShell對於利用Azure和Microsoft生態系統的公司來說是必不可少的

3.6. 關注基本面以瞭解不會改變的東西

3.7. 關注持續的發展，瞭解該領域的發展方向

3.8. 新的正規化和實踐一直在被引入，你有責任與時俱進

3.9. 努力瞭解新技術將如何在生命週期中發揮作用

4. 角色的連續性

4.1. 資料工程師並非都從事相同型別的工作或擁有同樣的技能組合

4.2. 資料成熟度是一個瞭解公司在提高資料能力時將面臨的資料挑戰型別的有用指導

4.3. A型資料科學家

  • 4.3.1. A代表分析(Analysis)

  • 4.3.2. 專注於理解資料並從中獲得洞察力

4.4. B型資料科學家

  • 4.4.1. B代表構建(Building)

  • 4.4.2. 與A型資料科學家有著相似的背景，並擁有強大的程式設計技能

  • 4.4.3. B型資料科學家建立使資料科學在生產中發揮作用的系統

4.5. A型資料工程師

  • 4.5.1. A代表抽象化(Abstraction)

  • 4.5.2. 在這種情況下，資料工程師避免了無差別的繁重工作，保持資料架構儘可能抽象和直接，而不是重新發明輪子

  • 4.5.3. A型資料工程師主要透過使用完全現成的產品、託管服務和工具來管理資料工程生命週期

  • 4.5.4. A型資料工程師在各行各業、各種等級的資料成熟度的公司中工作

4.6. B型資料工程師

  • 4.6.1. B代表構建(Build)

  • 4.6.2. B型資料工程師建立資料工具和系統，以擴充套件和利用公司的核心競爭力和競爭優勢

  • 4.6.3. 在資料成熟度範圍內，B型資料工程師更常見於處於第2階段和第3階段（透過資料擴充套件和領先）的公司，或者當初始資料用例非常獨特且關鍵以至需要自定義資料工具來開始時

5. 組織內部的資料工程師

5.1. 資料工程師不是在真空中工作

5.2. 根據他們從事的工作，他們將與技術人員和非技術人員互動，並面對不同的方向（內部和外部）​

5.3. 面向內部與面向外部的資料工程師

  • 5.3.1. 面向外部的資料工程師通常與面向外部的應用程式的使用者保持一致

  • 5.3.1.1. 社交媒體應用程式、物聯網(Internet of Things，IoT)裝置和電子商務平臺

  • 5.3.2. 面向外部的資料工程帶來了一系列獨特的問題

  • 5.3.2.1. 面向外部的查詢引擎通常比面向內部的系統處理更大的併發負載

  • 5.3.2.2. 工程師還需要考慮對使用者可以執行的查詢進行嚴格限制，以限制任何單個使用者對基礎設施的影響

  • 5.3.2.3. 安全性對於外部查詢來說是一個更為複雜和敏感的問題，尤其是當查詢的資料是多租戶

  • 5.3.3. 面向內部的資料工程師通常關注對業務和內部利益相關者的至關重要的需求活動

  • 5.3.3.1. 為BI儀表板、報告、業務流程、資料科學以及ML模型建立和維護資料管道與資料倉儲

  • 5.3.4. 面向外部和麵向內部的職責經常混合在一起

  • 5.3.4.1. 在實踐中，面向內部的資料通常是面向外部的資料的先決條件

  • 5.3.5. 資料工程師有兩組使用者，他們對查詢併發性、安全性等有著截然不同的要求

6. 其他技術角色

6.1. 資料工程生命週期跨越許多責任領域

6.2. 資料工程師直接或間接（透過經理）與許多組織單位互動，擔任著各種角色的紐帶

  • 6.2.1. 資料工程師是資料生產者[如軟體工程師、資料架構師和DevOps或站點可靠性工程師(Site Reliability Engineer，SRE)]與資料消費者（如資料分析師、資料科學家和機器學習工程師）之間的樞紐

  • 6.2.2. 資料工程師將與運營角色的人員（如DevOps工程師）進行互動

6.3. 上游利益相關者

  • 6.3.1. 資料架構師

  • 6.3.1.1. 資料架構師的功能在抽象級別上與資料工程師相差無幾

  • 6.3.1.2. 資料架構師設計組織資料管理的藍圖，規劃流程、整體資料架構和系統

  • 6.3.1.3. 還充當組織技術和非技術方面之間的橋樑

  • 6.3.1.4. 成功的資料架構師通常有豐富的工程經驗所帶來的“戰鬥傷痕”​，使他們能夠指導和協助工程師，同時成功地將工程挑戰傳達給非技術業務利益相關者

  • 6.3.1.5. 實施跨孤島和業務部門管理資料的政策，指導資料管理和資料治理等全球戰略，並指導重大舉措

  • 6.3.1.6. 通常在雲遷移和未開發雲設計中發揮核心作用

>  6.3.1.6.1. 雲資料架構比本地系統更具流動性，因此傳統上涉及廣泛研究、較長交付週期、購買合同和硬體安裝的架構決策現在通常在實施過程中做出，只是更大戰略中的一個步驟
  • 6.3.1.7. 根據公司的資料成熟度和規模，資料工程師可能會與資料架構師的職責有重疊，或者承擔資料架構師的職責
>  6.3.1.7.1. 資料工程師應該對架構最佳實踐和方法有好的理解
  • 6.3.1.8. 資料架構師通常幫助設計作為資料工程師源系統的應用程式資料層
>  6.3.1.8.1. 還可以在資料工程生命週期的各個其他階段與資料工程師進行互動

  • 6.3.2. 軟體工程師

  • 6.3.2.1. 構建執行業務的軟體和系統

  • 6.3.2.2. 主要負責生成資料工程師將使用和處理的內部資料

  • 6.3.2.3. 資料工程師應該與軟體工程師一起工作，瞭解產生資料的應用程式、生成資料的數量、頻率和格式，以及任何其他會影響資料工程生命週期的因素

  • 6.3.3. DevOps工程師和站點可靠性工程師

  • 6.3.3.1. DevOps和SRE通常透過運營監控來生成資料

  • 6.3.3.2. 將他們歸類為資料工程師的上游，但他們也可能是下游，透過儀表板使用資料或直接與資料工程師互動以協調資料系統的操作

6.4. 下游利益相關者

  • 6.4.1. 資料科學家

  • 6.4.1.1. 建立前瞻性模型來進行預測和提供建議，然後根據實時資料評估這些模型，以各種方式提供價值

>  6.4.1.1.1. 具有前瞻性
  • 6.4.1.2. 根據常見的行業傳說，資料科學家花費70%～80%的時間來收集、清洗和準備資料
>  6.4.1.2.1. 這些數字通常反映了不成熟的資料科學和資料工程實踐

>  6.4.1.2.2. 許多流行的資料科學框架如果沒有適當地進行擴充套件，可能會成為瓶頸

>  6.4.1.2.3. 只在單一工作站上工作的資料科學家強迫自己對資料進行下采樣，這使得資料準備變得更加複雜，並可能影響他們製作的模型的質量

>  6.4.1.2.4. 資料工程師應該儘可能地將這項工作自動化
  • 6.4.1.3. 對生產就緒資料科學的需求是資料工程專業興起的重要驅動力
>  6.4.1.3.1. 資料工程師應該幫助資料科學家實現一條生產路徑

  • 6.4.2. 資料分析師

  • 6.4.2.1. 尋求瞭解業務績效和趨勢

  • 6.4.2.2. 通常關注過去或現在

  • 6.4.2.3. 通常在資料倉儲或資料湖中執行SQL查詢

  • 6.4.2.4. 利用電子表格進行計算和分析，以及各種BI工具

  • 6.4.2.5. 資料分析師是資料領域的專家，他們經常處理資料並且非常熟悉資料的定義、特徵和質量問題

  • 6.4.2.6. 資料分析師的典型下游客戶是業務使用者、管理層和高管

  • 6.4.2.7. 資料工程師與資料分析師合作，為業務所需的新資料來源構建管道

>  6.4.2.7.1. 資料分析師的主題專業知識對於提升資料質量非常有價值，他們經常以這種身份與資料工程師合作

  • 6.4.3. 機器學習工程師和人工智慧研究人員

  • 6.4.3.1. 機器學習工程師（ML工程師）與資料工程師和資料科學家重疊

  • 6.4.3.2. ML工程師開發先進的ML技術、訓練模型以及設計和維護在規模化生產環境中執行ML流程的基礎設施

  • 6.4.3.3. ML工程師通常具有ML和深度學習技術及框架（如PyTorch或TensorFlow）的高階工作知識

  • 6.4.3.4. ML工程的世界正在滾雪球般發展，並且與資料工程中發生的許多相同的發展並行

  • 6.4.3.5. AI研究人員致力於新的、先進的ML技術

>  6.4.3.5.1. AI研究人員可能在大型科技公司、專門的智慧財產權初創公司(OpenAI、DeepMind)或學術機構工作
  • 6.4.3.6. 在資金充足的組織中，AI研究人員高度專業化，並與支援型工程師團隊一起合作

7. 業務領導

7.1. 資料工程師還作為組織聯結器在更廣泛的範圍內運作，通常以非技術身份

  • 7.1.1. 資料工程師要麼作為集中式團隊處理各種傳入請求，要麼作為資源被分配給特定的經理、專案或產品

7.2. 產品經理

  • 7.2.1. 產品經理監督產品開發，通常擁有產品線

  • 7.2.2. 資料工程師的背景下，這些產品被稱為資料產品

  • 7.2.3. 資料產品要麼是從頭開始構建，要麼是對現有產品的逐步改進

  • 7.2.4. 隨著企業界聚焦以資料為中心，資料工程師與產品經理的互動更加頻繁

  • 7.2.5. 與專案經理一樣，產品經理平衡技術團隊的活動與客戶和業務的需求

7.3. 企業決策層資料

  • 7.3.1. C級高管越來越多地參與到資料和分析中，因為這些被認為是現代企業的重要資產

7.4. 執行長

  • 7.4.1. 非技術公司的執行長(Chief Executive Officer，CEO)通常不關心資料框架和軟體的細節

  • 7.4.2. 他們與技術最高管理層角色和公司資料領導層合作定義願景

  • 7.4.2.1. 資料工程師為了解資料的可能性提供了一個視窗

  • 7.4.2.2. 資料工程師和他們的經理維護著一張地圖，說明在什麼時間範圍內組織內部和第三方可以使用哪些資料

7.5. 資訊長

  • 7.5.1. 資訊長(Chief Information Officer，CIO)是負責組織內資訊科技的高階管理人員

  • 7.5.2. 一個面向內部的角色

  • 7.5.3. CIO經常與擁有良好資料文化的組織中的資料工程領導層合作

  • 7.5.3.1. 如果一個組織的資料成熟度不是很高，CIO通常會幫助塑造其資料文化

  • 7.5.3.2. CIO將與工程師和架構師合作制定重大舉措，並就採用主要架構元素做出戰略決策

  • 7.5.3.3. 企業資源規劃(Enterprise Resource Planning，ERP)和客戶關係管理(Customer Relationship Management，CRM)系統、雲遷移、資料系統和麵向內部的IT

7.6. 技術長

  • 7.6.1. 技術長(Chief Technology Officer，CTO)與CIO類似

  • 7.6.2. 面向外部

  • 7.6.3. CTO擁有面向外部應用程式的關鍵技術戰略和架構，這些應用程式包括移動、Web應用程式和物聯網

  • 7.6.3.1. 這些都是資料工程師的關鍵資料來源

7.7. 首席資料官

  • 7.7.1. 首席資料官(Chief Data Officer，CDO)於2002年在Capital One創立

  • 7.7.2. 負責公司的資料資產和戰略

  • 7.7.3. 專注於資料的商業效用，但應具備強大的技術基礎

  • 7.7.4. 負責監督資料產品、戰略、計劃和核心功能，如主資料管理和隱私

  • 7.7.5. 會管理業務分析和資料工程

  • 7.7.6. 專注於交付資料所需的技術和組織

7.8. 首席分析官

  • 7.8.1. 首席分析官(Chief Analytice Officer，CAO)是CDO角色的變體

  • 7.8.2. 負責業務的分析、戰略和決策制定

  • 7.8.3. 可以監督資料科學和ML，但這在很大程度上取決於公司是否有CDO或CTO角色

7.9. 首席演算法官

  • 7.9.1. 首席演算法官(Chief Algorithms Officer，CAO-2)是最高管理層最近的創新

  • 7.9.2. 一個高度技術性的角色，專注於資料科學和ML

  • 7.9.3. CAO-2通常具有在資料科學或ML專案中作為個人貢獻者和團隊領導的經驗

  • 7.9.4. 具有ML研究背景和相關的高階學位

相關文章