這是2017年10月到2018年10月在全民直播期間的一個項目渊额，因為在直播公司的緣故瓢阴，所以會涉及很多直播相關(guān)的業(yè)務(wù)畅蹂。當(dāng)時有幾家做的比較好的直播平臺，比如斗魚荣恐、虎牙液斜、熊貓累贤、戰(zhàn)旗、全民等少漆，直播內(nèi)容都以游戲臼膏、才藝表演為主，直播受眾廣检疫，每天產(chǎn)生的數(shù)據(jù)流量巨大讶请，公司為此啟動一個新項目，采集全平臺直播數(shù)據(jù)屎媳，并經(jīng)大數(shù)據(jù)技術(shù)清洗統(tǒng)計后為直播行業(yè)提供數(shù)據(jù)化運營解決方案夺溢。

加入全民直播的時候正值剛畢業(yè)不久，從河北來到杭州烛谊，機緣巧合就入職了全民风响，接手了這一項目，因為當(dāng)時負責(zé)項目開發(fā)的工程師即將離職丹禀，因此我也算緊急受命状勤。對那時候的我來說，這個項目算是相對難度最高的双泪，為什么這樣說呢持搜？首先因為我本身并不是計算機科班出身，再加上在學(xué)校自學(xué)的經(jīng)歷焙矛，雖也接觸過不少的技術(shù)葫盼，但都不深入，所以當(dāng)初次接觸到這種成體系的項目時就顯得有些局促了村斟。當(dāng)然贫导，項目本身也算是難度比較大的，由于是后期接手的緣故蟆盹，所以也就沒有參與初期技術(shù)方案的設(shè)計孩灯，但其中的細節(jié)還是值得考慮的。本文即是復(fù)盤當(dāng)時項目的業(yè)務(wù)及技術(shù)細節(jié)逾滥，結(jié)合接手項目后及二期改進所做的工作峰档，對當(dāng)時碰到的問題及技術(shù)方案設(shè)計進行整理和思考。

簡單介紹一下業(yè)務(wù)

如果你看過游戲直播（如果沒看過現(xiàn)在可以打開看看寨昙，比如斗魚讥巡、虎牙）就會比較熟悉，當(dāng)打開一些熱門網(wǎng)紅的直播主頁時會看到很多內(nèi)容毅待，首先是源源不斷刷過整個屏幕的彈幕尚卫，還有一些粉絲送給主播的禮物（比如火箭），這些都算是動態(tài)數(shù)據(jù)尸红，而且從全網(wǎng)來看數(shù)據(jù)量巨大吱涉。其次還有很多相對靜態(tài)的內(nèi)容刹泄，比如主播名稱、熱度怎爵、關(guān)注度等相關(guān)信息特石。對于做直播業(yè)務(wù)的公司來說，這當(dāng)然是有價值的鳖链。因此我們要做的事情就是把這些動態(tài)和靜態(tài)的數(shù)據(jù)源源不斷地從網(wǎng)絡(luò)上抓取下來姆蘸，并通過一些大數(shù)據(jù)手段進行清洗和計算，最后得到一個全網(wǎng)主播的動態(tài)信息匯總平臺芙委，并向行業(yè)內(nèi)相關(guān)人士或機構(gòu)提供大數(shù)據(jù)咨詢服務(wù)逞敷。

面臨的問題

從技術(shù)層面思考這個事情，其實簡單來說我們要做的就是通過一些手段把上面說的各種靜態(tài)和動態(tài)數(shù)據(jù)從各個直播平臺上抓取下來（說白了就是爬蟲）灌侣，然后通過一個大數(shù)據(jù)清洗和計算流程匯總得到業(yè)務(wù)所需的形態(tài)推捐，最后通過網(wǎng)頁或 app 的形式把數(shù)據(jù)展示給用戶。

業(yè)務(wù)目標清楚了侧啼，接下來從技術(shù)角度梳理一下做這個事情可能會碰到什么問題：

• 直播平臺眾多牛柒，各平臺無兼容性：當(dāng)時正值娛樂直播業(yè)務(wù)的紅海期，各種直播平臺相互競爭痊乾，首期決定采集的平臺有斗魚皮壁、虎牙、龍珠哪审、戰(zhàn)旗蛾魄、觸手、熊貓协饲、全民畏腕。
• 涉及數(shù)據(jù)類別有多種缴川，協(xié)議層適配和數(shù)據(jù)清洗會很復(fù)雜：首期決定采集的直播數(shù)據(jù)有彈幕茉稠、禮物、主播個人信息把夸、主播熱度及關(guān)注度
• 可能會遭到平臺方的封鎖：畢竟是爬蟲而线，你懂的（不過不像現(xiàn)在，當(dāng)時還沒有這么嚴重的法律風(fēng)險）恋日。
• 從直觀上看數(shù)據(jù)量可能會很大：最終從事實上來看確實很大膀篮，數(shù)據(jù)的采集、計算岂膳、存儲誓竿、讀取都需要考慮這方面因素。

