<b>核心觀點： 服務的本質是資料的流轉與變換</b>
資料的變換依賴于資料的流轉，隻有流轉的資料才能夠被變換。基于這個理念，我們提出了transformer架構。
<b>transformer</b>。 我們的每一個服務應用，都是一個資料轉換器。資料在這些transformer之間進行流動和轉換。流動的過程就是pipeline形成的過程(pipeline的概念在後續會有定義)。典型的例子比如你開發的一個spark streaming程式，一個storm程式，一個tomcat web服務，都是一個transformer。
<b>estimator </b>。它是一類問題的抽象與實作。現實生活中，我們要解決的問題舉例有，實時計算問題，離線批量問題，緩存問題，web服務問題等。對這些問題，我們都有一些可擴張，靈活動态的，具有平台性質的estimator。比如mr 可以解決大部分離線批量問題,比如spark則可以解決實時計算，離線批量等多個方面的問題。比如storm則可以解決實時計算問題,比如tomcat。并不是所有的estimator 都能夠實作平台特質，隔離底層的。譬如 基于spark的transformer 可以實作以資源為需求的動态部署。但基于tomcat的transormer則不行，因為tomcat本身并沒有做到分布式的，以資源為粒度的提供給上層transormer使用的特質。
<b>parameter </b>。 每個transformer都有自己的參數，每個estimator有自己的參數。parameter就是所有參數的集合。如果進行擴充，他可以包括transformer/estimator/pipeline/core/os 等各個層次的參數。
<b>pipeline</b>。 資料在transfomer之間流動的形成了pipeline。每一個transformer 以自己作為root節點，都會向下延伸出一個樹狀結構。
<b>dataframe</b>。資料框。資料需要被某種形态進行表示。可以是byte數組，可以一個son字元串。這裡我們用dataframe 對 資料表示( data represention )。 它是各個transformer之間交換資料的表示和規範。
transformer架構概覽
在前文中，我們在對estimator進行第一的時候，我們提到了平台特質，以資源為導向等概念。那麼這些指的是什麼呢？
如果上層的transformer可以按資源進行申請，并且被送出到estimator上運作，則我們認為該estimator 是具有平台特質，以資源為導向的。典型的比如spark。
但是譬如tomcat,他本身雖然可以運作web類的transformer,但是transformer無法向tomcat提出自己的資源訴求，比如cpu/記憶體等，同時tomcat本身也沒辦法做到很透明的水準擴充(在transformer不知情的情況下)。是以我們說tomcat 是不具備平台特質，并且不是以資源為導向的estimator。
但是，當我們基于core層開發了一套容器排程系統(estimator),則這個時候tomcat則隻是退化成了transfomer的一個環境，不具備estimator的概念。
在transformer架構中，我們努力追求estimator 都是具備平台特質，并且以資源為導向的服務平台。
下面以搜尋為例子，簡單畫了個三者之間的關系。特定的transformer依賴于特定的estimator運作，不同的transformer 建構了pipeline實作了資料的流動，資料流動到具體的transformer後發生資料的transform行為。
transformer/estimator/pipeline的關系
transformer 和pipeline建構了一個複雜的網絡拓撲。在pipeline流動的的dataframe則實作了資訊的流動。如果我們跳出公司的視野，你會發現整個公司的網狀服務體系隻是全世界網絡體系的一小部分。整個網際網路是一張複雜的大網。而整個網際網路其實也是可以通過上面五個概念進行涵蓋的。
譬如，我們部署服務到底是一件什麼樣的事情？
你可能覺得這個問題會比較可笑。然而，如果之前我們提出的概念是正确或者合理的，讓我們離真理更近了一步的話，那麼它應該能夠清晰的解釋，我們部署或者下線一個服務，或者一個服務故障，到底是什麼？
所謂部署服務，不過是建立一個transformer，并且該transformer和已經存在的的transformer通過pipeline建立了聯系，在網絡拓撲中形成一個新的節點。這個新的transformer無論業務有多複雜，不過是實作了一個對資料transform的邏輯而已。
前文我們提到了具有平台特質，以資源為導向的estimator,可以給我們帶來如下的好處：
這些estimator 底層共享 yarn/mesos這個大資源池，可以提高資源使用率
estimator如果已經實作了adaptive resource allocation,則根據transformer的運作情況，可以動态添加或者縮進對應的資源
transformer 部署變得異常簡單，申明資源即可。開發人員無需關心起如何運作。一切由estimator來解決。
有了estimator的規範和限制，transformer開發變得成為套路，真正隻要關注如何transform，和哪些transformer建立pipline
平台組和應用組隻能劃厘清晰。平台組總結資料處理模式，提供抽象的estimator供應用組進行開發和運作
除了這些，對我們進行架構設計也具有極大的知道意義。讓我們換了一種思考模式去思考面對新的需求，如何設計的問題。
我們不希望每次遇到一個新的業務問題，都需要根據自己的聰明才智，通過經驗，得到一個解決方案。任何事情都是有迹可循的。正如吳文俊提出的機器證明，可以通過流程化的方式讓計算機來證明幾何問題。當面臨一個新的業務問題的時候，我們應該有标準的流程可以走。
<code>針對業務邏輯，定義好如何對資料進行transform 哪個estimator 最适合這個transformer？ 從已經存在的transformer中找出我們需要建立pipeline的transformer</code>
一個複雜的業務必定是由多個transfomer進行建構的，每個transfomer的建構流程都可以遵循這個方式。
假設我現在有個搜尋服務，我要新接入一個産品，再次假設新産品的資料已經遠遠不斷的放到了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服務，還能對機器學習流程進行模組化。