斗鱼大数据的玩法
我是吳瑞誠，現在負責斗魚數據平臺部，今天給大家分享一下斗魚大數據這塊的玩法。我先做個自我介紹，我是11年初華科通信碩士畢業就進入淘寶，主要做HBase相關開發，后來回武漢后在1號店轉向應用架構方向。
我是14年9月加入斗魚，當時斗魚研發是30人的規模，從0開始搭建斗魚大數據平臺，單槍匹馬一個人，大概干了三個月，招不到大數據開發，哪怕只是基本了解Hadoop的都很招不到，干的很苦。所以團隊第一批組員是組內培養的，會一些Java開發基礎的應屆生，生拉硬拽湊到大數據團隊。其中一位武漢理工15年的本科應屆生，現在已經成長為我們部門BI/DW團隊的Leader。到現在，加上即將入職的應屆生，數據平臺部團隊規模接近60人，分為四個組：大數據處理組、BI/DW組、數據挖掘組、基礎架構組。
在武漢招開發難，招大數據開發更難，這也是我、柴楹和貓友會發起這個收費群的主要目的。讓整個武漢互聯網圈看著起勢的時候，會有一個大數據的圈子。大家多溝通，多交流，把整個圈子的氣氛帶動起來。這樣對于我們研發人員本身和武漢本地的公司都是極大的利好。
先簡單介紹一下斗魚：1.國內最大游戲直播平臺，從16年開始向泛娛樂化方向發展；2.日活用戶 2000萬，最高同時在線人數約500萬；3.主播日活 40,000人，每天產生原創視頻數萬小時。；4.ALEXA排名：全球約200名、國內約20名（近期略下滑，今天中午看在30多名，比優酷、Bilibili等站要高）；
這是一個典型的斗魚直播間，是斗魚最主要的內容形態：左邊是視頻區，上面飄過的文字就是彈（dàn）幕，直播網站上用戶和主播互動的最主要形式。彈幕服務是性能壓力最大的服務之一，相當于是需要百萬人群聊時的消息推送量，后續有機會和大家分享；視頻區下面是禮物贈送區；右側是彈幕區，Tab頁上是排行榜，用戶對該直播間的貢獻值，土豪喜聞樂見；
接下來我會跟大家分享一下斗魚大數據現在的玩法和下一步的規劃。主要內容分為四方面：
1.斗魚大數據平臺的整體架構；
2.斗魚數據倉庫
3.斗魚個性推薦系統
4.斗魚風控系統
1、斗魚大數據平臺整體架構
先來看看斗魚大數據平臺的整體架構，上一張鎮樓的圖：
14年加入斗魚，當時負責的第一個業務是用shell腳本，從主站服務器上拉Nginx log到Hive集群中，統計產生報表。隨著網站數據量的增長和配備約來越完備，從最開始的小系統越做越大，做到現在這個架構。
這個架構差不多是在16年初的時候成型的，主要包括：數據源層，用戶行為打點、服務日志、Nginx/PHP日志（離線和實時兩條數據流）、線上MySQL庫、MongoDB、Redis存儲數據接入層，包括了Kafka，負責接入打點上報（最大吞吐量約200w TPS）、Canal/Sqoop（主要解決數據庫數據接入問題）、Flume/Logstash/rsyslog等實時日志；數據預處理層，簡單的清洗和聚合計算；存儲層，典型的系統HDFS（文件存儲）、HBase（KV存儲）、Kafka（消息緩存）；計算層，主要包含了典型的所有計算模型的計算引擎，包含了MR、Hive、Storm、Spark以及深度學習平臺比如Tensorflow等等再往上就是數據服務層，主要提供對外數據服務。這一塊現在主要是基于Docker實現的一整套微服務環境來支撐；
1.1 大數據管理平臺
下面先簡單介紹一下各個組件的玩法，首先是大數據管理平臺，承載所有的元數據管理、統一監控系統、報表展示、任務調度、發布系統等所有配套功能。
1.2 基礎集群架構
可以看到，清晰的區別了online 和offline 集群
機器配置：
現負責約300臺高配服務器，Dell 730xd，32Cores 128/256G內存，16*6T Sata Disk；
Hadoop大集群150臺物理機，5PB數據，日增量約20T；
實時離線集群分離，避免資源競爭造成業務處理抖動。集群分離后也可以更安全的對集群進行運維操作；
使用Kafka作為MQ，更確切說是消息通道；
1.3 OLAP查詢引擎Impala
Impala之前，我們有使用Presto的經驗，后來因為運維上的問題，暫時下線了。Kylin15年很早的時候，在北京和kylingence官方有過一次深入溝通，仔細評估后發現斗魚的場景不能發揮他的優勢。最近Kylin重大版本之后，準備再評估一次。這方面應該有不少同學都有相關的經驗，最后討論階段，大家可以一起聊一下。
可能對大數據組件不太熟悉的同學，可能對OLAP概念不太熟悉，主要是針對秒級大數據量查詢場景。對應的OLTP 是針對事務處理，我們比較常見的MySQL和Oracle屬于這類。這樣解釋大家可能接受起來會簡單一些。
使用Impala作為SQL查詢引擎，相比Hive整體提升5倍速度；使用了完全區別于MapReduce的一套數據處理模式。
我們主要做了一點：由于Impala是C++編寫，為了提升性能，將部分高查詢密度的UDF（如：JSON解析）替換為C++實現。使用HA Proxy作為Impala負載均衡器，均衡JDBC連接。避免 Impala Daemon 故障、重啟時影響正常業務。這樣，可以覆蓋我們現在大部分的秒級大數據量查詢（10億級別）
1.4 Spark應用
Spark在斗魚大數據生態系統有著舉足輕重的作用。涉及到：
接入實時流（7*24h）各個場景的實時PV、UV統計，實時日志分析，服務接口性能監控，用戶分布及其他報表等。已上線獨立實時任務20余個。
數據抽取與處理抽取異構數據源（MySQL，MongoDB），將其抽取數據合并、加工后寫入數據倉庫。每日凌晨觸發數據抽取加工任務。為最重要依賴調度任務，為后續每日離線任務準備數據。
數據分析/挖掘包含彈幕統計分析，流量渠道統計分析，垃圾彈幕識別，用戶點擊預測，用戶分群，推薦系統等任務。這也是部門今年非常重視的一塊，任務規模也在日益龐大。
部署：Spark on Yarn ，單節點部署，依賴Yarn環境
發布：基于自研發布系統，可配置一件部署
調度：基于自研發布系統，定時調度與依賴調度兩種模式可選
告警：監控與告警系統支持任務執行監控及其結果校驗監控
由于正在經歷Spark大版本升級（1.6.xà2.1.x）進程之中，斗魚數據平臺部線上存在兩個Spark集群來支撐目前的業務
1.6.3版本Spark基于線上yarn進行部署（Spark on Yarn）： 66個節點 72G 內存/節點 22個核/節點
2.1.0版本Spark基于Standalone： 12個節點 72G 內存/節點 22個核/節點
Spark生態中，我們主要用到的兩個組件：
1.Zeppelin主要提供Spark SQL交互界面查詢，數據可視化支持。后續將支持Python、R語言的建模，支持用戶Notebook的提交和調度。
2.Alluxio基于內存的分布式文件系統，它是架構在底層分布式文件系統和上層分布式計算框架之間的一個中間件，主要職責是以文件形式在內存或其它存儲設施中提供數據的存取服務。
底層的存儲層和計算層的基礎集群大概是這些。
2、基于ELK的統一日志監控系統
現在我們把es集群按業務場景劃分為多個小集群，這樣的可以避免不同業務出現搶占資源的情況。
多個ES集群，50+物理節點、每日15T+日志量，多實例部署，接入全站所有服務器日志；
年后，完成全部升級至ElasticSearch 5.X，性能提升明顯；
廢棄FlumeAgent，使用Firebeat、Rsyslog，小巧穩定、資源占用低；
為部分業務獨立開發日志解析器，提高性能，有Java版和Spark版；
我們應用ELK的場景中，最難的就是在agent 資源占用和 agent抽取吞吐之間做權衡，想馬兒快，又想馬兒不吃草，會針對不同的語言棧，使用不同的agent是實現。
推薦日志使用JSON格式，降低解析壓力、增減字段靈活；
我們agent會把日志灌入kafka，然后從kafka出口的日志流就需要穩定、格式化的結構往ES集群小batch灌，這樣就出現了使用hangout和自研數據管道兩種實現方式，hangout是java版的Logstash，效率仍然滿足不了我們的要求，所以，有了基于spark 的自研日志消費管道。
對ELK的使用，算是踩坑無數。講一些ES主要優化點：
1.索引按小時切分，當索引無數據寫入時進行ForceMerge提升查詢性能；
2.由于日志收集寫請求遠遠大于讀請求，保證每個節點有分片分攤寫壓力（每個節點1~2個分片），節點磁盤獨立；
3.每臺服務器（128G內存），1Master+2Data，預留大約一半內存作為System Cache提升查詢性能；記住，一定要留足cache 。。
4.cluster.routing.allocation.same_shard.host禁止主從分片被分到同一臺服務器上（不同節點），保證服務器宕機時索引可用；
ELK的整體優化思路是為了能抗住低延遲和大日志量的問題；現在我們已經能穩定在每日15T+日志量級，基于這一套統一日志監控系統，做了很多業務、服務的監控和告警。
我們現在吞吐量最大的實時數據流，100w+TPS，全站各個端所有用戶行為的實時監控，可以實時看到整體打點水位、各個客戶端、各個版本播放器的健康狀況
這是推薦接口的實時Dashboard監控效果圖：左上是每次請求的最大耗時、右上50分位和99分位耗時統計；左下是推薦接口的整體水位統計、右下是各個Tomcat實例的水位統計；這樣可以對實時推薦接口的整體訪問量、每個實例的請求量、性能水位、超時請求一目了然，監控神器。基于此可以做閥值的監控，解放雙手。
現在每個核心接口分給不同同學來負責，人手配置一個類似的Dashboard。加上告警，就可以騰出手來了。
再分享最前面有一個大的架構圖，最上層是數據應用層，我們會對外提供多種服務，包括個性推薦、實時監控、廣告系統、風控系統、搜索引擎（基于ES）、后臺數據應用等服務都是由我們自己來完成整個服務的部署，用以對外提供訪問；這樣，除了數據層面的處理，也對我們工程實現上提出了高要求，要能直接提供對外服務。我們現在的玩法是基于Docker生態構建完備的微服務體系來實現，直接上圖
前后端完全分離，使用Nginx作為網關，代理后端服務。功能較單一，正在預研其他網關方案；
全面升級至SpringBoot，擁抱微服務；
1.使用內嵌的Web容器（Tomcat、Jetty、Undertow），由應用自己掌控整個生命周期，形成閉環；
2.容器化改造更平滑，提高應用彈性（方便統一底層系統環境、方便擴縮容）；
3.內置的Metrics 接口使應用監控更方便。
這樣，就講到斗魚服務容器化
1.使用K8S作為容器編排引擎，進行容器調度、運行、滾動升級、灰度發布；
2.暴露服務狀態接口（isReady，isHeahthy），更好的利用K8S探針進行自我健康檢查；
3.容器網絡使用Flannel（VxLan模式）；
4.使用Nginx作為網關代理外部請求（非容器網絡內的請求）;
5.進行容器化改造的過程中，對于需要暴露接口的服務，初期可以將服務容器網絡設置為宿主機網絡，避免接口無法訪問的問題（尤其是在服務發現場景，注冊的是容器IP，外部無法訪問），后期進行宿主機端口感知、注冊。
主要挑了核心組件來做簡單分享，拋個磚；當然為了支撐Devops開發模式（每位同學從需求分析開始，一直負責設計、開發、測試、發布、運維、告警、優化等服務全周期），需要有配套的任務調度系統（基于ZK自研）、發布系統（基于Jenkins自研）、監控系統（自研）等系統限于篇幅不做展開；
2、斗魚數據倉庫
斗魚數據倉庫最開始就是一個Hive default庫，導入的表是Nginx/PHP log。慢慢需要對注冊用戶進行統計分析，逐漸導入了注冊表、禮物流水、充值表等等關系表。逐漸增加到近200張表粗放的放在default庫，碰到權限、誤刪除等問題后，數據倉庫分層刻不容緩；
斗魚數據倉庫分層主要分為以下幾層：ods：ods層主要用來存儲從業務數據庫表，如MySQL，MongoDB同步過來的原始數據，以及線上用戶行為等原始數據external：external層主要用來存放線上寫到HBase數據建立的外部表，以及日志數據的外部表dim：dim層主要用來存放維度表信息，如直播間維度信息等dwd：dwd層主要用來存放從ods層以及dim，external處理清洗過后的數據，方便接下來的計算dw：dw層主要用來對用戶或主播等進行一些輕維度的匯總ads：ads層主要是應用層的一些數據，如對外的報表數據archive：archive層主要是歸檔歷史數據
數據倉庫中還會根據業務以及數據類型做域的劃分：
業務域：ad-廣告，game-游戲數據域： log-日志域，pay-交易域
斗魚數據倉庫規范實施數據倉庫基本的建設完成后，就會有一些用戶操作數據的規范，如：SQL規范，數據時間周期的規范SQL規范主要有以下幾個方面類型統一：double，string，bigint數據傾斜：group，count distinct，開窗函數表級&字段級注釋條件語句類型必須一致case when語句必須要有else表查詢帶上庫名稱
開始同步數據時使用了開源的sqoop作為同步工具，由于對多數據源的支持不夠豐富以及對內部系統的兼容性問題，逐漸放棄使用；
自研了Data-Porter工具作為目前主要的多種數據源與數據倉庫間的同步工具。Data-Porter基于Spark Pipeline，將數據從DB讀取為Spark RDD，再轉為Spark DateFrame，最后使用Spark SQL將數據寫入Hive，這種通過API由低階到高階的應用，實現了無附加操作的數據同步。
目前支持MySQL的數據庫分庫分表的同步，MongoDB集群同步以及數據源去重，但是也有一些不足的地方，比如對數據源目前還只支持了MySQL和MongoDB，后續會規劃開發關于HBase等目前主要使用的數據源的同步支持。
3、斗魚個性推薦系統
先看看斗魚個性推薦的主要欄目位：
– App首頁幾乎都是個性推薦的欄目位，每個用戶看到的都是依據自己口味推薦的直播間，千人千面；
– 直播列表中有特定的兩個位置；
– 直播間頁面中，有“超管推薦”，每個直播間看到的都不一樣，百人百面。
其中App首頁是完全千人千面，不同的分區、不同的房間，都是根據用戶歷史行為，預測的用戶偏好進行推薦。可以看下斗魚個性推薦的場景，很多，而且會越來越多。是公司的總體戰略目標。
斗魚個性推薦是從15年開始預研，線下做推薦方案對比、模型效果對比、實際數據試跑，到16年6月份才正式上線。從Web端的列表、直播間內的推薦位，同步APP端上線。現在APP首頁大部分都是個性推薦位，做到千人千面的實時推薦；
個性推薦的算法模型選擇是一方面，推薦服務本身工程實現的性能也是很大的考驗，要支持500w的用戶同時在線量，接口處理請求峰值近1w +QPS。得益于服務化，核心功能都配備完備的監控告警。正在上線的Docker容器化，可以大大提升服務的彈性，方便服務規模的擴縮。
個性推薦的效果好壞拼的就是用戶畫像，對自己用戶越熟悉，推薦效果才可能越好；斗魚的用戶畫像現在是這么玩的：
從上面的圖可以看到，目前我們的推薦系統主要分為三個模塊：推薦服務層、數據維護層、監控層。
1)推薦服務層推薦業務規則過濾，根據業務需求過濾不需要推薦的數據推薦算法配置，根據業務場景及推薦位配置不同的推薦算法ABTest分流，用于推薦算法對比及灰度上線結果數據格式化及排序
2)數據維護層基礎信息數據使用dubbo提供服務，降低服務層對數據源的依賴基于物品相似、用戶標簽、KPI體系等算法，離線計算與實時計算相結合推薦算法數據存儲，基于不同算法數據分開存儲維護數據緩存策略，提升緩存命中率，降低DB請求
3)監控層接口可用性監控、接口性能監控數據質量監控，保證數據準確性推薦效果監控，實時關注推薦轉化率
個性推薦無法速成，斗魚個性推薦當前也有不少問題：
a.推薦規則單一，點擊轉化率約5成，仍有提升空間
b.推薦服務開發效率及擴展性不高
c.推薦數據分散，復用率低
4.斗魚風控系統
這個圖片有一個很勵志的故事，是這樣的：20平米房間，2萬張卡，前期投入約40萬，一天換一次，一個月內所有的卡都跑一圈。每月收入30萬，高峰月入百萬。工作室的日常：每天晚上將卡一張張取下來，更換新卡。這是黑產的一個縮影。
那斗魚面對的黑產風險有：
這是前天我從淘寶上搜索斗魚tv時的結果截圖，可以作為現在斗魚面對黑產形勢的一個典型縮影。
主要集中在直播間人氣（主播價值的一個衡量依據）、魚丸（主播可兌換的禮物）、打折魚翅（黑卡充值—重災區，主播可以兌換，危害更大更直接）、主播刷關注，可以從淘寶價格上一瞥黑市上各個刷量的難易和獲益程度。同時，在搜索結果中，也能看到斗魚友臺出現在搜索結果中，可見，黑產風險是整個行業要面對的，不僅僅是斗魚。在這一塊，是需要行業內的整體合作的，盡管這個合作有些障礙。
斗魚風控系統是這樣的：
1 大力懲治的同時，要保證用戶體驗，盡量降低誤殺；
2 依據用戶行為數據獲取特征模型，提取作弊行為的特征模型；
3 針對IP和設備畫像，對IP和設備進行嫌疑級別評級打分；
4 采用線上實時+離線分析雙層識別模型為主，輔以“基于規則-rule-based”判斷；
5 提取用戶行為風險模型、用戶風險評分等級
對照上圖，挨個注釋一下：
建設決策中心(Drools)，識別各種作弊行為，優化反作弊算法模型。風控實時引擎，以實時彈幕、異地登錄等關鍵行為實時流為基礎，在結合賬號防盜及充值消費數據，實時評估用戶風險等級。
用戶行為軌跡分析系統，協助分析用戶作弊行為，提煉風控規則。風控離線引擎，不定期更新離線風控規則，接入決策中心，統一配置。
風控web管理平臺，用于配置決策規則、黑白名單管理、行為軌跡查詢等功能。風控數據服務化，對外提供安全訪問的接口，實時查詢用戶風險行為，降低損失。
總結：
我們有很多數據；圍繞數據我們做了很多努力；要讓數據發揮更大的價值
Q&A ：
1 、快速發展的小公司有哪些潛在的大數據處理場景？需要用到哪些關鍵的技術和架構？除了個性化推薦，還有哪些大數據落地的例子？離線計算在斗魚的應用有哪些？
吳：我個人感覺上大數據一般都會被業務推著走，如果是特意要去玩大數據，可能會比較難推動。比如我從淘寶回武漢，在一號店干了一段時間，在某些場景，確實是不合適。。所以我建議，用集群的方式，先做一個簡配版數據倉庫，拿到了數據，才好想一些玩法。這個問題大概是這樣。
2、看你們剛剛的集群有好幾個，分為計算集群，和實時等，為啥不用yarn 的隊列機制，分隊列進行彈性計算，這樣可以充分利用集群。cdh 有推出資源池，有沒有去嘗試？好幾個集群維護比較麻煩，你們這幫是怎么管理的？
吳：我們現在用的cdh版本，也是基于的yarn管理集群資源。
3、對于北上廣漂著的想回武漢發現的程序猿們有什么建議和忠告？
吳：這個問題我有經歷，所以有發言權。我當時回武漢，是因為家庭原因。所以我是沒有選擇的情況下回的武漢。現在武漢的坑位比早兩年已經多了很多，公司也多了很多。大公司的研發中心，本土起來的互聯網公司都有不少。所以坑位有了，就看自身的成長，能不能滿足這些坑的期望。我們的offer被好多公司都有搶過，所以薪資這塊，我覺得也不是問題，呵呵。
4、斗魚的負載均衡是如何做的？斗魚數據安全是怎樣保證的? 如果想構建自己的VPN服務器，有啥要注意的?
吳：按我的理解來回答，網站入口是DNS-lvs-nginx-服務容器，數據安全依靠權限管理（賬號-角色-權限）。構建自己的VPN，這個我就不太了解的。太偏網絡層面，得找IT同學幫忙。
5、我在北京工作已有五年。先后在百度,小米做過游戲視頻分發的開發工作。大數據這一塊接觸的比較少。年后想回武漢發展。請問斗魚有合適的坑嗎？
吳：游戲和視頻分發斗魚現在沒有自己做，但是從你的經歷來看，在武漢肯定能有坑。
總結
- 上一篇： 第3章 Python 数字图像处理(DI
- 下一篇： 解决docker pull 速度过慢问题