1. 概要

在過去五年間，負責過從數(shù)百萬DAU到幾千萬DAU的成熟型數(shù)據(jù)算法團隊，也曾負責從零開始的到幾百萬DAU增長型團隊，積累了一些數(shù)據(jù)建設的想法思考以及數(shù)據(jù)團隊管理經(jīng)驗。以前數(shù)據(jù)團隊-啟明星的好幾個小伙伴，現(xiàn)在也陸續(xù)走上了數(shù)據(jù)團隊負責人的管理崗位，時不時還會和我討論數(shù)據(jù)團隊的建設、管理遇到的問題和疑惑，討論過程沉淀了不少的總結和思索。

于是乎寫下這篇文章，旨在介紹在公司內大數(shù)據(jù)團隊的定位作用，以及如何搭建一個高效精干(便宜)的大數(shù)據(jù)團隊。本文面向的讀者，首先應該最適合剛負責團隊的數(shù)據(jù)TeamLeader，希望于此拋磚引玉，能夠引發(fā)些許思考。其次創(chuàng)業(yè)中老板們也可以看看，能夠知道你們花大價錢建立的數(shù)據(jù)團隊能夠給企業(yè)帶來什么價值。最后，應該也適合期望成長的數(shù)據(jù)研發(fā)、BI工程師、算法工程師們，希望此文有些許insight，能夠幫助你們加深對數(shù)據(jù)架構和團隊工作的認知與理解。

2. 團隊價值

時至今日，大數(shù)據(jù)團隊應已成為移動互聯(lián)網(wǎng)公司的標配，其價值和重要性被業(yè)界反復宣傳多年，早已不言而喻。大數(shù)據(jù)的作用，其實可以大體歸納為兩類，一類是數(shù)據(jù)驅動業(yè)務為核心，一類則是數(shù)據(jù)即業(yè)務。前者非常多見，基本能聽到的故事，都是數(shù)據(jù)如何指導、驅動業(yè)務，什么Netflix通過大數(shù)據(jù)分析下重拍《紙牌屋》獲得空前成功[1]，什么Google持續(xù)改進的算法源源不斷提升其廣告收入[2]等等，不勝枚舉，亂花迷眼。至于后者，數(shù)據(jù)即業(yè)務，最著名當屬今日頭條，海量的爬取數(shù)據(jù)作為起家之本，佐之強大無匹的推薦算法，在注意力的世界所向披靡，頗有將微信斬于馬下之態(tài)勢。AT漫漫鐵幕之下，殺出一家近千億美金級別的企業(yè)，其老板乃龍巖四杰之首，江湖人稱「機器人」的張一鳴[3]，曾宣稱頭條是全球單位面積內算法工程師數(shù)量最高的公司。管中窺豹，亦可想象大數(shù)據(jù)在此類公司的價值。

雖然經(jīng)常存在的對大數(shù)據(jù)的神秘化、復雜化的行為，然而大數(shù)據(jù)它絕非萬能：

世間并無銀子彈，就像沒有吸血鬼一樣。 --尼古拉斯趙四

它通常適合或者擅長以下場景：

1. 在復雜的市場情況下，通過大數(shù)據(jù)分析可以幫助公司更好了解用戶的思考過程和反饋，甚至能夠預測用戶行為。
2. 長期而言，大數(shù)據(jù)工具能夠有效提高效率，降低企業(yè)成本。
3. 新產(chǎn)品和服務。通過大數(shù)據(jù)來預估用戶需求以及通過分析所帶來的能力去滿足用戶需求。

具體到互聯(lián)網(wǎng)公司，大數(shù)據(jù)團隊大部分時候作為公司中臺部門，最重要也是最基本的定位價值就是：反饋業(yè)務以及輔助決策。用以前所做的一頁PPT結合業(yè)務簡單解釋以上三點。

大數(shù)據(jù)團隊價值

