順豐科技有限公司隸屬於順豐速運集團，成立於2009年，致力於構建智慧大腦，建設智慧物流服務。順豐科技經過多年的自主研發，已經建成大資料整體生態系統，完成資料採集與同步、資料儲存與整合、資料分析與挖掘、機器學習、資料視覺化等平臺的構建。在建設底盤平臺的基礎上，結合大資料、區塊鏈、物聯網與人工智慧技術，廣泛應用於速運、倉儲、冷運、醫藥、商業、金融、國際等業務領域。

“ 作者：嚴向東，

順豐科技大資料平臺架構師 ”

順豐大資料平臺簡介

早期順豐在 OLAP 層主要使用了 Elasticsearch、ClickHouse、Presto、Kylin 這四個元件。

• Elasticsearch 在順豐場景使用的最多，倒排索引的機制下，檢索效率高，整體運維也比較方便。目前在日誌類、條件檢索類的場景用的比較多。目前版本以Elasticsearch 5.4為主，新接入的業務使用了7.6版本，基於標準版本進行了一些定製化的開發工作，包含跨機房備份方案、K8S 容器化部署、資料服務平臺等。
• ClickHouse 是這兩年引入，用於一些重點的運單場景，進行了 K8S 叢集化改造，很好的滿足了資源快速交付的需求。
• Presto 在順豐也使用的很多，主要用於 Hive 資料的查詢。我們針對 Presto 進行了 Yarn 叢集部署的改造，很好地用到了 Yarn 佇列的資源。
• Kylin 使用的相對較少，目前只在財經線的幾個業務上作為試點。

當前痛點及產品選型

順豐透過內部容器化建設、元件深度定製、元件平臺的建設，元件的一些突出問題、共性問題已經解決，但是還有一些難以解決的元件自身的痛點問題。我們對這些元件的問題進行了一些總結：

• 一、多版本多框架並存、基礎元件升級難。由於歷史原因，同時存在多個版本在線上執行，但因為多個版本的不相容性，使用者業務在線上穩定運轉，主動切換意願不高，導致版本難以統一，元件升級方案複雜、操作風險高，也是元件升級難的另外一方面原因。
• 二、使用者選用元件容易一刀切。在實際的應用中，有很多使用者進行大資料選型時，缺乏對元件本身的瞭解，導致大量的使用不合理的情況，如使用 ES 做大量的聚合計算、使用 Presto 做報表、使用 Kafka 做批次互動等。
• 三、使用難/運維難。各種元件的使用/運維不盡相同，需要使用者和運維都要具備相應的專業知識。

OLAP 產品選型

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

• 元件的核心能力要夠強，短板不明顯。
• 元件交付的版本工程質量高。
• 核心訴求/大的生產環境的問題響應足夠及時。
• 可塑性強，未來長期發展潛力大。
• 運維的門檻要低。

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

• 不同產品之間使用標準測試集的橫向評估，主要選取評估的元件有 ClickHouse、Presto、Apache Doris、StarRocks。
• 中等業務規模的業務體驗：10億規模的契合度高的場景，帶 Join。
• 公司內典型場景的需求評測：百億規模的運單場景的典型 SQL 等。
• 重點功能項的評測：如大資料資料匯入、大表 Join 、failover 等。

從評估的結果來看，對於 StarRocks 我們整體還是比較滿意的，最終我們選擇了 StarRocks ，基於如下的考慮：現階段 StarRocks 效能、穩定性佔優；StarRocks 處於高速發展期，能夠提供專業的技術支援、生產環境問題/需求的快速反應；StarRocks 擁有強大的運維管理系統，使用者開發、運維的功能很全面。

StarRocks 應用實踐

整體目標

順豐引入 StarRocks 的目標是：使StarRocks成為一站式的大資料分析平臺的底座。從資料的源頭來看，包含三條資料流：

