讀資料工程之道：設計和構建健壯的資料系統01資料工程概述

1. 資料工程

1.1. 自從公司開始使用資料做事，資料工程就以某種形式存在了

• 1.1.1. 預測性分析、描述性分析和報告

1.2. 資料工程師獲取資料、儲存資料，並準備資料供資料科學家、分析師和其他人使用

1.3. 資料工程是系統和流程的開發、實施和維護，這些系統和流程接收原始資料並生成支援下游用例（例如分析和機器學習）的高質量、一致的資訊

1.4. 資料工程是安全、資料管理、資料運維(DataOps)、資料架構、編排和軟體工程的交集

1.5. 資料工程師管理資料工程生命週期，從源系統獲取資料開始，到為用例（例如分析或機器學習）提供資料結束

2. 資料工程生命週期

2.1. 生成

2.2. 儲存

2.3. 獲取

2.4. 轉換

2.5. 服務

3. 資料工程師的演變

3.1. 舊的又成了新的

3.2. 早期

• 3.2.1. 1980年到2000年，從資料倉儲到Web

• 3.2.2. 資料工程師的誕生可以說起源於資料倉儲，最早可以追溯到20世紀70年代

• 3.2.3. 商業資料倉儲在20世紀80年代初具規模，Bill Inmon於1989年正式創造了資料倉儲一詞

  • 3.2.3.1. 資料倉儲開創了第一個可擴充套件分析的時代，新的大規模並行處理(Massively Parallel Processing，MPP)資料庫使用多個處理器來處理市場上出現的大量資料並支援前所未有的資料量

• 3.2.4. 在IBM的工程師開發了關聯式資料庫和結構化查詢語言(Structured Query Language，SQL)之後，Oracle普及了該技術

3.3. 21世紀00年代初期

• 3.3.1. 當代資料工程的誕生

• 3.3.2. 雅虎、谷歌和亞馬遜最初繼續依賴20世紀90年代傳統的單機關聯式資料庫和資料倉儲，將這些系統推向了極限

• 3.3.3. 一些創新允許在大規模計算叢集上進行大規模分散式計算和儲存

• 3.3.4. 資料的三個V

  • 3.3.4.1. 速度(velocity)

  • 3.3.4.2. 多樣性(variety)

  • 3.3.4.3. 數量(volume)

• 3.3.5. 2003年，谷歌發表了一篇關於Google檔案系統的論文

• 3.3.6. 在2004年發表了一篇關於MapReduce（一種超可擴充套件資料處理正規化）的論文

• 3.3.7. 谷歌的出版物構成了資料技術的“大爆炸”和我們今天所知的資料工程的文化根基

• 3.3.8. Google的論文啟發了Yahoo的工程師開發並於2006年開源了Apache Hadoop

  • 3.3.8.1. 隨著各種規模和型別的公司看到他們的資料增長到數TB甚至PB，大資料工程師的時代誕生了

• 3.3.9. 亞馬遜

  • 3.3.9.1. 建立了彈性計算環境（Amazon Elastic Compute Cloud，或EC2）​、無限可擴充套件的儲存系統（Amazon Simple Storage Service，或S3）​、高度可擴充套件的NoSQL資料庫(Amazon DynamoDB)和許多其他核心資料構建塊

  • 3.3.9.2. 亞馬遜選擇透過Amazon Web Services(AWS)為內部和外部消費提供這些服務，成為第一個流行的公有云

  • 3.3.9.3. AWS透過虛擬化和轉售巨大的商品硬體池建立了一個超靈活的即付即得資源市場

    3.3.9.3.1. 簡單地從AWS租用計算和儲存，無須為資料中心購買硬體

• 3.3.10. Google Cloud、微軟Azure和DigitalOcean

  • 3.3.10.1. 公有云可以說是21世紀最重要的創新之一，它引發了軟體和資料應用程式開發與部署方式的革命

3.4. 21世紀00年代和21世紀10年代

• 3.4.1. 大資料工程

• 3.4.2. 任何企業都可以使用頂級科技公司使用的相同的前沿資料工具

• 3.4.3. 從批處理計算到事件流的轉變，開創了大“實時”資料的新時代

• 3.4.4. Hadoop、Apache Pig、Apache Hive、Dremel、Apache HBase、Apache Storm、Apache Cassandra、Apache Spark、Presto以及出現的許多其他新技術

• 3.4.5. 大資料工程師必須精通軟體開發和底層基礎設施駭客技術

  • 3.4.5.1. Hadoop、YARN、Hadoop分散式檔案系統(Hadoop Distributed File System，HDFS)和MapReduce在內的Hadoop生態系統

• 3.4.6. 大資料很快成為其自身成功的犧牲品

  • 3.4.6.1. 大資料抓住了試圖理解不斷增長的資料量的公司的想象力，以及銷售大資料工具和服務的公司無休止的營銷

  • 3.4.6.2. 沒有足夠的時間來提供業務的洞察力和價值

