近些年,由于互聯(lián)網(wǎng)的快速發(fā)展以及線上需求的爆發(fā),直播在國內(nèi)已經(jīng)成為一個非常成熟的商業(yè)模式。在娛樂、教育、辦公等場景中涌現(xiàn)出許多優(yōu)秀的視頻直播產(chǎn)品。隨著國內(nèi)市場競爭日益白熱化,加之企業(yè)出海漸成趨勢,越來越多的直播公司選擇走出去,尋找新的海外直播市場,借鑒國內(nèi)成熟的產(chǎn)品、運(yùn)營以及商業(yè)模式,讓全球的用戶都用上中國人創(chuàng)造的產(chǎn)品,LiveMe 便是成功的出海直播產(chǎn)品之一。
LiveMe 是一個全球直播和社交平臺,于 2016 年 4 月推出。LiveMe 的產(chǎn)品功能包括 H2H、多人聊天、虛擬形象直播、蹦迪房等,它使用戶能夠隨時隨地直播、并觀看其他精彩的直播以及與世界各地的朋友進(jìn)行視頻聊天。目前 LiveMe 已在全球積累了超過 1 億用戶和超過 300 萬的主播。它已成為美國最受歡迎的社交應(yīng)用程序之一,并已在 200 多個國家和地區(qū)推出。
業(yè)務(wù)痛點(diǎn)
(資料圖片僅供參考)
與其他行業(yè)出海一樣,直播產(chǎn)品的出海也面臨著許多全球化挑戰(zhàn)。如各地的合規(guī)監(jiān)管、本地化運(yùn)營、持續(xù)創(chuàng)新、政治文化差異等,都為直播產(chǎn)品出海帶來巨大挑戰(zhàn)。而在出海的過程中,底層的技術(shù)能力幫助 LiveMe 在成本節(jié)約、用戶增長、金融風(fēng)控、提升研發(fā)效率等方面不斷實現(xiàn)精細(xì)化運(yùn)營與業(yè)務(wù)創(chuàng)新。
經(jīng)過了多年的沉淀,LiveMe 在業(yè)務(wù)上已經(jīng)形成了線上微服務(wù)主導(dǎo),線下計算中心主導(dǎo)的技術(shù)架構(gòu)。線上業(yè)務(wù)是通過 Go 語言開發(fā)的一套微服務(wù)架構(gòu),每個服務(wù)根據(jù)不同業(yè)務(wù)特性具有自己獨(dú)立的存儲。線下業(yè)務(wù)是由數(shù)據(jù)研發(fā)團(tuán)隊來維護(hù),通過 sqoop 和 MySQL Binlog 同步等方式從數(shù)據(jù)庫層面抓取數(shù)據(jù)到數(shù)據(jù)倉庫,完成一系列業(yè)務(wù)相關(guān)的支持。
這套業(yè)務(wù)架構(gòu)中線上業(yè)務(wù)主要面臨著以下痛點(diǎn):
第一,雖然完成了微服務(wù)分庫的設(shè)計,每個服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫,但是每個業(yè)務(wù)中又存在很多業(yè)務(wù)上的大表,都存在 MySQL 分表的現(xiàn)象。在典型的分表場景中,數(shù)據(jù)庫表會按照用戶的 UID 尾號經(jīng)過 MD5 后分到 256 張表,但是日積月累后又需要再根據(jù)時間日期做一個垂直的分表,導(dǎo)致數(shù)據(jù)庫表無法完成聚合查詢,再加上跨時間段的分表需求,很多場景無法滿足線上需求。
第二,對于分析型業(yè)務(wù)數(shù)據(jù)而言,需要保證數(shù)據(jù)的實時性,并保留數(shù)據(jù)細(xì)節(jié)。實時的數(shù)據(jù)分析,可以在業(yè)務(wù)上更快做出決策,例如在一些活動運(yùn)營場景中,業(yè)務(wù)團(tuán)隊需要快速從各個數(shù)據(jù)維度來分組統(tǒng)計觀察活動效果;在金融相關(guān)風(fēng)控業(yè)務(wù)中,需要根據(jù)各個維度快速聚合來判斷各項數(shù)據(jù)是否達(dá)到風(fēng)控模型的閾值。如果使用離線計算的方式,數(shù)據(jù)的實時性根本無法得到保證;此外,經(jīng)過離線計算或者實時計算過的數(shù)據(jù),如果用戶反饋數(shù)據(jù)有問題,需要查看數(shù)據(jù)的細(xì)節(jié)也很難實現(xiàn)。
第三,各種精細(xì)化運(yùn)營需求,例如推薦、個性化運(yùn)營等場景不斷增加,對于數(shù)據(jù)的實時要求越來越高。因此,LiveMe 急需一種更簡單,同時讓線上線下業(yè)務(wù)做好平衡的方案。
此時,如果 LiveMe 繼續(xù)選擇大數(shù)據(jù)技術(shù)棧解決痛點(diǎn)就會面臨以下挑戰(zhàn):1)大數(shù)據(jù)技術(shù)棧的架構(gòu)非常復(fù)雜,中間件過多;2)需要額外的技術(shù)棧學(xué)習(xí)成本,比如如果使用數(shù)據(jù)同步,就需要 sqoop、scala、kafka 等中間件,會大幅增加整個業(yè)務(wù)的復(fù)雜性;3)希望線上業(yè)務(wù)以及架構(gòu)非常簡單,能夠簡化到普通開發(fā)人員只要能夠 CRUD(增加(Create)、讀取(Read)、更新(Update)和刪除(Delete)) 數(shù)據(jù)庫就可以上手開發(fā)。
為什么選擇 TiDB ?
基于以上業(yè)務(wù)挑戰(zhàn),LiveMe 經(jīng)過一系列技術(shù)選型后最終選擇了 TiDB 數(shù)據(jù)庫。 TiDB 的以下特性可以幫助 LiveMe 很好的應(yīng)對挑戰(zhàn):
1)TiDB 的性能大于等于 MySQL ;
2)TiDB 的 HTAP 特性能夠解決線上大表的問題,在后臺或者一些實時分析場景中,其 OLAP 分析能力能夠保證實時數(shù)據(jù)報表;
3)TiDB 引入的 MPP 架構(gòu)分析能力,使得 OLAP 查詢速度非??欤@也是 OLAP 數(shù)據(jù)庫架構(gòu)上的技術(shù)方向;
4)TiDB 團(tuán)隊有著完善和專業(yè)的技術(shù)支持,在過程中可以幫助 LiveMe 解決很多問題,在線上大規(guī)模使用后也沒有后顧之憂。
如何利用 TiDB 實現(xiàn)實時聚合查詢
鑒于 LiveMe 的微服務(wù)架構(gòu),如果將數(shù)據(jù)源全部替換,工程量大且不能一蹴而就,因此就需要一種兼容性的方案,在保證線上業(yè)務(wù)不受影響的同時也能使用 TiDB 的特性來解決 LiveMe 的業(yè)務(wù)痛點(diǎn)。因此,對于需要聚合查詢的業(yè)務(wù), LiveMe 通過消息隊列廣播的方式,在業(yè)務(wù)層訂閱相關(guān)事件再補(bǔ)充業(yè)務(wù)側(cè)需要的寬表信息寫入 TiDB,基于 TiFlash 就可以做到實時的運(yùn)營報表。業(yè)務(wù)開發(fā)人員只需要編寫對應(yīng)的 SQL 查詢,就可以輕松完成需求。 沒有了復(fù)雜的 ETL 過程,大大簡化了開發(fā)流程。
對于業(yè)務(wù)數(shù)據(jù), LiveMe 使用 AWS SQS 消息隊列,相比 Kafka 的優(yōu)勢在于每條數(shù)據(jù)都是原子性的,每條數(shù)據(jù)都可以用來做冪等重試,來保證數(shù)據(jù)的最終一致性。目前,這套技術(shù)方案已經(jīng)支撐了 LiveMe 的活動運(yùn)營和金融風(fēng)控等多個業(yè)務(wù)場景,滿足了 LiveMe 對于線上大量數(shù)據(jù)實時聚合查詢的要求。
基于 TiDB 解決方案,LiveMe 技術(shù)團(tuán)隊在上述寫擴(kuò)散場景中,把擴(kuò)散寫入的部分替換成了 TiDB,使用一張數(shù)據(jù)庫表來存儲所有 feed 的寫入關(guān)系,比如用戶有 100 萬粉絲,就在數(shù)據(jù)庫里插入 100 萬條數(shù)據(jù)。基于 TiDB 的分布式數(shù)據(jù)庫特性,幫助 LiveMe 簡單高效地解決了數(shù)據(jù)增長擴(kuò)容問題。
基于此技術(shù)架構(gòu),技術(shù)團(tuán)隊簡化了一個典型的 redis 緩存設(shè)計問題,熱數(shù)據(jù)放在 redis 中,用 mget 來獲取。冷數(shù)據(jù)放在 TiDB 中,用 select in 查詢,這樣做數(shù)據(jù)冷熱區(qū)分就非常容易,甚至可以實現(xiàn)一個簡單的布隆過濾器來了解哪些數(shù)據(jù)在熱數(shù)據(jù),哪些數(shù)據(jù)在冷數(shù)據(jù)里。以此減少無效數(shù)據(jù)的回源,更高效獲取數(shù)據(jù)。
LiveMe 的朋友圈功能基于 TiDB 的分布式存儲特性進(jìn)行技術(shù)改造后, feed 表從 2021 年中旬上線至今已經(jīng)達(dá)到數(shù)十億數(shù)據(jù)寫入,現(xiàn)在的數(shù)據(jù)量單表 39 億條。因為這些數(shù)據(jù)是永久保留不會刪除的,所以該數(shù)據(jù)也會一直增長。
未來規(guī)劃
未來, LiveMe 將會繼續(xù)嘗試 TiDB 在更多業(yè)務(wù)中,一方面會做數(shù)據(jù)庫管理開發(fā);另一方面將對于強(qiáng)事務(wù)依賴交易型的業(yè)務(wù)嘗試使用 TiDB,為直播電商場景做技術(shù)儲備。