作者：周濤 同程旅行數(shù)據(jù)中心大數(shù)據(jù)研發(fā)工程師

同程旅行是中國在線旅游行業(yè)的創(chuàng)新者和市場(chǎng)領(lǐng)導(dǎo)者。作為一家一站式平臺(tái)，同程旅行致力于滿足用戶旅游需求，秉持 "讓旅行更簡單、更快樂" 的使命，主要通過包括微信小程序、APP、輕應(yīng)用及其他渠道在內(nèi)的線上平臺(tái)，為用戶提供幾乎涵蓋旅游所有方面的全面創(chuàng)新產(chǎn)品和服務(wù)選擇，涵蓋交通、住宿、景點(diǎn)門票預(yù)訂及各種配套增值旅游產(chǎn)品及服務(wù)，旨在滿足用戶在整個(gè)旅途中不斷變化的旅游需要。目前，同程旅行的月活躍用戶已達(dá)到2億多人。

為了提升數(shù)據(jù)分析查詢性能，同時(shí)降低人力和硬件成本，公司的出行、住宿和公共等多個(gè)業(yè)務(wù)線都已接入并使用了 StarRocks 技術(shù)。

同程旅行有多年的 OLAP 使用經(jīng)驗(yàn)，隨著業(yè)務(wù)增長和變化，促使我們需要不斷探索更合適的組件來滿足需求。在這方面，StarRocks 作為一款優(yōu)秀的數(shù)據(jù)庫，在同程旅行的生產(chǎn)環(huán)境中得到了廣泛應(yīng)用，涵蓋實(shí)時(shí)、離線和 Customer Data Platform（顧客數(shù)據(jù)平臺(tái)，以下簡稱 CDP）等多個(gè)應(yīng)用場(chǎng)景。

本文將從同程旅行 OLAP 平臺(tái)演進(jìn)、業(yè)務(wù)痛點(diǎn)和 StarRocks 是如何解決當(dāng)前業(yè)務(wù)痛點(diǎn)這幾個(gè)部分詳細(xì)介紹 StarRocks 在同程旅行的生產(chǎn)落地實(shí)踐。

同程旅行的 OLAP 平臺(tái)演進(jìn)

隨著公司的業(yè)務(wù)變化和用戶量的增加，數(shù)據(jù)量也在不斷增加。數(shù)據(jù)分析場(chǎng)景變得越來越多樣化，對(duì)實(shí)時(shí)分析的時(shí)效性要求也更高了。為了更好地滿足這些需求，同程旅行的 OLAP 平臺(tái)也在不斷演進(jìn)，整體的發(fā)展過程大致分為三個(gè)階段：

第一階段：以 Druid+Kylin 為基礎(chǔ)構(gòu)建的數(shù)據(jù)分析體系，滿足了當(dāng)時(shí)對(duì)于離線數(shù)據(jù)分析加速的需求，但在使用過程中也逐漸暴露出 SQL 分析、聯(lián)邦查詢、BI 兼容等方面能力不足與 CUBE 運(yùn)維成本較高等一系列問題；

第二階段（引入 StarRocks 前）：在這一階段，我們采用 ClickHouse+Greenplum 支撐實(shí)時(shí)、離線業(yè)務(wù)的分析處理，在一定程度上解決了上一階段存在的問題；

第三階段：由 StarRocks 作為統(tǒng)一的 OLAP 組件，減少多組件的維護(hù)壓力。同時(shí)注重在企業(yè)內(nèi)部與相關(guān)數(shù)據(jù)平臺(tái)的集成，提升用戶使用體驗(yàn)，降低用戶組件使用和切換成本。

在說明我們?yōu)槭裁催x擇 StarRocks 作為我們新一代的 OLAP 組件前，我們需要先了解原有平臺(tái)架構(gòu)的不足：

• ClickHouse：主要用于用戶行為軌跡和訂單實(shí)時(shí)數(shù)據(jù)存儲(chǔ)和分析

• Greenplum：主要用于公司內(nèi)部的靈動(dòng)分析看板，做分析報(bào)表使用

