分享嘉賓：梅柏七?聯友科技編輯整理：時磊 大疆創新出品平臺：DataFunTalk導讀：聯友科技是一家旨在提供在汽車行業全價值鏈解決方案的科技公司。公司以數字化、智能零部件以及智能網聯為三大核心業務領域，涵蓋研發/制造/營銷等領域的信息化產品、系統運行維護服務、云服務、大數據分析服務、智能網聯及數字化運營服務、車載智能部件及汽車設計等業務。本次分享會圍繞以下四點展開： 車聯網平臺 數據存儲 數據接入 數據應用?

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天，超出數據持有周期的數據我們同樣會做清理與銷毀。今天的分享就到這里，謝謝大家。