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

01車聯(lián)網(wǎng)平臺

聯(lián)友科技車聯(lián)網(wǎng)整體架構(gòu)由下往上分為四層，分別是云服務(wù)、車輛連接服務(wù)平臺、應(yīng)用服務(wù)平臺以及終端服務(wù)。目前平臺架構(gòu)支持多品牌、多車系、多協(xié)議鏈接，具備高可用、安全合規(guī)，支持千萬級車輛接入以及百萬級并發(fā)。

云服務(wù)：支持私有云、混合云部署，支持同城雙活和異地多活

車輛連接管理服務(wù)平臺：負責車輛連接，包括終端網(wǎng)關(guān)（接入?yún)f(xié)議、數(shù)據(jù)源可配置）、網(wǎng)絡(luò)通訊框架、數(shù)據(jù)存儲以及處理中心

應(yīng)用平臺：提供統(tǒng)一的能力開放，包括核心框架能力、服務(wù)管理、API管理、用戶管理等，在對外能力上包括內(nèi)部系統(tǒng)能力整合、提供與車輛相關(guān)數(shù)據(jù)服務(wù)與業(yè)務(wù)服務(wù)

終端服務(wù)：提供個性化的服務(wù)以及數(shù)據(jù)埋點，支持到多終端、多協(xié)議應(yīng)用設(shè)備的接入

在后續(xù)的部分我們主要針對車聯(lián)網(wǎng)數(shù)據(jù)流在車聯(lián)網(wǎng)平臺架構(gòu)中的實現(xiàn)展開介紹，承載這部分能力的模塊叫做 BDP。

1.?車聯(lián)網(wǎng)平臺整體架構(gòu)

架構(gòu)由左往右在大概可以分為三個階段：數(shù)據(jù)接入、數(shù)據(jù)存儲、數(shù)據(jù)開放。

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

02數(shù)據(jù)接入

1. 數(shù)據(jù)源

車輛終端：通過TCU上報數(shù)據(jù)到設(shè)備網(wǎng)關(guān)，原始上報的數(shù)據(jù)經(jīng)過數(shù)據(jù)解析服務(wù)完成數(shù)據(jù)的解碼，然后將語義化的消息推送到數(shù)據(jù)接入層的消息隊列中。

設(shè)備終端：通過數(shù)據(jù)采集SDK將智能終端產(chǎn)生的數(shù)據(jù)上報到服務(wù)網(wǎng)關(guān)，同樣在數(shù)據(jù)解析服務(wù)模塊完成數(shù)據(jù)解析，并注入到數(shù)據(jù)接入層的消息隊列中。

當前數(shù)據(jù)平臺接入的數(shù)據(jù)源具有多品牌、多渠道、多類型等特點，也正因為數(shù)據(jù)源的多樣性，我們在數(shù)據(jù)接入上分渠道，在數(shù)據(jù)清洗時統(tǒng)一單位和精度，在數(shù)據(jù)存儲上分庫&分表，以便于向下游提供同一規(guī)范的數(shù)據(jù)。

