聊聊雲原生資料平臺

語言: CN / TW / HK

在之前的文章中,我們介紹過 雲原生機器學習平臺的組成和搭建 。在實際企業應用中,機器學習平臺非常依賴於企業底層的資料平臺,雖然這兩年 AI 的熱潮一波接著一波,但要很好地去落地演算法應用,非常依賴於資料平臺的基礎建設。從a16z 的一些分析報告 中也可以看出,目前資料平臺類公司吸引了非常多的市場和資本關注,也應運而生了modern data stack 之類的概念。這篇文章我們就來聊聊什麼是所謂的雲原生資料平臺。

1 發展歷程

最早的資料平臺來自於關係型資料庫(RDBMS)技術,從一開始以記錄業務運作資料的 OLTP 系統開始,逐漸發展出了對業務情況做資料分析並進一步採取決策的相關需求,也就是所謂的 OLAP 系統,其中包含了很多經典的理論和技術方法。

在 1980 年代,出現了針對資料分析需求建立資料倉庫系統(Data Warehouse)的設計方法,成為了最早一代的“資料平臺”系統。1992 年,著名的“數倉之父”Bill Inmon 出版了《Building the Data Warehouse》一書,形成了一套自上而下中心化地構建企業級數倉的方法論。另外一位大佬 Ralph Kimball 則在 1996 年出版了《The Datawarehouse Toolkit》一書,提出了自下而上基於 Data Mart 的概念來構建企業級數倉的思路。在上世紀 90 年代,這兩位大佬的書幾乎成了從業者的必讀權威著作,企業級數倉的概念也逐漸開始普及,與 BI 分析應用一道被各大企業廣泛採納和部署。當時主流的軟體系統都來自於各大商業閉源軟體,如 IBM DB2,SQL Server,Teradata,Oracle 等。

到了 20 世紀初,網際網路的概念開始興起,在資料處理分析方面,“大資料”的挑戰也應運而生。傳統的數倉技術已經難以應對網際網路時代海量的資料,快速變化的資料結構,各種半結構化非結構化資料儲存和處理的需求。從谷歌發表的三篇經典論文(MapReduce,GFS,BigTable)開始,出現了與傳統關係型資料庫技術有所不同的分散式資料系統技術棧。這一趨勢被後來的 Hadoop 開源生態發揚光大,在業界形成了長達十多年的深遠影響。記得當時去參加各種技術會議,大家都在聊“資料湖”,NoSQL,SQL on Hadoop 等技術和理念,網際網路公司們採用的資料平臺也大都是基於 Hadoop 這套開源生態體系(HDFS,Yarn,HBase,Hive 等)構建起來的。市場上也湧現了著名的 Hadoop 三駕馬車,Cloudera,Hortonworks 和 MapR。

隨著 AWS 引領的雲端計算浪潮的崛起,大家越來越意識到 Hadoop 系統架構的各種問題,包括儲存和計算資源繫結,非常高的運維難度和成本,無法很好地支援流式資料處理,互動式查詢等。雲原生時代一個非常大的變化是大家都傾向於降低各種系統的擁有成本和運維成本,由雲廠商來提供專業的服務。另外一大趨勢是對極致的“彈性”能力的追求,比如現在一些雲資料倉庫甚至可以做到按單次查詢所消耗的計算量來收費。這些要求在 Hadoop 生態相對來說都比較難實現,因此逐漸出現了新一代的雲原生資料平臺的理念,也是本文主要討論的主題。

2 資料平臺架構

2.1 經典數倉架構

在傳統視角中,資料平臺就約等於數倉平臺。所以只需要 ETL 工具,把資料從各種資料來源中載入到數倉中,然後用 SQL 做各種處理,轉換,構建數倉分層體系,再通過 SQL 介面對外提供服務即可:

傳統資料平臺

2.2 資料湖架構

但隨著業務的發展,大家逐漸對資料平臺的能力有了更多的要求,包括經典的四個 V 中的幾點:

  • Variaty,資料的多樣性。比如需要儲存和處理各種半結構化的 Json,Avro,ProtoBuf 型別的資料,或者是非結構化的文字,影象,音訊,影片等。這些內容的處理,往往 SQL 就會比較難以應對了。此外需求方面也變得更加多樣,除了 BI 類分析,AI 類的分析建模需求,業務系統對分析結果的消費等也變得越來越普遍。
  • Volume,資料的量級。隨著業務線上化,數字化的轉變,資料驅動的思想越來越普及,現代企業需要儲存和處理的資料量級也變得越來越巨大。雖然傳統的商業數倉軟體可以支援水平擴充套件,但往往其架構是綁定了儲存和計算的,這就導致其開銷非常的巨大。這也是現代資料平臺中非常顯著的一個差異點。
  • Velocity,資料的變化速度。在一些資料應用場景中,逐漸開始出現了自動化實時決策的需求。例如使用者在瀏覽了一些商品後,系統可以獲取到新的行為資料而實時更新使用者推薦內容;或是結合使用者最近幾分鐘的行為作出的自動風控稽核決策等。在這種情況下,傳統的 T+1 形式的數倉作業顯然就無法滿足需求了。

