前言

從 2018 年起，整個汽車行業處于相對低迷的狀態，無論是政策導向或是外資引入的放寬，這些都在無形中加速國內車企的轉型步伐。除此之外，互聯網新勢力不斷加碼入場、消費者依賴并追求更高效的智慧互聯，這些都讓傳統車企感到“力不從心”。

如何在接下來的競賽中一馬當先，或是反超為王？車企又該如何利用好大數據這把利劍幫助企業實現數字化轉型？在上月 Kyligence 舉辦的云系列活動中，我司高級解決方案架構師張佑鋮結合在車企行業的多年實踐經驗為大家帶來了如何從 0-1 搭建云上數據湖的方案解讀。

汽車行業數字化轉型的趨勢

傳統車企面臨的挑戰越大意味著有更多的機遇，在應對以下新的變化趨勢時能快速適應變化就能在新的市場格局下占有一席之地，甚至成為行業新的領軍者。

移動端廣泛使用的新趨勢，收集更多車輛信息可以更好的提升用戶服務。
新能源汽車的普及，電動發動機需要實時掌控電池優化信息。
新型技術的發展如云計算、5G時代的到來，讓數據傳輸變得更快，讓企業可以對未來的駕駛技術提供更多的數據保障。

但在應對上述數字化轉型趨勢過程中眾多企業也經歷過以下數據挑戰：

數據來源廣
數據類型多
數據量大
數據增長快
分析時效性強
分析性能要求高

針對上述數據特征，許多企業的架構還是停留在傳統數倉的架構體系中，無法做到快速靈活分析；其次數據接入端和數據消費端的技術也在發生變更，傳統數倉架構必須要面臨著架構升級的趨勢。而數據湖技術可以很好得幫助車企解決上述轉型中遇到的問題。

車企數字化轉型的核心——數據湖技術

數據湖是企業新型數據生態的核心樞紐，負責收集全渠道的數據，確保數據能夠落地。相比于傳統數倉來說，數據湖沒有一個結構化的準入要求，能夠接入上游各種類型的數據，可以是結構化、半結構化，也可以是完全無結構的日志、音頻、視頻文件等，確保數據的統一匯聚，打破數據孤島，對資源的集中化管理，形成數據資產中心。下游多元化的應用也可以直接對接數據湖，實現實時或者離線的數據分析，給業務系統提供數據服務，最終實現數據服務化，資產化。

對于車企來說，如果想要尋找經濟適用型的數據湖方案，又能高效支撐業務的靈活發展與分析需求，并且能做到快速上線，相對于傳統的本地數據湖而言，云上數據湖架構是不錯的選擇。

本地數據湖 VS 云上數據湖

云上數據湖的優勢

1）低成本實現單一可信的數據源

集中把所有非結構化、結構化的數據能夠統一的落地
近乎無限的存儲能力，無需擔憂存儲擴容的問題
成本非常低廉，數據從熱到冷有對應的存儲方案

2）近乎無限的計算和擴展能力

計算和存儲是分離的
計算資源按需申請使用，理想狀態是可以近乎無限擴展的
有豐富的應用組件，可以滿足各應用場景的需求

3）完備的數據安全策略

完善的資源訪問策略及權限精細化控制能力
虛擬網絡及管理網絡安全策略確保數據不會被隨意訪問
數據容災備份
監控資源和服務情況

數據湖的挑戰

在現實情況中，企業想要做好數據湖的架構搭建卻不是一件容易的事情，對于企業 IT 人員來說會面臨以下挑戰：

1）海量數據的存儲開銷大

車聯網可以產生大量的電氣設備、駕駛過程、人機交互、地理位置數據。企業積累的原始數據集包含的數據種類豐富度（數據廣度）、數據積累的時間長度（數據深度）、數據細粒度和產生頻率（數據密度）決定其可能具有的價值高低。

現在很多企業會追求積累更加廣泛、深厚、密集的原始數據集。但由于起初利用數據的能力非常有限，原始數據轉換成高價值數據的速度相比數據產生的速度是非常緩慢的，導致原始數據越積越多。

高價值數據由熱轉冷：從原始數據抽絲剝繭得到的高價值數據隨著時間流逝，其數據價值對當前和未來的業務貢獻度普遍會降低，且越來越少。因此數據被提及或使用的頻率會逐漸降低，數據由熱轉冷，偶爾會被用到的冷數據越積越多，新的高價值數據還在不斷涌入，存儲開銷越來越大。

2）多源集成能力要求高

