順豐科技有限公司隸屬于順豐速運集團，成立于2009年，致力于構(gòu)建智慧大腦，建設(shè)智慧物流服務(wù)。順豐科技經(jīng)過多年的自主研發(fā)，已經(jīng)建成大數(shù)據(jù)整體生態(tài)系統(tǒng)，完成數(shù)據(jù)采集與同步、數(shù)據(jù)存儲與整合、數(shù)據(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在順豐場景使用的最多，倒排索引的機制下，檢索效率高，整體運維也比較方便。目前在日志類、條件檢索類的場景用的比較多。目前版本以Elasticsearch 5.4為主，新接入的業(yè)務(wù)使用了7.6版本，基于標準版本進行了一些定制化的開發(fā)工作，包含跨機房備份方案、K8S容器化部署、數(shù)據(jù)服務(wù)平臺等。

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

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

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

　　　　當前痛點及產(chǎn)品選型

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

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

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

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

　　　　OLAP產(chǎn)品選型

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

　　·組件的核心能力要夠強，短板不明顯。

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

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

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

　　·運維的門檻要低。

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

　　·不同產(chǎ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擁有強大的運維管理系統(tǒng)，用戶開發(fā)、運維的功能很全面。

　　　　StarRocks應(yīng)用實踐

　　　　整體目標

　　#FormatImgID_1#

　　順豐引入StarRocks的目標是：使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ā)/組件維護，目前順豐環(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明細、匯總數(shù)據(jù)的存儲。

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

　　　　StarRocks應(yīng)用進展

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

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

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

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

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

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

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

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

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

　　　　實踐案例

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

　　　　需求澄清

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

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

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

　　·數(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)入來看，核心問題是提升單機數(shù)據(jù)寫入性能。

　　·表設(shè)計按照日期分區(qū)，按照運單號分桶，第一個問題就是如何進行數(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ù)會增加。

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

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

　　·跨機器跨磁盤的副本均衡問題：由于機器down機或者增刪磁盤造成的，目前跨機器的副本均衡已經(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進行計算后寫入一個新的Kafka，StarRock通過Routine Load從新的Kafka拉取數(shù)據(jù)，很好的實現(xiàn)了Exactly Once語義，各個系統(tǒng)的耦合度很低，可用度高。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　·從資源管理來看：達到serverless的管理目標、可衡量。

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

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

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

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

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

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