在這些需求的驅動下,資料平臺的架構向著更加複雜的結構演化,也開始引入很多知名的大資料系統元件如 Hadoop,Spark 等。其中比較知名的有 Storm 作者 Nathan Marz 提出的 Lambda Architecture:

Lambda 架構

這個架構在設計上還是經過了很多經驗總結和深思熟慮的,核心還是每天的全量資料的批處理(Batch Layer),相比傳統的基於 SQL 的資料轉換,可以支援更加豐富的資料型別和處理方式,同時藉助 Hadoop 架構也能支撐更大的資料量。同時為了支援“實時”需求,增加了流處理層(Real-Time Layer),最後在資料消費時,可以再把這兩塊的資料結合起來(Serving Layer),形成最終的結果。不過這個架構也受到了一些詬病,尤其是需要維護批處理和實時兩套計算框架,且要重複實現兩遍相同的處理邏輯,在架構複雜度上和開發維護成本上都有不足。後續 Kafka 的作者 Jay Kreps 又提出了 Kappa 架構,想將批處理和實時處理統一到一起,有點“流批一體”的意思。

Kappa 架構

但個人感覺 Kappa 架構又太理想化了,即使到了 2022 年,流式資料也還遠沒有成為行業主流。對於訊息流的資料重複,訊息順序,複雜計算(如實時 join)之類的支援,各類源資料系統的支援,資料 schema 的管理,資料儲存的成本控制等方面,都還沒達到非常穩定好用且高效的狀態。所以要讓一個企業的資料完全跑在流式資料系統基礎上,目前看還是不太現實的。因此現階段比較主流的資料平臺架構實際上還是從業務需求和全流程系統成熟度出發,把批處理系統和實時處理系統進行了結合。

2.3 雲原生架構

對於各種元件的組合需求,伴隨著雲原生時代的到來,出現了越來越多更加易於直接“組裝使用”的 SaaS 資料產品。相比之前部署運維 Hadoop,Kafka 叢集的複雜度,新一代的雲原生產品一般都可以直接使用託管服務,按量付費,即開即用,對於非網際網路類公司來說非常友好。所以常見的資料平臺架構都開始往引入各種產品元件的方向發展,出現了很多有意思的新思路:

  • 在資料處理層面,會使用不同的計算引擎來執行批處理或者流式處理的任務,但對於使用者介面來說,希望儘可能保持一致,於是就有了所謂的“流批一體”。
  • 在儲存和資料服務層面,曾經“資料湖”和“資料倉庫”兩者爭得不可開交,但在幾年的發展後發現也並不能完全替代對方。於是資料湖陣營增加了很多 SQL,Schema,資料管控這些功能的支援,成為了新物種 lakehouse。而資料倉庫也都走向了雲原生化,很多雲數倉也支援使用他們的計算引擎直接對資料湖上的檔案進行計算處理。“湖倉一體”也成了一個熱門名詞。
  • 此外還有 feature store 中對於批量和單點查詢特徵的需求,實時分析和資料消費應用的需求結合而生的“HSAP”等等,不一而足。

著名的投資機構 a16z 給出的統一資料架構總覽就很具有代表性:

a16z 的統一資料架構

這張圖畫得非常詳細,把整個資料流轉的過程分成了資料來源(一般不包含在資料平臺裡),資料獲取與傳輸,儲存,查詢處理,資料轉換和分析輸出這幾大塊,而且每一塊中的各個模組,相關的產品都做了詳細的標註。一般企業都會根據需求來選擇其中的部分元件進行部署,例如如果沒有流式資料的需求,那麼就不需要下面那部分流式資料接入和處理的部分。而跟 Lambda 架構不同的是,對於同一個業務場景,一般也不需要讓同一份資料既經過實時處理鏈路,又在 T+1 時經過批處理鏈路做兩次,而是選擇合適的一條鏈路去做後續處理即可。

不過上述的架構圖因為考慮到不同企業不同場景不同階段的需求,畫的有些過於複雜了,個人更喜歡在《Designing Cloud Data Platform》一書中,作者給出的一張相對精簡的架構總覽:

雲資料平臺架構

這個架構在核心上與 a16z 給出的架構參考是基本一致的,不過在各個 layer 的拆分設計上更加的清晰一些,有助於我們理解和規劃整個資料平臺。如果能將各個 layer 之間的職責,介面定義清楚,那麼對於資料流程的標準化,元件實現的靈活替換升級也會非常有好處。後續我們會根據這兩張圖來展開描述雲資料平臺的各個組成部分。