• 高管會關心目前公司產(chǎn)品運轉現(xiàn)狀，數(shù)據(jù)是否錄得好的增長，營收情況如何，企業(yè)效率是否有所提高。從宏觀層面，大數(shù)據(jù)能夠很好概括、監(jiān)控公司的產(chǎn)品大盤，整體性反饋用戶行為。
• 產(chǎn)品運營會關心，當前用戶滿意度如何，AB測試下的新功能是否顯著有效，產(chǎn)品現(xiàn)有功能是否穩(wěn)定，用戶行為是怎樣的，運營活動效果表現(xiàn)如何？從微觀層面，大數(shù)據(jù)能夠刻畫每類乃至每個用戶的行為模式和反饋，并且通過洞察這些行為打造相關的效率工具。
• 研發(fā)、測試和運維會關心，我們所打造所維護的軟件服務、系統(tǒng)、客戶端是否足夠健壯，可用性是否得到保障，各個模塊是否反應足夠敏捷快速。大數(shù)據(jù)通過合理的數(shù)據(jù)埋點，能夠輕易勾勒出全鏈路的產(chǎn)品服務質量，打造企業(yè)獨有的APM工具系統(tǒng)。

在論證了大數(shù)據(jù)團隊價值所致之后，接下來會講一下較為硬核的內容，在互聯(lián)網(wǎng)公司，如何打造大數(shù)據(jù)的架構和流程。在不同階段的不同用戶量級的公司，所采用的技術棧、團隊規(guī)模、架構復雜程度都會不盡相同。我盡量抽象這些較為通用的內容來討論，難免會出現(xiàn)紕漏不足，都敬請方家不吝指正。

3. 數(shù)據(jù)架構

目前互聯(lián)網(wǎng)公司的大數(shù)據(jù)架構基本可以歸納成為以下兩類：Lambda架構[4]以及Kappa架構[5]。

3.1 Lamda架構

由Strom作者Nathan Marz在Twitter開發(fā)實時數(shù)據(jù)計算引擎時候，所總結提出的通用數(shù)據(jù)架構。它融合了批式處理與流式處理方法的優(yōu)點，嘗試平衡大數(shù)據(jù)處理過程中的延遲、吞吐量以及容錯性。lambda架構中，批量模塊負責復雜精確的離線計算，與之同時流式模塊負責實時的數(shù)據(jù)計算。Lambda架構圖如下：

Lambda架構

• 所有系統(tǒng)的數(shù)據(jù)都會被分發(fā)到批處理層(batch layer)和快速處理層(speed layer)
• 批處理層會持久化原始數(shù)據(jù)并批量處理計算這些數(shù)據(jù)，將結果視圖提供給服務層。
• 快速處理層會流式處理數(shù)據(jù)，并直接提供實時數(shù)據(jù)視圖。
• 任何查詢，都能通過融合批處理視圖和實時視圖的結果來獲得。

目前大部分互聯(lián)網(wǎng)公司采用這種大數(shù)據(jù)架構，它不但能夠同時滿足不同時效不同復雜程度的數(shù)據(jù)需求，還能有效節(jié)省企業(yè)機器成本。在離線鏈路(批處理層)，通常能夠對數(shù)據(jù)做大量復雜的計算，數(shù)據(jù)產(chǎn)出通常會是T+1(隔天)的，在某些場景離線鏈路會分裂成離線(天級別)和近線(小時級別)的兩條鏈路。實時鏈路(快速處理層)，通常用于實現(xiàn)核心KPI指標計算、或者高時效要求業(yè)務計算(實時推薦等)。

可以見到，Lambda架構存在幾個明顯的缺點，對于焦急的現(xiàn)代人來說，離線計算太慢了，時效性跟不上，吃瓜都不甜。

我好了。 -- 步行街網(wǎng)友Kappa

另外一個不容忽視的問題是，離線計算和實時計算雖然采用同一套數(shù)據(jù)，但是不同的計算邏輯代碼邏輯，最后的結果數(shù)據(jù)可能存在細微的差異。這種差異在對數(shù)據(jù)處理流程不夠了解的老板或者其他部門同事來說確實比較疑惑。昨晚說好的2315億，今天怎么就只剩2314億9999萬了？

不是說好雙十一當天不能退貨嗎？

于是不少團隊開始實踐融合離線在線的數(shù)據(jù)架構，有人將它簡化抽象為Kappa架構[6]。

3.2 Kappa架構

Kappa架構由LinkedIn工程師Jay Kreps 總結提出，其實是Lambda架構的簡化版，它主張去掉Lambda架構的批量處理層，所有數(shù)據(jù)都通過流式計算引擎來實時計算處理。在Apache 社區(qū)，以Samza[7],Flink[8]為首的產(chǎn)品都旨在實現(xiàn)一個融合批處理、流式處理的實時計算引擎，而實時計算引擎正是Kappa架構實現(xiàn)的核心部件。
Kappa架構如下圖所示：

