導讀：聯友科技是一家旨在提供在汽車行業全價值鏈解決方案的科技公司，公司以數字化、智能零部件以及智能網聯為三大核心業務領域，涵蓋研發/制造/營銷等領域的資訊化產品、系統運行維護服務、云服務、大資料分析服務、智能網聯及數字化運營服務、車載智能部件及汽車設計等業務，本次分享會圍繞以下四點展開：

• 車聯網平臺
• 資料存盤
• 資料接入
• 資料應用

--

01 車聯網平臺

聯友科技車聯網整體架構由下往上分為四層，分別是云服務、車輛連接服務平臺、應用服務平臺以及終端服務，目前平臺架構支持多品牌、多車系、多協議鏈接，具備高可用、安全合規，支持千萬級車輛接入以及百萬級并發，

• 云服務：支持私有云、混合云部署，支持同城雙活和異地多活
• 車輛連接管理服務平臺：負責車輛連接，包括終端網關（接入協議、資料源可配置）、網路通訊框架、資料存盤以及處理中心
• 應用平臺：提供統一的能力開放，包括核心框架能力、服務管理、API管理、用戶管理等，在對外能力上包括內部系統能力整合、提供與車輛相關資料服務與業務服務
• 終端服務：提供個性化的服務以及資料埋點，支持到多終端、多協議應用設備的接入

在后續的部分我們主要針對車聯網資料流在車聯網平臺架構中的實作展開介紹，承載這部分能力的模塊叫做 BDP，

1. 車聯網平臺整體架構

架構由左往右在大概可以分為三個階段：資料接入、資料存盤、資料開放，

由車機和智能設備采集到資料會經過資料接入模塊歸集到資料訊息佇列，并最終落入到資料存盤層（實時數倉+離線數倉），資料在數倉中經過清洗之后，會形成規范化的主題資料，這類資料我們會統一放到資料集市層，為了滿足到下游的資料獲取和傳統的資料可視化的需求，我們提供了統一開放的資料消費方式（JDBC/ODBC），支持下游BI需求，同時，對于資料集市中的資料，我們提供資料服務將資料按照資料主題封裝，并通過服務網關向外提供資料查詢的能力，為APP、H5、官網/官微、運營平臺等提供規范的資料，

--

02 資料接入

1. 資料源

• 車輛終端：通過TCU上報資料到設備網關，原始上報的資料經過資料決議服務完成資料的解碼，然后將語意化的訊息推送到資料接入層的訊息佇列中，

• 設備終端：通過資料采集SDK將智能終端產生的資料上報到服務網關，同樣在資料決議服務模塊完成資料決議，并注入到資料接入層的訊息佇列中，

當前資料平臺接入的資料源具有多品牌、多渠道、多型別等特點，也正因為資料源的多樣性，我們在資料接入上分渠道，在資料清洗時統一單位和精度，在資料存盤上分庫&分表，以便于向下游提供同一規范的資料，

2. 資料接入架構演進（配置化資料接入）

長期的業務程序證明，不同的“廠商”、不同的“車型”對資料采集項的要求是不一樣的，以前的做法是采用統一的資料采集協議，這就引入了一個問題，不同的車型對于資料采集項是不一樣的，例如我們采集欄位的列舉有3000個，但是某一個車型的資料欄位只有2000個，而“統一資料采集協議”要求所有回傳的資料都具有同樣的結構，這就要求上傳車型需要冗余其中1000個不屬于自己的欄位，并且全部置空，這會導致資料傳輸程序中存在大量的冗余資訊，但是我們希望車輛只回傳自己需要回傳的欄位，那么如何解決這類問題呢？我們后續的演進方向是支持“配置化資料接入”，具體的示意圖如下：

