總架構師眼裡的架構和架構師的成長之道

特約記者：盧億雷，精碩科技(AdMaster)技術副總裁兼總架構師，CCF（計算學會）大數據專委委員，北京航空航天大學特聘教授。

受訪嘉賓：鄧就慶（Jack），FreeWheel高級副總裁兼總架構師，擁有清華大學計算機科學學士和碩士學位。目前，他帶領一支架構師團隊全面負責設計和實施FreeWheel的核心繫統，包括廣告伺服器以及報告、預測、收入和費用計算等數據處理模塊。他還管理並指導基礎架構團隊，以支持並增強公司的服務能力，同時與運營部門密切合作，不斷優化產品和服務質量。

在加入FreeWheel之前，鄧就慶曾在創業公司Roxbeam擔任架構師，帶領一支幾十人的工程師團隊設計並實施基於P2P的視頻流媒體解決方案，包括客戶端應用、伺服器程序和管理工具等。職業發展早期，他為香港科技大學供應鏈管理和物流原型研究項目提供技術支持，其中包括GPS車輛追蹤系統和基於RFID的倉庫跟蹤管理系統等。

FreeWheel高級副總裁、總架構師鄧就慶

FreeWheel的技術團隊架構和文化

《程序員》：你在數據視頻的廣告領域精耕良久，FreeWheel技術團隊的組織架構是怎樣的？

鄧就慶： 10年前FreeWheel成立時，FreeWheel CTO Diane說服了另外兩個聯合創始人，把整個技術團隊建立在了北京。當時北京團隊的組織架構分成兩個模塊：UI團隊和Core團隊，前者主要負責將用戶的管理數據更新至資料庫，後者Core團隊又分為三部分：廣告伺服器AD Server、數據處理Reporting和預測Forecasting。

接著，FreeWheel又成立了一個新的Video Integration（客戶端集成）團隊，負責與客戶端到端的集成，幫助客戶將他們網站上的播放器集成到FreeWheel SDK，把客戶的廣告請求發送到AD Server模塊，然後生成特定數據至Reporting模塊，再將數據傳至Forecasting模塊用作預測，最終提供商業智能信息給客戶，客戶據此在UI上面來管理和調整廣告。所以這段時間大概有5個團隊。2011-2012年間，FreeWheel逐步開始在美國建設工程師團隊，主要集中在API和集成方面。

在FreeWheel技術人員有兩個發展方向：管理和技術，前者從經理→總監→高級總監→副總裁→高級副總裁→CTO；後者是從高級工程師→主任工程師→首席工程師→架構師→首席架構師→總架構師。

前面介紹的組織架構已運行多年，從2016年有了調整。在數百名工程師的規模下，若按照原有的5個團隊劃分會大大降低組織的有效性，所以我們慢慢轉向了矩陣式管理。比如，在垂直方向，從前端的UI→廣告伺服器→報表的工作模式，各個團隊根據某些業務應用的領域生成一個Squad（一個垂直的功能性團隊），但他們的彙報關係依舊屬於原來的團隊，只是形成了一個虛擬的團隊。目前在這種矩陣的管理模式下，FreeWheel大約有20個Squad。

《程序員》：FreeWheel的技術團隊有著跨國性、跨時差性等特點，在團隊管理方面有什麼心得和體會可分享？

鄧就慶：在2007-2013年，FreeWheel的技術團隊都在北京，而2013年之後，隨著團隊壯大、在美國建立了工程師團隊，以及收購了一家法國公司StickyADS，所以團隊合作方面的挑戰驟加，FreeWheel做了不少工作來迎接這些挑戰。

首先是調整和細分團隊。以一個項目為例，用Hadoop來替換舊的報表系統，在實施的過程中把一個美國團隊和一個團隊糅合到一起，共同開發一個功能，同時在這個層級下進行細微分工，相當於產生了兩個Squad垂直功能性團隊。

其次是尊重彼此。因為跨國的情況下不在一起工作，且時區不同，所以尊重彼此、承認彼此工作的獨立性尤為重要，即使StickyADs被收購后也是獨立工作的。

