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