在“配置化資料接入”中會有一個配置化管理portal，在界面上用戶可以配置資料字典，配置生效的資料采集協議會在欄位注冊服務中完成欄位注冊，并將資料采集協議下發到終端TCU，同時會將已經配置好的資料采集協議映射成后臺資料庫的資料結構，并走“結構同步服務”將最新的資料采集協議同步到資料庫中，當終端接收到新的資料協議之后，就會按照新的資料協議上報帶協議版本的資料到資料接入服務，并推送到云端的kafka中，云端資料決議服務會從kafka中消費訊息，然后根據“資料字典”中注冊的資料協議完成資料的動態決議，再根據資料結構執行資料動態入庫（表格schema已經被“結構同步服務”變更），

--

03 資料存盤

當前所有接入的資料在經過資料接入流程之后，會統一寫到貼源層的kafka集群，當前我們的數倉層分為兩塊：實時數倉、離線數倉，

• 實時數倉我們采用的是kafka+redis的組合
• 離線數倉我們采用的還是傳統的Hive+HDFS的方案

經過數倉清洗之后的資料會分主題推送到資料集市中，我們面向不同的應用場景選用了不同的解決方案：

• Doris：基于埋點資料分析用戶的運營活動，例如流程分析，漏斗分析等
• Kyligence：支持資料的多維分析（MOLAP），面向固定報表分析
• Clickhouse：支持資料自定義分析，體現資料分析的靈活性
• Elasticsearch：分資料視圖，支持資料檢索

1. 實時數倉

除了之前提到的車機資料接入以及埋點資料接入以外，我們數倉的資料源還包括車企內部系統的資料，針對這類資料，我們采用了CDC的方式從資料源（MySQL或者Oracle）中捕獲資料，并寫入到貼源層的kafka中，Kafka中的資料會被下游的Flink Job消費，并做資料的輕度匯總，然后寫入到DW（kafka）中，下游支持實時指標計算的 Flink job 會從資料DW中拉取資料完成指標計算，并按照下游需求，將計算結果推送DM層，在實時數倉的最上層是基于Flink SQL構建的可視化實時指標開發平臺，用戶可以通過寫SQL的方式，完成實時指標開發，所有DM層的指標資料會通過資料服務API的方式供下游的資料應用查詢，

2. 離線數倉

可以看到，離線數倉與實時數倉的資料源是相同的，都包括車機資料埋點、設備接入埋點以及外部系統資料，埋點資料統一接入kafka，然后寫入ODS（Hive），而在外部系統資料同步上存在差異，離線數倉在同步外部系統資料時采用的是sqoop，資料統一入倉之后會做輕度的資料匯總，并寫入到DW層（Hive），下游的DM層會對資料按照主題做分塊（cube）與分片（slice），應對穩定的BI需求（Kyligence），在資料可視化層，采用的是Tableau，支持到MOLAP場景的需求，內部的各種資料ETL任務會統一在底層的調度層（Azkaban）來做編排與調度，

在資料集市層，我們主要面臨兩類需求：固定報表分析與實時多維報表分析，

• 固定報表分析 – Kyligence

應對MOLAP場景時，Kyligence使用的是典型的空間換時間的方式支持到高性能的OLAP計算（預計算），除此之外，還能夠做到自動建模與查詢下壓，其中我們選擇Kyligence的一個很大的原因是由于其提供了與Tableau深度融合的能力，目前我們的客戶在資料可視化方案上采用的是Tableau，Kyligence提供的TDS很好地支持到我們將資料集市中的資料對接到Tableau，而不需要再走定時資料同步，提升了資料性能，

• 實時報表分析 – Doris

當前我們的埋點資料主要是用戶行為資料，這類資料會統一在用戶運營平臺完成用戶行為的分析（熱點事件，漏斗分析），這個程序會涉及到輕量級的join分析，Doris就非常適合這類場景，

--

04 資料應用

1. 用戶運營 – 離線

我們APP、車機、官網/官微的資料會通過服務網關的方式采集到大資料平臺，經過資料輕度匯聚之后，將用戶特征與我們標簽體系中的標簽特征做匹配，并打上相應的標簽，用戶運營人員會做大量的用戶群體分類篩選，這些資訊會支持我們對特定的用戶做客戶關懷、保養提醒、優惠促銷、廣告投放等服務，