如上圖所示，在原始架構(gòu)中，對(duì)于實(shí)時(shí)場(chǎng)景，業(yè)務(wù)數(shù)據(jù)通過 Kafka 傳入 Flink，在 Flink 中進(jìn)行清洗、打?qū)挶淼冗壿嬏幚?，之后將結(jié)果數(shù)據(jù)導(dǎo)入 ClickHouse 中；對(duì)于離線場(chǎng)景，數(shù)據(jù)統(tǒng)一存儲(chǔ)在 HDFS 中，通過 Hive+Spark 進(jìn)行清洗處理后，將結(jié)果數(shù)據(jù)傳入 Greenplum 中。

實(shí)時(shí)場(chǎng)景

主要涉及業(yè)務(wù)訂單數(shù)據(jù)，數(shù)據(jù)可以通過前端用戶埋點(diǎn)到 Kafka，或者訂閱業(yè)務(wù)訂單數(shù)據(jù)庫 Binlog，實(shí)時(shí)寫入到 MQ，然后使用 Flink SQL，關(guān)聯(lián)維度表，將數(shù)據(jù)打?qū)挘詈髮懭氲?ClickHouse 中。

離線場(chǎng)景

將實(shí)時(shí)的用戶埋點(diǎn)數(shù)據(jù)或訂單庫離線同步數(shù)據(jù)寫入到 HDFS 中，然后經(jīng)過離線調(diào)度做 ETL 數(shù)據(jù)清洗，再搬運(yùn)到 ClickHouse 或 Greenplum 中。然而，在使用過程中，我們發(fā)現(xiàn)實(shí)時(shí)和離線分離架構(gòu)存在一些問題：

• 分離架構(gòu)導(dǎo)致開發(fā)使用極度不方便，且浪費(fèi)計(jì)算存儲(chǔ)資源；

• 組件技術(shù)棧不統(tǒng)一，導(dǎo)致業(yè)務(wù)人員需要熟悉多種語法；

• 多組件造成了極高的運(yùn)維成本。

為解決在使用 ClickHouse、Greenplum 過程中遇到的性能、運(yùn)維和成本等各方面的問題，我們進(jìn)行了一些調(diào)研，開始對(duì)比和了解一些新的 OLAP 組件。接下來，我們將進(jìn)一步說明使用 ClickHouse 和 Greenplum 架構(gòu)所帶來的業(yè)務(wù)痛點(diǎn)。通過這些問題的闡述，我們可以更好地理解為何需要尋找新的解決方案。

01 ClickHouse + Greenplum 架構(gòu)帶來的業(yè)務(wù)痛點(diǎn)

目前，同程 OLAP 組件被廣泛使用，并已集成到實(shí)時(shí)開發(fā)平臺(tái)、離線開發(fā)平臺(tái)、靈動(dòng)分析、數(shù)據(jù)地圖和快速取數(shù)等多個(gè)平臺(tái)系統(tǒng)中。在業(yè)務(wù)方面，主要涉及以下三類場(chǎng)景：

1.1 實(shí)時(shí)數(shù)據(jù)分析

在使用實(shí)時(shí)數(shù)據(jù)分析的業(yè)務(wù)場(chǎng)景，我們主要針對(duì)用戶行為埋點(diǎn)、用戶實(shí)時(shí)訂單等數(shù)據(jù)進(jìn)行冷熱存儲(chǔ)。實(shí)時(shí)熱數(shù)據(jù)需要存儲(chǔ) 30 天至一年不等的時(shí)間數(shù)據(jù)，用于高性能要求的實(shí)時(shí)統(tǒng)計(jì)分析；歷史離線數(shù)據(jù)存儲(chǔ)在 HDFS。在查詢實(shí)時(shí)數(shù)據(jù)時(shí)，如果涉及多表關(guān)聯(lián)或者關(guān)聯(lián)歷史數(shù)據(jù)時(shí)，當(dāng)前組件性能無法滿足，需要提前離線清洗，導(dǎo)致數(shù)據(jù)時(shí)效性較低。

1.2 靈動(dòng)數(shù)據(jù)報(bào)表

