站長資訊網(wǎng)順豐科技有限公司隸屬于順豐速運集團(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ī)藥、商業(yè)、金融、國際等業(yè)務(wù)領(lǐng)域。
順豐大數(shù)據(jù)平臺簡介
早期順豐在OLAP層主要使用了Elasticsearch、ClickHouse、Presto、Kylin這四個組件。
Elasticsearch在順豐場景使用的最多，倒排索引的機(jī)制下，檢索效率高，整體運維也比較方便。目前在日志類、條件檢索類的場景用的比較多。目前版本以Elasticsearch 5.4為主，新接入的業(yè)務(wù)使用了7.6版本，基于標(biāo)準(zhǔn)版本進(jìn)行了一些定制化的開發(fā)工作，包含跨機(jī)房備份方案、K8S容器化部署、數(shù)據(jù)服務(wù)平臺等。
ClickHouse是這兩年引入，用于一些重點的運單場景，進(jìn)行了K8S集群化改造，很好的滿足了資源快速交付的需求。
Presto在順豐也使用的很多，主要用于Hive數(shù)據(jù)的查詢。我們針對Presto進(jìn)行了Yarn集群部署的改造，很好地用到了Yarn隊列的資源。
Kylin使用的相對較少，目前只在財經(jīng)線的幾個業(yè)務(wù)上作為試點。
當(dāng)前痛點及產(chǎn)品選型
順豐通過內(nèi)部容器化建設(shè)、組件深度定制、組件平臺的建設(shè)，組件的一些突出問題、共性問題已經(jīng)解決，但是還有一些難以解決的組件自身的痛點問題。我們對這些組件的問題進(jìn)行了一些總結(jié)：
一、多版本多框架并存、基礎(chǔ)組件升級難。由于歷史原因，同時存在多個版本在線上運行，但因為多個版本的不兼容性，用戶業(yè)務(wù)在線上穩(wěn)定運轉(zhuǎn)，主動切換意愿不高，導(dǎo)致版本難以統(tǒng)一，組件升級方案復(fù)雜、操作風(fēng)險高，也是組件升級難的另外一方面原因。
二、用戶選用組件容易一刀切。在實際的應(yīng)用中，有很多用戶進(jìn)行大數(shù)據(jù)選型時，缺乏對組件本身的了解，導(dǎo)致大量的使用不合理的情況，如使用ES做大量的聚合計算、使用Presto做報表、使用Kafka做批量交互等。
三、使用難/運維難。各種組件的使用/運維不盡相同，需要用戶和運維都要具備相應(yīng)的專業(yè)知識。
OLAP產(chǎn)品選型
目前OLAP場景，各家百花齊放。可以選擇的組件很多，選擇合適的組件需要方法論的支持。目前我們順豐在選型上，遵照了以下原則：
·組件的核心能力要夠強(qiáng)，短板不明顯。
·組件交付的版本工程質(zhì)量高。
·核心訴求/大的生產(chǎn)環(huán)境的問題響應(yīng)足夠及時。
·可塑性強(qiáng)，未來長期發(fā)展?jié)摿Υ蟆?/p>
·運維的門檻要低。
我們針對性進(jìn)行了相應(yīng)的評估，評估包含下面一些方面：
·不同產(chǎn)品之間使用標(biāo)準(zhǔn)測試集的橫向評估，主要選取評估的組件有ClickHouse、Presto、Apache Doris、StarRocks。
·中等業(yè)務(wù)規(guī)模的業(yè)務(wù)體驗：10億規(guī)模的契合度高的場景，帶Join。
·公司內(nèi)典型場景的需求評測：百億規(guī)模的運單場景的典型SQL等。
·重點功能項的評測：如大數(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)大的運維管理系統(tǒng)，用戶開發(fā)、運維的功能很全面。
StarRocks應(yīng)用實踐
整體目標(biāo)
#FormatImgID_1#
順豐引入StarRocks的目標(biāo)是：使StarRocks成為一站式的大數(shù)據(jù)分析平臺的底座。從數(shù)據(jù)的源頭來看，包含三條數(shù)據(jù)流：
·實時數(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ù)平臺臨時查詢導(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è)務(wù)已經(jīng)完成開發(fā)，正在灰度運營中。
·其他幾個細(xì)分業(yè)務(wù)領(lǐng)域也完成了接入，如財務(wù)、快運、國際等。
·其他也有一些業(yè)務(wù)正在接入、體驗中。受限于前期的機(jī)器采購預(yù)算未申報，接入節(jié)奏不算快。
統(tǒng)一的OLAP平臺能力建設(shè)
·已經(jīng)可以進(jìn)行BI工具平臺打通。
·全鏈路的多個集群環(huán)境的搭建，包含測試集群/預(yù)發(fā)布集群/生產(chǎn)公共集群/容災(zāi)公共集群/重點業(yè)務(wù)私有集群。
·大數(shù)據(jù)平臺DataX集成、Flink/Spark Connector的集成正在開發(fā)/測試中。
·中臺的數(shù)據(jù)服務(wù)、數(shù)據(jù)字典等正在進(jìn)行相關(guān)的設(shè)計，目前也和鼎石團(tuán)隊在一起看如何拿到元數(shù)據(jù)。
實踐案例
在物流行業(yè)，運單場景是最典型的場景。這里給大家分享一個順豐最大體量級別的運單場景。這個場景原來是在Oracle上單機(jī)運行，更新頻繁、對時效要求高。業(yè)務(wù)上存在著許多的痛點，業(yè)務(wù)數(shù)據(jù)成倍增長導(dǎo)致原來系統(tǒng)已經(jīng)不堪負(fù)荷，主要表現(xiàn)為可用性不高、速度變慢、數(shù)據(jù)多份、時效性不高等。業(yè)務(wù)側(cè)的訴求是希望接入StarRocks以后，性能和時效性大幅度提升，能夠在現(xiàn)有業(yè)務(wù)翻倍雙11場景下的撐得住，提供高可用的方案，能夠快速擴(kuò)容等等。
需求澄清
接到這個任務(wù)后，我們梳理了一遍需求：
·硬性指標(biāo)，雙11要滿足單行數(shù)據(jù)2k左右大寬表、8萬TPS寫入訴求。
·業(yè)務(wù)峰值效應(yīng)明細(xì)，未來還會有大的增長空間。
·數(shù)據(jù)保存三個月以內(nèi)的數(shù)據(jù)，目前數(shù)據(jù)量在百億級別以內(nèi)。
·舊業(yè)務(wù)改造需要考慮已有BI平臺工具的2K+報表的平滑過渡。
·數(shù)據(jù)導(dǎo)出需求，供業(yè)務(wù)側(cè)做二次分析。
數(shù)據(jù)導(dǎo)入
針對需求，我們做了數(shù)據(jù)導(dǎo)入和查詢兩個方面的方案設(shè)計和優(yōu)化。從數(shù)據(jù)導(dǎo)入來看，核心問題是提升單機(jī)數(shù)據(jù)寫入性能。
·表設(shè)計按照日期分區(qū)，按照運單號分桶，第一個問題就是如何進(jìn)行數(shù)據(jù)分布的設(shè)計，從使用經(jīng)驗來看，Kafka分區(qū)個數(shù)與StarRocks的BE節(jié)點個數(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ù)失敗，需要每個字段指定Json位置。
·StarRocks導(dǎo)入能力與單條記錄的字節(jié)數(shù)、合并效率有很大關(guān)系。為了更高的導(dǎo)入性能，我們把大寬表的按列分拆為兩個，更新少的數(shù)據(jù)放入一個表(這里叫公表)、更新頻繁的放到另外一個表(私表)，多表的導(dǎo)入的任務(wù)數(shù)會增加。
·機(jī)器選型上，由于寫入頻繁，我們升級了單機(jī)6盤到12盤，未來考慮使用ssd;StarRocks向量化優(yōu)化深入，我們升級了40核到80核，提升QPS。
·系統(tǒng)按照日期進(jìn)行分區(qū)，由于數(shù)據(jù)來源于多個業(yè)務(wù)系統(tǒng)，存在分區(qū)時間沒有的情況，需要反查，初期方案是從StarRocks跨區(qū)查，效率較低，后面采用了Flink的RocksDB方案。
·跨機(jī)器跨磁盤的副本均衡問題：由于機(jī)器down機(jī)或者增刪磁盤造成的，目前跨機(jī)器的副本均衡已經(jīng)在最新版本解決，跨磁盤的副本均衡期待在后續(xù)版本解決。
·版本數(shù)問題：如果版本數(shù)過多會導(dǎo)致BE節(jié)點暫停從Kafka消費，導(dǎo)致數(shù)據(jù)導(dǎo)入效率下降。這里可以通過調(diào)整Kafka消費時間、合理設(shè)置分片、分區(qū)個數(shù)、副本個數(shù)減少版本數(shù)。
查詢
·為解決原有系統(tǒng)的2K+報表的平滑遷移問題，由于拆成了兩個表，新增加了一個視圖，保持跟原有表結(jié)構(gòu)一致，降低遷移成本。
·跟BI平臺合作，做了一些查詢并行度限制核數(shù)據(jù)緩存策略，提高系統(tǒng)的穩(wěn)定性。
為了提高的查詢性能，做了一些針對性的優(yōu)化工作：
·對于最常用的查詢條件字段，加到key列，如客戶的公司等。
·通過增加布隆過濾器索引提升查詢效率。
·大表間的Join，調(diào)整Join的順序(未開啟CBO)。
·兩表Join時，增加冗余字段并放在ON條件里面使條件能夠下推，減少掃描量。
·問題：為了提升查詢性能，將查詢條件中的非key列的加到了key列，對于此非key列的變更變成了刪除+插入兩步操作，可能會造成未合并的版本數(shù)累積。
目前系統(tǒng)的整體數(shù)據(jù)來源于多個業(yè)務(wù)系統(tǒng)，通過Flink進(jìn)行計算后寫入一個新的Kafka，StarRock通過Routine Load從新的Kafka拉取數(shù)據(jù)，很好的實現(xiàn)了Exactly Once語義，各個系統(tǒng)的耦合度很低，可用度高。
為了更高的可用性，我們采用了雙機(jī)房、雙寫、雙活的方案。通過兩種域名配置方式以負(fù)載均衡方式給BI工具和業(yè)務(wù)APP使用。業(yè)務(wù)APP通過域名、JDBC LB方案具有更高可用性，機(jī)器遷移、down機(jī)無影響。
這里是我們具體的表設(shè)計：
1)聚合表模型、同時支持明細(xì)表和物化視圖。
2)按照使用更新頻度分成兩個表，提高導(dǎo)入任務(wù)個數(shù)。
3)按照寄件日期分區(qū)，運單號分桶。
4)通過replace_if_not_null支持部分字段更新。
5)變化不頻繁字段加到key列，并兩個表冗余，提高查詢效率。
6)兩表按照CollocateJoin提升Join效率。
7)按照日期動態(tài)分區(qū)，支持?jǐn)?shù)據(jù)淘汰。
8)查詢條件增加布隆過濾器索引，提升檢索效率。
在適應(yīng)性更高的場景、如不更新、數(shù)據(jù)量10億以下等，StarRocks更加得心應(yīng)手，性能強(qiáng)大。這里是目前順豐接入的其他一些非運單明細(xì)的場景，StarRocks都有良好表現(xiàn)，如原財務(wù)系統(tǒng)，時常會出現(xiàn)告警。接入StarRocks以后，使用1/3的資源消耗即可良好的運行。
后續(xù)規(guī)劃和社區(qū)共建
我們后續(xù)在OLAP方面的規(guī)劃如下：
·ClickHouse的新業(yè)務(wù)接入已基本停止。
·明年準(zhǔn)備大規(guī)模接入StarRocks，已經(jīng)全面啟動相關(guān)的機(jī)器采購預(yù)算申請，運單級別的業(yè)務(wù)系統(tǒng)已經(jīng)有幾個規(guī)劃會進(jìn)行改造接入。
·另外在云上數(shù)倉項目上，期待繼續(xù)深入使用StarRocks。
目前StarRocks已經(jīng)源代碼開放，面向未來，StarRocks有更多的可能性。順豐也有基于StarRocks建設(shè)統(tǒng)一、全場景、極速OLAP分析平臺的訴求：
·從終端用戶來看：建設(shè)一站式的開發(fā)/運營平臺。
·從資源管理來看：達(dá)到serverless的管理目標(biāo)、可衡量。
·從運維層面來看：更高可用性、更多的工具。
·從數(shù)據(jù)模型來看：更多的場景化模型支持。
·從統(tǒng)一查詢平臺：各種數(shù)據(jù)庫引擎的更好支持。
·從生態(tài)來看：深入各個周邊場景提供更多能力。
我們愿意與StarRocks社區(qū)一起，攜手共進(jìn)，為社區(qū)貢獻(xiàn)我們的一份力量。(作者：嚴(yán)向東，順豐科技大數(shù)據(jù)平臺架構(gòu)師)
特別提醒：本網(wǎng)信息來自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實，對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。
