作者簡(jiǎn)介

cd，攜程資深后端開(kāi)發(fā)工程師，度假商品系統(tǒng)研發(fā)，專注于后端系統(tǒng)性能提升。

團(tuán)隊(duì)熱招崗位：資深后端開(kāi)發(fā)/專家、資深后端開(kāi)發(fā)-商品后臺(tái)

在攜程旅游度假的線路類商品系統(tǒng)中，由于商品結(jié)構(gòu)復(fù)雜，涉及底層數(shù)據(jù)表上千張，在日常供應(yīng)商以及業(yè)務(wù)維護(hù)過(guò)程中，每日產(chǎn)生6億+的數(shù)據(jù)變動(dòng)記錄。這些數(shù)據(jù)的變動(dòng)留痕，不但可供錄入方查看，也對(duì)日常產(chǎn)研的排障起著至關(guān)重要的作用，同時(shí)也可以提供給BI做數(shù)據(jù)進(jìn)一步分析。商品日志系統(tǒng)建設(shè)尤為重要，隨著商品日志系統(tǒng)不斷發(fā)展迭代，已經(jīng)積累達(dá)到1700億條日志。

本文將介紹線路商品日志系統(tǒng)的演進(jìn)過(guò)程以及在其中遇到的問(wèn)題。

• 一、發(fā)展軌跡
• 二、演進(jìn)過(guò)程
• 2.1 V1.0 DB單表存儲(chǔ)
• 2.2 V2.0 平臺(tái)化
• 2.3 V3.0賦能
• 三、結(jié)語(yǔ)

一、發(fā)展軌跡

線路商品日志系統(tǒng)的發(fā)展大致可以分為以下三個(gè)階段：

2019年以前：?jiǎn)伪砣罩?/span>

在 2019 年以前，商品系統(tǒng)尚無(wú)統(tǒng)一的日志系統(tǒng)來(lái)記錄商品的變更，在系統(tǒng)中使用DB日志表，該表以非結(jié)構(gòu)化的方式記錄商品基本信息的變動(dòng)。

2020年~2022年：平臺(tái)化

在系統(tǒng)改造過(guò)程中，建立統(tǒng)一的商品系統(tǒng)日志平臺(tái)，通過(guò)配置的方式記錄商品的數(shù)據(jù)變動(dòng)日志，覆蓋商品維護(hù)的全部流程。

2023年~2024年：開(kāi)放

經(jīng)過(guò)在線路商品系統(tǒng)的實(shí)踐，商品系統(tǒng)日志平臺(tái)經(jīng)歷百億級(jí)數(shù)據(jù)的考驗(yàn)，并以靈活的配置方式記錄數(shù)據(jù)變動(dòng)日志，同時(shí)支持自定義索引字段，具有接入和使用成本較低的優(yōu)勢(shì)。為此，通過(guò)對(duì)商品系統(tǒng)日志進(jìn)行改造，逐步向門票、用車等業(yè)務(wù)線開(kāi)放使用。

二、演進(jìn)過(guò)程

2.1 V1.0 DB單表存儲(chǔ)

在2019年以前，記錄線路商品的變動(dòng)日志較為簡(jiǎn)單，在DB中建立一張日志表（id,LogContent）來(lái)記錄日志，數(shù)據(jù)變動(dòng)以非結(jié)構(gòu)化的文本記錄在LogContent字段內(nèi)，且僅覆蓋商品最基本的信息，在使用時(shí)通過(guò)數(shù)據(jù)庫(kù)查詢工具執(zhí)行sql語(yǔ)句like關(guān)鍵字進(jìn)行查詢，這種方式帶來(lái)的問(wèn)題也顯而易見(jiàn)：

• 數(shù)據(jù)量大，性能低

由于是單表文本字段存儲(chǔ)，導(dǎo)致表的數(shù)量非常巨大，達(dá)到單表10億+（370GB）的數(shù)據(jù)，查詢超時(shí)問(wèn)題嚴(yán)重，不得不進(jìn)行定期歸檔。

• 可讀性差，僅開(kāi)發(fā)人員使用
  

由于日志內(nèi)容以文本字段存儲(chǔ)，在進(jìn)行日志查詢時(shí)，一般由開(kāi)發(fā)人員使用 like 語(yǔ)句直接查詢 DB，例如：select id, LogContent from log where LogContent like '%1234%'。查詢速度緩慢，嚴(yán)重影響日常排障流程。

• 擴(kuò)展性差
  