在使用靈動(dòng)數(shù)據(jù)報(bào)表的業(yè)務(wù)場(chǎng)景，用戶在離線數(shù)倉中清洗出 DWD 或 ADS 層表，通過離線開發(fā)平臺(tái)導(dǎo)入到 Greenplum 中，然后在靈動(dòng)分析中配置數(shù)據(jù)集，以拖拉拽的形式生成看板，提供給分析決策使用。然而，在高峰時(shí)期，我們經(jīng)常遇到查詢速度慢甚至查詢超時(shí)等問題，這給業(yè)務(wù)帶來了困擾。

1.3 用戶畫像 & CDP

在用戶畫像和 CDP 的場(chǎng)景中，我們會(huì)根據(jù)用戶基本信息、消費(fèi)數(shù)據(jù)和行為數(shù)據(jù)等生成對(duì)應(yīng)標(biāo)簽數(shù)據(jù)，以創(chuàng)建用戶畫像，并進(jìn)行人群圈選和漏斗分析等。

之前我們使用了 ClickHouse 作為存儲(chǔ)分析引擎，但隨著 CDP 需求的變化，業(yè)務(wù)場(chǎng)景更加復(fù)雜，涉及到多表關(guān)聯(lián)場(chǎng)景以及寬表和 BitMap 關(guān)聯(lián)場(chǎng)景，用戶對(duì)實(shí)時(shí)分析的查詢性能提出了更高的要求。經(jīng)過測(cè)試，ClickHouse 已無法很好的滿足。

針對(duì)當(dāng)前 ClickHouse+Greenplum 體系存在的各種問題，我們開始了基于 StarRocks 構(gòu)建分析體系 3.0 階段的升級(jí)演變。

StarRocks 在同程旅行的應(yīng)用與實(shí)踐

01 選擇 StarRocks 的原因

為了解決上述問題，我們追求在新的 OLAP 組件中實(shí)現(xiàn)簡單、高速和統(tǒng)一的特點(diǎn)（包括支持聯(lián)邦分析）。為此，我們進(jìn)行了 StarRocks、ClickHouse、Greenplum 和 Presto 等 OLAP 組件的比較。我們比較了數(shù)據(jù)攝入速度、查詢性能、內(nèi)存占用率、維護(hù)成本和易用性等指標(biāo)。通過這些比較，我們希望找到最適合我們業(yè)務(wù)需求的 OLAP 組件。

下圖展示了這些組件的具體比較結(jié)果：

• 查詢性能優(yōu)異：

StarRocks 是一款分布式列式存儲(chǔ)分析數(shù)據(jù)庫，它具有非常高的查詢性能，尤其適用于實(shí)時(shí)數(shù)據(jù)分析和查詢場(chǎng)景。與ClickHouse 相比，StarRocks 在多表聯(lián)合查詢方面表現(xiàn)更出色，尤其在 Primary Key 模型方面，其在實(shí)時(shí)動(dòng)態(tài)更新和查詢性能方面都表現(xiàn)優(yōu)異。

• 維護(hù)難度低：

StarRocks 由 FE 和 BE 兩類組件組成，不依賴于第三方組件，可以開箱即用。而且，StarRocks 具有良好的可擴(kuò)展性，集群擴(kuò)縮容方便，可以根據(jù)需求動(dòng)態(tài)擴(kuò)展集群規(guī)模，靈活提高系統(tǒng)性能。此外，數(shù)據(jù)可以在節(jié)點(diǎn)之間自動(dòng)均衡，無需人為干預(yù)。

• 方便易用：

StarRocks 采用標(biāo)準(zhǔn) SQL 協(xié)議且兼容 MySQL 協(xié)議，可以輕松集成到現(xiàn)有系統(tǒng)中。此外，在實(shí)時(shí)寫入方面，官方也提供了 flink-connector-starrocks，寫入可實(shí)現(xiàn) exactly-once。另外，StarRocks 還具備方便的聯(lián)邦查詢功能，避免了數(shù)據(jù)搬運(yùn)帶來的資源消耗，從而提高了系統(tǒng)性能。

經(jīng)過多方比較，我們最終選擇了 StarRocks 作為統(tǒng)一的 OLAP 組件，并預(yù)計(jì)在未來逐步完成統(tǒng)一 OLAP 層的工作 。

02 StarRocks 的引入