再者有意加強溝通合作。比如採取Rotation（輪崗）計劃，和法國的工程師可以到美國與產品經理在兩個月左右的時間中緊密地合作，訪問客戶、支持客戶的業務、處理客戶的問題，由此增加工程師對業務的了解和多邊團隊的溝通。

FreeWheel的技術棧和技術選型

《程序員》：你們做了很多的垂直系統，FreeWheel系統的技術架構搭建有什麼特點？

鄧就慶： FreeWheel的垂直系統跟普遍的廣告系統不同，FreeWheel不擁有流量而是作為技術提供商，且大部分廣告銷售是Guaranteed Sale（保障性銷售），客戶簽好合同后FreeWheel來執行合同。比如客戶提出廣告商的購買需求、目標流量等，FreeWheel幫助他們分配流量進而滿足廣告商的購買需求並增加收入，這和普通的推薦系統關係不是很大，比較近似的可能是線性規劃一類的優化演算法。

其次，FreeWheel的業務大多是品牌廣告——按照展示收費，所以不太關注CTR（Click-Through-Rate，即點擊通過率），但有時品牌廣告商認為僅僅展示並不是一個特別好的指標，而會進一步關注不同目標人群的展示價值，也是受眾的特性不同所致。

再者，FreeWheel系統會有一些特定的統計信息來跟蹤——xTR（類似於CTR），對應的每一個展示有一個評估計數用於計費，會據此來優化廣告商計費事件的比例——類似於CTR的優化點擊數。現在，最常用的演算法還是線性回歸，也在用人工神經網路來做一些預測，建立一個基本模型部署到線上，當一個請求過來時再根據模型算它的評估計數對應事件的概率，從而選擇較高的概率的結果，這類似於一般的系統。在這個基礎上，有時候也會使用A/B Testing來檢測模型效果。

值得注意的是，這個模型並非實時更新，而是一天一次，但其中預測是實時的，將模型做成一個服務更新至線上，每收到一個請求就檢查一次，並預測應該選擇的廣告。

《程序員》： FreeWheel技術棧的構成是怎樣的？

鄧就慶：之前提到的Reporting和數據需求主要建立在Hadoop上，數據收集從各個伺服器通過Kafka將事件基本上以接近實時的要求傳輸至中央數據處理系統。

FreeWheel建立了自己的數據導入模塊Data Ingestion Pipeline，把收到的Log經過處理使查詢優化，再存到HDFS上，此外還有另外一個Pipeline作為Disaster Recovery用於容錯，數據文件放在了Amazon S3上，並通過Kafka實現實時性。在這基礎上也有Mini Batch對實時數據處理而生成Dashboard。為了查詢方便，存儲使用了Parquet格式。存儲的粒度基於事件級別，一個事件對應一條記錄，不做聚集。在這個基礎上，我們使用Presto，自己做了一些Connector用Presto直接查詢來得到結果。

而在伺服器AD Server方面用了C++和比較多的庫，新的代碼使用的是C++ 11, 傳輸用的是Protocol Buffers，NoSQL用的是收費版本的Aerospike。還應用了Memcached來緩存一些元數據。AD Server收到請求會在處理之後再把結果返回去，通過Kafka把這個過程記錄下來，進而上傳到數據處理系統里。

然後是提供API服務給第三方系統（比如廣告管理系統）。舉例來說，Operative是一家專門做Order Management的公司。同時客戶一般會有自己的CMS系統。通過API，客戶將數據導到我們MySQL資料庫里。API和UI之前用的是Ruby on Rails，現在我們正在把UI和API分離開來，而使用類似於Single Page App的架構。新的API用Golang，也在嘗試用Docker/Kubernetes來管理API服務；UI之前很多是Server Side Rendering，現在因為分離而轉移到瀏覽器端，使用的庫是Facebook的React.js。

Forecasting和Machine Learning方面使用的語言是Python和Golang，用來搭建一些服務，性能敏感的地方也有一些C++。主要庫是谷歌的TensorFlow。