• 3.4.7. 大資料一詞本質上是描述處理大量資料的特定時間和方法的遺留物

  • 3.4.7.1. 如今，資料的移動速度比以往任何時候都快，而且資料增長越來越大，但是大資料處理已經變得如此容易理解，以至於它不再是一個單獨的術語

  • 3.4.7.2. 每家公司都旨在解決其資料問題而不用關心實際資料大小

  • 3.4.7.3. 大資料工程師現在只是資料工程師

3.5. 21世紀20年代

• 3.5.1. 資料生命週期工程

• 3.5.2. 包括現代資料棧，代表了一組現成的開源和第三方產品，這些產品組合起來可以讓分析師的工作更輕鬆

• 3.5.3. 雖然資料工程師保持低階資料程式設計技能並根據需要使用這些技能，但他們越來越多地發現自己的角色側重於價值鏈中更高層次

  • 3.5.3.1. 安全

  • 3.5.3.2. 資料管理

  • 3.5.3.3. DataOps

  • 3.5.3.4. 資料架構

  • 3.5.3.5. 編排

  • 3.5.3.6. 一般資料生命週期管理

• 3.5.4. 開源專案和服務不再關注誰擁有“最大資料”​，而是越來越關注管理和治理資料，使其更易於使用和發現，並提高其質量

• 3.5.5. 設計管道時，關心隱私、匿名化、資料垃圾收集和法規遵從性

• 3.5.6. 強調去中心化和敏捷性，這與傳統的企業命令-控制型方法形成鮮明對比

• 3.5.7. 資料生命週期管理的黃金時代

  • 3.5.7.1. 管理資料工程生命週期的資料工程師擁有比以往更好的工具和技術

4. 資料工程與資料科學

4.1. 資料工程與資料科學和分析學是分開的

• 4.1.1. 資料工程位於資料科學的上游

  • 4.1.1.1. 意味著資料工程師提供資料科學家使用的輸入（資料工程的下游）

• 4.1.2. 資料科學家將這些輸入轉化為有用的東西

4.2. 資料科學需求層次

• 4.2.1. 收集

• 4.2.2. 移動/儲存

• 4.2.3. 探索/轉變

• 4.2.4. 複合/標籤

• 4.2.5. 學習/最佳化

4.3. 資料科學家通常沒有接受過設計生產級資料系統的培訓，他們最終會隨意地做這項工作，因為他們缺乏資料工程師的支援和資源

• 4.3.1. 在理想情況下，資料科學家應該將90%以上的時間專注於金字塔的頂層：分析、實驗和ML

• 4.3.2. 當資料工程師專注於層次結構的這些底層部分時，他們為資料科學家的成功奠定了堅實的基礎

4.4. 隨著資料科學推動高階分析和ML，資料工程跨越了獲取資料和從資料中獲取價值之間的鴻溝

• 4.4.1. 認為資料工程與資料科學具有同等的重要性和可見性，資料工程師在使資料科學在生產中取得成功方面發揮著至關重要的作用

5. 資料工程技能和活動

5.1. 資料工程師的技能集包含資料工程的“底層設計"

• 5.1.1. 安全、資料管理、DataOps、資料架構和軟體工程

• 5.1.2. 該技能集需要了解如何評估資料工具以及它們如何在整個資料工程生命週期中相互配合

• 5.1.3. 必須沿著成本、敏捷性、可擴充套件性、簡單性、複用性和互操作性等軸線不斷最佳化

5.2. 資料工程師需要知道並理解如何使用少數強大的龐大技術（Hadoop、Spark、Teradata、Hive等）來建立資料解決方案

• 5.2.1. 他們的工作將致力於叢集管理和維護、管理開銷、寫管道和轉換作業，以及其他任務

5.3. 資料工程師現在專注於平衡能夠為企業帶來價值的最簡單、最具成本效益的最佳服務

5.4. 資料工程師通常不直接構建ML模型、建立報告或儀表板、執行資料分析、構建關鍵績效指標(KPI)或開發軟體應用程式

5.5. 資料工程師應該對這些領域有很好的理解，以便更好地為利益相關者提供服務

6. 資料成熟度

6.1. 資料成熟度是指整個組織向著更高的資料利用率、功能和整合的方向發展，但資料成熟度不僅僅取決於公司的年齡或收入

6.2. 重要的是如何利用資料作為競爭優勢

6.3. 三個階段