總體來看資料平臺架構近年來的演變趨勢主要有兩個方面,一是為了滿足多樣化的業務需求,平臺整體的系統元件越來越多,處在一個高度分化的階段,但又希望能對使用者保持透明;二是元件的選擇會傾向於選擇各類公有云廠商或者資料 SaaS 平臺廠商的產品,在架構較為複雜的情況下並沒有提升太多的維護成本,但元件間的職責明確(松耦合)和介面標準化仍然是一個挑戰。

3 資料獲取

在資料獲取方面,平臺必須能夠同時支援批量資料和流式資料的接入。

各類資料接入

3.1 批量獲取

對於批處理資料,比如各種上傳檔案,ftp,或者其它無法支援實時消費的第三方 API 資料來源。實際上大多數企業目前對接的各種資料來源和企業內部的基礎資料架構,基本都是以批處理的形式為主的。絕大多數的平臺對於這塊的支援都還是比較好的。典型的做法是定時觸發任務,通過元件去資料來源中獲取全量或者增量更新的資料內容,存放到資料平臺中。如果把這個任務觸發設定的比較頻繁,我們也可以通過批處理的方式得到一個“準實時”更新的資料內容進行後續分析和使用。

3.2 流式獲取

流式資料是近年來非常熱門的趨勢方向,但在網際網路公司之外的應用還相對比較少。大家對於“實時”的理解也各不相同。比如對於分析場景來說,大家普遍的認知是 T+1(第二天看到截至前一天的情況)的資料更新屬於批處理,只要一天內有多次資料更新的,就屬於“實時”分析了。這類需求完全可以通過前面提到的小批量更新來實現。而對於一些自動決策場景,例如推薦系統,交易風控,即使做到分鐘級的“小批量”更新,其時效性也是不滿足需求的,必須對接流式資料系統。

一個比較有意思的場景是對接上游業務系統的資料庫資料。如果採用批處理接入的方式,一般做法是通過一個更新時間戳去定時查詢相關的資料表,然後把增量資料儲存到資料平臺中。這個做法看起來沒啥問題,但實際上如果在更新的時間窗口裡,原始的資料條目做了多次變更,例如使用者在 5 分鐘裡先開通了會員,然後取消,通過批量查詢的方式,可能兩次查詢下來使用者都是非會員的狀態,丟失了中間的狀態變更資訊。這也是為何現在有越來越多的場景會使用 CDC 的技術來捕捉業務資料的實時變化,通過流式資料的方式對接到資料平臺中來,避免有任何的資訊丟失。

這塊建議的建設路徑是先構建穩定的批處理資料接入能力,然後是流式資料獲取,最後才是根據實際需求考慮流式資料處理和分析(引入 Flink 這類)。

3.3 需求與產品

對於資料獲取的元件,需要滿足以下幾個要求:

  • 外掛化架構,支援多種資料來源的資料接入,如不同的資料庫,檔案,API,流式資料來源等,支援靈活的自定義配置。
  • 可運維性,因為需要與各種第三方系統打交道,各種資訊的記錄,出現錯誤時的排查的便利性都非常重要。
  • 效能與穩定性,為了應對大資料量,重要分析決策流程的穩定執行,需要有企業級的平臺質量保證。

資料獲取這塊可以考慮使用的產品也有不少:

  • 三大雲的相關服務,例如批處理方面的 AWS Glue,Google Cloud Data Fusion,Azure Data Factory;流資料方面的 AWS Kinesis,Google Cloud Pub/Sub,Azure Event Hubs 等。
  • 第三方 SaaS 服務,如 a16z 提到的 Fivetran,Stitch,Matillion,Airbyte 等。
  • 開源框架,如 Apache NiFi,Kafka,Pulsar,Debezium(CDC 工具) 等。
  • 基於 Serverless 服務來自行開發資料獲取功能。

注意涉及到雲服務,第三方 SaaS 服務,開源或自研工具選型時,可以參考下圖來做權衡評估。越靠近右端如雲廠商的產品,需要的運維開發投入就越小,但可控性和可移植性就相對較弱(除非相容開源框架的標準 API);越靠左的情況則反之,使用開源產品具有非常靈活的定製(但要注意控制私有分支魔改成分)和部署靈活度,但投入的研發運維成本就會高很多。

產品選擇的權衡

4 資料儲存

在進行資料獲取後,就需要把資料儲存到平臺儲存中。在前面的資料平臺架構圖中,我們看到作者把儲存分成了 fast,slow 兩塊:

快慢儲存

4.1 Slow Storage

這個 slow storage 相對比較好理解,在數倉時代就是 warehouse 系統裡的儲存部分,在大資料時代就是所謂的資料湖,之前比較流行的是 HDFS 這類分散式檔案系統,目前越來越往存算分離的方向發展,主流的儲存方式基本都選擇了各種物件儲存,如 S3,GCS,ABS 等。資料湖的儲存形式上比較自由,資料質量,企業管控等方面經常難以得到保證,所以這兩年 Databricks 又提出了 lakehouse 的概念,其中儲存方面在底層物件儲存之上又搭建了相應的元資料和儲存協議,能夠支援 schema 管理,資料版本,事務支援等特性,我們之前也在 演算法平臺中的資料湖系統 一文中有過介紹。