2. 數(shù)據(jù)接入架構(gòu)演進（配置化數(shù)據(jù)接入）長期的業(yè)務(wù)過程證明，不同的“廠商”、不同的“車型”對數(shù)據(jù)采集項的要求是不一樣的。以前的做法是采用統(tǒng)一的數(shù)據(jù)采集協(xié)議，這就引入了一個問題，不同的車型對于數(shù)據(jù)采集項是不一樣的，例如我們采集字段的枚舉有3000個，但是某一個車型的數(shù)據(jù)字段只有2000個，而“統(tǒng)一數(shù)據(jù)采集協(xié)議”要求所有回傳的數(shù)據(jù)都具有同樣的結(jié)構(gòu)，這就要求上傳車型需要冗余其中1000個不屬于自己的字段，并且全部置空，這會導致數(shù)據(jù)傳輸過程中存在大量的冗余信息。但是我們希望車輛只回傳自己需要回傳的字段。那么如何解決這類問題呢？我們后續(xù)的演進方向是支持“配置化數(shù)據(jù)接入”，具體的示意圖如下：在“配置化數(shù)據(jù)接入”中會有一個配置化管理portal，在界面上用戶可以配置數(shù)據(jù)字典，配置生效的數(shù)據(jù)采集協(xié)議會在字段注冊服務(wù)中完成字段注冊，并將數(shù)據(jù)采集協(xié)議下發(fā)到終端TCU。同時會將已經(jīng)配置好的數(shù)據(jù)采集協(xié)議映射成后臺數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)，并走“結(jié)構(gòu)同步服務(wù)”將最新的數(shù)據(jù)采集協(xié)議同步到數(shù)據(jù)庫中。當終端接收到新的數(shù)據(jù)協(xié)議之后，就會按照新的數(shù)據(jù)協(xié)議上報帶協(xié)議版本的數(shù)據(jù)到數(shù)據(jù)接入服務(wù)，并推送到云端的kafka中。云端數(shù)據(jù)解析服務(wù)會從kafka中消費消息，然后根據(jù)“數(shù)據(jù)字典”中注冊的數(shù)據(jù)協(xié)議完成數(shù)據(jù)的動態(tài)解析，再根據(jù)數(shù)據(jù)結(jié)構(gòu)執(zhí)行數(shù)據(jù)動態(tài)入庫（表格schema已經(jīng)被“結(jié)構(gòu)同步服務(wù)”變更）。

03數(shù)據(jù)存儲

當前所有接入的數(shù)據(jù)在經(jīng)過數(shù)據(jù)接入流程之后，會統(tǒng)一寫到貼源層的kafka集群。當前我們的數(shù)倉層分為兩塊：實時數(shù)倉、離線數(shù)倉。

實時數(shù)倉我們采用的是kafka+redis的組合

離線數(shù)倉我們采用的還是傳統(tǒng)的Hive+HDFS的方案

經(jīng)過數(shù)倉清洗之后的數(shù)據(jù)會分主題推送到數(shù)據(jù)集市中。我們面向不同的應(yīng)用場景選用了不同的解決方案：

Doris：基于埋點數(shù)據(jù)分析用戶的運營活動，例如流程分析，漏斗分析等

Kyligence：支持數(shù)據(jù)的多維分析（MOLAP），面向固定報表分析

Clickhouse：支持數(shù)據(jù)自定義分析，體現(xiàn)數(shù)據(jù)分析的靈活性

Elasticsearch：分數(shù)據(jù)視圖，支持數(shù)據(jù)檢索

1. 實時數(shù)倉

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

2.?離線數(shù)倉

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

在數(shù)據(jù)集市層，我們主要面臨兩類需求：固定報表分析與實時多維報表分析。

固定報表分析?– Kyligence

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

實時報表分析?– Doris

當前我們的埋點數(shù)據(jù)主要是用戶行為數(shù)據(jù)，這類數(shù)據(jù)會統(tǒng)一在用戶運營平臺完成用戶行為的分析（熱點事件，漏斗分析），這個過程會涉及到輕量級的join分析，Doris就非常適合這類場景。

04數(shù)據(jù)應(yīng)用

1. 用戶運營 – 離線我們APP、車機、官網(wǎng)/官微的數(shù)據(jù)會通過服務(wù)網(wǎng)關(guān)的方式采集到大數(shù)據(jù)平臺，經(jīng)過數(shù)據(jù)輕度匯聚之后，將用戶特征與我們標簽體系中的標簽特征做匹配，并打上相應(yīng)的標簽。用戶運營人員會做大量的用戶群體分類篩選，這些信息會支持我們對特定的用戶做客戶關(guān)懷、保養(yǎng)提醒、優(yōu)惠促銷、廣告投放等服務(wù)。