2. 智能推薦 – 實時

根據上圖所示，智能推薦核心業務程序包括場景識別、內容匹配、場景仲裁，我們在支持智能推薦應用上主要有如下幾個資料流程：

• 車機資料上報：車機上報的狀態資料經過報文決議為格式化的資料之后，會推送到BDP的資料接入層，這類資料在訊息佇列之后會做資料的分流：一條鏈路是資料落盤歸檔，作為最穩定的原始資料，支撐上游的分析與業務應用；另外一條鏈路會支持到實時業務場景應用，
• 埋點資料回傳：用戶終端在接收到這類推送之后會有自己的反饋，這類資料會以埋點資料的形式再回傳到大資料平臺
• 第三方資料：我們會與第三方廠商做一些合作，拉取物料資料到我們的大資料平臺，豐富我們的資料基礎，

基于以上三類資料源，在打上初步的標簽（物料標簽或者用戶標簽）之后會支持我們構建如下三個核心能力：

• 場景庫

將海量的用戶基礎資料與標簽資料經過閾值模型對用戶以及用戶行為進行分類后的結果豐富場景資料庫，下游的場景識別API可以基于場景庫與閾值模型做出場景識別，例如我們可以基于用戶真實加油習慣做加油時機的推薦，

• 內容庫

內容庫與場景庫建設類似，進入系統的用戶標簽資料與物料標簽資料輸入到推薦模型之后，會生成推薦串列，再通過內容匹配API開放給實時業務流程的內容匹配模塊，

• 場景仲裁

在資料流經仲裁模塊之后，場景仲裁模型會根據用戶配置的場景優先級進行場景評分，評分之后的場景會也通過場景仲裁API開放給實時業務模塊，

由以上業務程序與資料流程可知，我們的資料流程是在不斷運轉迭代的，智能推薦業務在上線之后，會產生源源不斷的用戶反饋資料，這些反饋資料會回流到我們的資料系統中，幫助我們提升推薦的準確度，例如基于提取到的車輛位置資訊，我們能了解到車輛軌跡資訊在空間上的分布，這類資訊可以支撐我們做一些加油站與充電樁的選址與建設，再例如我們可以基于收集到的用戶駕駛行為資料（急加速，急轉彎等）對用戶進行分類，并基于類別資訊作合適的維保推薦，在智能推薦中還有一個比較成功的場景是我們基于用戶的駕駛行為資料構建了用戶畫像與駕駛行為知識圖譜，基于知識圖譜搭建了一個智能客服，當前用戶90%的問題夠可以通過我們的智能客服來解決，很大程度上節約了我們的人力成本，

--

05 資料應用

問：剛才老師有提到我們有采集車輛的位置資料，那我們的資料合規與資料安全問題是怎么解決的呢？

答：資料安全與資料合規是我們在做資料采集時必須要考慮的，首先，用戶在購買搭載我們車聯網方案的車之后，在開始使用我們提供的服務之前，我們會讓用戶瀏覽我們的資料采集協議，在征得用戶同意之后，我們才會做協議范圍內的用戶資訊采集，其次，我們采集到的用戶隱私資料（例如位置資訊）只會在我們的資料中心存盤七天，七天之前的資料我們會做清理與銷毀，最后，我們基于用戶位置資訊加工產生的隱私資料（例如公司地點、居住地點等）在滿足資料合規要求的前提下進行持久化，這類資料我們目前持有的時間周期是30天，超出資料持有周期的資料我們同樣會做清理與銷毀，

今天的分享就到這里，謝謝大家，

本文首發于微信公眾號DataFunTalk”，歡迎轉載分享，轉載請留言或評論，

標籤：大數據

上一篇：ClickHouse 對付單表上億條記錄分組查詢秒出, OLAP應用秒殺其他資料庫

下一篇：Centos安裝mysql57