技術(shù)選型及解決方案

語言：Node.js / Go（二期升級時采用）

數(shù)據(jù)庫谈截、緩存及靜態(tài)存儲：MySQL筷屡、Redis涧偷、阿里云 OSS

數(shù)據(jù)搜索服務(wù)：Elasticsearch

服務(wù)器：阿里云 ECS

流數(shù)據(jù)池子：阿里云日志服務(wù)

前后端：Express / Koa / Vue

冷數(shù)據(jù)存儲：阿里云 ODPS

服務(wù)器監(jiān)控：Grafana / Alinode

部署方案：GitLab CI / Ansible

大數(shù)據(jù)清洗和計算：阿里云實時計算

平臺及數(shù)據(jù)兼容層

前面提到，首期業(yè)務(wù)決定采集斗魚虎牙等7個平臺的數(shù)據(jù)毙死，深入看一下這幾個平臺的數(shù)據(jù)采集方式（由于當(dāng)時有專門的團隊已經(jīng)做過相關(guān)工作燎潮，因此假設(shè)此時已經(jīng)得到各個平臺可用的 api 及接口訪問權(quán)限，全民屬于自有平臺扼倘，接口信息也可看作已知）會發(fā)現(xiàn)每個平臺都是不一樣的确封，從接口協(xié)議層面看，因數(shù)據(jù)類別不同涉及到的協(xié)議有 TCP再菊、WebSocket 以及 Http爪喘，動態(tài)數(shù)據(jù)如彈幕和禮物因為實時性比較強所以一般都是用 TCP 和 WebSocket 傳輸，當(dāng)然也有比較奇葩的用 Http 的（比如觸手）纠拔。靜態(tài)數(shù)據(jù)如主播個人信息腥放、關(guān)注度等則基本都是 Http 接口，當(dāng)然也有不提供特定接口而直接從后端渲染的绿语，不過本質(zhì)上沒有太大區(qū)別秃症，只是后期處理上會稍顯繁瑣。

為了解決上述問題吕粹，比較通用的做法是在所有平臺之上建立兼容層种柑，將需要采集的數(shù)據(jù)分為 彈幕/禮物、主播信息匹耕、熱度聚请、關(guān)注數(shù)四大類，并抽象出其中的接口及事件稳其。

如對于彈幕/禮物數(shù)據(jù)的采集模塊來說會抽象出如下接口和事件：

init：按平臺需求進行鑒權(quán)驶赏、Socket 連接及開啟數(shù)據(jù)監(jiān)聽（針對 TCP 和 WebSocket）、初始化輪詢請求（針對Http）以及請求一些附加的平臺數(shù)據(jù)操作既鞠。

destroy：斷開連接停止采集煤傍。

connect 事件：監(jiān)聽連接事件。

data 事件：接收請求到的數(shù)據(jù)嘱蛋，并進行相應(yīng)的后續(xù)處理蚯姆。

error 事件：等待超時或出現(xiàn)錯誤，則停止采集或進行重連洒敏。

close 事件：正常關(guān)閉操作龄恋。

在兼容層的上層，則按照采集到的數(shù)據(jù)的不同格式及類型建立 ETL 層對數(shù)據(jù)進行清洗得到平臺通用的數(shù)據(jù)格式凶伙，架構(gòu)示意圖如下：

[站外圖片上傳中...(image-7d6501-1577543052980)]
對于主播信息郭毕、熱度、關(guān)注數(shù)類別的數(shù)據(jù)處理方式也是類似函荣，針對平臺差異抽象出不同平臺的接口共性显押，并在使用時按平臺調(diào)用链韭。

采集集群