4.2 Fast Storage

這個 fast storage 可能就比較容易誤解了。在 Lambda 架構和 a16z 的架構圖中,fast storage 一般指對資料消費者提供即席查詢,實時分析服務的儲存系統,例如我們可以用一些實時性較高的分析型資料庫(Presto,ClickHouse),或者針對性的儲存服務如 KV 系統,RDBMS 等。而在作者提供的這張圖裡,fast storage 其實代表的含義更簡單,就是流式資料系統的自帶儲存,如 Kafka,Pulsar 系統儲存事件訊息的部分。這是不是感覺又回到計算和儲存繫結的老路上了?所以現在 Kafka 跟 Pulsar 也都開始支援tiered storage 了,提升整體的可擴充套件性,降低成本。

Tiered Storage

4.3 資料接入流程

從資料接入層進入的資料,一般會以原始資料的方式直接存放到 slow storage 中,後續再通過其它的處理排程轉換成後續需要使用的形式,如 lakehouse 中的表或者對外提供服務的數倉中。流式資料進入到 fast storage 後,實時處理分析元件會來獲取和消費其中的資料,最終觸發下游的資料更新。同時流式資料一般也會通過一個實時處理流同步把原始資料儲存一份到 slow storage 中,以便後續有其它使用需求可以進行靈活的處理操作。實時系統自帶的 fast storage 中的訊息,一般只會保留一段時間,避免高昂的儲存成本。這裡可以看出 slow storage 需要儲存的基本是全量的資料,其開銷會非常大,這也是為何現在一般主流都會選擇廉價易擴充套件的物件儲存系統的原因。

4.4 需求與產品

對於儲存元件,一些重要的特性需求包括:

  • 高度的可靠性,丟資料絕對是最不能接受的,一般 CAP 中只有 C 是不能妥協的一個特性。
  • 可擴充套件性,需要能非常輕鬆地做儲存空間的擴縮容。
  • 效能,slow storage 需要有比較好的吞吐量,支援消費者的併發大資料量的獲取。而 fast storage 需要有非常好的小資料量讀寫響應速度。

儲存產品方面雲廠商的服務應該是主流選擇,畢竟自己搭建維護儲存叢集太複雜了。也有一些開源專案基於這些雲廠商的物件儲存做了一些附加功能(例如支援 POSIX)和優化,如 lakeFSJuiceFSSeaseedFS 等(後兩個都是國人的專案)。

5 資料處理

資料處理是整個平臺中比較複雜,也是各種流派爭奪比較激烈的部分。最典型的做法是使用兩套計算引擎來分別支援批處理和流處理,與資料獲取部分一致。這樣做的好處是可以針對業務場景選擇最合適的技術,且更能發揮框架本身的特長。絕大多數公司都是以批處理需求為主的,那樣的話在一開始也就沒有必要引入流處理引擎了。

5.1 批處理

批處理方面最流行的框架莫過於 Apache Spark,作為一個老牌開源專案,社群活躍,發展階段較為成熟,功能上也非常全面強大,除了典型的結構化資料處理外,也能支援非結構化資料,圖資料等。如果是以結構化資料為主,那麼老牌的 Hive,以及 Presto,Dremio 等新晉力量也是非常不錯的 SQL 計算引擎選擇。在做海量資料的批處理時,也會涉及到不少優化手段,如各種 join 方式的選擇,任務並行度的調整,資料傾斜的處理等,這裡就不具體展開了。

5.2 流處理

流處理方面國內聽到最多的肯定是 Apache Flink 了。此外像 Spark Streaming,Kafka Streams 也都提供了相應的流處理能力。對於一些複雜計算邏輯,流式計算上的開發門檻還是相當高的,而很多需求其實不一定要在流處理中做複雜計算也能實現。例如我們可以把資料簡單處理後實時寫入到實時分析型資料庫,如 ClickHouse,Pinot,Rockset,或者像 ElasticSearch,KV 儲存,in-memory DB 之類的系統中,也能提供流式計算一大部分的需求滿足,後面我們會介紹相應例子。流式處理也跟批處理一樣,需要做各種效能,擴充套件性的優化工作,比如指定分割槽邏輯,解決資料傾斜,checkpoint 調優等。

5.3 流批一體

最近幾年流批一體的概念也比較火,尤其是 Flink 社群,認為批處理只是流處理的一種特殊形式,完全可以使用統一的框架來完成。這跟前面提到的 Kappa 架構差不多是一個意思。當然也有從軟體層面來做統一的嘗試,例如 Apache Beam,可以使用相同的 DSL 來做開發,底層執行時再轉換到 Spark 或者 Flink 上分別執行批處理和流處理。

Flink 的流批一體
Beam 的流批一體

5.4 需求與產品