由于日志寫入與業(yè)務(wù)代碼強(qiáng)耦合，且采用非結(jié)構(gòu)化存儲(chǔ)。對(duì)于新增日志，需要對(duì)業(yè)務(wù)代碼進(jìn)行改動(dòng)，在接入時(shí)存在一定的成本，且接入后無(wú)法直接提供給供應(yīng)商或業(yè)務(wù)人員直接使用，最終仍需要開(kāi)發(fā)人員進(jìn)行查詢轉(zhuǎn)換。

2.2 V2.0 平臺(tái)化

2.2.1 技術(shù)選型

針對(duì) V1.0 遇到的問(wèn)題，重點(diǎn)在于海量日志數(shù)據(jù)的存儲(chǔ)與查詢，業(yè)內(nèi)解決海量日志數(shù)據(jù)存儲(chǔ)與查詢的方案一般有以下幾個(gè)：

ES+Hbase

HBase 提供高并發(fā)的隨機(jī)寫和支持實(shí)時(shí)查詢，是構(gòu)建在 HDFS 基礎(chǔ)上的 NoSql 數(shù)據(jù)庫(kù)，適用于海量日志數(shù)據(jù)的存儲(chǔ)，可支持到 PB 級(jí)別的數(shù)據(jù)存儲(chǔ)。但其查詢能力有所欠缺，支持 RowKey 快速查詢，若有復(fù)雜查詢則需要自建索引。ES 提供強(qiáng)大的搜索能力，支持各種復(fù)雜的查詢條件，適合快速檢索及靈活查詢的場(chǎng)景。ES + HBase 的組合，利用各個(gè)組件的優(yōu)勢(shì)，結(jié)合起來(lái)解決海量日志數(shù)據(jù)存儲(chǔ)及查詢的問(wèn)題，但架構(gòu)較為復(fù)雜，需要保證兩個(gè)組件間數(shù)據(jù)的一致性。

MongoDB

支持多種查詢，具有文檔型及嵌套的數(shù)據(jù)結(jié)構(gòu)，但其支持的數(shù)據(jù)量級(jí)一般在 10 億級(jí)別，對(duì)比 HBase 要欠缺得多。如果想要處理 TB 級(jí)以上的數(shù)據(jù)量，需要進(jìn)行適當(dāng)?shù)募軜?gòu)設(shè)計(jì)和優(yōu)化，例如利用分片集群來(lái)水平擴(kuò)展數(shù)據(jù)等，付出的成本會(huì)比較高。

ClickHouse

Clickhouse 是一個(gè)開(kāi)源的列式數(shù)據(jù)庫(kù)，采用列存儲(chǔ)的數(shù)據(jù)組織方式，具有高性能、可伸縮性、容錯(cuò)性和低延遲查詢等特點(diǎn)。查詢性能出色，可實(shí)現(xiàn)秒級(jí)甚至毫秒級(jí)的查詢性能，對(duì)于數(shù)據(jù)壓縮和存儲(chǔ)效率高，可節(jié)省成本。適用于海量數(shù)據(jù)的存儲(chǔ)及查詢場(chǎng)景。

通過(guò)對(duì)以上方案進(jìn)行對(duì)比，我們的數(shù)據(jù)量級(jí)已經(jīng)超過(guò) MongoDB 一般的處理能力，因此該方案被淘汰。對(duì)比 ES + HBase 與 ClickHouse，這兩個(gè)方案都比較適合海量日志的存儲(chǔ)與查詢，但是受限于內(nèi)部成本控制，CK 集群的日志保存時(shí)長(zhǎng)被控制在一定天數(shù)內(nèi)，無(wú)法滿足我們業(yè)務(wù)場(chǎng)景的需求。最終，我們選擇 ES + HBase 的方案。

2.2.2 整體架構(gòu)

基本原理即利用 HBase 解決存儲(chǔ)問(wèn)題，利用 ES 解決搜索問(wèn)題，并將 ES 的 DocID 與 HBase 的 RowKey 關(guān)聯(lián)起來(lái)。通過(guò)發(fā)揮各個(gè)組件的優(yōu)勢(shì)，相互結(jié)合解決海量日志的存儲(chǔ)與查詢問(wèn)題。如上圖所示，在接入日志 API 后，所有日志均經(jīng)過(guò) MQ 進(jìn)行異步處理，如此既能夠?qū)⑷罩緦懭肱c業(yè)務(wù)代碼的邏輯解耦，又能確保寫入速度的平穩(wěn)，避免高峰流量對(duì)整個(gè) ES + HBase 集群的寫入造成壓力。