《程序員》：你們的技術選型選擇得很好，其中你選擇Presto的原因是什麼？市面上也有一些其它選擇，Druid如何？

鄧就慶：用 Presto的主要原因是數據系統的升級。老系統用的是C++，類似一個自建的MapReduce，將數據記錄分到各個節點用C++處理完后再合併到一個中央節點，做額外的聚集和處理。這個系統的主要問題在於做聚集以後數據修改和維護比較麻煩。FreeWheel用列式的資料庫Infobright來存聚集后的報表。Infobright與HP Vertica類似，我們使用的是社區版本。這個系統上主要的工作是數據維護，數據有問題以後，更新需要重載一遍數據，量級比較大也很費時。

第二是參考一些實踐后，發現Presto的設計相對比較簡單，且Connector可以自己實現，相對來講符合FreeWheel的架構設計要求。用Presto還有一個原因是來自同行業朋友的使用反饋比較好。

Druid的理念和系統設計非常不錯，其他比如Impala、Kudu都是Cloudera的系統也很好，但是沒有選的原因是考慮到社區規模和背後的技術團隊，Facebook顯得更加安全一些。

另外，Teradata和Amazon都有Presto的支持，比如Amazon現在也有了一個新服務Athena，把Presto重新包裝了，從這方面來講，Presto是一個比較安全的選擇。社區支持也是很重要的考慮。例如我們用的開源版本Infobright，需要自己維護而導致出bug很難處理。

數據分析師的從業指南

《程序員》： FreeWheel的數據分析能力很強，你認為數據分析師大概需要什麼樣的技能，最看重的是哪一點？畢竟有偏技術、產品和業務的。

鄧就慶：我個人認為數據分析的首要是數據，程序第二。如果一個人總是講編程語言或各種軟體等花哨的內容，我會認為他沒找到方向。

數據分析師第一個應先看數據，包括數據量和數據特性，比如說數據延遲的要求，畢竟實時性的要求不一樣，方法也不同。其次，也有存儲策略、數據處理、數據展示、存取模式、查詢模式等。舉例來說，我們是有多個客戶的，開始時數據按照自動方式存，客戶ID不在前面，所以要查一個數據時可能需要在硬碟上面跳著查，效率就很低。後來把客戶的ID放在前面再查詢，讀就變成Batch Mode，效率提升了10倍以上。所以，我們關注的重點就是從各個角度理解數據的特性，在這個基礎上面再考慮用什麼樣的工具。所以面試時我們主要關注其對處理數據特性的理解。

《程序員》：你們和運營部門合作比較密切，從而優化產品跟服務質量，你認為數字營銷的未來發展方向是怎麼樣的？

鄧就慶：我覺得會有兩個比較明顯的方向，一是數據驅動，未來會產生越來越多的數據，很多決策都依據數據來驅動，而不是以往的僅憑個人的經驗。其中數據有兩塊，首先是Targeting，即把廣告定位到每個人身上， Facebook、雅虎、Verizon和谷歌就是很好的例子，他們的目標都是要接觸更多的用戶，從用戶身上得到更準確的定位訊息，進而提高營銷收入。雖然，從雅虎和Verizon的角度，他們的流量並不是特別高端的流量，內容亦不高端（「高端」指專業製作的高質量視頻內容，而非用戶自行上傳的自拍或拍攝內容），YouTube亦是如此，但他們認可Targeting數據的價值。另外一塊是報表（或者是Insight和Measurement），即如何評估一支廣告的效果：有多少的受眾、有多少的到達率、每個人看了多少遍、觀感情況等。技術常用的是Hadoop，會有更多的日誌屬性，提供更多的交互查詢，而不受限於預定好的報表。

在數據驅動的框架下會催生更多的Data Science需求，因此FreeWheel會提供長期或短期的一些正在變化的見解。FreeWheel每個季度會發表《FreeWheel視頻行業發展趨勢報告》（Video Monetization Report，簡稱VMR），主要是從自身業務和客戶身上總結他們的業務發展趨勢。我們的內部實現是將原始的數據放在Hadoop上，用Presto查詢。從這些數據還會得到很多有意思的內容，比如廣告消費的增加、廣告消費的比例、不同觀看設備的變化等。