如果打開一些熱門網(wǎng)紅的直播間會發(fā)現(xiàn)在其直播期間，屏幕上會飄過海量的彈幕和禮物煮落，從全平臺來看敞峭，這些數(shù)據(jù)的量是非常大的，在項目維護期間我也曾做過粗略的統(tǒng)計蝉仇，發(fā)現(xiàn)每天流過系統(tǒng)的數(shù)據(jù)量達到 400 - 600G旋讹，也就是說每天采集到的數(shù)據(jù)能裝滿一個 500G 的硬盤，這還只是清洗過后的轿衔，且不計圖片沉迹、頭像等數(shù)據(jù)，如果按照清洗前的量將大大超出這個值害驹。要實現(xiàn)將這個量級的數(shù)據(jù)實時地從網(wǎng)絡(luò)上抓取下來并集中清洗鞭呕，勢必需要多臺服務(wù)器配合組成集群，將負載分配到每一個節(jié)點宛官，并能根據(jù)采集量動態(tài)伸縮集群容量葫松，達到業(yè)務(wù)和成本的平衡。

集群架構(gòu)設(shè)計如下圖：

[站外圖片上傳中...(image-92cae5-1577543052980)]

任務(wù)系統(tǒng)

要采用集群化采集方案底洗，則必然設(shè)計一套任務(wù)系統(tǒng)腋么，將采集任務(wù)細化、標準化亥揖。這里還會涉及到另一個數(shù)據(jù)需求珊擂，即直播間開關(guān)播狀態(tài)。因為當(dāng)時并沒有獲取直播間狀態(tài)的方法费变，因此采用列表對比的方式獲得相對準確的直播間開關(guān)播狀態(tài)摧扇，原理簡單來說就是定時拉取平臺的直播間列表并存儲到 DB 中，等下一次再拿到列表時與 DB 中的列表對比得出開關(guān)播狀態(tài)挚歧。如 DB 中已有 A扛稽、B、C 三個直播間狀態(tài)為開播昼激，下一次拿到的列表為 A庇绽、B 锡搜，則此時判定 C 直播間關(guān)播橙困，以此類推。開關(guān)播狀態(tài)除了本身是數(shù)據(jù)需求的一部分以外耕餐，還是采集節(jié)點采集數(shù)據(jù)與否的依據(jù)凡傅，因為觀察發(fā)現(xiàn)，當(dāng)主播關(guān)播時肠缔，直播間將沒有或只有少量彈幕禮物數(shù)據(jù)刷過夏跷，這一部分數(shù)據(jù)可以忽略不計哼转，為此當(dāng)主播關(guān)播時關(guān)閉采集可以節(jié)省成本。

使用一臺單獨的服務(wù)器拉取各個平臺主播列表作為任務(wù)源槽华，拉取時間間隔為 1 分鐘壹蔓，主播列表中會包含主播詳細信息并將該信息存到一張單獨的表中。拉取到的列表按不同平臺分批發(fā)送至調(diào)度中心猫态，由調(diào)度中心來完成直播間狀態(tài)的比對佣蓉，并將該信息更新到 DB 中。

調(diào)度中心

調(diào)度中心會負責(zé)兩方面的任務(wù)亲雪，一個是上面提到的勇凭，接受來自任務(wù)源的任務(wù)隊列，并與 DB 中已有的任務(wù)進行比對得出需要更新的直播間狀態(tài)义辕。另一個則是分配任務(wù)虾标。

采集集群會在啟動時與調(diào)度中心取得長連接，采集節(jié)點會告知本機的局域網(wǎng) IP 地址（集群中所有節(jié)點都在同一個局域網(wǎng)內(nèi)）灌砖，并將本機采集負載（采集任務(wù)數(shù)）通過 RPC 接口的方式暴露給調(diào)度中心璧函，保持長連接意味著采集節(jié)點的狀態(tài)變化可以實時地被調(diào)度中心感知到，調(diào)度中心依據(jù)此維護一個可用的采集節(jié)點列表（即 IP 列表）基显，并能通過 RPC 機制實時地獲取每個節(jié)點的負載柳譬。當(dāng)調(diào)度中心收到來自任務(wù)源的任務(wù)列表時會比對得出所有需要更新采集狀態(tài)（開啟或停止采集）的任務(wù)，如遇到需要新開采集的任務(wù)時续镇，會在可用的采集節(jié)點列表中選取一個負載最小的節(jié)點美澳，將該節(jié)點 IP 與該任務(wù)綁定，賦予任務(wù)狀態(tài)為 ACCEPT摸航，表示該任務(wù)為新接收的任務(wù)制跟，并將該任務(wù)存至任務(wù)列表。同時酱虎，若調(diào)度中心感知到某節(jié)點出現(xiàn)異常雨膨，比如斷開連接，則調(diào)度中心會將任務(wù)列表中標記給該節(jié)點 IP 的所有任務(wù)取出读串，重復(fù)上述步驟聊记，選取一個負載最小的節(jié)點，將該任務(wù)分配給該節(jié)點恢暖，若出現(xiàn)問題的是某任務(wù)排监，則調(diào)度中心會為其重新分配一個節(jié)點，該任務(wù)會被該節(jié)點發(fā)現(xiàn)并重新開啟采集杰捂。這樣一來舆床，所有任務(wù)將在整個采集集群中動態(tài)平均分配，并在節(jié)點異常時及時回收任務(wù)再分配，以此平衡所有節(jié)點的負載挨队，并將節(jié)點異常帶來的數(shù)據(jù)損失降到最低谷暮。