2.2.3 RowKey設(shè)計(jì)

RowKey設(shè)計(jì)原則：

唯一性：RowKey應(yīng)保證每行數(shù)據(jù)的唯一性；

散列性：數(shù)據(jù)均勻分布，避免熱點(diǎn)數(shù)據(jù)產(chǎn)生；

順序性：可以提高查詢性能；

簡(jiǎn)潔性：減少存儲(chǔ)空間及提高查詢性能；

可讀性：以便人工查詢及理解；

對(duì)于線路商品日志，對(duì)于直接可讀性要求不高，查詢的場(chǎng)景我們是從ES中先查出RowKey，再用RowKey去hbase查詢?nèi)罩驹?，整個(gè)過(guò)程RowKey是人工不可見(jiàn)的，結(jié)合我們實(shí)際的場(chǎng)景，線路商品數(shù)據(jù)日志的RowKey由五部分構(gòu)成{0}-{1}-{2}-{3}-{4}

{0}：傳入的pk 轉(zhuǎn)換為md5[pk]值16進(jìn)制字符串，取前8為

{1}：tableId補(bǔ)0至8位

{2}：pk+4位隨機(jī)值補(bǔ)0至24位

{3}：log類型補(bǔ)0至16位

{4}：時(shí)間戳

2.2.4 擴(kuò)展

對(duì)于線路商品信息的維護(hù)分散于不同的模塊中，例如錄入模塊、直連模塊等。鑒于此，我們抽象出統(tǒng)一的數(shù)據(jù)寫入服務(wù)，并提供統(tǒng)一的日志接入 API，API內(nèi)部異步寫入日志。在底層的數(shù)據(jù)寫入服務(wù)中，將所有的寫入操作接入日志 API。通過(guò)這個(gè)方式，將擴(kuò)展性統(tǒng)一到日志配置中心。

寫入流程

日志的寫入流程如上圖所示，客戶端調(diào)用日志 API 以進(jìn)行數(shù)據(jù)變動(dòng)日志的寫入操作。日志服務(wù)在接收到請(qǐng)求后，將其拋入 MQ，由后續(xù)的消費(fèi)組進(jìn)行消費(fèi)處理。消費(fèi)組件在接收到消息后，會(huì)進(jìn)行相應(yīng)的消費(fèi)處理，并根據(jù)上述的RowKey生成策略為該條日志生成 RowKey，隨后將日志文本內(nèi)容寫入 HBase，在寫入成功之后，再將索引數(shù)據(jù)寫入到 ES。其中，若 HBase 或 ES 中的任何一個(gè)寫入失敗，都會(huì)將此條日志寫入補(bǔ)償 redis 集群，再由補(bǔ)償邏輯進(jìn)行后續(xù)補(bǔ)償，以確保整個(gè)日志的寫入成功。

查詢流程

日志的查詢流程如上圖所示：客戶端調(diào)用查詢 API 并傳入查詢參數(shù)，日志服務(wù)接收到請(qǐng)求參數(shù)后，將其轉(zhuǎn)換為 ES 分頁(yè)查詢請(qǐng)求，從 ES 集群中查出 RowKey，再匯總 RowKey 并從 HBase 中批量查出日志全文內(nèi)容。

此外，我們利用上述查詢 API，建立一個(gè)日志查詢頁(yè)面，供研發(fā)人員使用。在該頁(yè)面，相關(guān)開(kāi)發(fā)人員可以便捷地進(jìn)行數(shù)據(jù)變動(dòng)日志的查詢。上述日志平臺(tái)的建立，相對(duì)完美地解決線路商品海量數(shù)據(jù)變動(dòng)日志的存儲(chǔ)及查詢問(wèn)題。同時(shí)，抽象日志的配置中心，解決一定的擴(kuò)展性問(wèn)題。

整個(gè)系統(tǒng)的優(yōu)點(diǎn)在于：基于表級(jí)別日志的商品日志記錄，覆蓋全面，配置靈活，索引結(jié)構(gòu)化存儲(chǔ)，支持海量日志數(shù)據(jù)的存儲(chǔ)及查詢。

缺點(diǎn)是：對(duì)于使用方而言存在一定的局限性，過(guò)于“技術(shù)化”，開(kāi)發(fā)人員使用較為方便，但供應(yīng)商與業(yè)務(wù)人員使用困難。

2.3 V3.0賦能

2.3.1 業(yè)務(wù)賦能

存儲(chǔ)能力

