順豐科技有限公司隸屬于順豐速運(yùn)集團(tuán)，成立于2009年，致力于構(gòu)建智慧大腦，建設(shè)智慧物流服務(wù)。順豐科技經(jīng)過多年的自主研發(fā)，已經(jīng)建成大數(shù)據(jù)整體生態(tài)系統(tǒng)，完成數(shù)據(jù)采集與同步、數(shù)據(jù)存儲與整合、數(shù)據(jù)分析與挖掘、機(jī)器學(xué)習(xí)、數(shù)據(jù)可視化等平臺的構(gòu)建。在建設(shè)底盤平臺的基礎(chǔ)上，結(jié)合大數(shù)據(jù)、區(qū)塊鏈、物聯(lián)網(wǎng)與人工智能技術(shù)，廣泛應(yīng)用于速運(yùn)、倉儲、冷運(yùn)、醫(yī)藥、商業(yè)、金融、國際等業(yè)務(wù)領(lǐng)域。

　　　　順豐大數(shù)據(jù)平臺簡介

　　早期順豐在OLAP層主要使用了Elasticsearch、ClickHouse、Presto、Kylin這四個(gè)組件。

　　Elasticsearch在順豐場景使用的最多，倒排索引的機(jī)制下，檢索效率高，整體運(yùn)維也比較方便。目前在日志類、條件檢索類的場景用的比較多。目前版本以Elasticsearch 5.4為主，新接入的業(yè)務(wù)使用了7.6版本，基于標(biāo)準(zhǔn)版本進(jìn)行了一些定制化的開發(fā)工作，包含跨機(jī)房備份方案、K8S容器化部署、數(shù)據(jù)服務(wù)平臺等。

　　ClickHouse是這兩年引入，用于一些重點(diǎn)的運(yùn)單場景，進(jìn)行了K8S集群化改造，很好的滿足了資源快速交付的需求。

　　Presto在順豐也使用的很多，主要用于Hive數(shù)據(jù)的查詢。我們針對Presto進(jìn)行了Yarn集群部署的改造，很好地用到了Yarn隊(duì)列的資源。

　　Kylin使用的相對較少，目前只在財(cái)經(jīng)線的幾個(gè)業(yè)務(wù)上作為試點(diǎn)。

　　　　當(dāng)前痛點(diǎn)及產(chǎn)品選型

　　順豐通過內(nèi)部容器化建設(shè)、組件深度定制、組件平臺的建設(shè)，組件的一些突出問題、共性問題已經(jīng)解決，但是還有一些難以解決的組件自身的痛點(diǎn)問題。我們對這些組件的問題進(jìn)行了一些總結(jié)：

　　一、多版本多框架并存、基礎(chǔ)組件升級難。由于歷史原因，同時(shí)存在多個(gè)版本在線上運(yùn)行，但因?yàn)槎鄠€(gè)版本的不兼容性，用戶業(yè)務(wù)在線上穩(wěn)定運(yùn)轉(zhuǎn)，主動切換意愿不高，導(dǎo)致版本難以統(tǒng)一，組件升級方案復(fù)雜、操作風(fēng)險(xiǎn)高，也是組件升級難的另外一方面原因。

　　二、用戶選用組件容易一刀切。在實(shí)際的應(yīng)用中，有很多用戶進(jìn)行大數(shù)據(jù)選型時(shí)，缺乏對組件本身的了解，導(dǎo)致大量的使用不合理的情況，如使用ES做大量的聚合計(jì)算、使用Presto做報(bào)表、使用Kafka做批量交互等。

　　三、使用難/運(yùn)維難。各種組件的使用/運(yùn)維不盡相同，需要用戶和運(yùn)維都要具備相應(yīng)的專業(yè)知識。

　　　　OLAP產(chǎn)品選型

　　目前OLAP場景，各家百花齊放。可以選擇的組件很多，選擇合適的組件需要方法論的支持。目前我們順豐在選型上，遵照了以下原則：

　　·組件的核心能力要夠強(qiáng)，短板不明顯。

　　·組件交付的版本工程質(zhì)量高。

　　·核心訴求/大的生產(chǎn)環(huán)境的問題響應(yīng)足夠及時(shí)。

　　·可塑性強(qiáng)，未來長期發(fā)展?jié)摿Υ蟆?/p>

　　·運(yùn)維的門檻要低。

　　我們針對性進(jìn)行了相應(yīng)的評估，評估包含下面一些方面：

　　·不同產(chǎn)品之間使用標(biāo)準(zhǔn)測試集的橫向評估，主要選取評估的組件有ClickHouse、Presto、Apache Doris、StarRocks。