第二個趨勢是更多的程序化的互動和操作，包括人工智慧的加入，程序通過API來直接交互，而不是人。比如DSP集成、SSP集成、Real-Time Bidding、Ad Exchange市場，這些都將由人工智慧來完成，用戶只要提一個比較高層次的目標和計劃之後，就可以由程序自動來集成、優化以及執行所有的板塊。

《程序員》：因為當時提到怎麼樣評估廣告的效果。剛好我們Admaster也是做這一塊的，所以我也想問一下，現在市場營銷這個行業裡面確實存在著大量的虛假流量，你們用什麼機制和方式來識別和甄別呢？

鄧就慶：我明白這個問題，其實我們的業務與普通的那些做市場的企業有一些區別，我們更多是作為廣告技術提供商，客戶基本上很多都是大的內容商，所以這種反虛假流量的工作並不是特別多。但是我們還是會做一些審計。如之前講述的，我們用的是原始的Log。現在的主要做法就是跟蹤從某個IP出來的所有流量，每個用戶有一個ID，也會跟蹤每個用戶的行為。比如這個用戶發來一個重複的請求，或者這個用戶包括這個IP每天發來的請求數特別多，而且這個IP不是一個已知的服務端的集成，又或者某個用戶在發起請求的時候，速度特別快，發的特別多——類似這些情況，我們就會去統計，就會去留意是否存在問題。其實很多時候我們是靠設一個域值去監控，加一些規則去進行跟蹤。之前有家名為White Ops的監控公司，會提供可疑的IP列表。經過檢查，我們基本上沒有出現在其列表裡的IP地址。FreeWheel監測到的虛假流量相對來說是比較少的，因為它沒有太多的經濟驅動。而我們產生的非法流量更多是因為集成的錯誤，或者是一些比較低級的機器人，而不是一些很複雜的工具。

《程序員》：國內外數字廣告領域有什麼異同？

鄧就慶：我覺得行業背景可能還是不一樣，國內好像沒有太多像國外那種比較大的內容商用第三方的系統來幫他們投放廣告。國內比較大的內容商，比如說門戶網站，有幾家他們都用自己的廣告系統，做得不錯。而大的視頻網站，比如優酷、愛奇藝等，也都有自己的廣告系統。

另一方面，美國的電視台內容服務相對比較好，且版權保護和版權管理也比較完備，在美國他們也有基礎把這個事情做好。所以國外內容商使用第三方的技術提供商從經濟上來說會比較合理，不用自己去建立一個系統。因為他們的優勢在於內容的製造和銷售，而不在於技術，這對他們來說是一個成本問題。這方面的區別比較大。

總架構師眼裡的架構和架構師的成長

《程序員》：作為FreeWheel總架構師，你對架構是如何理解的？

鄧就慶：關於這點，Microsoft Office的主管Terry Crowley發表過一篇文章，《Education of a Programmer》。文中總結得很好，建議大家可以去看一下。我的理解跟他的文章基本是一致的。此外Google的Jeff Dean也對此有很多獨到的見解。

總的來說就是，架構要在理想和現實之間折中，保證架構的設計實用可行「接地氣」，且又不過於「山寨」。具體總結為以下幾點：

1. 要端到端地審視系統

因為無論在課本教學還是文章介紹中，講解分析往往只是集中在一個系統的某一個小塊地方，會加以簡化與假設。但在現實中，系統則應該從端到端來處理，因此用這個模式來考慮問題，會得到一個比較合適的結果。否則可能會只看到局部，而丟掉全局的把控。谷歌的Jeff Dean也曾闡述過這一問題，強調要理解整個系統是如何串在一起的。

2. 對複雜性的理解和控制

