出租企業交通大數據平臺架構設計

王 堯，劉貝貝，李保民，張愛華

(中國航天系統工程有限公司，北京 10070)

0 引言

近年來，隨著大數據、物聯網、移動互聯聯網技術的迅速發展，互聯網出行公司為乘客提供了更加便捷的打車方式與多元化出行方式，推出的出行APP能夠即時或預約出租車、快車、專車等出行。現在人們也逐漸養成使用出行APP打車的習慣，導致傳統出租企業出行市場份額正在被分流到快車、專車等出行方式，逐漸失去了出行市場老大的地位。

相較于互聯網出行公司通過出行APP服務于乘客并監管車輛運營，傳統出租企業因信息化建設滯后，很難快速響應乘客出行需求與實時服務于企業運營管理及司機運營的需求，也沒有通過挖掘以往運營數據來發現運營問題，或提高企業出租運營管理及服務水平。為了達到提升企業運營效率與運營安全管理及運營服務水平，鑒于以往的交通大數據平臺的研究對象多為省級或城市級[1-2]，針對出租企業級研究較少，所以本文在分析北京市出租企業信息化與業務現狀的基礎上，提出了出租企業交通大數據平臺總體架構與技術實現架構。

1 出租企業交通大數據平臺建設需求

1.1 信息化現狀

(1)企業業務軟件。出租企業核心的信息化軟件一般為出租車運營監控系統、違章系統、人事管理系統、財務系統，具有車輛維修能力的企業還有車輛維修管理系統。因出租企業普遍缺少軟件研發能力，以上軟件均采用采購或委托第三方企業進行定制開發。因定制化程度差等原因，企業業務軟件間互通性很差，通常需要靠人工才能互通。已采購系統的升級也因缺少資金的支持或領導對信息化重視程度不夠而不能適應業務的發展或變化。

(2)乘客打車軟件。乘客的打車軟件使用第三方的居多，比如北京市大部分出租車均使用滴滴、嘀嗒、曹操出行，也有自研的平臺，如首汽出租自研的首汽約車。

1.2 業務現狀

(1)安全管理。出租企業司機在上崗前均需經過嚴格的考核，正式上車運營后，每月還需參加兩次安全例會。例會上安全管理人員與出租車員工集體進行安全學習，安全管理人員通報最近企業內部運營安全違規事件，提醒司機安全注意事項。在非安全例會時間，安全隊長會負責隨機巡邏車隊隊內車輛，減少司機在公司外違規運營可免于處罰的僥幸心理。

(2)車輛管理。相較于互聯網出行公司輕資產運營，出租車企業屬于重資產運營，出租車輛是出租車公司出資購買的，車輛技術隊長負責管理車輛車況安全。

(3)運營承包。出租企業出租車運營均實行承包制，按照車輛運營的方式可分為單班車、雙班車，單班車即一個司機租一輛車；而雙班車則兩個司機租一輛車，分早、晚班運營。

(4)運營考核。在員工運營效益考核方面，出租車企業更注重安全，比如違章、事故、糾紛等。車輛的運營成本、司機的收入情況，因為已經承包給司機，所以企業并不考核。

(5)司機運營。司機運營時間長短均有自己控制，一般司機運營的時間和最小收入、期望收入有關，最小收入=日承包費用+日均凈收入，期望收入=日承包費用+日最高期待凈收入。當達到期待收入后，司機一般會選擇下班休息而不再考慮繼續運營。

從以上5個方面可以看出出租企業管理重心在于安全，而司機的運營收入的多少取決于司機經驗與運氣。互聯網出行平臺出現后，APP叫車成為主流趨勢，司機收入則取決于互聯網出行平臺的派單情況。

1.3 業務需求

(1)運營安全。運營安全包車輛車況安全與車輛行駛安全。保證車況安全有利于車輛行駛安全、也有利于延長車輛零部件的使用壽命、減少車輛維修保養費用支出；行駛安全主要指司機在駕駛車輛過程中各種操作均符合企業、行業、道路交通安全相關法規條例，避免因為司機的疏忽或過失，對乘客及道路上的車輛行人造成傷害。(2)運營效率。高效運營能夠降低企業及司機的運營成本、提高企業與司機運營收入、提升企業的整體運營服務水平，還可輔助企業降低車輛空駛率，完成企業節能減排目標。(3)平臺使用。因為出租企業從業人員的組成結構，員工普遍抵觸使用復雜的軟件。又由于快車、專車加入到運營車輛大軍中，出租企業車輛被承包率開始下降，企業需要能夠以較低的成本實現企業整體運營管理水平的升級。

1.4 平臺目標

平臺能夠互通企業內部數據，支持數據挖掘分析，且分析后的數據可支持企業搭建用于提升企業運營安全、運營效率管理與服務水平相關的應用。

2 出租企業交通大數據平臺架構

2.1 總體架構設計

為達到平臺設計目標，本文從感知數據互通、數據深度挖掘、數據創新應用3個方面著手，構建了“一個中心、四大應用”的出租企業級交通大數據框架，如圖1所示。其中，“一個中心”指的是企業交通大數據中心，對應數據分析層，用于支撐數據的實時處理、存儲、挖掘分析、數據管理、數據共享，“四大應用”分別是服務于企業運營管理者的實時監控報警、統計挖掘、決策支持，服務于司機的服務應用。

