Transformer架構解析

核心觀點： 服務的本質是數據的流轉與變換

</div>

數據的變換依賴于數據的流轉，只有流轉的數據才能夠被變換。基于這個理念，我們提出了Transformer架構。

基本概念定義

• Transformer。 我們的每一個服務應用，都是一個數據轉換器。數據在這些Transformer之間進行流動和轉換。流動的過程就是Pipeline形成的過程(Pipeline的概念在后續會有定義)。典型的例子比如你開發的一個Spark Streaming程序，一個Storm程序，一個Tomcat Web服務，都是一個Transformer。

• Estimator 。它是一類問題的抽象與實現。現實生活中，我們要解決的問題舉例有，實時計算問題，離線批量問題，緩存問題，Web服務問題等。對這些問題，我們都有一些可擴張，靈活動態的，具有平臺性質的Estimator。比如MR 可以解決大部分離線批量問題,比如Spark則可以解決實時計算，離線批量等多個方面的問題。比如Storm則可以解決實時計算問題,比如Tomcat。并不是所有的Estimator 都能夠實現平臺特質，隔離底層的。譬如 基于Spark的Transformer 可以實現以資源為需求的動態部署。但基于Tomcat的Transormer則不行，因為Tomcat本身并沒有做到分布式的，以資源為粒度的提供給上層Transormer使用的特質。

• Parameter 。 每個Transformer都有自己的參數，每個Estimator有自己的參數。Parameter就是所有參數的集合。如果進行擴展，他可以包括Transformer/Estimator/Pipeline/Core/OS 等各個層次的參數。

• Pipeline。 數據在Transfomer之間流動的形成了Pipeline。每一個Transformer 以自己作為Root節點，都會向下延伸出一個樹狀結構。

• DataFrame。數據框。數據需要被某種形態進行表示。可以是byte數組，可以一個son字符串。這里我們用 DataFrame 對 數據表示( Data Represention )。 它是各個Transformer之間交換數據的表示和規范。

Transformer架構概覽

Transformer架構概覽

什么是資源需求為主導的Estimator

在前文中，我們在對Estimator進行第一的時候，我們提到了 平臺特質 ， 以資源為導向 等概念。那么這些指的是什么呢？

如果上層的Transformer可以按資源進行申請，并且被提交到Estimator上運行，則我們認為該Estimator 是具有 平臺特質 ， 以資源為導向 的。典型的比如Spark。

但是譬如Tomcat,他本身雖然可以運行Web類的Transformer,但是Transformer無法向Tomcat提出自己的資源訴求，比如CPU/內存等，同時Tomcat本身也沒辦法做到很透明的水平擴展(在Transformer不知情的情況下)。所以我們說Tomcat 是不具備 平臺特質 ，并且不是 以資源為導向 的Estimator。

但是，當我們基于Core層開發了一套容器調度系統(Estimator),則這個時候Tomcat則只是退化成了Transfomer的一個環境，不具備Estimator的概念。

在Transformer架構中，我們努力追求Estimator 都是具備平臺特質，并且以資源為導向的服務平臺。

Transformer/Estimator/Pipeline的關系

下面以搜索為例子，簡單畫了個三者之間的關系。特定的Transformer依賴于特定的Estimator運行，不同的Transformer 構建了Pipeline實現了數據的流動，數據流動到具體的Transformer后發生數據的transform行為。

Transformer/Estimator/Pipeline的關系

Transformer 架構可以對互聯網也進行建模

Transformer 和Pipeline構建了一個復雜的網絡拓撲。在Pipeline流動的的DataFrame則實現了信息的流動。如果我們跳出公司的視野，你會發現整個公司的網狀服務體系只是全世界網絡體系的一小部分。整個互聯網是一張復雜的大網。而整個互聯網其實也是可以通過上面五個概念進行涵蓋的。

利用Transformer概念去理解我們已經存在的概念

