本文作者：惠岸 朋春 謙樂
timetunnel（tt）在阿裡巴巴集團内部是一個有着超過6年曆史的實時資料總線服務，它是前台線上業務和後端異步資料處理之間的橋梁。從宏觀方面來看，開源界非常著名的kafka+flume的組合在一定程度上能夠提供和tt類似的基礎功能；不同的是，在阿裡巴巴的業務體量和訴求下，我們有比較多的配置管控、資源排程、軌迹校驗和血緣識别等方面的工作。
timetunnel産品架構
通過上圖我們清楚地看到，tt的核心部分是一個基于hbase做中間存儲的pub/sub服務，它提供了一個能支撐高讀寫比、大吞吐量和資料不丢的隊列服務。除此之外，基于日常運維考慮，我們還支援了按時間seek和彈性伸縮的能力。
資料需要在pub/sub“落地”的需求一方面來自于業務上對熱點資料多份消費的考慮，另一方面一些線上算法方面的應用需要經常性地對資料進行回放訓練，資料“落地”能夠比較好地對前背景進行解耦。事實上，tt裡最熱門的資料（例如天貓交易相關）有超過100倍的讀寫比；而從整體來看，僅雙11當天流出tt的資料也比流入的資料多了3倍以上。
選擇hbase作為中間存儲的原因是能夠成本較低地複用基于hdfs的多副本存儲能力，以及hbase自身在提供讀寫服務時對于熱點資料的記憶體管理能力。圖 8是寫入tt的資料在hbase中的存儲模型，我們在broker層面通過構造合理的rowkey來使得同一個分區下的資料可按rowkey順序scan；同時，因為在生成rowkey的時候我們使用了broker上的時間戳作為高位變量，是以能很友善地提供按時間seek的能力。
資料在hbase中的存儲模型
上圖左側黃色部分是tt的資料采集方案。我們通過以下途徑來準實時地收集前台業務産生的增量資料：
依賴drc實作對mysql、oceanbase以及oracle等前台業務資料庫的增量變更進行捕捉解析；
自研的日志agent部署在數十萬台的應用伺服器上，準實時地捕捉應用日志的變化；
和其他一些内部主流存儲例如ots進行打通；
使用者采用tt提供的sdk主動寫入。
随着集團内重要業務異地多活架構和全球化的發展，資料采集分散在跨越數千甚至上萬公裡的多個idc中；而與此相反，以galaxy、odps為代表的大資料計算服務則需要考慮充分地利用大集中的架構來提升吞吐能力。是以，不可避免地在資料采集過程中需要對資料進行緩沖和壓縮以盡可能降低長途鍊路對于吞吐量的負面影響。
沖突的是，緩沖意味着前端産生的資料需要在采集端“等待”，也就意味着消費方看到的資料是延遲的。這對于像阿裡媽媽這樣依賴tt做反作弊和實時計費的業務來講是很難接受的，資料延遲意味着資損，意味着使用者體驗的顯著下降。同樣地，壓縮也是要消耗采集端的伺服器資源的，尤其在雙11這樣的場景下，前台業務對于采集端的功耗尤其敏感。
遺憾的是，世界上從來沒有一個隻帶來好處而沒有任何弊端的事物，軟體和産品的設計中處處都是折衷和取舍。除了在技術層面将實作細節做到盡可能極緻，tt為了服務這些不同的場景，也提供了一些可配置的參數例如buffersize、sendthreads、compresslevel等用來比對使用者對延時、性能以及功耗的不同需求。
tt差別于其他類似産品的最大之處，是我們通過技術埋點實作了一套完整的資料軌迹校驗的方案——我們稱之為“門将”。軌迹校驗的目的在于通過監控的手段來保證“資料不丢”，設計得好，甚至可以識别出資料的重複、亂序等情況。
幾乎所有類似的産品都宣稱自己能做到“資料不丢”，當然也包括配備了“門将”之前的tt。有意思的是，幾乎所有類似的産品都會被“丢資料”這個問題困擾，同樣包括tt。因為我相信我們一定有能力在軟體設計以及編碼實作方面做到“資料不丢”的承諾，但往往會在一些預期外的異常case、版本更新或者系統耦合的地方出現這樣那樣的纰漏，進而導緻下遊消費方看起來缺失了部分資料。
以日志采集為例，我們碰到過因為作業系統的限制（請參閱max_user_watches相關的說明），inotify沒有通知到新檔案的産生而發生整個檔案漏采集；也碰到過因為軟體的bug在遞歸建立子目錄的情況下出現了時序問題導緻檔案漏采集；還碰到過儲存在應用伺服器上的checkpoint檔案被意外損壞導緻的“丢資料”。這樣的案例實在太多，而且防不勝防。
是以，工業界真正的“資料不丢”我認為是有完備的機制能夠快速地發現資料丢失，考驗的是系統的監控能力。
上文提到過，tt支撐着阿裡媽媽的實時反作弊和點選計費業務；同樣地，螞蟻金服大量涉及資金核對和商戶對賬的業務也将身家性命托付在tt上。這樣的業務不允許有任何原因導緻的資料正确性問題。
“門将”的核心思路是在采集端往tt寫入資料的同時，構造恰當的meta，将資料“連結清單化”，進而能夠在“門将”的校驗服務裡對資料軌迹進行還原，進而和源頭進行校驗（圖 8）。
仍然以日志采集為例。在采集過程中，我們以ip+dev+inode+sign來唯一識别内網上的一個檔案，在構造meta時記錄下目前資料包在原始檔案中的offset和目前資料包的大小size，那麼對于同一個檔案的多個資料包，通過offset和size就能快速地識别出檔案内有沒有被重複采集或者遺漏采集。如果在恰當的時間内與這台機器上ls指令得到的結果進行比對，就很容易發現有沒有檔案被漏采集。
所有的技術實作都是業務需求的抽象，這些需求有可能來自于大多數使用者需要用到的功能，更有可能來自對上下遊業務架構和場景的了解。資料總線服務是一個和業務架構耦合非常密切的基礎元件，阿裡巴巴集團獨特的技術架構、多樣性的存儲方案和橫向平台化的研發模式賦予了tt探究更複雜問題的原動力。
在2016年雙11這樣一個萬衆矚目的時間點，tt通過前期的軟體性能和機房規劃上的努力，高峰期單一叢集承擔了15gb/s的寫入和50gb/s的讀取流量，首次做到了對所有業務進行不降級服務。這對于我們、對于搭建在tt上的衆多業務，都是極大的鼓舞。
每年雙11除了“折扣”，阿裡人關注的另一個焦點，就是面向全世界媒體直播的“實時大屏”（如下圖所示）。包括總成交量在内的各項名額，通過數字次元展現了雙11狂歡節這一是買家，賣家及物流小二共同創造的奇迹！
圖：雙11媒體直播大屏
為實作這一大屏，背後需要實時處理海量的、龐大電商系統各個子產品産生的交易日志。例如雙11當天産生的日志量達到了pb級别，而每秒處理的峰值更是高達近1億事件！
如此大規模、高吞吐和低延時計算，帶來一系列世界級的技術挑戰，包括：
實時程式設計：流式的資料處理給業務邏輯的表達和推理帶來了很多的複雜性。特别面對不斷變化的業務需求，如何幫助使用者快速地編寫和驗證明時計算邏輯是至關重要的。
低延時：實時計算強調計算延時和結果的時效性。例如實時大屏對計算延時特别敏感，每年的雙11都超越前一年更早地達到相同的成交量，系統需要在秒級甚至毫秒級反應出每一筆交易。即使在流量高峰時（雙11晚0:00點）也需要保證延時！
叢集使用率：為提高資源使用率，我們将不用業務的實時處理邏輯共享一個叢集。這樣的共享也帶來性能隔離的問題，即如何讓同一台實體機上的不同邏輯任務不互相幹擾。這也是大部分開源架構忽略的重要問題。
嚴格容錯及資料一緻性：随着應對高吞吐而不斷擴大的叢集規模，各種軟硬體故障都難以避免。如何保證明時計算在任何故障下都能産生準确、一緻的計算結果，不遺漏、重複事件輸出，也不引起内部狀态的偏差，是另一個重大挑戰。
多樣化場景支援：随着實時決策對業務的價值越來越多，系統還需要支援越來越複雜和多樣化的場景，如線上機器學習、結合圖計算實作的動态關系網絡分析等等。
下文介紹galaxy的重要技術創新，簡要描述它們如何幫助應對以上技術挑戰。
為了簡化使用者程式設計，特别是利用原有的離線計算作業快速實作實時計算，galaxy允許通過高層描述性語言，如使用者熟悉的sql來編寫流計算作業。通過簡單幾行sql代碼就可以實作過濾、雙流關聯等業務邏輯。
在執行時，由于資料是以流式進入系統的，使用者的sql就像資料庫視圖一樣，被自動增量更新，并以一定的頻率輸出結果，供下遊計算和展示。
這一獨特的程式設計設計，不僅幫助使用者借助熟悉的離線處理思維表達實時計算邏輯，也因為同樣的程式可以在離線系統運作，使得結果的對比變得易如反掌。
使用者的sql腳本經過編譯優化，生成資料流圖，然後運作于galaxy的分布式引擎之上。相比開源資料流引擎，galaxy引擎在“阿裡巴巴規模”下，面對真實複雜的業務場景做了很多優化。包括自适應的消息打包、自定義序列化、資料行+列壓縮、先進的記憶體管理、和内部緩存隊列和線程模型，以及基于下遊向上遊“反向”傳遞壓力的流控政策等。
圖：galaxy優化執行流和運作時子產品
經過以上一系列的優化，galaxy相比去年提升了6倍左右的吞吐性能。下圖顯示了galaxy相比開源系統的性能優勢。在面對今年雙11 3倍于去年的峰值情況下，表現非常穩健。
圖：開源架構性能對比，通過“視窗wordcount（6組參數）”基準測試擷取
galaxy面對阿裡巴巴集團衆多業務場景，将不同業務放置于大規模（幾千台伺服器組成的）共享叢集中，以提高資源使用率。另一方面也随之帶來了“多租戶”環境下的作業資源隔離問題，它直接影響資源的有效利用和作業的計算性能。
經過多年的積累，galaxy支援cpu、記憶體、網絡和磁盤i/o等多元度資源的隔離。例如，對于cpu的隔離支援靈活的min-max政策，既保證了每個作業最基本的資源需求，也使的空閑的資源被最大限度利用。
圖：作業次元的cpu資源min-max共享模型
在此基礎上，galaxy的資源排程還支援一定比例的“超賣”、作業優先級排程、動态負載均衡和微作業共享單一實體核等多種機制。對于資源消耗特别大的作業還支援動态按需配置設定（即資源的彈性配置設定）。在滿足複雜的運維要求和實時計算連續性的同時，實作了高效的資源利用和性能隔離。
流計算需要連續處理可能無界的輸入和連續産生輸出。在長時間運作中，大規模計算叢集的各種軟體或硬體故障難以避免。由此對于計算和中間結果（如記憶體狀态）的容錯就至關重要。為了做到精确的容錯和故障恢複，保證結果的準确性。galaxy支援多種靈活的容錯政策，以在不同計算特性下，權衡容錯資源消耗和恢複性能。如基于輸入的重新計算、狀态檢查點（checkpoint），甚至是多副本的狀态和計算容錯等。
特别是自動的分布式增量檢查點功能，系統自動利用記憶體、本地磁盤和遠端存儲構成的多級存儲，在不影響流計算延時的情況下異步實作了計算狀态的持久化。當有故障發生時，儲存的狀态可以被快速加載。這一切對使用者都是無感覺的。
圖：自動利用多級存儲的流計算狀态管理
除了sql這樣高層的描述語言和使用者自定義邏輯（udf），galaxy還支援apache beam api，以提供更為靈活的實時邏輯程式設計。beam是一個統一開放的大資料應用程式設計接口，可以同時描述離線和線上邏輯，最早由google提出。beam提供了功能豐富的程式設計接口，能有效的處理有界、無界、亂序的資料流輸入。 下面顯示了通過beam實作的流式wordcount的例子：
借助beam，使用者可以利用高性能的galaxy引擎，定制面向特定領域的系統互動接口。同時，galaxy今後也将相容更多生态（如spark streaming和flink streaming api）。
galaxy還提供了“一站式”的內建開發環境——貝葉斯（bayes，https://data.aliyun.com/product/sc）和自動化運維平台——特斯拉（tesla）。通過它們，使用者可以友善地管理流計算應用的生命周期，包括程式設計、調試、監控運維，極大地降低了流計算系統的使用門檻。
圖：貝葉斯內建開發環境
為保障系統在雙11平穩支撐業務，在以上功能基礎上，我們還總結了完整的全鍊路保障方法：
主備雙鍊路容災：利用galaxy對多副本執行的支援，面向雙11重點媒體大屏等實時業務，實作了跨機房的多鍊路副本。哪怕是整個機房的故障，都能在秒級自動切換到另一副本上執行，保障了雙11系統高可用。
實時全鍊路監控：我們從資料采集、讀取、消費、入庫各個環節都增加延時名額的埋點，可以清晰地看到整條鍊路各個階段的延時，快速分析哪個元件性能瓶頸。另外，針對作業本身運作情況，比如輸入吞吐、流量、cpu和記憶體消耗，都做了實時分析和展示的系統，能在秒級發現作業的異常。
運維診斷工具：為應對各種應急響應，我們做了一套完整的運維診斷工具用于發現叢集熱點機器、熱點作業。在tesla頁面上能快速找到叢集的熱點機器，通過“機器分析”工具檢視這台機器上實時跑的任務，并且能定位到相應的業務和使用者。通過“作業分析”工具能自動診斷異常，結合作業的優先級，實作了一鍵負載均衡、啟停、續跑等運維操作。
通過這些保障設施，雙11當天，即使在發生交換機硬體故障的情況下，面向全球直播的媒體大屏業務并沒有受到任何影響！
擁有這些和其它諸多能力，galaxy已經具備了相當完善的實時計算能力，也提供了“一站式”的解決方案。今年雙11當天，galaxy處理了pb級别資料，處理峰值達到了1億事件每秒，平均處理延遲在毫秒級！除了雙11媒體大屏，galaxy還支撐着阿裡巴巴集團内外衆多實時業務，包括資料營運、廣告營銷、搜尋個性化、智能客服、物流排程、支付寶、聚劃算等。
每年雙11都是阿裡巴巴從最“前端”到最“背景”所有系統整條鍊路的一次大考。電商線上系統的浏覽和消費産生了大量資料，其資料量是平常的數倍到數十倍。這些資料最終要流到阿裡巴巴的大資料計算服務—maxcompute上來處理。
maxcompute承載了阿裡巴巴集團所有的離線計算任務，是集團内部核心大資料平台。截止到目前支撐着每日百萬級規模的作業，整個系統擁有數萬台機器，單叢集規模上萬，存儲已經到達了eb級别，每天有數千位活躍的工程師在平台上做資料處理。
面對如此多的海量資料，首先需要能夠低成本的将資料存儲下來。maxcompute依托背後的飛天分布式作業系統，将大量低成本pc服務管理起來。早在2013年，我們基于對業務增長速度的判斷，發現系統的存儲馬上就要“撞牆”了，叢集的規模将要應付不了與日俱增的資料量。直到後來成立了5k項目組，對技術難點進行了攻堅，将單叢集規模擴大到了5000台，阿裡巴巴也成為了中國首個獨立研發擁有大規模通用計算平台技術的公司。
實際上單叢集規模到達上萬台本身技術挑戰非常大，因為規模上來以後對系統設計要求非常高，整個架構不能有單點。但是整個業務規模決定了1萬台機器是不夠的，是以maxcompute抽象出來一個控制層，将分布在各個不同資料中心的多個計算叢集統一管理，根據業務特點将不同的業務放在不同的計算叢集中，通過跨叢集複制，自動将資料在多個叢集中同步，使得使用者可以把計算引擎當成一個平台。
運作在maxcompute上的業務種類非常多，各個業務部門之間資料也有着錯綜複雜的依賴關系。如果恰好資料不在同一個地域/機房中，那麼就要進行資料的異地讀寫。比如分析支付寶的資料需要淘寶的資料，支付寶的資料和淘寶的資料并不在同一個機房叢集，那就需要跨叢集的去讀（直讀），或者将資料拷貝到本地再讀（跨叢集複制）。此外由于資料是會被更新的，比如淘寶的資料更新了，這個時候要求支付寶的作業能夠讀到最新版本的資料。生産任務有各自的基線時間，對處理時間有要求，不能由于互訪資料導緻任務延時太長。機房之間雖然有幾十到上百g的直連網絡專線，但其他生産業務也對網絡帶寬有需求，互訪資料不能把帶寬都占滿，需要有網絡流量控制。多個任務可能會通路同一份異地資料，再考慮帶寬占用的限制，是以通路異地資料不能全部都通過直讀異地資料來解決，有的異地資料需要在本地複制一份以供多次任務使用。
為了解決這個問題，maxcompute引入了跨叢集複制和全局排程機制。maxcompute上所有的資料表和分區的中繼資料引入了版本号，當資料被更新時，其對應的計算叢集版本号也會更新。版本更新後，新版本所在的計算叢集的資料需要被複制到其他計算叢集。但這個複制操作該何時發生，需要考慮多種因素，比如任務完成時效要求，多叢集之間的帶寬大小等。對這些因素進行全局分析，才能利用動态預先調整，遠端讀，複制等多種手段做到全局排程。但這一全局分析需要系統運作資料才能進行。maxcompute中的中繼資料、資料血緣關系的分析，以及整個系統運作過程中産生的資料都會收集到中繼資料倉庫，這樣可以利用平台本身的資料分析能力來分析這些資料。這些資料被用來輔助maxcompute平台的工程師做資料化營運，甚至用來幫助系統自身進行優化。
通過對每天運作的作業進行分析，我們發現大部分作業都是重複執行的。這是資料倉庫中的一個典型的使用場景： 每天産生的新資料被同一套資料處理任務批量重複執行。這樣的場景帶來了巨大的優化機會。首先每天運作的任務所占用的資源資訊會被記錄下來，比如運作時占用的cpu、記憶體和運作時間。工程師新開發的作業在第一次運作時，申請的cpu和記憶體一般都會和實際占用的cpu、記憶體有所差别。如果申請的大于實際占用的，會造成排程的時候為作業多留資源，造成資源浪費，即資源的使用率下降。如果申請的小于實際占用的，會造成一台機器上排程的作業超過了機器能夠承載的負荷。這兩種資源錯配的後果都會降低系統使用效率。最理想的結果是作業申請的資源與實際使用的能夠完全比對。
hbo( history-ed based optimization) 基于曆史運作資訊的優化就是通過收集作業的曆史運作記錄，根據實際cpu、記憶體占用來指導作業合理設定的一種優化手段。它是對叢集資源配置設定的一種優化，概括起來就是根據：任務執行曆史+叢集狀态資訊+優化規則，得到最優的作業資源配置。
hbo包含兩部分工作：
線上部分(online)：查找是否存在相應的hbo優化計劃，如果有，則按照計劃進行資源配置設定并執行
離線部分(offline)：從中繼資料倉庫和神農擷取任務的曆史執行記錄，按照一定的政策生成hbo優化計劃
下圖為hbo的流程架構圖：
正常情況下，這種基于曆史的優化效果非常顯著，因為作業總體資料量在天與天之間變化一般不會很大。但到了雙11，由于當天産生的資料量通常是前幾天的數倍甚至數十倍，對于一些極限情況需要做特殊處理。比如作業instance數會因為處理的資料量增大同步增長而超過單個作業instance數量上限。依托hbo的工作，可以識别重複的作業、并且能夠精準的對單個作業進行設定。利用這個能力，我們可以在節日前先對所有作業做一次分析，比如找出輸入表在去年雙11當天資料量顯著增漲的作業，或者找出instance數量已經快要接近極限的作業，将他們單個instance處理的資料量設大，順利度過雙11的考驗。以同樣的手法可以指導制作針對雙11的預案，比如調整cpu、記憶體的設定、提前發現資料傾斜等等。