2016年雙11阿裡巴巴的産品成交額達到1207億元，而面對與交易額一樣巨大的流量洪峰，直播媒體大屏是怎樣做到将交易資料實時計算并且準确顯示出來的呢？在這背後究竟用到了哪些資料技術與産品呢？本次阿裡巴巴2016雙11技術創新論壇上，來自阿裡巴巴資料技術與産品部的進階技術專家羅金鵬（藏六）就為大家分享雙11媒體大屏背後的那些事。
<b>以下内容根據演講視訊以及ppt整理而成。</b>
本次為大家分享《雙11媒體大屏背後的資料技術與産品》。阿裡巴巴從2009年開始雙11産品大促，從最初的5千萬的産品成交額，到2016年的1207億的産品成交額，可能逍遙子自己也想不到，居然一不小心把事情搞這麼大。
在2014年，也就是ipo元年的時候，我們資料技術與産品部團隊開始承擔雙11的資料工作。因為是ipo的第一年，公司非常重視，決定要做現場直播。剛接到現場直播的資料媒體大屏任務的時候，我們團隊也非常緊張，緊張的同時也花費了大量的時間進行準備。但不巧的是在那一年11月10号23點50分的時候，前端還出現了問題，前端展示的趨勢圖突然顯示異常了，所有人都不知道是怎麼回事，于是開始緊急檢查，在最後5分鐘的時候檢查出了問題所在，在最後的5分鐘内，前端工程師緊急将這個bug修改完成。當時所有人都有一種非常崩潰的感覺，所幸的是那年的直播過程中資料媒體大屏并沒有出現什麼太大問題。但是一些的服務于商家的資料産品，比如生意參謀，還有服務于小二的阿裡直播廳等資料産品因為巨大的流量出現了延遲問題。這些問題的出現都是計劃外的，如果是計劃内的那就不叫故障而叫做服務降級了。
2014年的媒體大屏總體效果還是非常好的，從這之後阿裡巴巴每年雙11都會舉辦媒體大屏的活動而且是現場直播。當然媒體大屏上的數字是年複一年地增大，面對如此巨大的數字，很多人就會質疑我們的資料準确性和真實性。包括美國證監會在内的監管機構也是一樣，他們随時都會來檢查我們的資料，甚至于連代碼也會一行一行地進行檢查，是以每年雙11的代碼都會封存起來以備檢查。
整體而言，對于實時計算，需要面臨很多的挑戰。這其中最重要的有四大挑戰：海量、穩定、準确和及時。
海量資料的挑戰是顯而易見的，這8年來，從整體交易額就能看出資料量也是數千億地進行增長的。而因為需要面對電視媒體的現場直播，是以在穩定性方面也不能出現任何的差錯。在準确性方面，正如剛才所提到的包括美國證監會在内的監管機構會随時檢查我們的資料甚至是代碼，是以資料的準确性也是要求非常嚴格的。而及時性則是說從0點開始，必須保證在5秒内媒體大屏上的第一個數字就需要開始跳動，因為這時直播就開始了，而到24點時資料就必須停止展示，是以需要将資料在最短的時間内算好。以上就是我們在實時資料計算方面需要面對的四大挑戰。
那麼又該如何去應對這些挑戰呢？接下來從三個方面資料鍊路、資料模型和保障措施介紹應對實時計算的挑戰的方法。
資料鍊路
下圖是資料實時計算的鍊路，這張圖其實也包含了離線計算的鍊路。從左到右來看這張圖，資料鍊路的開始部分，也就是日志的同步和db資料同步。目前日志檔案的同步全部采用增量檔案同步的方式，這一過程可以依靠一些開源的工具完成日志的增量同步；而對于db資料的同步而言，則是既有增量資料同步的方式也有全量資料同步的方式。增量資料同步的工作是由阿裡内部的drc産品承擔的，而對于全量的資料同步，阿裡也有自己的資料工具，比如說datax，它可以負責将資料定時同步到批量計算引擎中。
接着實時資料同步的後面是分布式消息隊列，也就是消息中間件。分布式消息隊列的主要功能是将消息存儲起來，使得一份消息可以供多個的下遊進行訂閱，比如流式計算引擎也是消息隊列的下遊中的一方，而在正式的生産環境，其他的資料計算引擎也可以訂閱消息。
圖中框起來的這部分稱為資料公共層，資料公共層包括有流式計算引擎、批量計算引擎以及結構化存儲和資料服務引擎。資料公共層所要完成的重要工作基本都在這些地方完成，其中流式計算引擎通俗講叫做實時計算，它做了很多計算的工作，資料的準确性和實時性很大程度上取決于資料公共層。資料計算的結果存放在結構化存儲中，這裡我們使用的是hbase來存放計算結果資料，批量計算引擎計算的最終結果也會同步到結構化存儲裡面，對于結構化存儲而言，則可以使用hbase或者是mysql叢集等。最後當資料産品需要計算結果資料時，是不允許對結果資料進行直接調用的，需要通過内部的資料服務引擎才能得到資料服務，後面也會分享阿裡巴巴的資料服務引擎是如何對外提供服務的。在資料公共層之後的資料接口就會提供給媒體大屏、小二直播以及生意參謀等資料産品以及阿裡巴巴資料營運的其他的産品，整個資料計算的鍊路大緻就是如此。
接下來分享一下，資料實時計算鍊路上一些比較重要産品。
<b>增量資料同步</b>
首先是增量資料同步這款産品，目前我們使用的是drc，其全稱是data replication center，它負責對異構的資料源進行實時的遷移同步以及資料流訂閱的資料管道基礎技術設施。它最重要的服務場景有：跨域實時同步、實時增量分發、異地雙活以及分布式資料庫。
右側的圖是最初使用mysql叢集進行資料同步的版本，此時其已經具備增量資料同步的基本功能。其進行增量資料同步的主要原理就是對binlog進行實時解析，在解析完成之後将産生的資料同步到mysql的備庫裡面，這樣就能完成主備資料庫的實時同步。
<b>分布式消息隊列</b>
接下來分享一下分布式消息隊列的一款産品——tt/data hub。大家可以在阿裡雲上使用到付費版的data hub産品，這個産品其實是一個消息中間件，其主要的特性是高效、可靠、可擴充，并且是基于生産者、消費者和topic模式的消息中間件。topic模式是區分于點對點模式的，topic模式可以使得消息在經過一次發送之後可以被多次消費，一個消息源可以供多個下遊訂閱。
當然對于分布式消息隊列而言，也有很多其他的選擇，比如metaq也就是阿裡巴巴剛剛捐獻給apache基金會的rocketmq，它也是一款非常優秀的消息中間件；另外還有很早之前就比較出名的kafka等。對于一個優秀的架構師而言，架構設計肯定不是照搬照抄的，需要适應不同的業務場景進行合理的架構設計，結合不同産品的特性選擇最适合于場景的産品。比如我們在内部對于rocketmq和kfaka進行測試時發現：kfaka消息中間件在消息量比較少的情況下性能比較好，其單機的qps會非常高，但是在topic訂閱量非常高，業務比較複雜的情況下，kfaka的吞吐量則将會急劇下降，而rocketmq在處理複雜的訂閱關系和業務時，卻能保證線性的擴充。
<b>流計算引擎</b>
接下來介紹使用的流計算引擎産品，我們目前使用的是galaxy平台。galaxy是阿裡雲的通用流計算平台，這個産品最重要的特點是易用性非常高，支援sql模式。大家都知道流計算的開發成本相對于離線計算而言還是比較高的，一般而言都需要使用java寫很多代碼，是以有很多同學就需要重新學習java，而對于隻會python或者sql的同學就無法進行開發流計算的任務。而galaxy是支援sql模式的，這樣掌握sql的同學就可以完成流計算開發任務了。除此之外，galaxy支援資料準确性高的模式，還可以定制模式，另外可以支援叢集線性擴充以及容錯和多租戶等，并且可以進行資源隔離。當然對于流計算産品而言還有一些其他的選擇，比如jstorm、flink以及spark streaming。
<b>結構化存儲</b>
結構化存儲部分，也就是流計算或者批量計算引擎最後需要将資料存放到地方。我們選用的是hbase，大家當然也可以選用阿裡雲的ots，也就是開放結構化資料服。ots是建構在飛天大規模分布式計算系統之上的海量結構化和半結構化資料存儲于實時查詢的服務。ots以資料表的形式來組織資料，保證強一緻性，提供跨表的事務支援并提供視圖和分頁的功能來加速查詢，非常适用于資料規模大且實時性要求高的應用。
<b>資料模型</b>
接下來從第二個層面也就是資料模型層面進行分享，聊一聊面對海量資料進行快速而又準确的計算需要面對的挑戰。
<b>實時資料公共層</b>
提到實時資料公共層，大家往往會問為什麼需要做資料公共層這個問題。其實阿裡巴巴的資料業務是非常複雜的，阿裡有很多像來自于電商的資料，這些資料往往很多bu也都需要使用。在很早的時候，很多部門往往會自己從源頭計算一遍來擷取這些資料，也就相當于煙囪模式的開發。這樣的開發模式有一個優點就是效率非常高，因為不需要依賴其他的任何團隊就能擷取想要的資料，開發出想要的功能，但是這樣的缺點也非常明顯，也就是會導緻非常多的重複開發和計算。當時我們的團隊在做離線計算的時候發現，當時整個阿裡巴巴集團的離線計算叢集每年的增長速度是2.5倍，大家可以算一下，經過5年這個資料量會是原來的多少倍呢？大約會是原來的100倍，假如在最初的一年在離線叢集資料伺服器上的投入是10個億的話，經過5年之後這上面的投資将會達到一千億。是以我們在離線計算方面做了實時資料公共層這個項目，将離線計算裡面的一些公共的模型抽象出來由我們團隊負責呈現，建設好之後将這些公共的模型提供給其他的bu以及業務部門使用。
而對于實時資料而言，建構資料公共層的隐患也是非常多的。實時計算叢集規模比較小，離線計算叢集可能是幾千台，而實時計算叢集可能在開始時隻有幾十台機器，最多也就上百台，但是實時計算叢集的增長速度遠遠超過離線計算叢集的增長速度，可能會是離線計算叢集增長速度的10倍，以這樣的增長速度實時計算叢集很快就可以超過離線計算叢集，是以這個成本将會更加恐怖。
是以在實施離線資料計算公共層項目的同時也開始了實時資料集計算公共層的建構。從上圖中可以看到，業務層的資料表經過drc實時、日志通過tailfile同步到消息中間件，公共資料層裡面的明細層會對這些資料進行第一次處理，明細層處理完的資料結果還會回流到消息中間件。也就是說對于下遊的使用者而言，明細層處理完成的資料就形成了一個新的資料源，而且這個新資料源和原始資料源相比，進行了很多解析和處理的工作。
比如一筆交易訂單過來，其背後可能會有10條相關資料會産生，而這10條資料其實可能就是為了得到一些比較簡單的資料比如交易的金額，而在這背後其實需要明細層進行很多複雜的運算，這個運算最後的結果回流到消息中間件之後可能就變成了一條簡單的資料，如此就可以供下遊非常友善地使用。如果不做這樣的工作，可能每一個下遊都需要處理這10條資料記錄，那麼叢集的規模就需要上百倍地增長。通過實施資料公共層進行資料處理之後，下遊應用隻要訂閱明細層的基礎資料就可以了。
彙總層也是這樣，彙總層處理的資料會存放在hbase提供對外的資料服務，如果下遊想要使用彙總資料就可以直接通路資料接口不需要自己再進行計算。
在雙11的時候，實時資料層qps的峰值超過一個億，bps每秒鐘超過一百g，占到整個galaxy吞吐量的80%多。如果沒有實時資料公共層，galaxy叢集的規模可能需要目前的上千倍。
<b>實時計算事務處理</b>
實時計算事務處理機制是保證資料準确性的最重要工作。因為當一切正常的時候，事情往往會很簡單，但是通常情況下事情卻不會那麼簡單，比如網絡中斷時，源頭的資料會需要重發；再比如消息中間件可能無法保證資料準确性達到exactly once，這個時候的很多工作就需要流計算的開發同學自己來做，這時就需要實時事務處理的機制了。我們從資料源頭到中間聚合的過程以及最後的結果都使用了一些政策來提升最後資料結果的準确性，比方說資料源這個層面，采取了中繼資料資訊schema統一管理，也就是對于消息中間件的資料偏移量進行統一管理，這樣可以記錄資料偏移的位置。當某個事務需要重新處理的時候，我們能夠知道資料從哪一個位置重新進行計算，而不會全部從頭開始。另外我們還做了從zk切換到hbase的工作，因為zk的性能跟不上，是以需要切換到hbase來滿足業務發展的要求，在完成切換之後，事務處理性能有了很大程度的提升。另外還實作了業務時間監控報警的功能，對于實時計算的資料，要判斷是否有延遲其實要看這一批量的資料最近一次更新的時間，比如在21點的時候發現這個資料最後處理更新的時間是20點，就可以發現這個資料已經有一個小時的延遲了，如果資料延遲超過了設定的門檻值，就會報警。
從聚合層面，也可以做很多的事情，比方進行主鍵唯一性的過濾，可以實作資料的精确去重和布隆去重的優化。比如說在交易時需要資料非常精确，所有的資料都需要進行精确去重，一旦源頭的資料發生了污染，就需要将重複的資料丢掉。
布隆去重就是在對于流量、uv以及日志等對于流量精度要求不是非常高的場景下使用的一種資料去重方式，布隆去重主要是對資料通過哈希的方式組成資料集合，當新的資料來的時候就通過其哈希值進行判斷，當這個哈希值已經存在了，就說明這個資料有可能已經在資料集合裡面。這個判斷結果有可能是不正确的，但是出錯機率比較低，另外當通過哈希值判斷新的資料不在資料集合裡面時則是非常準确的。
對于最後的資料結果使用了backup的機制。因為流計算的處理可能會中斷，比如因為資源不夠的原因将某個程序殺死，在程序被殺死之後會需要重新開機這個程序，重新開機的時候就需要重算。有時需要将中間計算結果存儲在結構化存儲裡面，在程式重新開機的時候就可以讀取這些中間計算結果，這就是backup的機制。對于ttl機制，剛才提到過阿裡巴巴的流量資料是非常大的，當發生中斷的時候，就需要重新計算一些結果，可以根據自身業務的特點将近期一定時間段内的資料緩存起來，如果不設定ttl，記憶體肯定要爆掉，ttl的設定則取決于自身的業務。
<b>實時計算任務優化</b>
實時計算任務優化有很多可行的措施，第一個優化措施是合理地使用緩存機制，盡量降低讀寫庫的次數。計算機對于記憶體進行讀寫的速度是比較快的，是以盡量将最常使用的資料放置在記憶體裡面，這樣吞吐量才能夠提升。
第二個優化措施就是将計算單元合并，并且降低拓撲層級。流計算拓撲有時會非常複雜，并且複雜的拓撲結構的層級越深，它的性能也會越差，這是因為資料在每個節點傳輸的過程基本都需要經過序列化和反序列化的過程，而這個過程是非常消耗cpu和時間的。如果能夠減少拓撲的層級，将計算單元盡量地合并起來，整個系統的性能肯定會得到極大的提升。
第三個措施是記憶體對象共享，避免字元串拷貝。在海量資料進行中，大部分資料對象都是以字元串的形式存在的，在不同的線程間合理共享對象可以大幅度減少字元串的拷貝，因為字元串的拷貝是非常消耗性能的，不過也要注意不合理使用記憶體對象共享的記憶體溢出的問題。
第四個措施就是獨占資源和共享資源的政策。一般在多個機器中共享資源池是提供給多個任務搶占的，如果當一個任務運作的時候，80%的時間都在搶資源，這時就需要考慮配置設定給任務的資源是否足夠了。當然如果給每任務都配置設定獨占的資源，成本也會非常高，是以此時需要根據任務優先級高低進行權衡。
最後一個政策是批量送出和低延遲的權衡。對于批量送出而言，像mysql這樣的資料庫往往都有一些優化政策，這樣的政策其實就是将原本應該每次送出的工作積攢在一起，之後進行批量送出，這樣的做法可以節省時間，減少網絡的讀寫，但是也有一個缺點，就是延遲會非常高。比如實時流計算的任務，流資料從上遊流向下遊的時候，需要等這些資料攢到一定程度再進行送出，往往會發現下遊的資料一直沒有變化，必須要等到資料寫入之後，下遊才會感受到資料的變化，是以此時需要進行權衡，到底是要使得吞吐量更大還是延遲更低。
保障措施
<b>資料鍊路保障</b>
接下來從資料鍊路的保障措施的角度分享如何保障媒體大屏的穩定性。
整個實時資料處理的鍊路是非常長的，從資料同步到資料計算、資料存儲，再到最後的資料服務，這中間的任何一個環節出現了一丁點的問題都會導緻最終的數字不發生變化，這樣的話通過直播所有人都會知道我們的資料出現了問題。
但是在分布式計算中，單個節點發生故障是一種常态，在直播大屏的時候就更加明顯。是以為了保證資料的實時性，需要對整個流程進行多鍊路的建設，做到多機房的容災甚至是異地容災。當某條鍊路出現問題的時候，可以一鍵切換到備用鍊路，比如下圖中的配置中心可以進行鍊路切換的推送過程。當某一條鍊路出現了故障或者大量延遲的時候，配置中心就可以檢測到鍊路出現了問題，此時就可以非常迅速地發送一個鍊路切換推送的配置檔案，這個配置檔案會非常快速地發送到下遊的資料服務中，下遊的資料服務檢測到配置檔案以後會透明地切換到新的鍊路上，這樣下遊的資料産品是完全沒有感覺的。這就是非常重要的鍊路推送切換的保障。
<b>資料服務引擎：oneservice</b>
oneservice資料服務引擎是阿裡巴巴資料服務與産品部自己研發的産品。之前提到了資料往往不是直接提供給資料業務方或者下遊通路的，必須要通過oneservice服務。雖然這個服務會使得下遊使用資料不是很友善，但是其優勢也非常明顯，就是可以屏蔽由于資料庫切換或者資料庫變更所帶來的影響，可以實作對于下遊的透明。
oneservice服務包括三種産品，第一個是smartdq，它是一種簡單資料查詢引擎，通過實體表和邏輯表的組合綁定将具體的資料來源屏蔽在引擎内部。使用者在平台簡單配置一下來源表就可以做到不依賴任何應用代碼就可以獲得接口服務，也就是最終在使用資料接口的時候不需要關心資料存儲在哪一個實體庫上，隻要配置需求即可，oneservice還可以将不同的異構的資料拼接在一起提供資料通路。
第二種是lego，它是一種複雜資料查詢引擎，目前承擔了阿裡巴巴使用者識别、使用者畫像這樣的基于複雜資料處理的查詢，這樣複雜資料查詢往往是基于圖進行查詢的。
第三種是ipush，不同于前面兩種基于拉取方式，ipush是基于推送的資料服務。它提供的資料格式是基于jsonp或websocket的格式，它提供與流量或者交易相關的實時資料推送服務，當然這種方式的成本也是比較高的。
<b>壓力測試</b>
最後分享一下面對雙11時的壓力測試情況。
壓力測試是一個非常重要的環節，我們在2016年進行了11次壓力測試。壓力測試中有兩個比較重要的測試與資料關系比較緊密，一種是蓄洪壓測，另一種是影子壓測。
蓄洪壓測和影子壓測都是線上上環境進行的，但是他們也有很大的差別。蓄洪壓測就像是大壩把水存蓄起來一樣，存在将線上産品進行中斷的過程，比如将幾個小時或者幾天的資料全部積累起來，在某一個時刻全部放出來，以此來模拟雙11洪峰流量的情況。這裡面的資料都是真實的資料，比方說比如将實時資料的訂閱點位調到幾小時以前或者幾天以前，這樣每一批讀到的資料都是最多的，對實時計算的壓力也是最大的，但蓄洪壓測存在的一個缺陷就是線上服務在這之前其實是停止的，使用者會有非常明顯的感覺。
除了資料壓測還有一些對于産品的壓測，比如對資料大屏進行壓測。在對資料大屏進行壓測的時候，我們會收集對于資料大屏進行讀操作的url，通過壓測平台對這些url的流量進行回放，比如将qps設定為1萬，就可以按照1萬的qps目标進行壓測。産品壓測還包括前端的壓測，也就是像剛才講的2014年的故事，前端産品的壓測就比如說在浏覽器裡面測試至少8小時，然後分析這8小時内的記憶體以及cpu的情況來判斷前端是否發生了記憶體洩漏。
<b>接下來的挑戰和應對</b>
最後分享我們下一步要做的事情。從今年我們感受到實時計算平台的優化已經做到了極緻，假如未來流量進一步翻倍，又應該如何處理呢？整個叢集的規模已經增長到了極限，是以架構上不做改變的話，是沒有辦法抗住未來的流量洪峰的。
是以我們開始引進了data flow、apache beam，希望未來流量計算引擎能夠切換，除galaxy之外，還能對接jstorm、flink以及spark等。有的計算引擎吞吐量很大但是延遲很高，有的雖然吞吐量不是很大但是延遲很低，需要根據業務特點選擇不同特點的計算引擎，以便在下一個雙11來臨時克服流計算叢集引擎規模的問題。另外因為做流計算的也隻有幾位同學，但是要面對全集團的實時計算業務需求，可以說是力不從心。讓更多的研發工程師加入到實時流計算的行列，才能夠減少每個人的工作負擔，但是因為流計算的門檻非常高，尤其是雙11媒體大屏的挑戰要求非常高的服務，是以需要在上遊通過産品将開發門檻降低，我們明年規劃開發streaming develop product做成開放式的服務，通過托拉拽的方式生成流計算任務，同時能夠保證整個流計算任務的性能。
最後介紹一下整個資料技術與産品部，我們這個部門做的很重要的一件事情就是進行全域的資料集資産的建設。阿裡巴巴整個業務生态非常龐大，之前我們隻做到了電商資料的建設，其實還有很多除了電商以外的業務的資料，需要将這些業務的資料與電商業務資料進行有機的融合，建設全域的大資料資産服務。隻有将這些服務建設好才能更好地服務商家，小二以及媒體等。除了全域的資料資産建設之外，我們的産品還有服務商家的生意參謀，服務小二的資料平台、孔明燈、觀星台以及服務媒體的媒體資料大屏等。
大會系列整理文章：
阿裡雙11背後的網絡自動化技術——張銘（阿裡巴巴研究員）
阿裡大規模資料計算與處理平台——林偉（阿裡巴巴資深技術專家）
線上ai技術在搜尋與推薦場景的應用——徐盈輝（阿裡巴巴研究員）
揭秘阿裡虛拟互動實驗室——袁嶽峰（阿裡巴巴進階技術專家）
阿裡超大規模docker化之路——林昊（阿裡巴巴研究員）
雙11媒體大屏背後的資料技術和産品——羅金鵬（阿裡巴巴進階技術專家）
資料賦能商家背後的ai技術——魏虎（阿裡巴巴資深技術專家）
面對雙11的前端“極限挑戰”——舒文亮（阿裡巴巴進階技術專家）