• 6.3.1. 從資料開始

  • 6.3.1.1. 根據定義，一個開始使用資料的公司處於其資料成熟度的早期階段

  • 6.3.1.2. 資料團隊很小，人數通常只有個位數

    6.3.1.2.1. 在這個階段，資料工程師通常是多面手，通常會扮演其他幾個角色，例如資料科學家或軟體工程師

  • 6.3.1.3. 資料工程師的目標是快速行動、獲得牽引力並增加價值

  • 6.3.1.4. 從資料中獲取價值的實用性通常不為人所知，但這種願望是存在的

    6.3.1.4.1. 報告或分析缺乏正式的結構，大多數資料請求都是臨時性的

  • 6.3.1.5. 沒有辦法以可擴充套件和可重複的方式將這些模型部署到生產中

  • 6.3.1.6. 主要來自在沒有足夠的資料成熟度或資料工程支援的情況下參與不成熟的資料科學專案的個人經驗

  • 6.3.1.7. 資料工程師應該關注

    6.3.1.7.1. 獲得包括執行管理層在內的主要利益相關者的支援

    6.3.1.7.1.1. 理想情況下，資料工程師應該有一個關鍵舉措的發起人來設計和構建資料架構以支援公司的目標

    6.3.1.7.2. 定義正確的資料架構（通常是單獨的，因為資料架構可能不可用）

    6.3.1.7.3. 識別和審計將支援關鍵舉措的資料，並在你設計的資料架構內執行

    6.3.1.7.4. 為未來的資料分析師和資料科學家構建堅實的資料基礎，以生成具有競爭價值的報告和模型

    6.3.1.7.4.1. 你可能還必須生成這些報告和模型，直到僱用該團隊

  • 6.3.1.8. 如果資料沒有帶來很多可見的成功，組織的意志力可能會減弱

  • 6.3.1.9. 走出去與人交談，避免孤島工作

  • 6.3.1.10. 避免無差別的繁重工作

  • 6.3.1.11. 僅在可以創造競爭優勢的地方構建自定義解決方案和程式碼

• 6.3.2. 用資料擴充套件

  • 6.3.2.1. 在這個階段，一家公司已經擺脫了臨時資料請求並擁有正式的資料實踐

  • 6.3.2.2. 現在的挑戰是建立可擴充套件的資料架構併為公司真正的資料驅動的未來做規劃

  • 6.3.2.3. 資料工程角色從通才轉變為專家，人們專注於資料工程生命週期的特定方面

  • 6.3.2.4. 資料工程師的目標

    6.3.2.4.1. 建立正式的資料實踐

    6.3.2.4.2. 建立可擴充套件且健壯的資料架構

    6.3.2.4.3. 採用DevOps和DataOps實踐

    6.3.2.4.4. 建立支援ML的系統

    6.3.2.4.5. 繼續避免無差別的繁重工作，只有在產生競爭優勢時才進行自定義

  • 6.3.2.5. 隨著我們對資料的處理變得越來越複雜，人們很想採用基於矽谷公司社會證明的尖端技術

    6.3.2.5.1. 這很少能很好地利用你的時間和精力

  • 6.3.2.6. 擴充套件的主要瓶頸不是叢集節點、儲存或技術，而是資料工程團隊

  • 6.3.2.7. 你會很想把自己定位成一名技術專家，一個可以提供神奇產品的資料天才

    6.3.2.7.1. 將你的注意力轉移到務實的領導力上，並開始過渡到下一個成熟階段，與其他團隊就資料的實用性進行溝通

    6.3.2.7.2. 教會組織如何使用和利用資料

• 6.3.3. 以資料領先

  • 6.3.3.1. 在這個階段，公司是由資料驅動的

  • 6.3.3.2. 資料工程師建立的自動化管道和系統允許公司內部的人員進行自助分析和ML

    6.3.3.2.1. 資料工程師實施適當的控制和實踐，以確保資料始終可供人員和系統使用

    6.3.3.2.2. 資料工程角色比第2階段更加專業化

  • 6.3.3.3. 引入新的資料來源是無縫的，並且產生了有形的價值

  • 6.3.3.4. 資料工程師

    6.3.3.4.1. 建立自動化以無縫引入和使用新資料

    6.3.3.4.2. 專注於構建利用資料作為競爭優勢的自定義工具和系統

    6.3.3.4.3. 專注於資料的“企業級”方面

    6.3.3.4.3.1. 資料管理（包括資料治理和質量）和DataOps

    6.3.3.4.4. 在整個組織中公開和傳播資料的部署工具，包括資料目錄、資料血緣工具和後設資料管理系統

    6.3.3.4.5. 與軟體工程師、ML工程師、分析師和其他人高效協作

    6.3.3.4.6. 建立一個人們可以在這裡協作和公開發言的社群和環境，無論他們的角色或職位如何

  • 6.3.3.5. 需要注意的問題

    6.3.3.5.1. 在這個階段，自滿是一個重大危險

    6.3.3.5.1.1. 一旦組織達到第3階段，他們就必須不斷專注於維護和改進，否則就有退回到較低階段的風險

    6.3.3.5.2. 與其他階段相比，技術干擾在這裡是一個更大的危險

    6.3.3.5.2.1. 追求昂貴的業餘專案是一種誘惑，這些專案不會為企業帶來價值

    6.3.3.5.2.2. 應該只在可提供競爭優勢的情況下使用自定義技術