平臺需要能夠集成和存儲多種來源、多種形式的數據。融合的分析和應用要求企業將車聯網數據、互聯網數據、企業內部數據和外部供應商數據一起結合，這要求平臺不僅需要兼容關系型數據庫數據源，還要具有集成文件、媒體數據、流數據、接口來源數據的能力。另外對于數據源的變化，平臺也要有實時的感知能力，能夠及時更新與之相關的分析結果。

3）彈性擴展能力要適應動態變化

平臺需要能應對數據接入和數據計算壓力的大范圍波動。數據系統在高峰期同時要接受來自前端的查詢計算壓力，以及來自后端的數據接入、校驗、離線或實時倉庫數據計算和存儲壓力，此時需要大量硬件資源來完成工作。但在平峰期系統所需的計算、網絡、存儲又趨于穩定，可以釋放空閑的資源。

IT 基礎設施如果有足夠彈性的能力來適應這種大動態的變化，既能顯著降低業務高峰期由于 IT 設施導致的效率瓶頸，又能在業務平峰期減少系統空轉帶來的資源浪費。

4）100% 安全保障

平臺需要自身以及數據資產的安全得到完善的保障。

首先，原始數據集所具有的業務含義會導致不同數據集需要采用的安全保護策略有顯著差異。

其次，原始數據來源和其結構的多樣化產生了對原始數據存儲、處理方式的多樣化要求。數據系統會對結構化、半結構化和非結構化數據采用不同的存儲形式，而且在對這些數據進行離線或實時處理使用的技術棧也多有不同。

第三，數據系統作為一個形式上的整體，實際由數據采集、存儲計算、模型構建、數據展現這些基本能力組成，更進一步還要具有數據治理、任務調度監控、資源動態分配、服務組件運行狀態監控和告警等保障平臺運營的能力。

因此數據系統在提供眾多復雜能力的同時，為了其每一項服務或功能能夠應對來自不同場景、不同角色用戶對其接入安全性、數據安全性的考驗，平臺需要在所有層面實行安全機制，有嚴格的身份驗證機制，能夠對用戶行為進行追溯審計，對數據的訪問范圍進行安全管控。

企業如何找到省心、安全、同時又能保證高效性能的云端數據管理工具，關鍵還有真實的車企應用案例，幫助用戶做好架構搭建，可以接著看下 Kyligence Cloud 是如何助力企業完成云端“藍圖”的構建。

Kyligence Cloud，一站式云端數據管理和分析服務

Kyligence Cloud 利用云原生的計算和存儲，幫助企業在任意數據湖上構建快速、彈性、成本高效的創新型大數據分析應用。Kyligence Cloud可以有效提高數據分析的時效性、節省IT總成本、通過統一數據服務賦能跨部門協作，并靈活應對未來數據量和業務發展可能帶來的挑戰。

1) AI增強的分析引擎：自主研發的創新型AI增強引擎，可智能發現高價值數據，并通過自動預計算加速關鍵業務分析，提供海量數據下的高并發、高性能的分析能力，不僅有效提高數據分析的時效性，又能極大地節省總體成本。

2) 統一語義層：面向業務的統一語義層，對數據模型、維度、指標等實現統一定義和管理，幫助企業實現統一的數據中臺，為業務應用提供單一數據囗徑，打破數據孤島，提高跨部門共享、協作的整體效率。

3) 云原生架構：基于云原生架構設計，支持云原生數據源例如AWS的S3、Azure的Blob，利用云原生的計算與存儲資源，提供一鍵部署、按需啟停、動態伸縮等自動化運維能力。降低運維管理的復雜度的同時降低運維成本。通過容器化部署，提供高容錯能力，保障系統的穩定性。

4) 全面集成 Apache Spark 生態：與主流大數據技術生態集成，為企業提供各行業的的端到端方案，既實現數據分析應用落地, 又為上線機器學習、人工智能應用做好了準備。

總的來說，通過 Kyligence Cloud 在云上搭建數據湖平臺能夠通過低成本，更高效的去訪問海量的數據，并且能夠應對高并發的場景，應對這樣高并發場景之后能夠使用相對來說更加低廉的成本。結合過往積累了大數據平臺相關的最佳實踐，幫助客戶快速落地IT底層的架構。

案例：某汽車品牌企業級數據湖建設

該車企原本的 IT 架構是本地部署，受限于本地架構的限制，每天落地處理的數量非常大，會被迫丟棄一些有價值的數據。結合企業自身發展方向的調整，新能源動力車的發布，采集更多數據，從車企角度來看，為了更好適應企業未來長期發展目前，傳統本地的 IT 架構需要快速的替代升級。