譬如，我們部署服務到底是一件什么樣的事情？

你可能覺得這個問題會比較可笑。然而，如果之前我們提出的概念是正確或者合理的，讓我們離真理更近了一步的話，那么它應該能夠清晰的解釋，我們部署或者下線一個服務，或者一個服務故障，到底是什么？

所謂部署服務，不過是新建一個Transformer，并且該Transformer和已經存在的的Transformer通過Pipeline建立了聯系，在網絡拓撲中形成一個新的節點。這個新的Transformer無論業務有多復雜，不過是實現了一個對數據transform的邏輯而已。

Transformer 的優勢

前文我們提到了具有平臺特質，以資源為導向的Estimator,可以給我們帶來如下的好處：

• 這些Estimator 底層共享 Yarn/Mesos這個大資源池，可以提高資源利用率

• Estimator如果已經實現了Adaptive Resource Allocation,則根據Transformer的運行情況，可以動態添加或者縮進對應的資源

• Transformer 部署變得異常簡單，申明資源即可。開發人員無需關心起如何運行。一切由Estimator來解決。

• 有了Estimator的規范和限制，Transformer開發變得成為套路，真正只要關注如何transform，和哪些Transformer建立Pipline

• 平臺組和應用組只能劃分清晰。平臺組總結數據處理模式，提供抽象的Estimator供應用組進行開發和運行

除了這些，對我們進行架構設計也具有極大的知道意義。讓我們換了一種思考模式去思考面對新的需求，如何設計的問題。

我們不希望每次遇到一個新的業務問題，都需要根據自己的聰明才智，通過經驗，得到一個解決方案。任何事情都是有跡可循的。正如吳文俊提出的機器證明，可以通過流程化的方式讓計算機來證明幾何問題。當面臨一個新的業務問題的時候，我們應該有標準的流程可以走。

一個復雜的業務必定是由多個Transfomer進行構建的，每個Transfomer的構建流程都可以遵循這個方式。

用Transformer架構思考樣例

假設我現在有個搜索服務，我要新接入一個產品，再次假設新產品的數據已經遠遠不斷的放到了Kafka里。

這個時候，我們需要新建立一個Transformer。

數據進入索引，必然有個吞吐量和實時性的權衡。如果你追求實時性，譬如要達到毫秒級，這個時候實時計算里的Estimator Storm是個更好的選擇。而如果是秒級的，可能Spark Streaming是個更好的選擇。假設我們選擇了Spark Streaming,則說明我們的Transformer是個Spark Streaming程序。

這里我們要連接的Transformer 非常清晰，就是搜索和Kafka。 他們之間需要通過我們新的Transformer將數據進行流轉。為了解決他們的數據表示的不一致性(DataFrame的不一致)，所以我們需要新的Transformer 能夠做兩次轉換，將Kafka的數據轉換為搜索能夠認識的數據表示形態。

你需要調研Kafka里的DataFrame以及搜索需要的DataFrame,實現transform邏輯。

程序員根據這三點進行是靠，按照Estmator的規范(這里是Spark Streaming 的編程規范)，寫了幾十行(或者百余杭代碼)，然后提出資源要求，譬如：

• 10顆核
• 10G內存
• 無磁盤要求

這個時候他package好后，通過一個簡單的submit 命令(或者如果你有web提交任務的界面)，帶上資源要求，將服務進行提交。

過了幾秒，你就會發現數據已經神奇的從Kafka流入到搜索，通過搜索的API我們已經能夠檢索的數據了。

整個過程從設計，從實現，我們都是嚴格按照規范來做的。我們無需有所謂的服務器。我們只要知道根據Transformer架構去思考，然后提出自己需要的資源，就可以實現一個新的業務邏輯。可能一到兩小時就搞定了整件事情。

個人感覺

Transformer 架構，不僅僅能建模我們的數據平臺，也能建模我們傳統的Web服務，還能對機器學習流程進行建模。