對於資料處理元件,需要滿足的要求有:

  • 計算的水平擴充套件能力,能夠使用多節點來進行大資料量的計算。
  • 穩定性和可用性,多節點的 failover/recovery 能力。
  • 靈活開放的 API/SDK/DSL 支援,如可以使用 SQL,或者各類主流程式語言開發處理邏輯。

批處理產品除了前面提到的各種開源框架,雲廠商也有提供各種 managed service,包括我們耳熟能詳的 AWS EMR,Google Dataproc 或 Cloud Dataflow(基於 Beam),Azure Databricks 等。

流處理產品包括雲廠商提供的 AWS Kinesis Data Analytics,Google Cloud Dataflow,Azure Stream Analytics。此外也有一些知名的 SaaS 廠商,包括 Kafka 的“官方”公司Confluent,Upsolver ,Materialize 等。

流式資料處理公司 Materialize

6 元資料

傳統的 RDBMS 經過了多年的行業應用,產品打磨,在元資料方面做得還是比較完善的。而云資料平臺因為還沒有普及,在各家公司內部搭建過程中往往容易被忽略。這部分的能力實際上作為企業級成熟產品是至關重要的一環。

6.1 平臺元資料

平臺在執行過程中會產生各種資訊,例如配置的各類資料來源,資料獲取的執行情況,資料處理的執行情況,資料集的 schema、統計資訊、血緣關係,系統的資源使用情況,各種日誌資訊等等。通過這些資訊,我們可以對各種平臺任務進行監控和告警,當出現問題時也能通過這些資訊的檢視進行方便地排查處理,而不是分別登入到各個模組的管理控制檯上去一一檢查。

平臺元資料型別

Schema 這塊是一個比較大的話題。相對於基於關係型資料庫技術的數倉系統來說,雲資料平臺在靈活的處理資料集 schema 的變化方面具有一定優勢。大多數的雲資料倉庫在處理 schema 變化時,都會對其服務造成一定影響(例如需要鎖表)。而很多 lakehouse 則可以比較好地支援 schema evolution,例如 Delta 裡的 mergeSchema 選項。當然這個功能也並不是萬能的,在整個資料平臺中,涉及到各種資料的處理轉換,各個環節的互動配合,下游系統如數倉,實時分析資料庫的寫入和其它外部系統的消費,我們必須對 schema 進行嚴格的記錄和管理。

元資料中的 Schema Registry

6.2 業務元資料

除了技術層面的元資料外,在業務上也有相關的元資料管理和使用的需求。例如平臺數據集多了之後,管理和搜尋就會比較複雜,基礎的資料夾結構可能難以滿足需求,所以我們需要支援對資料集的描述,打 tag,搜尋等功能,幫助業務使用者更快地找到合適的業務資料資訊。所謂的 Data Discovery,Data Catalog 產品一般就是為了滿足此類需求。

6.3 需求與產品

對元資料元件,常規的需求肯定還是需要保證高可用和擴充套件效能,當平臺規模較大時,元資料的規模量級也會非常可觀。此外一個重要的是靈活性和擴充套件性,比如支援使用者自定義的元資料內容,通過開放 API 來提供對外服務等。在資料處理,流程編排執行,以及後續資料消費等模組中,都需要與各類元資料打交道,因此一個設計優良的元資料服務也越來越受到大家的重視。

這個領域相對來說比較新,雲廠商提供的產品不一定能滿足所有需求,如 AWS Glue Data Catalog,Google Data Catalog,Azure Data Catalog。

也有一些開源廠商有提供相關服務,平臺元資料方面相對比較少,比較有代表性的是 Marquez 。而在業務元資料層面或綜合性的比較多一些,有Apache Atlas,Amundsen ,DataHub ,Atlan ,Alation 等。

Atlan 功能介紹

7 資料消費

資料平臺對外提供的服務相比於數倉時代也豐富了許多,除了典型的資料分析型應用,也開始湧現出流式資料消費和資料科學,機器學習類應用需求。為了滿足不同的需求,雲資料平臺可以在松耦合元件化的設計思路下,引入或對接各類專用資料系統,靈活擴充套件其服務能力。

各類資料消費需求

7.1 分析查詢

對於 BI 資料分析類需求,絕大多數的應用都是通過 SQL 來進行資料的查詢獲取的。由於自助式資料分析需求的興起,對於查詢的靈活性,互動的時效性(一般需要亞秒級到秒級響應),以及對大資料量處理的要求越來越高,傳統的 Hive,Spark 查詢由於響應時間的問題往往無法滿足需求。在這個背景下也出現了很多相應的解決方案:

  • 雲數倉,如三大廠商的 BigQuery,Redshift,Azure Synapse,或者第三方的 Snowflake 等。在結構化資料處理需求為主的情況下,甚至可以直接以這些系統為核心,替代傳統數倉來打造整個資料平臺。
  • Lakehouse,例如 Spark 的商用版計算引擎 Photon,或者 Presto,Dremio 等技術,基於一些資料湖上的 open format(Delta,Hudi,Iceberg)做高效的查詢處理。
  • 開源實時分析資料庫,如前面多次提到的 ClickHouse,以及各種新湧現的專案如Apache Doris,Databend 等。