整個項目的一期是搭建統一的云上數據湖，從開始設計架構制定 SOW 到最終項目落地一共就花了 3 個月的時間，非常快速的完成了從傳統本地部署到云上數據湖架構的升級。

1）企業設計目標：

從設計的目標來看，為了能支持各種數據資產的集成，設計了一層數據網格，能支持各種數據的自動集成，也便于進行數據管理和編目數據資產。通過數據網格，數據收集落地到云上的數據湖中。對于數據訪問需要做到統一的身份認證和訪問管理，以單點真相提供與市場相關的數據資產。在數據湖之上有很多的數據出口，為了統一管控需要封裝統一數據API層，屏蔽底層數據的復雜度，確保上層的不同應用通過統一的方式進行連接。

2）基于 AWS 數據湖的架構設計

基于這樣的設計目標，最終實現了實時、離線兩條數據流處理的分支。實時的數據流，統一接入 AWS 的 Kinesis 在做數據分發，一部分通過數據消費直接落地，另外一部分通過 Spark streaming消費后流入 DynamoDB; 離線的數據通過一系列的文件校驗、文件檢索等步驟處理完落地到AWS S3 上，后面就是 ETL 和數據分析。數據 API 封裝在統一的數據服務 Data Services 里。

數據都接入 S3 后，如果沒有分層，數據會比較凌亂不好維護。從邏輯上主要分了三層（如下圖所示），首先是Raw Data(原生數據)，通過各種方式去接入，有不同的格式，有SVS，有 XML，有 JSON 格式，還有一些非結構化的數據，都會落地到這個 Raw Data 里，然后會通過一些 ETL 的處理以及 Catalog 的定義，把有價值的數據進行提煉，生成 Golden Data (黃金數據)，在 Golden Data 之上是OLAP Cube (預計算結果數據)，最終是通過 OLAP Cube 提供高效的數據服務。這樣的分層其實能夠統一進行一個數據的管理，然后減少一些重復的數據開發。

3）云上數據湖平臺安全設計

云上的數據安全是非常重要的，Kyligence Cloud提供安全可靠的云上數據管理和分析服務。一方面利用云平臺本身的服務可靠性和安全性可以有效保障基礎設施的安全性；另一方面，Kyligence Cloud本身在數據交換、數據存儲、數據訪問等方面采用業界標準的安全策略，以保障數據安全。

網絡安全：所有的部署在用戶自己的私有網絡中，通過配置私有網絡的防火墻，可以將Kyligence Cloud服務與外網隔離，阻斷外網對數據服務的訪問。
存儲安全：依托云存儲提供的安全特性，可以對工作目錄內的數據進行加密存儲。使用云平臺托管的密鑰或者通過自己的密鑰進行加密管理，滿足組織的安全性和合規性承諾。
數據交換安全：默認使用SSL加密所有對外數據交換，并使用云平臺原生的數據訪問方式（如AccessKey，IAMRole等）訪問數據源，以滿足數據傳輸過程中的安全要求。
身份認證與鑒權：提供身份認證與鑒權功能，支持與第三方LDAP服務集成（如OpenLDAPNActive Directory)。支持為不同用戶設置不同操作權限，實現細粒度用戶角色管控，
數據訪問：提供針對項目級/表級/行列級的細粒度數據訪問控制。為不同用戶、用戶組提供不同的數據視

4）數據湖商業價值-分析場景實踐

完成了這個數據湖搭建之后，陸續有不同的應用開始嘗試落地數據湖，以下是車聯網數據分析的應用場景：

第一個場景是車主數據的接入，車主可以通過移動手機App或者是車載一些應用進行數據接入，通過收集車主行為，對把車主進行分群分類，最后實現精準進行服務的推廣。
第二個場景跟服務相關，車主接入流程有的時候非常長，根據流失率的分析，可以判斷車主在接入過程中的哪些步驟是引起車主流失的問題關鍵，優化用戶接入的流程，減少用戶的流失率。
第三個場景是收集車輛行駛軌跡，行駛軌跡數據作為基礎，可以衍生出一些服務，比如說像代駕等等。后期的規劃過程當中會上更多的應用場景，數據的維度會更加豐富。甚至可以引入第三方的數據來豐富車聯網的應用，例如引入交通系統的數據，為車主推薦更好的出行服務；引入實時停車信息，為車主推薦離目的地不遠的廉價停車場。