集群

采集集群的工作即按平臺差異以不同的方式從各個直播平臺源源不斷地拉取數(shù)據(jù)，集群中每一個節(jié)點都是等價的盛垦，集群規(guī)模也可以動態(tài)伸縮湿弦。集群節(jié)點服務(wù)主要以兩部分組成：Manager（任務(wù)管理器）和 Bee（采集器）。Manager 是集群節(jié)點的主體腾夯，一方面在節(jié)點啟動時省撑，Manager 會與調(diào)度中心連接并實時同步 IP 信息和負載水平，另一方面俯在，因調(diào)度中心已實時地將各個需要開啟和關(guān)閉的任務(wù)同步至任務(wù)列表中竟秫，Manager 會定時到任務(wù)列表中領(lǐng)取與本機 IP 相匹配的任務(wù)進行相關(guān)操作，如開啟或關(guān)閉采集跷乐。采集的主體即 Bee（命名取自小蜜蜂采集花蜜）肥败，當(dāng) Manager 拿到一個需要開啟采集的任務(wù)時，會初始化一個 Bee 實例愕提，Bee 初始化時會按照指定平臺調(diào)用實現(xiàn)了特定接口的客戶端與平臺方取得連接馒稍，并將列表中任務(wù)狀態(tài)改為 RUNNING，Bee 會接受來自平臺的數(shù)據(jù)流浅侨，并調(diào)用特定的方法對數(shù)據(jù)流進行解析纽谒、計算、清洗如输，最終以統(tǒng)一的格式寫入阿里云日志服務(wù)鼓黔。也就是說，一個采集結(jié)點中只有一個 Manager不见，但該 Manager 會管理多個 Bee 實例澳化。當(dāng)某個 Bee 實例出現(xiàn)異常，比如與平臺斷開連接稳吮，則 Bee 會停止采集并將該任務(wù)標記為 FAILED缎谷，后續(xù)該任務(wù)會被調(diào)度中心發(fā)現(xiàn)并重新分配。同理灶似，當(dāng) Manager 拿到一個待關(guān)閉任務(wù)時列林，則將該任務(wù)標記為 CLOES，后續(xù)該任務(wù)會進入關(guān)閉流程酪惭，關(guān)閉與平臺的連接希痴，并從任務(wù)列表中清除。

初期集群規(guī)模為 40 臺阿里云 ECS 服務(wù)器撞蚕，并通過 Ansible 統(tǒng)一部署與管理润梯。每個集群上的任務(wù)數(shù)和資源占用水平都可以通過 Grafana 查看。從最終結(jié)果看來甥厦，全平臺高峰期同時開播的直播間最高為 10 萬個纺铭，也就是峰值任務(wù)約為 2500 個/臺，LogHub 流數(shù)據(jù)為 400 - 600 G/天刀疙，這都在系統(tǒng)各個部件的承受范圍內(nèi)舶赔。且所有服務(wù)器都通過 Alinode 進行實時監(jiān)控。

規(guī)避風(fēng)控

前面已經(jīng)提到過谦秧，該采集任務(wù)可能會碰到平臺封鎖的問題竟纳，事實上也是如此，且在業(yè)務(wù)后期平臺封鎖問題已成為整個服務(wù)的最大瓶頸疚鲤。平臺的封鎖主要集中在任務(wù)源處锥累，若直播平臺封鎖任務(wù)列表的拉取，會導(dǎo)致采集任務(wù)無法更新集歇，最終導(dǎo)致數(shù)據(jù)與實際數(shù)據(jù)差距巨大桶略，造成業(yè)務(wù)上數(shù)據(jù)不可信。因此解決該問題一直是最重要的任務(wù)诲宇。當(dāng)時采取了以下幾種方式：