Kappa架構

Kappa架構采用一套代碼邏輯實時處理所有流入數(shù)據(jù)，給用戶提供實時數(shù)據(jù)視圖。Kappa架構確實能夠解決Lambda的一些問題，但是依然存在以下幾個問題：

• 實時計算框架對機器資源的消耗比離線處理要高。

只要有源源不斷的錢，任何人都可以抄底成功 -- 飯否網(wǎng)友王先生

• Hadoop/Spark的適用場景、穩(wěn)定性、社區(qū)活躍度以及開發(fā)者數(shù)量都遠高于Flink、Samza這些后起之秀。

綜上所述，Kappa架構還在持續(xù)演化中，需要更多企業(yè)用戶打磨和參與。目前它更多的部署在業(yè)務實時性要求比較高的公司、部門中，最著名的應該是阿里的雙十一大屏項目[9]。

4.數(shù)據(jù)流程

抽象的數(shù)據(jù)架構能讓我們剝離現(xiàn)實數(shù)據(jù)世界的繁復混亂，思考什么是對企業(yè)最好大數(shù)據(jù)實施方案。對于一線數(shù)據(jù)團隊的同學們而言，具體、嚴格、規(guī)范的數(shù)據(jù)流程，才是真正核心需要關注的工作內容。

4.1 產(chǎn)品視角

首先回顧一下，從產(chǎn)品視角，我們是如何實現(xiàn)大數(shù)據(jù)分析挖掘的？

大數(shù)據(jù)產(chǎn)品數(shù)據(jù)流程

1. 用戶打開App或者小程序，一般會有一個數(shù)據(jù)規(guī)范權限的必讀，里面說明本公司會對用戶采集的數(shù)據(jù)種類、內容，以及使用范圍。在用戶接受該協(xié)議，后續(xù)用戶在APP內的行為就會上報到云服務器上。具體數(shù)據(jù)上報的形式，一般有兩種，一種是在線日志，也就是說用戶在使用app過程中，將用戶的數(shù)據(jù)請求、行為動作以URL請求的形式，從客戶端向服務端發(fā)起，服務端一般會以與數(shù)據(jù)團隊約定好的規(guī)范，以日志的形式記錄下來這些請求。另外一種是離線日志，通常這些日志所代表的用戶行為優(yōu)先級較低，為了節(jié)省用戶流量，這些日志會在客戶端打印壓縮存儲，在客戶端在wifi場景或者達到一定容量才會上傳到服務器。

2. 日志規(guī)范和采集是數(shù)據(jù)流程的第一步，源頭出錯后續(xù)基本無補救空間，同時涉及到的部門繁多，產(chǎn)品、運營、服務端、客戶端、數(shù)據(jù)端研發(fā)、測試、項目經(jīng)理等等，需要極端的重視。具體如何構建一個合理規(guī)范的用戶追蹤規(guī)范，可以參考我以前寫的博文--用戶行為的深度追蹤[10]。

3. 數(shù)據(jù)通常會分布在多臺云服務器上，需要通過類似于flume[11],logstash[12]等采集工具，將日志數(shù)據(jù)導入類似于Kafka等消息隊列中。

4. 數(shù)據(jù)業(yè)務方，比如BI、搜索、推薦、廣告等團隊會根據(jù)自己的需求，通過多種不同手段來消費、存儲、應用以及展示這些日志數(shù)據(jù)。

4.2 研發(fā)視角

從數(shù)據(jù)團隊負責人的角度，來梳理從數(shù)據(jù)集成到數(shù)據(jù)消費全鏈路容易遇到的問題以及其應對的產(chǎn)品技術方法論，提供一個貫穿數(shù)據(jù)生命周期、統(tǒng)一化、規(guī)范化、智能化數(shù)據(jù)體系建設的解決方案。