同程旅行主要在以下三個(gè)場(chǎng)景中使用 StarRocks：實(shí)時(shí)數(shù)據(jù)分析、離線報(bào)表和 CDP 系統(tǒng)。

隨著 StarRocks 的接入，新的數(shù)據(jù)應(yīng)用流程架構(gòu)如下：

?

2.1 使用 StarRocks 解決當(dāng)前痛點(diǎn)

1）實(shí)時(shí)數(shù)據(jù)分析的整體時(shí)效性提升

在實(shí)時(shí)應(yīng)用場(chǎng)景中，業(yè)務(wù)數(shù)據(jù)進(jìn)入到 Kafka 或者 TurboMQ，然后通過 Flink 任務(wù)或 Flink SQL 任務(wù)進(jìn)行業(yè)務(wù)計(jì)算轉(zhuǎn)換，最終通過 flink-starrocks-connector 實(shí)時(shí)寫入到 StarRocks，進(jìn)行實(shí)時(shí)指標(biāo)統(tǒng)計(jì)或者實(shí)時(shí)數(shù)據(jù)分析。實(shí)時(shí)鏈路中不再涉及關(guān)聯(lián)打?qū)挘s短了鏈路，提升了整體的時(shí)效性。同時(shí)，StarRocks 采用星型模型組織數(shù)據(jù)，減少數(shù)據(jù)冗余存儲(chǔ)。以下是我們實(shí)際中的一個(gè) Flink SQL 案例：

?

通過將 StarRocks 集成到實(shí)時(shí)開發(fā)平臺(tái)，用戶可以輕松快速地將實(shí)時(shí)數(shù)據(jù)導(dǎo)入 StarRocks 并進(jìn)行使用。

2）離線報(bào)表查詢性能大幅提升

我們已經(jīng)成功將 StarRocks 數(shù)據(jù)源集成到靈動(dòng)分析系統(tǒng)中?，F(xiàn)在可以將 StarRocks 中的表創(chuàng)建為靈動(dòng)中的數(shù)據(jù)集，進(jìn)行分析看板配置，并實(shí)時(shí)寫入數(shù)據(jù)。此外，無需重復(fù)清洗，還可以直接進(jìn)行報(bào)表配置。由于 StarRocks 支持標(biāo)準(zhǔn) SQL 并兼容 MySQL 協(xié)議，因此系統(tǒng)集成 StarRocks 數(shù)據(jù)源非常便捷。切換引擎后，與 Presto 和 Greenplum 相比，報(bào)表查詢性能大幅提升（在某些實(shí)際場(chǎng)景中，相較于 Greenplum，查詢性能提升近一倍）。

下圖是對(duì) 14 個(gè) SQL 耗時(shí)進(jìn)行統(tǒng)計(jì)對(duì)比：

3）CDP 系統(tǒng)查詢效率提高

CDP 是一種數(shù)據(jù)管理平臺(tái)，它可以集成多方數(shù)據(jù)，幫助企業(yè)更好地了解用戶行為、喜好和需求，從而制定更加精準(zhǔn)的運(yùn)營策略。CDP 系統(tǒng)上線后，可以服務(wù)于公司各個(gè)事業(yè)部，對(duì)用戶進(jìn)行分層或保存人群進(jìn)行運(yùn)營，從而極大地提升了運(yùn)營效率并降低了運(yùn)營成本。

CDP 系統(tǒng)的具體工作流程如下：

1）數(shù)據(jù)導(dǎo)入：

當(dāng)前先知系統(tǒng)有 1000 多個(gè)歷史人群需要作為人群圈選的條件，而這 1000 多個(gè)人群數(shù)據(jù)的導(dǎo)入耗時(shí)較高，存在性能瓶頸。經(jīng)過調(diào)研，使用以下方法可以很好的解決這個(gè)問題：

• 將 String 類型的用戶 ID 轉(zhuǎn)換成 Long 類型的 oneId；

• 然后通過 Spark 任務(wù)將 oneId 轉(zhuǎn)換成 Java 代碼的 BitmapValue 對(duì)象；

• 在所有的相同 key 的 BitMap 合并后，轉(zhuǎn)換成 Base64string，這樣將相同的 key 的數(shù)據(jù)合并成一條數(shù)據(jù)，導(dǎo)入到 StarRocks 中。