因為只要是一個系統，到最後都會變得相當複雜，有各種原因導致它越來越複雜。對此我有一些經驗，比如盡量把複雜性控制在一個地方，然後再通過一些分層次、模塊之類的方法來將其隔離開來。我覺得對於做架構來說，很重要的一個工作就是對複雜性的控制，因為所有的系統到最後如果崩潰的話，基本上都是因為複雜性失控導致的。

3. 關注分散式

目前，所有的系統基本上都是分散式的，所以在設計系統時基本上都是以分散式為先，應該假設這個系統就是分佈的。分散式代表什麼？比如說一個請求可能會失敗，你要做好對失敗的處理，一個請求可能會不在你期望的時間內返回，會有一些超時的設計，可能涉及資源競爭。總而言之，各種在單機和單個程序內不會發生的錯誤，在這個產品裡面都會出現，所以在設計的時候，一定要把這些因素考慮在內。

4. 性能

雖然Donald Knuth曾說過一句頗有名的話，就是「所有未成熟的性能優化是所有罪惡的根源」，意思是過早地做優化對整個系統是不利的。但是，還有一點我覺得可能沒有說太清楚。所有的系統設計其實都應該有一些性能的考慮在內。雖然說不要過早做優化，但是應該定好幾個標線。與此相關的還有Jeff Dean在一個PPT里列出來的：你應該對各個硬體和軟體的各種延遲、各種吞吐量，有一些量化的理解，無論是硬碟、SSD、內存，還是CPU Cache，都應當有一個量級上的理解，以此保證你對這個性能的預估不會差得太離譜。因為如果架構開始出錯，性能設計存在瓶頸，最後將極難推廣。

5. 技術以外的其他因素

其實在我看來，架構是幾個因素的綜合考慮，包括：

技術，也就是目前有哪些技術可以用；
人員分配，你現在有哪些技術人員可以用。因為不同的工程師可能使用的技術不一樣，舉例來說，有些熱門語言，比如Erlang VM上的Elixir，還有Spark、Scala等的適用人群和像是Python、PHP，或者Golang、C++等語言是不一樣的。
產品，不同的產品對人和技術的要求可能也不一樣；
時間表，你打算何時發布你的產品？

架構需要從這幾個角度全面考慮，找到一個折中的點，也就是可行的位置。有時在這幾點受限的情況下，可能是很難找到這個各方面都滿意的平衡點。我認為架構師需要從這些因素排選，比如說某產品不行，就要砍掉一些功能；這些人員、這些技術不合適，可能就需要換技術或人；時間表如果滿足不了就往後延遲——這是一個動態的過程，通過調整這幾個因素來尋求平衡。

《程序員》：因為我自己是從一個程序員慢慢成長為一個架構師，你覺得這兩個角色最大的區別是怎麼樣的？

鄧就慶：程序員更多是考慮一個局部的問題，而架構師可能更側重全局考量。程序員眼中更傾向於一個點化的世界，可以有很多假設，但架構師往往不能有那麼多假設，他需要根據實際情況來考慮問題，包括所掌握的人力資源、技術限制、時間安排等——在這些因素的約束下，選擇將受限，一切也不再那麼理想化。

另外一方面，架構師對知識了解的廣度和深度，可能比程序員要高一些。因為架構師的某些決策，有時甚至會對他人的最終結果產生影響。如果程序員寫了很多代碼，那個代碼卻無法做出產品，這無疑是時間的浪費，而我覺得在這一方面，架構師應該承擔更多責任。

最後，架構師需要跳出技術——這是我想要給大家分享的一個建議，即不完全只看技術，而是要綜合考量包括技術和技術以外的因素，將其想象成一個類似於數學優化的問題。換一個角度來說，就是給你一些材料比如技術和人員，你要獲得結果包括產品和團隊，而這個時候很多情況是不理想的、有限制的，包括預算和時間的限制，所以你要思考如何靈活處理這個問題，包括調整各種輸入、限制，甚至是輸出，從而獲得更優或者至少是可行的方案。架構師的世界，不僅僅是技術，通常囊括人員、溝通、產品等各種因素。把這些因素都考慮進去，才是一個完整的架構設計。

-------- 熱聞回顧 --------