大數(shù)據(jù)體系建設是一個相對復雜的系統(tǒng)工程，它涉及到數(shù)據(jù)集成、數(shù)據(jù)開發(fā)、數(shù)據(jù)質量管理、數(shù)據(jù)服務、數(shù)據(jù)管理、數(shù)據(jù)運維、數(shù)據(jù)安全多個方面的工作。這些模塊它們相互依存、環(huán)環(huán)相扣，同時對研發(fā)人員的技術要求大相徑庭，需要服務端工程師、大數(shù)據(jù)平臺工程師、BI工程師、分析師、各種方向的算法工程師、前端工程師等來參與整個系統(tǒng)的建設。具體的數(shù)據(jù)流程如下圖所示：

大數(shù)據(jù)研發(fā)視角下數(shù)據(jù)流程

整個大數(shù)據(jù)體系構建過程中，需要關注的重點工作內容：

• 數(shù)倉規(guī)劃與建模：良好的數(shù)倉規(guī)劃和建模，要求所有數(shù)據(jù)指標，嚴格遵循標準規(guī)范，同時需要數(shù)倉架構層次清晰，合理均衡存儲與計算的取舍。
• 數(shù)據(jù)平臺與工具：長期穩(wěn)定、高可用的離線在線計算平臺，高高效、可debug的任務調度系統(tǒng)，智能、可靠的監(jiān)控系統(tǒng)，高性能、高可用的數(shù)據(jù)服務，敏捷、可快速迭代的數(shù)據(jù)開發(fā)系統(tǒng)。
• 數(shù)據(jù)挖掘與應用：它和企業(yè)業(yè)務息息相關，是將數(shù)據(jù)轉化成為價值的最核心所在。不同規(guī)模不同階段的企業(yè)，都有極其不同的挖掘應用內容，包括搜索、推薦、廣告、用戶畫像、反作弊、風控、空間數(shù)據(jù)挖掘、計算機視覺、對話機器人等等。下一章，團隊職責中會概略性討論一下這塊的內容(顯然可以看出來，這塊可謂包羅萬象，幾十本書也講不完)。

企業(yè)的大數(shù)據(jù)體系建設容易遇到以下問題：

1. 數(shù)據(jù)體系構建過程十分困難，數(shù)據(jù)建設周期比較長，效率很難保證。
2. 數(shù)據(jù)容易重復建設、數(shù)據(jù)前后不一致問題嚴重
3. 數(shù)據(jù)管理困難，數(shù)據(jù)復用率低
4. 數(shù)據(jù)價值得不到充分挖掘應用

5. 團隊建設

毋庸置疑的是大數(shù)據(jù)能夠賦能企業(yè)，為企業(yè)帶來不可替代的價值。但是又存在建設維護困難等問題。如何去搭建一個好大數(shù)據(jù)團隊顯得至關重要。

那么 …… 在哪里才能買得到呢？ -- 華府武狀元

5.1 職責分工

在上面一個章節(jié)梳理了大數(shù)據(jù)研發(fā)中主要的工作流程，要這些生產(chǎn)、集中、分發(fā)、消費、存儲等過程都處理得妥妥帖帖、順順當當，那確實需要一支分工明確、又高度協(xié)作，充滿責任心也相互擔待，滿懷技術好奇又處事謹慎的工程師團隊的全力以赴。我嘗試從總結之前團隊分工情況，同時從工程師能力以及業(yè)務內容來劃分數(shù)據(jù)團隊的職責，如下圖所示：

數(shù)據(jù)團隊職責

養(yǎng)這支團隊一年2000w打不住啊，銀八老師！ --望京 soho T2 李總以及張總