7.2 資料科學

在資料科學,機器學習領域,目前最重要的生態都是基於 Python 構建的,其典型的運作方式會通過 notebook,Python 指令碼等方式,直接從資料儲存層獲取大批量的資料來進行統一處理並用於後續模型訓練等,比較少需要通過 SQL 來執行復雜的查詢。在這種情況下,如果可以直接訪問 slow storage 中的原始檔案,那麼成本開銷自然是最低的了。當然這樣做也有壞處,比如資料的管控,許可權等就會難以保證。

另外如果考慮整個機器學習的開發,部署,監控全流程,那麼就會引入另外一大坨 MLOps 相關的需求,其中像資料這塊的需求涉及到 Feature Store,裡面的批量和實時特徵請求模式的區別,也跟我們討論的資料平臺中批量獲取和單點查詢的需求有所對應,在建設時可以考慮是否能複用部署元件。

機器學習相關 Infra

關於 MLOps 相關的討論,也可以參考我之前的這篇MLOps 簡介。

7.3 實時消費

最後,對於流式處理和分析的結果,也會有相應的應用來進行實時消費。可以通過實時結果推送,寫入關係型資料庫,KV 儲存,快取系統(如 Redis),搜尋系統(如 ElasticSearch)來對外提供服務。很多流式處理系統如 Flink 也支援實時查詢,可以開發特定 API 來直接從流式系統中提供資料結果。

7.4 許可權與安全

在企業級應用中,使用者許可權的控制,各類操作記錄的審計和監控,包括資料脫敏,加密等方面的需求至關重要。除了平臺本身要重視這方面能力的支援外,我們也可以考慮利用各類相關的雲服務,例如 Azure Active Directory,Auth0 之類的身份認證服務,雲廠商提供的各種 VPC,VPN 相關的網路安全服務等。

7.5 服務層產品

除了前面提到的雲數倉,lakehouse 和實時分析資料庫,也有類似 Metric Store 之類的產品,構建在各類資料來源之上,對外提供統一的服務。如LookML,Transform ,Metlo 等。

Metric Store

8 流程編排與 ETL

8.1 流程編排

傳統數倉架構中,編排工具也是極其重要的一環,在雲資料平臺中,相關的 pipeline 流程執行排程會更加的繁多複雜。例如我們需要通過定時或 API 的方式來觸發資料獲取的流程,並在之後進行各種級聯任務的觸發和排程執行。在任務執行出現問題或失敗時,可以自動進行重試和恢復,或提示使用者介入處理。

流程編排示意

例如上圖中就是一個最簡單的任務依賴關係示意,任務 2 的觸發依賴於任務 1 的批處理任務成功完成的前提,這時我們就需要編排工具來支援此類工作。

8.2 ETL

編排流程中執行的具體任務,一般都是各種資料接入,資料轉換操作,也就是我們俗稱的 ETL 了。除了通過 SQL 或者計算引擎的 SDK(如 PySpark)來開發業務邏輯,市面上也有不少產品支援通過 no-code/low-code 方式做開發,大大降低了使用者門檻。例如我們觀遠的 SmartETL 就是這個方面的一個不錯的產品,受到了很多業務人員的喜愛。

觀遠 SmartETL

8.3 需求與產品

對於流程編排相關的工具,主要的系統需求有:

  • 可擴充套件性,支援海量 pipeline 的排程,監控。
  • 穩定性,必須保證穩定和高可用,一旦流程編排能力癱瘓,相當於整個平臺的資料處理核心能力都陷入了停滯狀態。
  • 可觀測,可運維,各種任務的執行狀態,日誌,系統資源開銷等都需要進行記錄並方便檢視,方便運維與問題排查。
  • 開放性,能夠方便地在工具中開發各種自定義的處理邏輯,執行不同型別的任務。
  • DataOps 支援,即使提供了 no-code 的拖拽式開發,底層應該仍然能夠很好的支援 DataOps 的需求,例如 pipeline 邏輯的版本化管理,測試與釋出(CI/CD),支援 API 呼叫以實現流程自動化等。

可以注意到實際上很多資料獲取,資料處理工具多少也帶了些 ETL 或編排的能力。雲廠商的產品基本都是資料獲取工具的那幾個,包括 AWS Glue,Google Cloud Composer(託管版的 Airflow),Google Cloud Data Fusion,Azure Data Factory。

開源工具方面,編排工具中,Airflow 應該是最著名的一個,後面隨著機器學習領域對 workflow 編排的巨大需求,也湧現出了很多後起之秀,如 Dagster,Prefect,Flyte,Cadence,Argo(KubeFlow Pipeline) 等。另外像國人的 DolphinScheduler 的知名度也相當不錯。ETL 的開源工具好用的不多,talend 並不是完全開源的,比較有名的主要是 Apache NiFiOpenRefine 兩個歷史比較悠久的開源專案了。