　　·中等業(yè)務(wù)規(guī)模的業(yè)務(wù)體驗(yàn)：10億規(guī)模的契合度高的場景，帶Join。

　　·公司內(nèi)典型場景的需求評測：百億規(guī)模的運(yùn)單場景的典型SQL等。

　　·重點(diǎn)功能項(xiàng)的評測：如大數(shù)據(jù)數(shù)據(jù)導(dǎo)入、大表Join、failover等。

　　從評估的結(jié)果來看，對于StarRocks我們整體還是比較滿意的，最終我們選擇了StarRocks，基于如下的考慮：現(xiàn)階段StarRocks性能、穩(wěn)定性占優(yōu);StarRocks處于高速發(fā)展期，能夠提供專業(yè)的技術(shù)支持、生產(chǎn)環(huán)境問題/需求的快速反應(yīng);StarRocks擁有強(qiáng)大的運(yùn)維管理系統(tǒng)，用戶開發(fā)、運(yùn)維的功能很全面。

　　　　StarRocks應(yīng)用實(shí)踐

　　　　整體目標(biāo)

　　#FormatImgID_1#

　　順豐引入StarRocks的目標(biāo)是：使StarRocks成為一站式的大數(shù)據(jù)分析平臺的底座。從數(shù)據(jù)的源頭來看，包含三條數(shù)據(jù)流：

　　·實(shí)時(shí)數(shù)據(jù)、離線數(shù)據(jù)導(dǎo)入，通過StarRocks原生的幾種Load任務(wù)完成。

　　·通過Flink/Spark的Connector完成數(shù)據(jù)ETL。

　　·Hadoop、Elasticsearch、MySQL等環(huán)境中的數(shù)據(jù)，作為數(shù)據(jù)源，通過StarRocks外表導(dǎo)入。

　　從數(shù)據(jù)使用的角度來看，通過JDBC接口給數(shù)據(jù)使用者提供服務(wù)，主要的數(shù)據(jù)使用者包含：

　　·組件開發(fā)/組件維護(hù)，目前順豐環(huán)境對應(yīng)的是大數(shù)據(jù)組件平臺。

　　·BI工具平臺，在順豐內(nèi)部叫作豐景臺。

　　·數(shù)據(jù)中臺，如數(shù)據(jù)服務(wù)、數(shù)據(jù)字典等。

　　·業(yè)務(wù)平臺的訪問，比如數(shù)據(jù)平臺臨時(shí)查詢導(dǎo)數(shù)的平臺，及其他一些業(yè)務(wù)平臺。

　　為了應(yīng)對統(tǒng)一的大數(shù)據(jù)分析底盤的訴求，需要一些場景化的能力，這里列一些我們主要的訴求：

　　·替代Presto，在BI工具平臺快速查詢Hive數(shù)據(jù)。

　　·替代ElastcSearch、ClickHouse、Kylin做OLAP明細(xì)、匯總數(shù)據(jù)的存儲。

　　·較好的數(shù)據(jù)導(dǎo)出能力，便于業(yè)務(wù)做二次分析。

　　　　StarRocks應(yīng)用進(jìn)展

　　　　業(yè)務(wù)接入

　　·運(yùn)單級別的業(yè)務(wù)已經(jīng)完成開發(fā)，正在灰度運(yùn)營中。

　　·其他幾個(gè)細(xì)分業(yè)務(wù)領(lǐng)域也完成了接入，如財(cái)務(wù)、快運(yùn)、國際等。

　　·其他也有一些業(yè)務(wù)正在接入、體驗(yàn)中。受限于前期的機(jī)器采購預(yù)算未申報(bào)，接入節(jié)奏不算快。

　　　　統(tǒng)一的OLAP平臺能力建設(shè)

　　·已經(jīng)可以進(jìn)行BI工具平臺打通。

　　·全鏈路的多個(gè)集群環(huán)境的搭建，包含測試集群/預(yù)發(fā)布集群/生產(chǎn)公共集群/容災(zāi)公共集群/重點(diǎn)業(yè)務(wù)私有集群。

　　·大數(shù)據(jù)平臺DataX集成、Flink/Spark Connector的集成正在開發(fā)/測試中。

　　·中臺的數(shù)據(jù)服務(wù)、數(shù)據(jù)字典等正在進(jìn)行相關(guān)的設(shè)計(jì)，目前也和鼎石團(tuán)隊(duì)在一起看如何拿到元數(shù)據(jù)。

　　　　實(shí)踐案例