圖1 出租企業大數據平臺總體架構

2.1.1 物理感知

物理感知為大數據中心準備數據，包括兩個方面的數據，主要數據為出租終端上傳的位置、出租計價(運營)、車輛OBD(車輛各種狀態)、實時乘車人數數據，還包括原各個業務系統中數據庫的數據，比如違章管理、例會管理、人事管理、財務等業務系統。

2.1.2 大數據中心

大數據中心主要負責數據接入、數據計算、數據存儲、數據統計分析挖掘、數據共享和數據管理。物理感知層數據全部實時接入大數據中心后處理流程如圖2所示。具體流程如下：經過數據解析后一方面存儲原始數據，另一方面用于實時監控報警等類業務處理。存儲的原始數據經過批處理引擎的處理一方面存入數據倉庫，另一方面用于支撐對數據倉庫的統計分析(或挖掘)類服務，為應用層提供分析后的數據。數據共享主要與交通管理部門共享運營、能耗數據；而數據管理則負責管理大數據中心所有的數據。

圖2 大數據中心數據處理流程

2.1.3 四大應用

(1)實時監控報警，主要包含車況報警、駕駛行為報警、位置報警、客流實時分析等。其中，車況報警可包含故障碼、水溫異常、車輛電壓異常、前/后氧傳感器異常、三元催化發生異常報警；駕駛行為報警可包含超速、超轉、過長怠速、疲勞駕駛、急加速、急減速、急轉彎、發動機非經濟運轉等不良行為；客流實時分析主要指所有車輛經過客流實時分析后，顯示不同地點的打車熱度及人員流向。

(2)統計挖掘，主要分析的對象包含車況、能耗、司機、客流。對車況的統計挖掘能夠挖掘車輛零部件發生各種類型故障的規律，有助于企業制定預防性的維修策略；對能耗的統計挖掘能夠挖掘車輛能耗與行駛里程、車齡、行駛道路、天氣、路況之間的關聯關系；對司機的統計挖掘主要包含對司機的運營特征及駕駛行為特征的挖掘分析，能夠分析出司機的運營時間偏好、駕駛行為類型、駕駛安全類型。對客流的分析能夠分析不同時間客流的發生點及客流流向、吸引點及客流流向，有助于企業提升司機運營效率。

(3)決策支持，主要包含企業采購車輛、安全、運營策略的制定。第一，車輛采購。企業在積累的不同車型隨行駛里程、行駛時間車輛零部件的故障變化、車輛能耗變化的規律后，既可支持車型評價，又可定制汽車企業車輛零部件甚至參與車輛設計與制造，來降低企業車輛運營及司機運營成本，提高在企業在出租市場上的競爭力。第二，安全策略。企業在掌握車況、司機駕駛行為及違章的狀況后，著重針對司機行駛不安全問題及車輛車況不安全問題制定安全策略，盡可能減少或杜絕可誘發不安全運營的各種因素。第三，運營策略。企業在掌握車況、當前的司機的運營里程、運營時長狀況后，可適當地提高或者降低司機承包運營車輛月租金，達到企業運營車輛整體上充分利用的目的，依此提高企業運營收入。

(4)服務應用，主要服務于司機，包含事故提醒、車輛維修提醒、違章提醒、駕駛行為的警告、客流大地點推薦等。事故、違章提醒是基于相同地點或相似場景下常發事故及違章的及時提醒；維修提醒是車輛零部件需要維修或者保養的預防性提醒或者實時的報警；駕駛行為警告是對司機不良駕駛行為的預警或者實時報警；客流服務是當客流滯留時，調度車輛疏散客流或者為長時間空載的司機提供調度服務，增加司機運營收入，或者為工時長、收入低司機優先提供調度支持，平衡司機收入差距。

2.2 技術架構設計

為降低企業搭建平臺成本，技術架構設計上均使用開源且已經經受住眾多場景下考驗的組件；考慮到企業人員使用的易上手性及操作方便性，架構上考慮盡可能支持SQL分析、處理數據(如Flink，Spark，Phonix，Kylin)、拖拽+配置組件完成數據整合與挖掘(如kettle，RapidMiner)，可視化操作(如Zeppelin)。通過技術架構中組件的整合，可實現數據接入、數據處理、數據存儲、數據整合、業務整合、數據分析、數據挖掘。大數據中心技術架構如圖3所示。

圖3 大數據中心技術架構

2.2.1 數據接入

(1)Flume，是一種分布式的、可靠的、高可用的海量日志采集、聚合和傳輸系統，支持在系統中定制各類數據發送方，用于收集日志數據。同時，它提供對數據進行簡單處理，并寫到各種數據接受方的能力[3]。本架構中用于實時收集車載終端上傳的日志數據，并將數據傳輸至Kafka。(2)Kafka，是一個高吞吐量分布式發布訂閱消息系統，因其擴展性好、高吞吐量、快速持久化、高可用性等優點被各大消息系統、流數據處理平臺等廣泛使用[4]。本架構中可保證在Flume瞬間上傳實時車載終端數據量超過集群處理能力時，數據不丟失，并按照時序進行處理。