• 實時資料、離線資料匯入，透過 StarRocks 原生的幾種 Load 任務完成。
• 透過 Flink/Spark 的 Connector 完成資料 ETL。
• Hadoop、Elasticsearch、MySQL 等環境中的資料，作為資料來源，透過 StarRocks 外表匯入。

從資料使用的角度來看，透過 JDBC 介面給資料使用者提供服務，主要的資料使用者包含：

• 元件開發/元件維護，目前順豐環境對應的是大資料元件平臺。
• BI 工具平臺，在順豐內部叫作豐景臺。
• 資料中臺，如資料服務、資料字典等。
• 業務平臺的訪問，比如資料平臺臨時查詢導數的平臺，及其他一些業務平臺。

為了應對統一的大資料分析底盤的訴求，需要一些場景化的能力，這裡列一些我們主要的訴求：

• 替代 Presto，在 BI 工具平臺快速查詢 Hive 資料。
• 替代 ElastcSearch、ClickHouse、Kylin 做 OLAP 明細、彙總資料的儲存。
• 較好的資料匯出能力，便於業務做二次分析。

StarRocks 應用進展

業務接入

• 運單級別的業務已經完成開發，正在灰度運營中。
• 其他幾個細分業務領域也完成了接入，如財務、快運、國際等。
• 其他也有一些業務正在接入、體驗中。受限於前期的機器採購預算未申報，接入節奏不算快。

統一的 OLAP 平臺能力建設

• 已經可以進行 BI 工具平臺打通。
• 全鏈路的多個叢集環境的搭建，包含測試叢集/預釋出叢集/生產公共叢集/容災公共叢集/重點業務私有叢集。
• 大資料平臺 DataX 整合、Flink / Spark Connector的整合正在開發/測試中。
• 中臺的資料服務、資料字典等正在進行相關的設計，目前也和鼎石團隊在一起看如何拿到元資料。

實踐案例

在物流行業，運單場景是最典型的場景。這裡給大家分享一個順豐最大體量級別的運單場景。這個場景原來是在 Oracle 上單機執行，更新頻繁、對時效要求高。業務上存在著許多的痛點，業務資料成倍增長導致原來系統已經不堪負荷，主要表現為可用性不高、速度變慢、資料多份、時效性不高等。業務側的訴求是希望接入 StarRocks 以後，效能和時效性大幅度提升，能夠在現有業務翻倍雙11場景下的撐得住，提供高可用的方案，能夠快速擴容等等。

需求澄清

接到這個任務後，我們梳理了一遍需求：

• 硬性指標，雙11要滿足單行資料2k左右大寬表、8萬 TPS 寫入訴求。
• 業務峰值效應明細，未來還會有大的增長空間。
• 資料儲存三個月以內的資料，目前資料量在百億級別以內。
• 舊業務改造需要考慮已有 BI 平臺工具的2K+報表的平滑過渡。
• 資料匯出需求，供業務側做二次分析。

資料匯入

針對需求，我們做了資料匯入和查詢兩個方面的方案設計和最佳化。從資料匯入來看，核心問題是提升單機資料寫入效能。

• 表設計按照日期分割槽，按照運單號分桶，第一個問題就是如何進行資料分佈的設計，從使用經驗來看，Kafka 分割槽個數與 StarRocks 的 BE 節點個數、導數任務並行度要一致，匯入效率才最高。
• 由於源頭資料來源於不同的業務系統加工成大寬表，需要透過配置欄位的 replace_if_not_null 支援部分欄位更新，另外為了避免 Json 資料欄位增刪導致導數失敗，需要每個欄位指定 Json 位置。
• StarRocks 匯入能力與單條記錄的位元組數、合併效率有很大關係。為了更高的匯入效能，我們把大寬表的按列分拆為兩個，更新少的資料放入一個表（這裡叫公表）、更新頻繁的放到另外一個表（私表），多表的匯入的任務數會增加。
• 機器選型上，由於寫入頻繁，我們升級了單機 6 盤到 12 盤，未來考慮使用 ssd；StarRocks 向量化最佳化深入，我們升級了 40 核到 80 核，提升 QPS。
• 系統按照日期進行分割槽，由於資料來源於多個業務系統，存在分割槽時間沒有的情況，需要反查，初期方案是從 StarRocks 跨區查，效率較低，後面採用了 Flink 的 RocksDB 方案。
• 跨機器跨磁碟的副本均衡問題：由於機器 down 機或者增刪磁碟造成的，目前跨機器的副本均衡已經在最新版本解決，跨磁碟的副本均衡期待在後續版本解決。
• 版本數問題：如果版本數過多會導致 BE 節點暫停從 Kafka 消費，導致資料匯入效率下降。這裡可以透過調整 Kafka 消費時間、合理設定分片、分割槽個數、副本個數減少版本數。