隨著日志寫入量的增加，日志查詢效率逐漸下降，對(duì) ES 和 HBase 的拆分勢(shì)在必行。如下圖所示，我們對(duì) ES 和 HBase 進(jìn)行橫向的拆分與擴(kuò)容，并在日志配置中心制定匹配規(guī)則，根據(jù)接入日志類型的不同，將其匹配到不同的集群進(jìn)行寫入。此外，對(duì)于接入方，我們也支持獨(dú)立集群申請(qǐng)，使用方可以根據(jù)自身情況決定是使用獨(dú)立的集群部署，還是使用公用集群。

搜索能力

搜索能力的提升主要由以下兩個(gè)部分：

索引字段擴(kuò)展：支持的索引字段更多。前期我們絕大部分場(chǎng)景的日志的索引條件是產(chǎn)品id或者資源ID，隨著接入的日志變多，索引字段也變的豐富起來(lái)。對(duì)于日志搜索場(chǎng)景我們進(jìn)行梳理，預(yù)留10個(gè)可支持不同查詢的索引字段（其中四個(gè)數(shù)值型、4個(gè)字符型，2個(gè)日期型）供使用方使用，覆蓋絕大多數(shù)的查詢場(chǎng)景。

ES索引分區(qū)：隨著接入的日志增多，單個(gè)索引文件也愈發(fā)龐大，直接影響日志的查詢性能。一般而言，對(duì)于日志類型數(shù)據(jù)，常見(jiàn)的方案是依據(jù)時(shí)間建立索引，該方案的優(yōu)勢(shì)如下：

1）提升查詢性能。若日志攜帶時(shí)間范圍進(jìn)行查詢，則可僅搜索特定時(shí)間段的索引，避免全量索引的查詢開(kāi)銷。

2）便于數(shù)據(jù)管理。可以按照時(shí)間刪除舊的索引，從而節(jié)省存儲(chǔ)空間。

通過(guò)對(duì)日志進(jìn)行分類，主要包括商品信息、開(kāi)關(guān)班、價(jià)格庫(kù)存等模塊。隨后結(jié)合業(yè)務(wù)使用場(chǎng)景、每天產(chǎn)生的增量數(shù)據(jù)以及服務(wù)器資源進(jìn)行評(píng)估，最終決定按周建立索引，且索引數(shù)據(jù)保留一年。

1）利用定時(shí)任務(wù)在每周一時(shí)創(chuàng)建下一周的索引；

2）利用定時(shí)任務(wù)每周刪除已過(guò)期的索引；

基于以上存儲(chǔ)能力與搜索能力的擴(kuò)展提升之后，我們?cè)谌罩九渲弥行亩ㄖ屏恕緲I(yè)務(wù)線<-->日志集群】的路由規(guī)則，來(lái)決定接入的其它業(yè)務(wù)線日志最終存儲(chǔ)的日志集群，提供了更加靈活與具有彈性的業(yè)務(wù)線接入能力。

2.3.2 供應(yīng)商賦能

展示能力

在 V2.0 版本中，日志頁(yè)面僅限于研發(fā)人員使用，底層數(shù)據(jù)過(guò)于技術(shù)化，業(yè)務(wù)與供應(yīng)商難以理解。通常情況下，如果能將日志的查詢前置到供應(yīng)商及業(yè)務(wù)環(huán)節(jié)，將極大地減少研發(fā)人員平時(shí)工作中的排障時(shí)間。

為此，我們提供 B 端的日志查詢頁(yè)面，給供應(yīng)商及業(yè)務(wù)人員平時(shí)排查問(wèn)題使用。我們對(duì)日志內(nèi)容進(jìn)行格式化的轉(zhuǎn)換處理，將其轉(zhuǎn)換為供應(yīng)商和業(yè)務(wù)人員能夠理解的信息，包括行轉(zhuǎn)列、新舊對(duì)比、KV 轉(zhuǎn)換、關(guān)聯(lián)數(shù)據(jù)查詢等。日志內(nèi)容不再是抽象的文本，而是展示為與平時(shí)使用的商品系統(tǒng)相對(duì)應(yīng)的內(nèi)容。這對(duì)業(yè)務(wù)和供應(yīng)商更加友好。

擴(kuò)展能力