• 規(guī)避平臺風(fēng)控規(guī)則：平臺的封鎖規(guī)則一般都和拉取頻率有關(guān)际歼，若拉取頻率超過平臺規(guī)定的閾值，會導(dǎo)致封鎖姑蓝。因此在拉取列表時盡量規(guī)避鹅心，該方法成本低，雖造成任務(wù)更新不及時纺荧，但也算保全了一部分數(shù)據(jù)旭愧，總體來看效果一般。
• 通過 CDN 節(jié)點拉取數(shù)據(jù)：直播平臺一般都會有大量 CDN 節(jié)點宙暇，因此可以借助 CDN 進行數(shù)據(jù)拉取榕茧。但實施后發(fā)現(xiàn) CDN 節(jié)點部署位置較分散，甚至有很多部署在國外客给，雖說這樣做規(guī)避了一部分封鎖的風(fēng)險用押，但由于拉取速度太慢，總體效果不好靶剑，最終放棄該方案蜻拨。
• 代理：終極解決方案，通過專門的爬蟲代理服務(wù)器對目標平臺進行請求桩引，最終實現(xiàn)了較平穩(wěn)的數(shù)據(jù)流輸出缎讼。唯一的缺點是該方案成本較高。

計算

本系統(tǒng)中采集到的所有數(shù)據(jù)坑匠，除了主播信息血崭、主播關(guān)注度、圖片等少量且靜態(tài)的數(shù)據(jù)存儲在 MySQL 和 OSS 以外，其他動態(tài)數(shù)據(jù)都被存至阿里云 LogHub 日志服務(wù)中夹纫，主要原因是 LogHub 成本極低咽瓷，且能在阿里云平臺上動態(tài)查詢檢索數(shù)據(jù)，又由于 LogHub 與阿里云實時計算已實現(xiàn)了無縫對接舰讹，所以將其作為消息隊列使用茅姜，業(yè)務(wù)過程中曾經(jīng)考慮使用 Kafka 作為消息隊列，但由于部署成本較高月匣，且若使用 Kafka钻洒，則后續(xù)實時計算和流計算都需考慮自行部署（當(dāng)時是這樣），因此一直堅持使用 LogHub锄开。

由于大數(shù)據(jù)計算部分是由另外一名同學(xué)專門負責(zé)的素标，因此我當(dāng)時也沒有參與相關(guān)操作，這里不再贅述萍悴。由于經(jīng)過計算后的數(shù)據(jù)量仍然極大头遭，以此該同學(xué)已考慮到將所有結(jié)果數(shù)據(jù)按照時間（大部分數(shù)據(jù)區(qū)分到月份，部分數(shù)據(jù)區(qū)分到日期）分表存放退腥，以便于后續(xù)服務(wù)讀取任岸。

服務(wù)

業(yè)務(wù)的最終目標是將上述采集、清洗計算得出的數(shù)據(jù)以數(shù)據(jù)平臺的方式展示給用戶狡刘，因此最終的產(chǎn)品形態(tài)是一個網(wǎng)頁享潜，主要由 Koa + Vue 實現(xiàn)，其中涉及到數(shù)據(jù)的讀取嗅蔬，由于數(shù)據(jù)量較大剑按，因此前期會將一部分數(shù)據(jù)按照熱度進行緩存以提高讀取效率。因該服務(wù)也是另一位同學(xué)專門負責(zé)澜术，其中涉及的技術(shù)主要有 Web 服務(wù)艺蝴、用戶系統(tǒng)、數(shù)據(jù)庫 CRUD鸟废、API 接口等猜敢，與一般 Web 服務(wù)沒有太大差異，因此在此不再贅述盒延。

還沒完

由于業(yè)務(wù)上的需求以及技術(shù)迭代缩擂，該項目進行了二期改造。其中會涉及到更多的技術(shù)細節(jié)添寺，如調(diào)度中心的單點問題胯盯、任務(wù)分配機制有沒有更好的方案、如何提高本地數(shù)據(jù)清洗效率等等计露。本文即較完整地闡述了直播大數(shù)據(jù)采集一期項目的技術(shù)實現(xiàn)細節(jié)博脑，原本打算將二期也一起講述憎乙，但由于涉及細節(jié)太多，目前篇幅已過長叉趣，因此決定將二期內(nèi)容放到下一篇文章詳細講述泞边。

本人一直堅持，技術(shù)沒有好壞君账。而技術(shù)也一定是與業(yè)務(wù)的平衡和取舍繁堡。如有不明確或錯誤的地方歡迎留言或指出~不喜勿噴 :)