查詢

• 為解決原有系統的 2K+ 報表的平滑遷移問題，由於拆成了兩個表，新增加了一個檢視，保持跟原有表結構一致，降低遷移成本。
• 跟 BI 平臺合作，做了一些查詢並行度限制核數據快取策略，提高系統的穩定性。

為了提高的查詢效能，做了一些針對性的最佳化工作：

• 對於最常用的查詢條件欄位，加到 key 列，如客戶的公司等。
• 透過增加布隆過濾器索引提升查詢效率。
• 大表間的 Join ，調整 Join 的順序（未開啟 CBO ）。
• 兩表 Join 時，增加冗餘欄位並放在 ON 條件裡面使條件能夠下推，減少掃描量。
• 問題：為了提升查詢效能，將查詢條件中的非 key 列的加到了 key 列，對於此非 key 列的變更變成了刪除+插入兩步操作，可能會造成未合併的版本數累積。

目前系統的整體資料來源於多個業務系統，透過 Flink 進行計算後寫入一個新的 Kafka ，StarRock 透過 Routine Load 從新的 Kafka 拉取資料，很好的實現了 Exactly Once 語義，各個系統的耦合度很低，可用度高。

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

這裡是我們具體的表設計：

1）聚合表模型、同時支援明細表和物化檢視。

2）按照使用更新頻度分成兩個表，提高匯入任務個數。

3）按照寄件日期分割槽，運單號分桶。

4）透過 replace_if_not_null 支援部分欄位更新。

5）變化不頻繁欄位加到 key 列，並兩個表冗餘，提高查詢效率。

6）兩表按照 Collocate Join 提升 Join 效率。

7）按照日期動態分割槽，支援資料淘汰。

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

在適應性更高的場景、如不更新、資料量10億以下等，StarRocks 更加得心應手，效能強大。這裡是目前順豐接入的其他一些非運單明細的場景，StarRocks 都有良好表現，如原財務系統，時常會出現告警。接入 StarRocks 以後，使用1/3的資源消耗即可良好的執行。

後續規劃和社群共建

我們後續在OLAP方面的規劃如下：

• ClickHouse 的新業務接入已基本停止。
• 明年準備大規模接入 StarRocks ，已經全面啟動相關的機器採購預算申請，運單級別的業務系統已經有幾個規劃會進行改造接入。
• 另外在雲上數倉專案上，期待繼續深入使用 StarRocks。

目前 StarRocks 已經原始碼開放，面向未來，StarRocks 有更多的可能性。順豐也有基於StarRocks建設統一、全場景、極速 OLAP 分析平臺的訴求：

• 從終端使用者來看：建設一站式的開發/運營平臺。
• 從資源管理來看：達到 serverless 的管理目標、可衡量。
• 從運維層面來看：更高可用性、更多的工具。
• 從資料模型來看：更多的場景化模型支援。
• 從統一查詢平臺：各種資料庫引擎的更好支援。
• 從生態來看：深入各個周邊場景提供更多能力。

我們願意與StarRocks社群一起，攜手共進，為社群貢獻我們的一份力量。