導讀：聯友科技是一家旨在提供在汽車行業全價值鏈解決方案的科技公司。公司以數字化、智慧零部件以及智慧網聯為三大核心業務領域，涵蓋研發/製造/營銷等領域的資訊化產品、系統執行維護服務、雲服務、大資料分析服務、智慧網聯及數字化運營服務、車載智慧部件及汽車設計等業務。本次分享會圍繞以下四點展開：
- 車聯網平臺
- 資料儲存
- 資料接入
- 資料應用
--
01 車聯網平臺
聯友科技車聯網整體架構由下往上分為四層，分別是雲服務、車輛連線服務平臺、應用服務平臺以及終端服務。目前平臺架構支援多品牌、多車系、多協議連結，具備高可用、安全合規，支援千萬級車輛接入以及百萬級併發。
- 雲服務：支援私有云、混合雲部署，支援同城雙活和異地多活
- 車輛連線管理服務平臺：負責車輛連線，包括終端閘道器（接入協議、資料來源可配置）、網路通訊框架、資料儲存以及處理中心
- 應用平臺：提供統一的能力開放，包括核心框架能力、服務管理、API管理、使用者管理等，在對外能力上包括內部系統能力整合、提供與車輛相關資料服務與業務服務
- 終端服務：提供個性化的服務以及資料埋點，支援到多終端、多協議應用裝置的接入
在後續的部分我們主要針對車聯網資料流在車聯網平臺架構中的實現展開介紹，承載這部分能力的模組叫做 BDP。
1. 車聯網平臺整體架構
架構由左往右在大概可以分為三個階段：資料接入、資料儲存、資料開放。
由車機和智慧裝置採集到資料會經過資料接入模組歸集到資料訊息佇列，並最終落入到資料儲存層（實時數倉+離線數倉）。資料在數倉中經過清洗之後，會形成規範化的主題資料，這類資料我們會統一放到資料集市層。為了滿足到下游的資料獲取和傳統的資料視覺化的需求，我們提供了統一開放的資料消費方式（JDBC/ODBC），支援下游BI需求。同時，對於資料集市中的資料，我們提供資料服務將資料按照資料主題封裝，並通過服務閘道器向外提供資料查詢的能力，為APP、H5、官網/官微、運營平臺等提供規範的資料。
--
02 資料接入
- 資料來源
-
車輛終端：通過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”，歡迎轉載分享，轉載請留言或評論。