確實如此，在一個公司建立完整編制的這樣一支團隊，人數(shù)規(guī)模一般在數(shù)十到上百，對于中等規(guī)模(C、D輪）以下的企業(yè)，很難養(yǎng)得起。幸運的是，互聯(lián)網(wǎng)是偉大的，它最重要的思想是開放透明、信息共享，開源社區(qū)在這個理念下快速健康成長，提供了大量的開源大數(shù)據(jù)套件，極大提升了大數(shù)據(jù)研發(fā)的生產(chǎn)力。再加上云計算的浪潮勢不可擋地席卷這顆星球[13][14]，基礎設施、架構、平臺由云供應商提供，大幅度減低了中小企業(yè)的數(shù)據(jù)團隊門檻，節(jié)約了不少人力、建設成本。

• A輪左右的初創(chuàng)公司，可能只需要1~5人，盡量利用云平臺提供的產(chǎn)品解決方案，主要在于把公司數(shù)據(jù)流程搭建好，數(shù)據(jù)目的在于輔助決策。(ELK這時候是一個非常贊的選擇[15])
• 在B、C輪左右，百萬DAU以內公司業(yè)務復雜度不大的時候，數(shù)據(jù)團隊可能只需要5~10人，負責BI、算法相關、數(shù)據(jù)服務，在于輔助決策同時支撐業(yè)務。當然像互聯(lián)網(wǎng)金融行業(yè)、O2O這種，復雜度較高的業(yè)務，可能要人數(shù) * 業(yè)務數(shù)。(ELK這時候還可以支撐)
• 在C、D輪左右，千萬DAU左右的公司，數(shù)據(jù)團隊可能擴展到數(shù)十到上百人，云計算公司提供的工具可能已經(jīng)不太適用，或者需要更多對數(shù)據(jù)的挖掘應用。數(shù)據(jù)平臺的更多角色也會加入，算法人才的需求也會增加。這里面靈活度很大，好的架構和負責人能夠很好把握住人力成本和規(guī)模的均衡。(ELK適用于部分業(yè)務，需要替換部件)
• 在上市公司，可能整套體系已經(jīng)比較完善，人數(shù)可能在數(shù)百到幾千不等。只有新的業(yè)務可能會像創(chuàng)業(yè)公司那樣搭建整個大數(shù)據(jù)團隊。

著重講述下數(shù)據(jù)團隊內的算法工程團隊，部分公司選擇將BI和算法團隊獨立，更多的公司將它們放在一個大部門下，小團隊職能雖然可能相對獨立，但是它們之間的業(yè)務、數(shù)據(jù)關聯(lián)非常多而深，處于數(shù)據(jù)流程的不同位置，融合一起的公司架構會讓整體協(xié)作效率更高。

其中在不同業(yè)務不同階段的公司，算法團隊的規(guī)模會從一個小組到數(shù)十個事業(yè)部巨大區(qū)間中波動，算法團隊也有可能會因而組建自身的數(shù)據(jù)部門，從這點也可以看到，其實這些組織架構并非一成不變，也遠非涇渭分明。尤其是近年來，隨之深度神經(jīng)網(wǎng)絡的突破，不少創(chuàng)業(yè)公司核心能力就是算法本身，比如計算機視覺應用領域、自動化駕駛領域，這些企業(yè)的數(shù)據(jù)團隊，可能和傳統(tǒng)移動互聯(lián)網(wǎng)的日志數(shù)據(jù)分析挖掘已經(jīng)有明顯的差異了。所以以下對算法工程團隊職能劃分，可能只能大概適用于較為主流的以用戶為中心的互聯(lián)網(wǎng)企業(yè)：

算法工程團隊職責

數(shù)據(jù)算法都是具有復雜計算機、統(tǒng)計學背景的工作，本身要求對數(shù)據(jù)、算法開發(fā)過程以及結果有嚴格的規(guī)范和驗證。同時與公司內部其他部門同事溝通關于數(shù)據(jù)與算法的內容時候，由于雙方的教育背景的差異，存在可能導致溝通成本的上升，相互之間信任下降的情況。一套行之有效的工作方法論，相信能夠有效凝聚團隊，提升外部影響力，降低溝通成本。

5.2 工作方法論

這里所總結的數(shù)據(jù)團隊的工作方法論，遠稱不上金科玉律。屬于我個人過去五年工作、學習的一點心得。

1. 數(shù)據(jù)算法平臺是一個產(chǎn)品

• 產(chǎn)品化：數(shù)據(jù)算法平臺可能只是企業(yè)內部的工具，但是作為互聯(lián)網(wǎng)公司應該有將自己負責的業(yè)務打造成為一個優(yōu)秀易用的產(chǎn)品的覺悟。團隊負責人有義務和權利把控數(shù)據(jù)算法平臺劃分長期以及近期研發(fā)目標，在滿足繁重的數(shù)據(jù)算法需求同時，需要思考如何抽象業(yè)務需求形成產(chǎn)品特性。同時建議，將產(chǎn)品feature的roadmap公開化、透明化，能讓所有關心數(shù)據(jù)算法的團隊了解當前、未來的產(chǎn)品研發(fā)規(guī)劃。最后，經(jīng)常性做數(shù)據(jù)算法平臺的產(chǎn)品宣講、培訓，及時傾聽收集用戶反饋，都是ToB產(chǎn)品的重要步驟和不可或缺的環(huán)節(jié)。

• 迭代節(jié)奏：數(shù)據(jù)算法平臺可能不需要像前端后端團隊一般緊跟公司的ART[16]的發(fā)版節(jié)奏，但是依然建議自己實現(xiàn)固定的迭代節(jié)奏(數(shù)據(jù)一周一版，算法兩周一版),用發(fā)版來保證整個團隊的工作節(jié)奏，確保松弛有度。

2. 數(shù)據(jù)是一種權力

• 必須竭盡全力保護用戶數(shù)據(jù)。如同話語權一般，大數(shù)據(jù)也是一種強大的權力。隨著國內外對知識產(chǎn)權、用戶隱私保護日益嚴厲，GDPR[17]的頒發(fā)、執(zhí)行也是對公司這種大數(shù)據(jù)權力的一種限制和監(jiān)管。科技公司的公眾形象大有從屠龍少年向惡龍墮落的趨勢，從Facebook到滴滴出行深陷泥潭[[18]]。嚴格執(zhí)行相應法律法規(guī)，加大數(shù)據(jù)安全的投入，絕對是劃算的。

• 盡力增強數(shù)據(jù)算法的可解釋性。很多數(shù)據(jù)和算法團隊同學看來理所當然的基本知識、概念，在外部團隊可能都難以理解，這樣其實本質上也算是一種知識的權力。大數(shù)據(jù)團隊的應該盡力使用圖表、分析報告、文檔解釋等方式增強數(shù)據(jù)、算法的易用性、可讀性。

3. 數(shù)據(jù)工作的科學性

• 數(shù)據(jù)絕對不可造假。任何的數(shù)據(jù)作假，都很難圓謊。Data will talk。
• 算法需要嚴格驗證。算法開發(fā)需要設置嚴格的線上線下驗證流程，從統(tǒng)計意義上保證結果的可靠性。

4. 團隊文化

• 自由開放：互聯(lián)網(wǎng)的無遠弗屆，自由開放為人類貢獻了這個世紀以來最偉大的進步力量。大數(shù)據(jù)更是最直接得益于開源社區(qū)對自由開放的踐行。法上得中，之前我的團隊都秉持這種氛圍。

• Owner精神：阿里文化里面?zhèn)€人最為欣賞也是時刻在踐行的owner精神。不管你是以何種身份參與到一個包括了數(shù)據(jù)團隊的項目、產(chǎn)品中的時候，必須具備我會owner這件事情的精神勁頭，與級別無關與身份無關，真正做到數(shù)據(jù)驅動業(yè)務。Data don't lie.