SaaS 廠商方面可以參考資料獲取部分的廠商,如 Airbyte,Fivetran,Stitch,Rivery 等,上面提到的很多編排工具的開源專案也都有對應的商業公司提供託管服務。還有不得不提到的是如今非常火爆的dbt,基本上每家公司都在用的資料轉換工具,很好的借鑑了很多軟體工程領域的最佳實踐,可以說是對於 DataOps 需求支援的非常好的一款產品了。

9 最佳實踐

9.1 資料分層

我們在建設企業數倉體系時,一般會遵循一些經典的最佳實踐,例如關於資料表模型,有星型模型和雪花模型等設計方式;從資料的流轉過程來看,有非常經典的數倉分層模式:

數倉分層

在雲資料平臺,我們也可以借鑑這方面的思路。例如 Databricks 設計的 lakehouse 中的資料流程就跟上面的數倉分層很相似:

Lakehouse 資料架構

具體流程步驟如下:

  1. 一般通過資料獲取進入到雲資料平臺時,都會盡量保持原始資料的狀態(可以是原始格式或者 Avro 格式)存放在 landing(bronze) 區域,注意在整體架構中,只有資料獲取層工具可以寫入這個區域。
  2. 原始資料接下來會進行一些通用的質量檢查,去重,清洗轉換,進入到 staging(silver) 區域。從這裡開始更建議使用類似 parquet 的列式儲存格式。
  3. 同時原始資料會被拷貝到 archive 區域,後續用於重新處理,流程 debug,或者進行新 pipeline 的測試等工作。
  4. 資料處理層工具,會從 staging 區域讀取資料,進行各類業務邏輯的處理,聚合等,最終形成 production(golden) 資料,提供資料服務。
  5. Staging 區域的資料也可以不做處理,bypass 到 production 區域並最終流入數倉中,這部分相當於是原始資料,可以在某些情況下幫助資料消費者來做比對和定位相關問題。
  6. 不同的資料處理邏輯會形成面向不同業務主題,應用場景的“資料產品”,在 production 區域提供 batch 消費服務(尤其是演算法場景),或者載入數倉中提供 SQL 查詢服務。
  7. 在 staging,production 流轉過程中,如果資料處理層碰到了任何錯誤,可以將資料儲存到 failed 區域,等排查解決後,再將資料放回 landing 區域,重新觸發全流程。
資料流程最佳實踐

上述這些區域的劃分可以通過典型物件儲存的概念,如“桶”或者“資料夾”來進行劃分。也可以根據不同的讀寫 pattern 來決定各個區域對於不同 layer 模組的訪問許可權控制,以及冷熱儲存的設計以節約成本。另外流式資料的處理流程也可以借鑑類似的邏輯,但在資料去重,質量檢查,資料增強,schema 管理等方面會有更多的挑戰。

9.2 區分流式獲取與流式分析需求

我們經常聽到 BI 分析類的客戶有“實時資料分析”的需求。但仔細分析來看,使用者並不會時時刻刻一直盯著 BI 分析看板來做“實時分析”,總體來說開啟看板是有一定的時間間隔的。我們只需要保證客戶每次開啟分析看板時看到的資料是最新的即可,因此完全可以使用如下的架構來滿足:

流式資料獲取架構

這裡我們只需要通過流式資料獲取系統把訂單資料實時寫入雲數倉即可,當用戶每隔一段時間開啟報表時,觸發數倉的 SQL 查詢,展現最新結果即可。

但考慮另一個場景,在某個遊戲中,我們希望展示使用者的實時行動資料,如自上線以來獲得的經驗值等統計資訊。這個時候,如果我們仍然沿用上述“流式獲取”的架構可能就不合適了。因為此時每個玩家都是真正“實時”盯著自己的統計資料的,必須做到高頻,大併發的查詢支援。一般雲數倉的響應時間和併發服務能力就難以滿足了,這時才是真正涉及到了“實時分析”的需求。我們需要在流式獲取使用者的新資料後,執行流式統計分析操作,並將結果存入到一些能夠支援高併發,低延遲查詢的資料庫/快取系統中,才能支援海量線上玩家的資料消費需求。

流式資料分析架構

9.3 控制雲端計算開銷

雲原生時代,我們在使用各類元件時的上手門檻低了很多,開箱即用,彈性伸縮,免運維給開發者帶來了非常多的便利,也在悄悄地轉變我們的思維意識。在自建系統的年代,我們對於各個元件的資源開銷,整個叢集的利用率等都有比較精細化的理解和深入優化。但現在各種系統設計的 trade-off 從有限的資源池分配,轉向了費用與效能的權衡上來,反而減少了對各個元件做資源開銷優化的意識。包括雲廠商們自己有時候也會有意無意的“擺爛”,最近還有一篇The Non-Expert Tax 專門來討論雲廠商的 auto-scaling 的經濟性問題。