　　在物流行業(yè)，運(yùn)單場景是最典型的場景。這里給大家分享一個(gè)順豐最大體量級別的運(yùn)單場景。這個(gè)場景原來是在Oracle上單機(jī)運(yùn)行，更新頻繁、對時(shí)效要求高。業(yè)務(wù)上存在著許多的痛點(diǎn)，業(yè)務(wù)數(shù)據(jù)成倍增長導(dǎo)致原來系統(tǒng)已經(jīng)不堪負(fù)荷，主要表現(xiàn)為可用性不高、速度變慢、數(shù)據(jù)多份、時(shí)效性不高等。業(yè)務(wù)側(cè)的訴求是希望接入StarRocks以后，性能和時(shí)效性大幅度提升，能夠在現(xiàn)有業(yè)務(wù)翻倍雙11場景下的撐得住，提供高可用的方案，能夠快速擴(kuò)容等等。

　　　　需求澄清

　　接到這個(gè)任務(wù)后，我們梳理了一遍需求：

　　·硬性指標(biāo)，雙11要滿足單行數(shù)據(jù)2k左右大寬表、8萬TPS寫入訴求。

　　·業(yè)務(wù)峰值效應(yīng)明細(xì)，未來還會有大的增長空間。

　　·數(shù)據(jù)保存三個(gè)月以內(nèi)的數(shù)據(jù)，目前數(shù)據(jù)量在百億級別以內(nèi)。

　　·舊業(yè)務(wù)改造需要考慮已有BI平臺工具的2K+報(bào)表的平滑過渡。

　　·數(shù)據(jù)導(dǎo)出需求，供業(yè)務(wù)側(cè)做二次分析。

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

　　針對需求，我們做了數(shù)據(jù)導(dǎo)入和查詢兩個(gè)方面的方案設(shè)計(jì)和優(yōu)化。從數(shù)據(jù)導(dǎo)入來看，核心問題是提升單機(jī)數(shù)據(jù)寫入性能。

　　·表設(shè)計(jì)按照日期分區(qū)，按照運(yùn)單號分桶，第一個(gè)問題就是如何進(jìn)行數(shù)據(jù)分布的設(shè)計(jì)，從使用經(jīng)驗(yàn)來看，Kafka分區(qū)個(gè)數(shù)與StarRocks的BE節(jié)點(diǎn)個(gè)數(shù)、導(dǎo)數(shù)任務(wù)并行度要一致，導(dǎo)入效率才最高。

　　·由于源頭數(shù)據(jù)來源于不同的業(yè)務(wù)系統(tǒng)加工成大寬表，需要通過配置字段的replace_if_not_null支持部分字段更新，另外為了避免Json數(shù)據(jù)字段增刪導(dǎo)致導(dǎo)數(shù)失敗，需要每個(gè)字段指定Json位置。

　　·StarRocks導(dǎo)入能力與單條記錄的字節(jié)數(shù)、合并效率有很大關(guān)系。為了更高的導(dǎo)入性能，我們把大寬表的按列分拆為兩個(gè)，更新少的數(shù)據(jù)放入一個(gè)表(這里叫公表)、更新頻繁的放到另外一個(gè)表(私表)，多表的導(dǎo)入的任務(wù)數(shù)會增加。

　　·機(jī)器選型上，由于寫入頻繁，我們升級了單機(jī)6盤到12盤，未來考慮使用ssd;StarRocks向量化優(yōu)化深入，我們升級了40核到80核，提升QPS。

　　·系統(tǒng)按照日期進(jìn)行分區(qū)，由于數(shù)據(jù)來源于多個(gè)業(yè)務(wù)系統(tǒng)，存在分區(qū)時(shí)間沒有的情況，需要反查，初期方案是從StarRocks跨區(qū)查，效率較低，后面采用了Flink的RocksDB方案。

　　·跨機(jī)器跨磁盤的副本均衡問題：由于機(jī)器down機(jī)或者增刪磁盤造成的，目前跨機(jī)器的副本均衡已經(jīng)在最新版本解決，跨磁盤的副本均衡期待在后續(xù)版本解決。

　　·版本數(shù)問題：如果版本數(shù)過多會導(dǎo)致BE節(jié)點(diǎn)暫停從Kafka消費(fèi)，導(dǎo)致數(shù)據(jù)導(dǎo)入效率下降。這里可以通過調(diào)整Kafka消費(fèi)時(shí)間、合理設(shè)置分片、分區(qū)個(gè)數(shù)、副本個(gè)數(shù)減少版本數(shù)。

　　　　查詢

　　·為解決原有系統(tǒng)的2K+報(bào)表的平滑遷移問題，由于拆成了兩個(gè)表，新增加了一個(gè)視圖，保持跟原有表結(jié)構(gòu)一致，降低遷移成本。