• 保持好奇：大數(shù)據(jù)還處于高速發(fā)展階段，各種理論、方法、工具、算法層出不窮，團隊整體保持好奇，保持學習，是保持競爭力的唯一途徑。

• 導師制度： 阿里最棒的制度之一，能夠很快凝聚新老員工的向心力。

6. 總結

本文主要是概略闡述了大數(shù)據(jù)團隊的工作應該如何開展，團隊應該如何建設。業(yè)界很容易高估或低估的大數(shù)據(jù)團隊價值，大數(shù)據(jù)并非銀子彈，它適用于復雜市場情況對用戶了解和對企業(yè)效率提高。然后，概述了大數(shù)據(jù)架構現(xiàn)今的兩種最流行架構，分析了兩者的優(yōu)劣，并討論基于主流架構的數(shù)據(jù)流程應該如何開展。由于大數(shù)據(jù)研發(fā)流程復雜冗長，需要建設一支強大高效的大數(shù)據(jù)團隊，又討論了完整編制的大數(shù)據(jù)團隊應該如何分工合作。最后總結了個人過去幾年負責幾個數(shù)據(jù)算法團隊所總結的一些工作方法論，建議將數(shù)據(jù)算法平臺當做產(chǎn)品來打造，慎用大數(shù)據(jù)這種強大的權力，同時保持團隊平等自由開放的氛圍，讓團隊成員敢于承擔業(yè)務責任，保持對知識的好奇。

參考文獻

[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]用戶行為的深度追蹤——事件與埋點
http://m.itdecent.cn/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