2. 智能推薦?– 實時

根據(jù)上圖所示，智能推薦核心業(yè)務(wù)過程包括場景識別、內(nèi)容匹配、場景仲裁。我們在支持智能推薦應(yīng)用上主要有如下幾個數(shù)據(jù)流程：

車機數(shù)據(jù)上報：車機上報的狀態(tài)數(shù)據(jù)經(jīng)過報文解析為格式化的數(shù)據(jù)之后，會推送到BDP的數(shù)據(jù)接入層。這類數(shù)據(jù)在消息隊列之后會做數(shù)據(jù)的分流：一條鏈路是數(shù)據(jù)落盤歸檔，作為最穩(wěn)定的原始數(shù)據(jù)，支撐上游的分析與業(yè)務(wù)應(yīng)用；另外一條鏈路會支持到實時業(yè)務(wù)場景應(yīng)用。

埋點數(shù)據(jù)回傳：用戶終端在接收到這類推送之后會有自己的反饋，這類數(shù)據(jù)會以埋點數(shù)據(jù)的形式再回傳到大數(shù)據(jù)平臺

第三方數(shù)據(jù)：我們會與第三方廠商做一些合作，拉取物料數(shù)據(jù)到我們的大數(shù)據(jù)平臺，豐富我們的數(shù)據(jù)基礎(chǔ)。

基于以上三類數(shù)據(jù)源，在打上初步的標簽（物料標簽或者用戶標簽）之后會支持我們構(gòu)建如下三個核心能力：

場景庫

將海量的用戶基礎(chǔ)數(shù)據(jù)與標簽數(shù)據(jù)經(jīng)過閾值模型對用戶以及用戶行為進行分類后的結(jié)果豐富場景數(shù)據(jù)庫，下游的場景識別API可以基于場景庫與閾值模型做出場景識別，例如我們可以基于用戶真實加油習慣做加油時機的推薦。

內(nèi)容庫

內(nèi)容庫與場景庫建設(shè)類似，進入系統(tǒng)的用戶標簽數(shù)據(jù)與物料標簽數(shù)據(jù)輸入到推薦模型之后，會生成推薦列表，再通過內(nèi)容匹配API開放給實時業(yè)務(wù)流程的內(nèi)容匹配模塊。

場景仲裁

在數(shù)據(jù)流經(jīng)仲裁模塊之后，場景仲裁模型會根據(jù)用戶配置的場景優(yōu)先級進行場景評分。評分之后的場景會也通過場景仲裁API開放給實時業(yè)務(wù)模塊。

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

05數(shù)據(jù)應(yīng)用問：剛才老師有提到我們有采集車輛的位置數(shù)據(jù)，那我們的數(shù)據(jù)合規(guī)與數(shù)據(jù)安全問題是怎么解決的呢？答：數(shù)據(jù)安全與數(shù)據(jù)合規(guī)是我們在做數(shù)據(jù)采集時必須要考慮的。首先，用戶在購買搭載我們車聯(lián)網(wǎng)方案的車之后，在開始使用我們提供的服務(wù)之前，我們會讓用戶瀏覽我們的數(shù)據(jù)采集協(xié)議，在征得用戶同意之后，我們才會做協(xié)議范圍內(nèi)的用戶信息采集。其次，我們采集到的用戶隱私數(shù)據(jù)（例如位置信息）只會在我們的數(shù)據(jù)中心存儲七天，七天之前的數(shù)據(jù)我們會做清理與銷毀。最后，我們基于用戶位置信息加工產(chǎn)生的隱私數(shù)據(jù)（例如公司地點、居住地點等）在滿足數(shù)據(jù)合規(guī)要求的前提下進行持久化，這類數(shù)據(jù)我們目前持有的時間周期是30天，超出數(shù)據(jù)持有周期的數(shù)據(jù)我們同樣會做清理與銷毀。今天的分享就到這里，謝謝大家。