　　·跟BI平臺合作，做了一些查詢并行度限制核數(shù)據(jù)緩存策略，提高系統(tǒng)的穩(wěn)定性。

　　為了提高的查詢性能，做了一些針對性的優(yōu)化工作：

　　·對于最常用的查詢條件字段，加到key列，如客戶的公司等。

　　·通過增加布隆過濾器索引提升查詢效率。

　　·大表間的Join，調(diào)整Join的順序(未開啟CBO)。

　　·兩表Join時(shí)，增加冗余字段并放在ON條件里面使條件能夠下推，減少掃描量。

　　·問題：為了提升查詢性能，將查詢條件中的非key列的加到了key列，對于此非key列的變更變成了刪除+插入兩步操作，可能會造成未合并的版本數(shù)累積。

　　目前系統(tǒng)的整體數(shù)據(jù)來源于多個(gè)業(yè)務(wù)系統(tǒng)，通過Flink進(jìn)行計(jì)算后寫入一個(gè)新的Kafka，StarRock通過Routine Load從新的Kafka拉取數(shù)據(jù)，很好的實(shí)現(xiàn)了Exactly Once語義，各個(gè)系統(tǒng)的耦合度很低，可用度高。

　　為了更高的可用性，我們采用了雙機(jī)房、雙寫、雙活的方案。通過兩種域名配置方式以負(fù)載均衡方式給BI工具和業(yè)務(wù)APP使用。業(yè)務(wù)APP通過域名、JDBC LB方案具有更高可用性，機(jī)器遷移、down機(jī)無影響。

　　這里是我們具體的表設(shè)計(jì)：

　　1)聚合表模型、同時(shí)支持明細(xì)表和物化視圖。

　　2)按照使用更新頻度分成兩個(gè)表，提高導(dǎo)入任務(wù)個(gè)數(shù)。

　　3)按照寄件日期分區(qū)，運(yùn)單號分桶。

　　4)通過replace_if_not_null支持部分字段更新。

　　5)變化不頻繁字段加到key列，并兩個(gè)表冗余，提高查詢效率。

　　6)兩表按照CollocateJoin提升Join效率。

　　7)按照日期動態(tài)分區(qū)，支持?jǐn)?shù)據(jù)淘汰。

　　8)查詢條件增加布隆過濾器索引，提升檢索效率。

　　在適應(yīng)性更高的場景、如不更新、數(shù)據(jù)量10億以下等，StarRocks更加得心應(yīng)手，性能強(qiáng)大。這里是目前順豐接入的其他一些非運(yùn)單明細(xì)的場景，StarRocks都有良好表現(xiàn)，如原財(cái)務(wù)系統(tǒng)，時(shí)常會出現(xiàn)告警。接入StarRocks以后，使用1/3的資源消耗即可良好的運(yùn)行。

　　　　后續(xù)規(guī)劃和社區(qū)共建

　　我們后續(xù)在OLAP方面的規(guī)劃如下：

　　·ClickHouse的新業(yè)務(wù)接入已基本停止。

　　·明年準(zhǔn)備大規(guī)模接入StarRocks，已經(jīng)全面啟動相關(guān)的機(jī)器采購預(yù)算申請，運(yùn)單級別的業(yè)務(wù)系統(tǒng)已經(jīng)有幾個(gè)規(guī)劃會進(jìn)行改造接入。

　　·另外在云上數(shù)倉項(xiàng)目上，期待繼續(xù)深入使用StarRocks。

　　目前StarRocks已經(jīng)源代碼開放，面向未來，StarRocks有更多的可能性。順豐也有基于StarRocks建設(shè)統(tǒng)一、全場景、極速OLAP分析平臺的訴求：

　　·從終端用戶來看：建設(shè)一站式的開發(fā)/運(yùn)營平臺。

　　·從資源管理來看：達(dá)到serverless的管理目標(biāo)、可衡量。

　　·從運(yùn)維層面來看：更高可用性、更多的工具。

　　·從數(shù)據(jù)模型來看：更多的場景化模型支持。

　　·從統(tǒng)一查詢平臺：各種數(shù)據(jù)庫引擎的更好支持。

　　·從生態(tài)來看：深入各個(gè)周邊場景提供更多能力。

　　我們愿意與StarRocks社區(qū)一起，攜手共進(jìn)，為社區(qū)貢獻(xiàn)我們的一份力量。(作者：嚴(yán)向東，順豐科技大數(shù)據(jù)平臺架構(gòu)師)

特別提醒：本網(wǎng)信息來自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時(shí)聯(lián)系我們，本站將會在24小時(shí)內(nèi)處理完畢。