近幾年，汽車行業全面擁抱電氣化和數字化，一方面有行業先行者和政策法規的激勵作用，另外一方面隨着無線網絡升級換代以及雲計算技術越發成熟，車機端到企業端能夠更加實時穩定傳輸豐富數據。如何利用好這些數據，爲生產、營銷決策提供支持是各大車企都迫切關心的問題。大數據分析對於車企的價值也更加凸顯。
對企業來說如何搭建一個可應對未來數據量幾何級增長的數據分析平臺？是選在在本地搭建還是雲上？在數據湖上如何構建？Kyligence 團隊很幸運參與到一家世界領先的車企數字化轉型的實際項目中，今天特別邀請到這個項目的負責同事與大家分享 Kyligence 在數據湖上搭建大數據分析平臺方面的一些思考。
背景
過去幾年，汽車行業在排放法規、激勵政策、行業競爭等內外壓力驅動下實施了電氣化戰略、進行數字化轉型。產業鏈藉助雲計算、IoT、邊緣計算、微服務、反應式架構等技術手段完成V2X（Vehicle-to-everything）的建設，已經建立了對車輛電氣數據和用車數據全面、準確、實時的收集的能力。
圖1：車聯網數據鏈路：車-企業-公共平臺
人們對汽車的定位也逐步從機械產品向電子信息系統控制的智能產品轉變，由單純的交通運輸工具逐漸轉變爲智能移動空間和應用終端，有網聯能力的新能源汽車保有量也越來越高，行業向縱深發展越來越依賴對數據的應用。
在不久前，中國發改委印發《智能汽車創新發展戰略》中提出“加強智能汽車複雜使用場景的大數據應用，重點在數據增值、出行服務、金融保險等領域，培育新商業模式”。這標誌着行業在投入了諸多精力打通了車輛端到企業端的數據鏈路後，整個行業必須儘快駛入挖掘數據更高附加價值的快車道中，深耕數據實在推動業務發展。
以汽車行業電氣化和數字戰略先行者Tesla公司爲例，自2012年起累計生產交付了100萬輛電動車，所有這些車輛都可以持續不斷上傳三電系統、車載雷達、攝像機、車主用車行爲和全球主要城市的交通信息數據。若一輛車平均每天行駛2小時，行駛中每秒上傳10kb壓縮數據，100萬輛車每天產生的數據量大約爲 70tb。Tesla藉助雲計算、大數據技術能夠處理利用這些數據，用來提升電池安全與性能、提高汽車自動駕駛能力以及爲車主提供個性化的用車體驗。
Kyligence 服務的這家客戶今年將在中國推出第一款純電動跑車，加上存量車型，到2021 年大約會有 10 多萬臺具有智聯模塊的車輛行駛在道路上。雖然車輛端到企業端數據鏈路建設的十分成熟，但因爲還沒有數據平臺的支持，只能採用低頻策略收集有限的數據滿足安全監控等基礎應用場景，也無法積累更久遠的數據，這些導致數據價值得不到很好的發揮，無法滿足行業對車輛智能化發展、數據創新型應用的要求。這家企業於去年下半年啓動了中國區數據平臺建設計劃，希望能夠藉助平臺基礎能力，將核心經營數據、合作伙伴數據、互聯網開放數據、車聯網實時數據做綜合運用，使數據爲業務創造更多價值。考慮到企業級數據平臺建設是一個持續迭代的過程，結合客戶方中短期內業務部門、IT團隊對平臺能力的要求，我們確定了首期建設目標是打造企業級數據湖。
架構挑戰
數據湖（Data Lake）概念自2011年被推出後，其概念定位、架構設計和相關技術都得到了飛速發展和衆多實踐，數據湖也從單一數據存儲池概念演進爲支撐高效、安全、穩定企業級數據應用的下一代基礎數據平臺，也是客戶進行數據平臺建設的核心訴求。
基於上述業務背景和客戶需求，我們在進行數據湖的方案選擇和架構設計時，需要解決的核心挑戰主要有以下四個方面：
1. 良好經濟的存儲方案，平臺經濟性的要求主要爲了應對以下兩個問題：
- 原始數據被大量存儲：車聯網可以產生大量的電氣設備、駕駛過程、人機交互、地理位置數據。企業積累的原始數據集包含的數據種類豐富度（數據廣度）、數據積累的時間長度（數據深度）、數據細粒度和產生頻率（數據密度）決定其可能具有的價值高低。很多企業會追求積累更加廣泛、深厚、密集的原始數據集。但由於起初利用數據的能力非常有限，原始數據轉換成高價值數據的速度相比數據產生的速度是非常緩慢的，導致原始數據越積越多。
- 高價值數據由熱轉冷：從原始數據抽絲剝繭得到的高價值數據隨着時間流逝產生的問題是，其數據價值對當前和未來的業務貢獻度普遍會降低，且越來越少。因此數據被提及或使用的頻率會逐漸降低，數據由熱轉冷，偶爾會被用到的冷數據越積越多，新的高價值數據還在不斷涌入，存儲開銷越來越大。
2. 多源集成能力，平臺需要能夠集成和存儲多種來源、多種形式的數據。融合的分析和應用要求企業將車聯網數據、互聯網數據、企業內部數據和外部供應商數據一起結合，這要求平臺不僅需要兼容關係型數據庫數據源，還要具有集成文件、媒體數據、流數據、接口來源數據的能力。另外對於數據源的變化，平臺也要有實時的感知能力，能夠及時更新與之相關的分析結果。
3. 彈性擴展能力，平臺需要能應對數據接入和數據計算壓力的大範圍波動。數據系統在高峯期同時要接受來自前端的查詢計算壓力，以及來自後端的數據接入、校驗、離線或實時倉庫數據計算和存儲壓力，此時需要大量硬件資源來完成工作。但在平峯期系統所需的計算、網絡、存儲又趨於穩定，可以釋放空閒的資源。IT基礎設施如果有足夠彈性的能力來適應這種大動態的變化，既能顯著降低業務高峯期由於IT設施導致的效率瓶頸，又能在業務平峯期減少系統空轉帶來的資源浪費。
4. 全面安全性保障，平臺需要自身以及數據資產的安全得到完善的保障。
- 首先，原始數據集所具有的業務含義會導致不同數據集需要採用的安全保護策略有顯著差異；
- 其次，原始數據來源和其結構的多樣化產生了對原始數據存儲、處理方式的多樣化要求。數據系統會對結構化、半結構化和非結構化數據採用不同的存儲形式，而且在對這些數據進行離線或實時處理使用的技術棧也多有不同；
- 另外，數據系統作爲一個形式上的整體，實際由數據採集、存儲計算、模型構建、數據展現這些基本能力組成，更進一步還要具有數據治理、任務調度監控、資源動態分配、服務組件運行狀態監控和告警等保障平臺運營的能力。
- 因此數據系統在提供衆多複雜能力的同時，爲了其每一項服務或功能能夠應對來自不同場景、不同角色用戶對其接入安全性、數據安全性的考驗，平臺需要在所有層面實行安全機制，有嚴格的身份驗證機制，能夠對用戶行爲進行追溯審計，對數據的訪問範圍進行安全管控。
解決方案
數據湖早期的落地案例與Hadoop技術生態的發展息息相關，可以說是共生共存，因此大量的數據湖實踐方案都是基於本地的Hadoop集羣。而近幾年，隨着雲計算的普及和飛速發展，各家雲廠商的雲上數據湖方案也逐漸成熟。
兩種方案的優缺點對比大致如下：
在方案選擇過程中，除上述客觀存在的挑戰外，客戶對平臺還有以下幾個方面的期待：
1. 較高的敏捷性：平臺可以快速響應業務的變化，如新增一個項目或添加一個新的數據格式，在整體架構不進行大的變化下，能滿足既定和突發的需求。
2. 良好的靈活性：能夠儘可能的用自動化的方式快速部署系統，所需的測試環境能夠根據實際需要任意擴大或縮小，按需計費，避免資源和成本的浪費。
考慮到客戶的車聯網系統和車機數據已經在公有云平臺上運行和存儲，公有云的安全性及其優勢也被企業所熟知。結合客戶對數據湖平臺架構的期望和需求，項目最終選擇基於AWS公有云來構建雲上數據湖平臺。
- 雲上數據湖在IaaS方面的優勢：
- 近乎無限的數據存儲能力和強大的容災能力：雖然本地部署集羣利用HDFS能夠做到近乎無限的且較爲可靠的數據存儲，但云存儲在可靠和無限存儲的同時能夠提供強大的同城、異地容災能力
- 較低的存儲成本：對數據進行冷熱度劃分，將冷數據置於歸檔存儲中，而高度結構化且經常訪問的數據存放在高性能對象存儲中
- 計算與存儲分離：通過避免計算和存儲資源高耦合部署的方式來避免一旦擴展存儲就必須擴展計算資源，造成資源的浪費
- 按需使用資源：通過實時監控數據平臺對底層存儲和計算資源的需求情況，爲其動態申請或釋放存儲和計算資源，降低成本，提高IT基礎設施投資回報率
- 雲上數據湖在PaaS和SaaS方面的優勢：
- 託管的大數據基礎服務能力：例如，通過使用託管的（Managed Bigdata Platform Service）Hadoop、Spark、Hive、Flink、HBase、Kafka等開源生態存儲和計算服務，能夠使雲數據湖快速並持續穩定地支持離線批處理、在線流處理、機器學習等場景，具備構建數據倉庫的能力。
- 豐富的數據應用能力：例如，分別一鍵部署Marketplace中的Kyligence Cloud和Tableau Server服務，通過二者的能力結合使企業快速在數據湖之上獲得數據倉庫多維分析及數據可視化展現能力。
- 雲上數據湖利用雲平臺管理套件中的監控工具、網絡管理、安全管理等服務的優勢：
- 資源快速安裝和變更能力：能夠對基礎設施、應用程序進行代碼化，對平臺快速創建或編輯，使IT基礎設施能夠快速響應業務實際需求
- 完善的資源訪問策略及權限精細化控制能力：能夠對IaaS、PaaS、SaaS資源訪問策略和資源間共享策略進行精細化權限控制
- 創建或修改虛擬網絡及管理網絡安全策略的能力：通過配置子網、路由表、安全組及其規則、VPN等來實現安全且靈活的網絡策略
- 監控資源和服務情況：通過在雲監控模塊中配置策略來對運行中的資源和服務異常情況進行記錄或告警
最佳實踐
Kyligence 團隊在一線長期服務客戶過程中較爲了解客戶對數據的實際需求和使用場景，將積累的交付經驗與公司在大數據產品、雲計算產品研發過程中的積累相結合，以標準化方案和服務作爲基礎，結合每一個客戶的實際需求和條件做出定製，最終幫助客戶達成項目期望。
總體架構
分層介紹
1.數據集成
我們爲客戶採用數據集成工具集（Data Integration Toolkit）+專項定製方案的形式進行源數據的發現和集成，支持主要Raw Data類型有：
- 關係型數據庫的鏡像庫：包括帶時間戳、有主鍵不帶時間戳、無主鍵不帶時間戳的數據。
在關係數據庫對接過程中，會根據數據庫類型、數據源質量、數據實時性要求、數據總量和變化情況等要素來形成專項的技術方案。一些特殊場景需要客戶購買額外的專項定製服務或者直接採購商業化工具。此外，對於AWS RDS的MySQL實例，Maxwell’s daemon這樣的同步工具也很適用。 - 源系統導出的文件形式的離線數據：比如預先定義交換協議的文件（包含數據內容和描述信息）、Parquet格式的文件、系統生成的CSV格式文件等。
Toolkit在這裏會創建一個Spark運行環境，根據預先定義的規則校驗數據。校驗通過後將數據內容轉換成Parquet格式文件，生成的元數據的可以轉換成Hive元數據並自動註冊。 - 源系統通過消息隊列提供的實時數據：包括Kafka、Kinesis數據源等。對外部系統提供的Kafka數據集成方法是，將消費者程序註冊運行在AWS ECS中，消費程序解析後的數據立即寫入Kinesis，通過Kinesis Firehose把數據給到S3存儲歸檔。此時EMR中運行的Spark Streaming或者Flink程序可以直接讀取Kinesis Stream中的數據進行流處理。
這樣設計的好處在於，當外部系統提供的某一類型數據的源頭是多個Kafka集羣時，由ECS中的consumer程序作爲緩衝統一收集數據，會減少後端側重業務邏輯處理的實時程序實現和運維的複雜度。
- API數據源：通過AWS Lambda實現對API的調用，將獲取到的數據按照規則組裝並形成Parquet格式文件寫入S3中存儲。
2. 數據存儲
- 使用AWS S3將數據分層存儲，是爲了更好的組織、管理我們的數據資產，讓我們的數據體系更有序，使得數據有清晰的結構、減少重複的開發、提供統一的數據口徑，複雜的問題簡單化（拆解任務，每一層處理特定的問題）：
- 原始數據集（Raw Data）：所有對象數據，包括視頻、音頻等二進制數據
- 有業務價值的數據（Golden Warehouse Data）：離線或實時計算結果集
- 直接面向分析的數據（OLAP Cube Data）：Kyligence Enterprise維度建模結果集
- 針對部分業務價值高、或者重要度高的數據採用了版本控制進行保護。
- 使用AWS S3 Glacier，存儲價值密度低和Golden Data中的冷數據，相當一部分Raw Data和歷史久遠的Golden Warehouse Data中的明細數據通過數據生命週期管理機制會被識別成冷數據，將冷數據歸檔可以顯著降低數據存儲的成本。
- 使用AWS RDS，存儲應用程序的元數據（metadata）
3. 數據計算
Kyligence 團隊使用AWS EMR作爲數據處理的計算平臺，由於加工前的數據和加工後數據結果集都保存在S3存儲中，所以平臺很自然的做到了計算與存儲分離。
平臺大部分時間是依賴EMR自身的監控和策略實現集羣規模的Auto-Scaling，而當這些策略無法滿足實際需要時，我們採用自定義策略進行Scale Out或Scale In。而能夠做到這些的基礎是，我們在雲上數據湖用到的雲資源以及定製化服務，無論是創建、啓停、配置、相互集成，都是通過Terraform進行了腳本化實現。
針對離線批和實時流兩類場景，目前有多套數據處理Pipeline和運用過程中需要遵循的標準與規範：
- 批量數據處理
- 使用Kettle作爲ETL工具，使用Hive SQL，以Hive Job的形式提交到EMR中進行計算
- 直接向EMR集羣提交Spark Job。其中對於Spark SQL類型的任務，通過定製Toolkit支持申請一次資源執行一套腳本
- 流式數據處理
- 可以將Spark Streaming或Flink作爲流處理的實現框架，建議所有外部流統一進入Kinesis，流處理程序會直接消費Kinesis Stream中的數據
4.平臺安全
圍繞平臺安全的建設是持續且多方面的，在我們方案中，保障平臺安全可以拆分成五個維度來實施，包括：
- 保障網絡的安全
- 保障雲資源的安全
- 保障PaaS服務的安全（例如保障EMR中衆多應用）
- 保障有Web服務的應用的安全
- 保障數據的安全
針對上述每一個維度，我們又再次進行了拆分。以保障數據安全爲例，我們進一步將其拆分成保障下列過程的安全：
- 數據在集成過程中的安全
- 數據存儲後日常運維過程中的安全
- 發現數據和探索數據時的安全
- 數據在開發和建模過程的安全
- 數據被下游系統或業務用戶使用時的安全
在實施過程中，我們主要通過以下手段來完成上述工作：1. 爲將雲數據湖運營中相關的安全流程與客戶現有流程、規定、IT系統相結合，我們進行：
- 熟悉客戶現有的信息安全尤其是數據安全相關規定和流程
- 熟悉客戶現有的IT流程系統中有關數據安全相關的功能
2. 按照四大屬性十二個角色，將與數據湖有關的實體對號入座：
3. 根據客戶實際情況，制定平臺安全運營核心章程，例如：
- 數據集成、數據治理、權限管理、數據開發評審是數據湖良好運營的基礎
- 平臺外部人員僅可以通過外部程序、工具以及特定的通道訪問數據湖的功能及數據
- 平臺外部程序或者工具通過雙重驗證的方式、經加密協議的方式、跳板的方式訪問數據湖平臺的功能數據
- 數據開發團隊作爲平臺外部人員能夠將數據湖作爲數據基礎設施使用，可以進行數據處理、建模，但開發方式及過程管理必須遵循數據湖規定和標準
- 平臺外部產生的程序在平臺中安裝部署需要遵循DevOps流程
4. 按照我們從實際經驗中總結的經驗和公有云廠商的最佳實踐指導，藉助標準的雲資源安全組件和我們標準化方案中提供的產品或組件來進一步完善安全配置：
- 在基於AWS構建雲數據湖過程中，我們在VPC、Subnet總體框架下，按照角色劃分時得到的實體關係，配置Security Group、ACL規則控制網絡策略，並使用IAM管理對雲資源的訪問。
- 使用AD進行用戶和角色管理。打通外部AD和內部AD，按照角色劃分得到的實體關係，在內部AD中劃分角色和組，作爲管理應用權限和數據權限的基礎。
- 啓用安全模式機制管理PaaS服務的安全，例如啓用EMR的Kerberos模式
- 使用Ranger等三方工具，通過Ranger來進行Hive、S3訪問時的數據權限控制
其他方面
- 採用資源編排工具Terraform，將基礎設施所有的操作和配置腳本化，使得複雜的雲基礎設施部署簡單化
- 良好的平臺運營監控，通過AWS提供的監控組件、客戶購買的第三方工具以及任務調度工具，我們能夠實現對以下資源的監控和告警：
- 基礎資源的運營監控
- 數據應用的運營監控
- 日常數據處理程序的運營監控
- 協助客戶將雲上數據湖運營融入日常IT流程並符合相關規範，包括敏捷開發和DevOps自動化流程
項目價值
雲數據湖平臺的成功搭建和運營，幫助客戶進一步強化了端到端利用大數據價值的能力，讓數據變現有了更強的技術平臺支撐。其最大價值在於可以幫助用戶明確數據接入、存儲到匯聚的全過程，更加清晰地瞭解數據的全生命週期，有效的進行數據拉通，解決數據孤島問題，有利於數據價值的探索發現，結合着雲數據湖平臺的技術架構和運營方式能夠隨需求實時的做出調整和優化，這也鼓勵了客戶業務部門積極利用平臺建設創新型業務場景。
目前項目團隊和客戶信息部門一起，逐步完成車聯網數據的積累並完善平臺+數據一體化運營流程，在流程合規、數據安全的前提下，將車聯網數據與業務系統中數據相結合，支撐業務部門探索更多場景。不久前，業務部門已完成首例實踐，通過車機端用戶行爲相關數據與內部客戶關係數據集結合建模，輔助售後服務部門更有效觸達車主需求，提高車主對隨車服務的粘性。
隨着數據類型及數據量的幾何式增長，數據湖很容易變成一個緩慢、僵化的數據沼澤，這在數據質量和治理方面發出危險的信號。我們需要持續優化數據，確保數據得到治理，不會任由數據處於最原始狀態，將數據在語義層上保持一致，並且能夠滿足用戶分析需求。數據治理的同時我們也要保障數據的質量及數據的安全，這也是今後我們在雲上數據湖的應用中需要側重探索的方向。讓平臺更加智能，激活數據資源價值，提升數據應用能力。