因此作為雲資料平臺的開發者,仍然要深入理解各類雲端計算元件,產品的架構原理,收費模式,並實踐相應的資源監控,優化手段。典型的例子包括網路開銷的控制(減少跨雲傳輸),冷熱儲存的設計,資料分割槽等提升資料計算處理效率的優化手段等等。

9.4 避免緊耦合

從前面複雜的架構圖中可以看到,雲資料平臺一般會由非常多的元件構成,而且整個技術生態的變化也是日新月異。一般對於這類複雜系統,我們會採取分步構建的方式,過程中會持續增加,替換或淘汰部分元件產品,因此必須要借鑑軟體工程中的松耦合原則,避免對某個具體的產品/介面有緊密的依賴。雖然有時候直接訪問底層儲存之類的做法看起來減少了中間步驟效率較高,但也會讓我們後續想要做擴充套件和變更時碰到很大的麻煩。理想情況下我們應該儘可能明確元件之間的邊界和介面,對不同的產品進行封裝以提供相對標準的介面實現互動和服務。

10 資料平臺建設

10.1 業務價值

最後值得一提的是,複雜的雲資料平臺建設不能僅僅是從技術角度出發去推動的。必須從業務(商業)的目標出發來發起和規劃整個專案。資料平臺的典型價值包括:

  1. 節流,提升業務運營效率,節約資產投入和各類運維成本。
  2. 開源,支撐營銷優化,客戶體驗優化等場景,促進公司收入增長。
  3. 創新,通過優秀的產品能力,支撐業務的自助式資料分析與決策,快速探索新增長點。
  4. 合規,通過統一平臺建設來滿足各類資料方面的法規,政策,監管需求。

我們應該明確企業的業務訴求,針對性的設計資料戰略和資料平臺建設的規劃。對於技術戰略如何服務業務目標,也可以參考這篇 資深工程師之路:技術戰略 ,這裡就不詳細展開了。

10.2 建設路徑

從前面的架構圖看到,整個平臺的組成是相當複雜的,一般需要經過幾年的時間來逐漸搭建與完善。這與企業本身的線上化,數字化,智慧化演進路線需要保持一致,而不是無視企業資料現狀,上來就開發部署流式資料平臺,機器學習平臺等看起來更新潮的技術。

我們觀遠在成立早期就深入思考並提出了資料分析與智慧決策在企業落地的5A 落地路徑方法論,包括從自助式分析,到場景化,自動化,增強化最終實現決策自動化的 5 個步驟。對應到資料平臺的構建,也可以參考類似的策略框架,例如:

  1. 敏捷化,可以通過基礎數倉體系搭建和自助式 BI 分析產品的應用來實現,達到“看見資料”的目標。
  2. 場景化,通過 metric layer 和 BI 產品中的應用市場,形成各個業務場景的最佳實踐,讓更多的使用者知道“怎麼看資料”。
  3. 自動化,需要平臺有一定的編排能力,將各類分析結果與業務系統打通,自動化推送結果(反向 ETL),資料預警等,達到“資料追人”的效果。
  4. 增強化,在分析的基礎上,進一步加入 AI 建模與預測的能力,需要平臺支援演算法類的資料處理與消費(如非結構化資料,notebook),實現“洞見未來”。
  5. 行動化,最終我們希望能在預測基礎上更進一步,從分析型 AI 延展到行動化的 AI,需要平臺提供更加綜合的對外服務能力(API,實時資料,AB Test 等),結合一些低程式碼工具打造資料驅動的業務應用,有望實現“自動決策”。
資料分析成熟度歷程

10.3 使用者推廣

除了從技術架構層面的演進方法論,如何在業務層面對平臺進行宣傳與推廣也是一個重要課題。有太多的資料平臺專案都是缺乏深入的業務溝通理解,在雙方缺乏一致認知的情況下,推進複雜專案,建設週期極為漫長,最終導致中途的失敗。我們更應該通過一些小型專案快速體現平臺價值,增進雙方的共識,獲取使用者的信任,並逐漸推廣到更多組織部門;在得到更多應用之後,也會帶動場景,需求的豐富,反過來也可以指導和促進平臺本身的建設與發展,進入一個良性迴圈。這也是我們觀遠在持續探索和實踐的“讓業務用起來”的路線方法。

最後小小的打一個廣告,我們觀遠資料在前面提到的產品技術層面和企業服務,業務推廣方面都有非常豐富的經驗。通過 Universe,Galaxy,Atlas 產品線,可以支撐處於各個資料分析成熟度階段的企業資料平臺,BI + AI 分析決策需求。在一些行業頭部客戶,我們的產品也成功達到了 20000 名以上活躍分析師和資料決策使用者的里程碑,可以想象這樣的企業在激烈的市場競爭中能夠體現出來的決策效率與質量的巨大優勢。非常歡迎有興趣的朋友來一道探討交流,尋求合作共建的機會 :)

如果你對我的作品感興趣,歡迎搜尋關注公眾號:RandomGenerator。