1. 概要
在過去五年間，負責過從數百萬DAU到幾千萬DAU的成熟型數據算法團隊，也曾負責從零開始的到幾百萬DAU增長型團隊，積累了一些數據建設的想法思考以及數據團隊管理經驗。以前數據團隊-啓明星的好幾個小夥伴，現在也陸續走上了數據團隊負責人的管理崗位，時不時還會和我討論數據團隊的建設、管理遇到的問題和疑惑，討論過程沉澱了不少的總結和思索。
於是乎寫下這篇文章，旨在介紹在公司內大數據團隊的定位作用，以及如何搭建一個高效精幹(便宜)的大數據團隊。本文面向的讀者，首先應該最適合剛負責團隊的數據TeamLeader，希望於此拋磚引玉，能夠引發些許思考。其次創業中老闆們也可以看看，能夠知道你們花大價錢建立的數據團隊能夠給企業帶來什麼價值。最後，應該也適合期望成長的數據研發、BI工程師、算法工程師們，希望此文有些許insight，能夠幫助你們加深對數據架構和團隊工作的認知與理解。
2. 團隊價值
時至今日，大數據團隊應已成爲移動互聯網公司的標配，其價值和重要性被業界反覆宣傳多年，早已不言而喻。大數據的作用，其實可以大體歸納爲兩類，一類是數據驅動業務爲核心，一類則是數據即業務。前者非常多見，基本能聽到的故事，都是數據如何指導、驅動業務，什麼Netflix通過大數據分析下重拍《紙牌屋》獲得空前成功[1]，什麼Google持續改進的算法源源不斷提升其廣告收入[2]等等，不勝枚舉，亂花迷眼。至於後者，數據即業務，最著名當屬今日頭條，海量的爬取數據作爲起家之本，佐之強大無匹的推薦算法，在注意力的世界所向披靡，頗有將微信斬於馬下之態勢。AT漫漫鐵幕之下，殺出一家近千億美金級別的企業，其老闆乃龍巖四傑之首，江湖人稱「機器人」的張一鳴[3]，曾宣稱頭條是全球單位面積內算法工程師數量最高的公司。管中窺豹，亦可想象大數據在此類公司的價值。
雖然經常存在的對大數據的神祕化、複雜化的行爲，然而大數據它絕非萬能：
世間並無銀子彈，就像沒有吸血鬼一樣。 --尼古拉斯趙四
它通常適合或者擅長以下場景：
- 在複雜的市場情況下，通過大數據分析可以幫助公司更好了解用戶的思考過程和反饋，甚至能夠預測用戶行爲。
- 長期而言，大數據工具能夠有效提高效率，降低企業成本。
- 新產品和服務。通過大數據來預估用戶需求以及通過分析所帶來的能力去滿足用戶需求。
具體到互聯網公司，大數據團隊大部分時候作爲公司中臺部門，最重要也是最基本的定位價值就是：反饋業務以及輔助決策。用以前所做的一頁PPT結合業務簡單解釋以上三點。
-
高管會關心目前公司產品運轉現狀，數據是否錄得好的增長，營收情況如何，企業效率是否有所提高。從宏觀層面，大數據能夠很好概括、監控公司的產品大盤，整體性反饋用戶行爲。 -
產品運營會關心，當前用戶滿意度如何，AB測試下的新功能是否顯著有效，產品現有功能是否穩定，用戶行爲是怎樣的，運營活動效果表現如何？從微觀層面，大數據能夠刻畫每類乃至每個用戶的行爲模式和反饋，並且通過洞察這些行爲打造相關的效率工具。 -
研發、測試和運維會關心，我們所打造所維護的軟件服務、系統、客戶端是否足夠健壯，可用性是否得到保障，各個模塊是否反應足夠敏捷快速。大數據通過合理的數據埋點，能夠輕易勾勒出全鏈路的產品服務質量，打造企業獨有的APM工具系統。
在論證了大數據團隊價值所致之後，接下來會講一下較爲硬核的內容，在互聯網公司，如何打造大數據的架構和流程。在不同階段的不同用戶量級的公司，所採用的技術棧、團隊規模、架構複雜程度都會不盡相同。我儘量抽象這些較爲通用的內容來討論，難免會出現紕漏不足，都敬請方家不吝指正。
3. 數據架構
目前互聯網公司的大數據架構基本可以歸納成爲以下兩類：Lambda架構[4]以及Kappa架構[5]。
3.1 Lamda架構
由Strom作者Nathan Marz在Twitter開發實時數據計算引擎時候，所總結提出的通用數據架構。它融合了批式處理與流式處理方法的優點，嘗試平衡大數據處理過程中的延遲、吞吐量以及容錯性。lambda架構中，批量模塊負責複雜精確的離線計算，與之同時流式模塊負責實時的數據計算。Lambda架構圖如下：
- 所有系統的數據都會被分發到批處理層(batch layer)和快速處理層(speed layer)
- 批處理層會持久化原始數據並批量處理計算這些數據，將結果視圖提供給服務層。
- 快速處理層會流式處理數據，並直接提供實時數據視圖。
- 任何查詢，都能通過融合批處理視圖和實時視圖的結果來獲得。
目前大部分互聯網公司採用這種大數據架構，它不但能夠同時滿足不同時效不同複雜程度的數據需求，還能有效節省企業機器成本。在離線鏈路(批處理層)，通常能夠對數據做大量複雜的計算，數據產出通常會是T+1(隔天)的，在某些場景離線鏈路會分裂成離線(天級別)和近線(小時級別)的兩條鏈路。實時鏈路(快速處理層)，通常用於實現核心KPI指標計算、或者高時效要求業務計算(實時推薦等)。
可以見到，Lambda架構存在幾個明顯的缺點，對於焦急的現代人來說，離線計算太慢了，時效性跟不上，吃瓜都不甜。
我好了。 -- 步行街網友Kappa
另外一個不容忽視的問題是，離線計算和實時計算雖然採用同一套數據，但是不同的計算邏輯代碼邏輯，最後的結果數據可能存在細微的差異。這種差異在對數據處理流程不夠了解的老闆或者其他部門同事來說確實比較疑惑。昨晚說好的2315億，今天怎麼就只剩2314億9999萬了？
不是說好雙十一當天不能退貨嗎？
於是不少團隊開始實踐融合離線在線的數據架構，有人將它簡化抽象爲Kappa架構[6]。
3.2 Kappa架構
Kappa架構由LinkedIn工程師Jay Kreps 總結提出，其實是Lambda架構的簡化版，它主張去掉Lambda架構的批量處理層，所有數據都通過流式計算引擎來實時計算處理。在Apache 社區，以Samza[7],Flink[8]爲首的產品都旨在實現一個融合批處理、流式處理的實時計算引擎，而實時計算引擎正是Kappa架構實現的核心部件。
Kappa架構如下圖所示：
Kappa架構採用一套代碼邏輯實時處理所有流入數據，給用戶提供實時數據視圖。Kappa架構確實能夠解決Lambda的一些問題，但是依然存在以下幾個問題：
- 實時計算框架對機器資源的消耗比離線處理要高。
只要有源源不斷的錢，任何人都可以抄底成功 -- 飯否網友王先生
- Hadoop/Spark的適用場景、穩定性、社區活躍度以及開發者數量都遠高於Flink、Samza這些後起之秀。
綜上所述，Kappa架構還在持續演化中，需要更多企業用戶打磨和參與。目前它更多的部署在業務實時性要求比較高的公司、部門中，最著名的應該是阿里的雙十一大屏項目[9]。
4.數據流程
抽象的數據架構能讓我們剝離現實數據世界的繁複混亂，思考什麼是對企業最好大數據實施方案。對於一線數據團隊的同學們而言，具體、嚴格、規範的數據流程，纔是真正核心需要關注的工作內容。
4.1 產品視角
首先回顧一下，從產品視角，我們是如何實現大數據分析挖掘的？
用戶打開App或者小程序，一般會有一個數據規範權限的必讀，裏面說明本公司會對用戶採集的數據種類、內容，以及使用範圍。在用戶接受該協議，後續用戶在APP內的行爲就會上報到雲服務器上。具體數據上報的形式，一般有兩種，一種是在線日誌，也就是說用戶在使用app過程中，將用戶的數據請求、行爲動作以URL請求的形式，從客戶端向服務端發起，服務端一般會以與數據團隊約定好的規範，以日誌的形式記錄下來這些請求。另外一種是離線日誌，通常這些日誌所代表的用戶行爲優先級較低，爲了節省用戶流量，這些日誌會在客戶端打印壓縮存儲，在客戶端在wifi場景或者達到一定容量纔會上傳到服務器。
日誌規範和採集是數據流程的第一步，源頭出錯後續基本無補救空間，同時涉及到的部門繁多，產品、運營、服務端、客戶端、數據端研發、測試、項目經理等等，需要極端的重視。具體如何構建一個合理規範的用戶追蹤規範，可以參考我以前寫的博文--用戶行爲的深度追蹤[10]。
數據通常會分佈在多臺雲服務器上，需要通過類似於flume[11],logstash[12]等採集工具，將日誌數據導入類似於Kafka等消息隊列中。
數據業務方，比如BI、搜索、推薦、廣告等團隊會根據自己的需求，通過多種不同手段來消費、存儲、應用以及展示這些日誌數據。
4.2 研發視角
從數據團隊負責人的角度，來梳理從數據集成到數據消費全鏈路容易遇到的問題以及其應對的產品技術方法論，提供一個貫穿數據生命週期、統一化、規範化、智能化數據體系建設的解決方案。
大數據體系建設是一個相對複雜的系統工程，它涉及到數據集成、數據開發、數據質量管理、數據服務、數據管理、數據運維、數據安全多個方面的工作。這些模塊它們相互依存、環環相扣，同時對研發人員的技術要求大相徑庭，需要服務端工程師、大數據平臺工程師、BI工程師、分析師、各種方向的算法工程師、前端工程師等來參與整個系統的建設。具體的數據流程如下圖所示：
整個大數據體系構建過程中，需要關注的重點工作內容：
- 數倉規劃與建模：良好的數倉規劃和建模，要求所有數據指標，嚴格遵循標準規範，同時需要數倉架構層次清晰，合理均衡存儲與計算的取捨。
- 數據平臺與工具：長期穩定、高可用的離線在線計算平臺，高高效、可debug的任務調度系統，智能、可靠的監控系統，高性能、高可用的數據服務，敏捷、可快速迭代的數據開發系統。
- 數據挖掘與應用：它和企業業務息息相關，是將數據轉化成爲價值的最核心所在。不同規模不同階段的企業，都有極其不同的挖掘應用內容，包括搜索、推薦、廣告、用戶畫像、反作弊、風控、空間數據挖掘、計算機視覺、對話機器人等等。下一章，團隊職責中會概略性討論一下這塊的內容(顯然可以看出來，這塊可謂包羅萬象，幾十本書也講不完)。
企業的大數據體系建設容易遇到以下問題：
- 數據體系構建過程十分困難，數據建設週期比較長，效率很難保證。
- 數據容易重複建設、數據前後不一致問題嚴重
- 數據管理困難，數據複用率低
- 數據價值得不到充分挖掘應用
5. 團隊建設
毋庸置疑的是大數據能夠賦能企業，爲企業帶來不可替代的價值。但是又存在建設維護困難等問題。如何去搭建一個好大數據團隊顯得至關重要。
那麼 …… 在哪裏才能買得到呢？ -- 華府武狀元
5.1 職責分工
在上面一個章節梳理了大數據研發中主要的工作流程，要這些生產、集中、分發、消費、存儲等過程都處理得妥妥帖帖、順順當當，那確實需要一支分工明確、又高度協作，充滿責任心也相互擔待，滿懷技術好奇又處事謹慎的工程師團隊的全力以赴。我嘗試從總結之前團隊分工情況，同時從工程師能力以及業務內容來劃分數據團隊的職責，如下圖所示：
養這支團隊一年2000w打不住啊，銀八老師！ --望京 soho T2 李總以及張總
確實如此，在一個公司建立完整編制的這樣一支團隊，人數規模一般在數十到上百，對於中等規模(C、D輪）以下的企業，很難養得起。幸運的是，互聯網是偉大的，它最重要的思想是開放透明、信息共享，開源社區在這個理念下快速健康成長，提供了大量的開源大數據套件，極大提升了大數據研發的生產力。再加上雲計算的浪潮勢不可擋地席捲這顆星球[13][14]，基礎設施、架構、平臺由雲供應商提供，大幅度減低了中小企業的數據團隊門檻，節約了不少人力、建設成本。
- A輪左右的初創公司，可能只需要
1~5人，儘量利用雲平臺提供的產品解決方案，主要在於把公司數據流程搭建好，數據目的在於輔助決策。(ELK這時候是一個非常讚的選擇[15]) - 在B、C輪左右，百萬DAU以內公司業務複雜度不大的時候，數據團隊可能只需要
5~10人，負責BI、算法相關、數據服務，在於輔助決策同時支撐業務。當然像互聯網金融行業、O2O這種，複雜度較高的業務，可能要人數 * 業務數。(ELK這時候還可以支撐) - 在C、D輪左右，千萬DAU左右的公司，數據團隊可能擴展到
數十到上百人，雲計算公司提供的工具可能已經不太適用，或者需要更多對數據的挖掘應用。數據平臺的更多角色也會加入，算法人才的需求也會增加。這裏面靈活度很大，好的架構和負責人能夠很好把握住人力成本和規模的均衡。(ELK適用於部分業務，需要替換部件) - 在上市公司，可能整套體系已經比較完善，人數可能在數百到幾千不等。只有新的業務可能會像創業公司那樣搭建整個大數據團隊。
着重講述下數據團隊內的算法工程團隊，部分公司選擇將BI和算法團隊獨立，更多的公司將它們放在一個大部門下，小團隊職能雖然可能相對獨立，但是它們之間的業務、數據關聯非常多而深，處於數據流程的不同位置，融合一起的公司架構會讓整體協作效率更高。
其中在不同業務不同階段的公司，算法團隊的規模會從一個小組到數十個事業部巨大區間中波動，算法團隊也有可能會因而組建自身的數據部門，從這點也可以看到，其實這些組織架構並非一成不變，也遠非涇渭分明。尤其是近年來，隨之深度神經網絡的突破，不少創業公司核心能力就是算法本身，比如計算機視覺應用領域、自動化駕駛領域，這些企業的數據團隊，可能和傳統移動互聯網的日誌數據分析挖掘已經有明顯的差異了。所以以下對算法工程團隊職能劃分，可能只能大概適用於較爲主流的以用戶爲中心的互聯網企業：
數據算法都是具有複雜計算機、統計學背景的工作，本身要求對數據、算法開發過程以及結果有嚴格的規範和驗證。同時與公司內部其他部門同事溝通關於數據與算法的內容時候，由於雙方的教育背景的差異，存在可能導致溝通成本的上升，相互之間信任下降的情況。一套行之有效的工作方法論，相信能夠有效凝聚團隊，提升外部影響力，降低溝通成本。
5.2 工作方法論
這裏所總結的數據團隊的工作方法論，遠稱不上金科玉律。屬於我個人過去五年工作、學習的一點心得。
- 數據算法平臺是一個產品
產品化：數據算法平臺可能只是企業內部的工具，但是作爲互聯網公司應該有將自己負責的業務打造成爲一個優秀易用的產品的覺悟。團隊負責人有義務和權利把控數據算法平臺劃分長期以及近期研發目標，在滿足繁重的數據算法需求同時，需要思考如何抽象業務需求形成產品特性。同時建議，將產品feature的roadmap公開化、透明化，能讓所有關心數據算法的團隊瞭解當前、未來的產品研發規劃。最後，經常性做數據算法平臺的產品宣講、培訓，及時傾聽收集用戶反饋，都是ToB產品的重要步驟和不可或缺的環節。
迭代節奏：數據算法平臺可能不需要像前端後端團隊一般緊跟公司的ART[16]的發版節奏，但是依然建議自己實現固定的迭代節奏(數據一週一版，算法兩週一版),用發版來保證整個團隊的工作節奏，確保鬆弛有度。
- 數據是一種權力
必須竭盡全力保護用戶數據。如同話語權一般，大數據也是一種強大的權力。隨着國內外對知識產權、用戶隱私保護日益嚴厲，GDPR[17]的頒發、執行也是對公司這種大數據權力的一種限制和監管。科技公司的公衆形象大有從屠龍少年向惡龍墮落的趨勢，從Facebook到滴滴出行深陷泥潭[[18]]。嚴格執行相應法律法規，加大數據安全的投入，絕對是划算的。
盡力增強數據算法的可解釋性。很多數據和算法團隊同學看來理所當然的基本知識、概念，在外部團隊可能都難以理解，這樣其實本質上也算是一種知識的權力。大數據團隊的應該盡力使用圖表、分析報告、文檔解釋等方式增強數據、算法的易用性、可讀性。
- 數據工作的科學性
- 數據絕對不可造假。任何的數據作假，都很難圓謊。Data will talk。
- 算法需要嚴格驗證。算法開發需要設置嚴格的線上線下驗證流程，從統計意義上保證結果的可靠性。
- 團隊文化
自由開放：互聯網的無遠弗屆，自由開放爲人類貢獻了這個世紀以來最偉大的進步力量。大數據更是最直接得益於開源社區對自由開放的踐行。法上得中，之前我的團隊都秉持這種氛圍。
Owner精神：阿里文化裏面個人最爲欣賞也是時刻在踐行的owner精神。不管你是以何種身份參與到一個包括了數據團隊的項目、產品中的時候，必須具備我會owner這件事情的精神勁頭，與級別無關與身份無關，真正做到數據驅動業務。Data don't lie.
保持好奇：大數據還處於高速發展階段，各種理論、方法、工具、算法層出不窮，團隊整體保持好奇，保持學習，是保持競爭力的唯一途徑。
導師制度： 阿里最棒的制度之一，能夠很快凝聚新老員工的向心力。
6. 總結
本文主要是概略闡述了大數據團隊的工作應該如何開展，團隊應該如何建設。業界很容易高估或低估的大數據團隊價值，大數據並非銀子彈，它適用於複雜市場情況對用戶瞭解和對企業效率提高。然後，概述了大數據架構現今的兩種最流行架構，分析了兩者的優劣，並討論基於主流架構的數據流程應該如何開展。由於大數據研發流程複雜冗長，需要建設一支強大高效的大數據團隊，又討論了完整編制的大數據團隊應該如何分工合作。最後總結了個人過去幾年負責幾個數據算法團隊所總結的一些工作方法論，建議將數據算法平臺當做產品來打造，慎用大數據這種強大的權力，同時保持團隊平等自由開放的氛圍，讓團隊成員敢於承擔業務責任，保持對知識的好奇。
參考文獻
[1] How Netflix built a House of Cards with big data https://www.cio.com/article/3207670/big-data/how-netflix-built-a-house-of-cards-with-big-data.html
[2] History of Google Algorithm Updates
https://www.searchenginejournal.com/google-algorithm-history/
[3] 對話張一鳴：世界不是隻有你和你的對手 https://36kr.com/p/5059197.html
[4] Lambda architecture
https://searchbusinessanalytics.techtarget.com/definition/Lambda-architecture
[5] What is Kappa Architecture?
http://milinda.pathirage.org/kappa-architecture.com/
[6] Questioning the Lambda Architecture
https://www.oreilly.com/ideas/questioning-the-lambda-architecture
[7] What is Samza?
http://samza.apache.org/
[8]Apache Flink - Stateful Computations over Data Streams
https://flink.apache.org/
[9]一文揭祕阿里實時計算Blink核心技術：如何做到唯快不破？
https://yq.aliyun.com/articles/399401?spm=5176.10695662.1996646101.searchclickresult.bf495006uksRQA
[10]用戶行爲的深度追蹤——事件與埋點
https://www.jianshu.com/p/d45235b51601
[11] Apache Flume https://flume.apache.org/
[12] Logstash https://www.elastic.co/cn/products/logstash
[13] Amazon Web Services (AWS) - Cloud Computing Services https://aws.amazon.com/
[14] 阿里雲 - 上雲就上阿里雲 https://cn.aliyun.com/
[15] Elastic Stack https://www.elastic.co/elk-stack
[16]Agile Release Train https://www.scaledagileframework.com/agile-release-train/
[17] General Data Protection Regulation https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
[18]從Facebook到滴滴出行：平臺的黑化
https://mp.weixin.qq.com/s/mJ2VAEap6BIWC-lvGSLEIg