2.2.2 數據處理

(1)批處理。Spark能夠在內存中進行計算，比MapReduce更加高效，適用于批處理、迭代算法、交互式查詢場景。并且可通過SQL完成Hive數據倉庫數據批處理，在spark分布式集群上快速完成機器學習的訓練[5]。(2)實時處理。Apache Flink是一個高吞吐、低延遲、高性能分布式流式數據處理框架。Flink支持SQL完成大部分計算場景[6]，本架構中使用Flink實時處理Kafka中的實時終端類數據，用于駕駛行為及車況的報警等。

2.2.3 數據存儲

(1)HBase，是一個分布式、持久的、強一致性存儲系統，適用于有序數據的讀取場景，具有近似最優的寫性能(能使I/O利用率達到飽和)和出色的讀性能[7]，本架構中Hbase用于存儲出租車載終端上傳的數據。HBase不支持SQL操作，本架構通過Phonix 執行SQL對Hbase 中存儲的數據進行查詢。(2)Hive，是最適合數據倉庫應用程序的，可以維護海量數據，可以對數據進行挖掘，然后形成意見和報告[8]。Hive提供HiveQL查詢語言，將大多數查詢轉譯成MapReduce作業[8]。本架構應用Hive存儲海量客流分析、能耗分析等主題庫中的數據。

2.2.4 數據整合

Kettle具有容易使用的圖形用戶界面[9]，數據抽取高效穩定，轉換組件豐富多樣，是關聯原有業務系統數據及建立數據倉庫得力工具。本架構應用kettle用于數據進入數據倉庫前清洗及補充關聯企業的人、車基礎信息。

2.2.5 業務整合

ESB提供了網絡中最基本的連接中樞，是構筑企業神經系統的必要元素。通過ESB新建平臺與原有系統能夠互聯互通，在平臺數據的應用方面ESB的主要功能是通過ESB發布的接口獲取對應業務系統的數據。平臺相關的服務也將注冊到ESB上，支撐原有或新業務系統的升級或建設。

2.2.6 數據分析

(1)OLAP分析。Apache Kylin是一個開源的分布式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多維分析(OLAP)能力以支持超大規模數據，能在亞秒內查詢巨大的Hive表。比如按照公司、車隊、車輛分析年/月/日/時/運營里程、運營時間、運營收入的統計值(最大、最小、平均值等)。

(2)交互分析。Apache Zeppelin提供了Web版的notebook，支持使用scala 編寫Spark 腳本、使用SQL查詢JDBC支持的數據庫、使用Python、shell腳本交互式分析、處理數據和數據的可視化。

2.2.7 數據挖掘

RapidMiner[10]是用于數據挖掘、機器學習、商業預測分析的開源計算環境。提供的數據挖掘和機器學習程序包括：數據預處理、可視化、建模、評估和部署。其數據挖掘過程簡單，強大和直觀，非常適用于搭建數據挖掘demo，而sparkML則可用于分布式機器學習訓練。數據挖掘可用于推薦空載司機乘客高頻乘車點、車輛零部件故障預測等。

3 交通大數據中心在出租企業業務中的作用

交通大數據中心在出租企業中起著最基礎的分析作用，比如，本企業出租出行路網，支撐著客流發生吸引點的時空變化分析、客流分流時空分析，相同發生吸引點乘車路徑傾向性分析、道路承載客流分析，對車輛的事故、違章預警等也都起著支撐性的作用。下面簡單介紹下出租出行路網，及其如何支撐客流發生吸引點的時空變化分析、客流分流時空分析、乘車路徑傾向性分析、道路承載客流分析。

(1)出租出行路網。通過處理出租車歷史位置可生成出租出行所經過所有的路段記錄。路段包含了路段的起終點、道路的等級、主路/輔路還有路段節點是平面交叉/立體交叉，本功能支持了以下分析結果的展示，輔助企業制定空載車輛調度策略。(2)客流發生吸引點的時空變化分析。在分析某時間段內出租上下客流的基礎上，可在出租出行路網上渲染出不同時間、不同地點客流發生吸引的強度。(3)客流分流時空分析。在分析某時間段內出租乘車客流的基礎上，可分析出不同時間、不同乘車地點客流去往不同目的地的流向變化。(4)乘車路徑傾向性分析。在分析某時間段內出租乘車客流的基礎上，找出乘車地點與目的地均相同的出行，可分析出不同時間、某一乘車地點客流去往相同目的地實際出行路徑變化。(5)道路承載客流分析。在分析某時間段內出租乘車客流的基礎上，可分析出不同時間、不同路段載客人數變化情況，載客人數越多的路段。

4 結語

隨著大數據、物聯網、移動互聯聯網技術的迅速發展，為出租行業發展帶來了革命性的機遇。本文分析了出租企業信息化與業務現狀，設計了可滿足平臺目標的租企業級交通大數據平臺的總體架構與技術架構，此架構以為出租企業自設計大數據平臺架構提供參考。