經(jīng)過驗(yàn)證，采用以上方法可以大大提高數(shù)據(jù)導(dǎo)入性能，將 1.5 億條數(shù)據(jù)的 10 個(gè)任務(wù)同時(shí)導(dǎo)入的耗時(shí)從 10 分鐘以上下降到 10s 以內(nèi)，并且可以減少導(dǎo)明細(xì)數(shù)據(jù)的集群資源消耗。

?

如上圖所示，根據(jù)數(shù)據(jù)監(jiān)控顯示，紅框內(nèi)時(shí)間段是明細(xì)導(dǎo)入的網(wǎng)絡(luò)傳輸量，而其他時(shí)間段為 BitMap 合并 Base64 后的傳輸量。這兩者之間的傳輸量相差約 10 倍。針對(duì)這個(gè)問題，我們正在努力優(yōu)化導(dǎo)入代碼，并將其整理成 Demo，以便提交給社區(qū)供大家參考使用。

2）人群圈選：

接下來我們需要通過 BitMap 的函數(shù)操作，對(duì)用戶選擇的條件進(jìn)行人群圈選。通過將條件組合成 StarRocks 對(duì)應(yīng)的 BitMap 的 and、or、union 等函數(shù)，簡單的查詢可以在3秒以內(nèi)得出結(jié)果。即使是復(fù)雜的（例如涉及寬表與多個(gè) BitMap 表的關(guān)聯(lián)查詢）且數(shù)據(jù)量大的查詢，也都可以在 10 秒以內(nèi)得到結(jié)果。

3）人群保存：

這一步將圈選的結(jié)果人群 BitMap 轉(zhuǎn)換成一個(gè)明細(xì)表，然后再通過 export 語句方式，將表的數(shù)據(jù)導(dǎo)入 HDFS 進(jìn)行輸出應(yīng)用。

下述是實(shí)際應(yīng)用中的人群分層遷移?；鶊D的 SQL 示例：

?

對(duì)應(yīng)結(jié)果圖：

?

該 SQL 中包含了 BitMap 與普通寬表的關(guān)聯(lián)操作，以及三個(gè)億級(jí)別大表的關(guān)聯(lián)操作，整體可以在5至10秒內(nèi)計(jì)算完成。

未來規(guī)劃

• 更多業(yè)務(wù)場(chǎng)景推廣落地

在公司內(nèi)，我們將繼續(xù)擴(kuò)大和推廣 StarRocks 的使用，以替換其他業(yè)務(wù)中遺留的 ClickHouse 和 Greenplum 組件，減少多組件的維護(hù)壓力。同時(shí)注重在企業(yè)內(nèi)部與相關(guān)數(shù)據(jù)平臺(tái)的集成，提升用戶使用體驗(yàn)，降低用戶組件使用和切換成本。

• 上云

將 StarRocks 部署在公司的 Kubernetes 私有云中，以提高集群的擴(kuò)展性和靈活性，并且可以依賴于 Kubernetes 的容錯(cuò)機(jī)制，自動(dòng)監(jiān)測(cè)和替換故障節(jié)點(diǎn)，提升集群可靠性和穩(wěn)定性。目前，我們已經(jīng)完成了開發(fā)，進(jìn)行到了測(cè)試驗(yàn)證階段。后續(xù)我們也將持續(xù)跟進(jìn)測(cè)試 StarRocks 提供的云原生能力。

• 存算分離特性的使用

在離線報(bào)表應(yīng)用中，我們計(jì)劃測(cè)試使用即將推出的 3.x 版本。根據(jù)其存算分離的能力，在不降低查詢性能的條件下，可以大大減少離線數(shù)據(jù)同步的工作量。

• 與社區(qū)共贏

我們將持續(xù)保持與社區(qū)的溝通，積極地將使用體驗(yàn)和性能測(cè)試反饋社區(qū)。通過與社區(qū)的合作，實(shí)現(xiàn)雙贏的目標(biāo)。文章來源地址http://www.zghlxwxcb.cn/news/detail-487474.html

到了這里，關(guān)于降本增效，StarRocks 在同程旅行的實(shí)踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！