作者簡介

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

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

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

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

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

一、發(fā)展軌跡

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

2019年以前：單表日志

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

2020年~2022年：平臺化

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

2023年~2024年：開放

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

二、演進(jìn)過程

2.1 V1.0 DB單表存儲

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

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

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

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

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

• 擴(kuò)展性差
  

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

2.2 V2.0 平臺化

2.2.1 技術(shù)選型

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

ES+Hbase

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

MongoDB

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

ClickHouse

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

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

2.2.2 整體架構(gòu)

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

2.2.3 RowKey設(shè)計

RowKey設(shè)計原則：

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

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

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

簡潔性：減少存儲空間及提高查詢性能；

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

對于線路商品日志，對于直接可讀性要求不高，查詢的場景我們是從ES中先查出RowKey，再用RowKey去hbase查詢?nèi)罩驹?，整個過程RowKey是人工不可見的，結(jié)合我們實際的場景，線路商品數(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}：時間戳

2.2.4 擴(kuò)展

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

寫入流程

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

查詢流程

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

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

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

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

2.3 V3.0賦能

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

存儲能力

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

搜索能力

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

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

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

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

2）便于數(shù)據(jù)管理?？梢园凑諘r間刪除舊的索引，從而節(jié)省存儲空間。

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

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

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

基于以上存儲能力與搜索能力的擴(kuò)展提升之后，我們在日志配置中心定制了【業(yè)務(wù)線<-->日志集群】的路由規(guī)則，來決定接入的其它業(yè)務(wù)線日志最終存儲的日志集群，提供了更加靈活與具有彈性的業(yè)務(wù)線接入能力。

2.3.2 供應(yīng)商賦能

展示能力

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

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

擴(kuò)展能力

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

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

2）數(shù)據(jù)關(guān)聯(lián)類：此類日志內(nèi)容中記錄的是一個 id，但實際內(nèi)容存在于另一個關(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)容記錄的是一個 key 值，實際用戶能理解的是該 key 值所代表的含義，例如產(chǎn)品鉆級：0，就需要轉(zhuǎn)換為：“不分級”，這就需要關(guān)聯(lián)枚舉值的配置文件進(jìn)行查詢轉(zhuǎn)換。

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

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

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

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

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

三、結(jié)語

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

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