基于上一步展示能力的提升，對(duì)于新接入的日志如何能快速為業(yè)務(wù)及供應(yīng)商提供 B 端的頁(yè)面進(jìn)行查看，這一步將大幅節(jié)省開(kāi)發(fā)排查時(shí)間。對(duì)底層日志數(shù)據(jù)需要轉(zhuǎn)換為業(yè)務(wù)及供應(yīng)商能看懂的信息的場(chǎng)景進(jìn)行分析，并總結(jié) 7 種數(shù)據(jù)展示的方式，分別如下：

1）文本字段類：此種展示內(nèi)容最為簡(jiǎn)易，無(wú)需進(jìn)行轉(zhuǎn)換，用戶可直接理解日志記錄的內(nèi)容，前端展示的即為此內(nèi)容。

2）數(shù)據(jù)關(guān)聯(lián)類：此類日志內(nèi)容中記錄的是一個(gè) id，但實(shí)際內(nèi)容存在于另一個(gè)關(guān)聯(lián)表的數(shù)據(jù)中，例如 id：1 表示的是跟團(tuán)游，不能將 id：1 的日志展示給用戶，而需轉(zhuǎn)換為“跟團(tuán)游”，這就需要進(jìn)行一步關(guān)聯(lián) db 表的查詢轉(zhuǎn)換。

3）枚舉類：此類日志內(nèi)容記錄的是一個(gè) key 值，實(shí)際用戶能理解的是該 key 值所代表的含義，例如產(chǎn)品鉆級(jí)：0，就需要轉(zhuǎn)換為：“不分級(jí)”，這就需要關(guān)聯(lián)枚舉值的配置文件進(jìn)行查詢轉(zhuǎn)換。

4）位存儲(chǔ)類：此類日志內(nèi)容記錄的是一種計(jì)算后的結(jié)果數(shù)值。例如支付方式是通過(guò)按位與計(jì)算然后累加的結(jié)果。這種情況就需要按照一定的計(jì)算方式將其還原回去。

5）字段組合：此類日志記錄的是分散的數(shù)據(jù)，但實(shí)際需要將數(shù)據(jù)結(jié)合在一起查看才會(huì)更具業(yè)務(wù)意義，例如資源適用人檔，日志中分為最大、最小記錄。實(shí)際展示時(shí)需要結(jié)合到一起展示范圍。

6）外部接口：此類日志記錄的是一種依賴外部接口的值，例如日志記錄的是城市 id：2，代表的是上海，這就需要調(diào)用外部接口將 2 轉(zhuǎn)換為上海。

7）差異對(duì)比類：此類日志需對(duì)結(jié)果進(jìn)行解析以作對(duì)比，從而使用戶能夠更為直觀地理解。通常存在兩種情形：其一，日志內(nèi)容所記錄的即為兩份對(duì)比數(shù)據(jù)，此種情況僅需依循規(guī)則予以解析即可；其二，若日志數(shù)據(jù)屬于當(dāng)次的快照數(shù)據(jù)，則需與前一次快照數(shù)據(jù)進(jìn)行對(duì)比，以找出差異。最終達(dá)成如下圖所示的展示效果。

針對(duì)以上這些日志解析的場(chǎng)景，我們最終構(gòu)建一個(gè)日志轉(zhuǎn)換配置。對(duì)于新加入的日志，在絕大多數(shù)場(chǎng)景下，我們只需修改底層的數(shù)據(jù)提取及轉(zhuǎn)換配置，便可較為快速的配置出日志查詢頁(yè)面，提供給供應(yīng)商使用。

三、結(jié)語(yǔ)

本文詳細(xì)介紹度假商品日志平臺(tái)的演進(jìn)歷程，以及在各個(gè)階段遇到的問(wèn)題及解決方案。在整個(gè)演進(jìn)過(guò)程中，針對(duì)海量日志數(shù)據(jù)存儲(chǔ)與搜索的技術(shù)挑戰(zhàn)，我們采取一系列措施，實(shí)現(xiàn)千億級(jí)數(shù)據(jù)查詢?cè)?500ms 內(nèi)的響應(yīng)。

同時(shí)將日志系統(tǒng)開(kāi)放，將問(wèn)題查詢解決前置到供應(yīng)商及業(yè)務(wù)人員，極大降低一些數(shù)據(jù)變動(dòng)查詢需求的復(fù)雜度，減輕研發(fā)及TS同事重復(fù)性的工作。此外，我們還對(duì)日志平臺(tái)進(jìn)行橫向的擴(kuò)容配置，以支持更多的業(yè)務(wù)線可以接入。截至目前，多個(gè)業(yè)務(wù)線總數(shù)據(jù)存儲(chǔ)量達(dá)到千億級(jí)別。