7 年,上汽通用是如何從 0 開始打造“大數據平臺”的?

導讀:過去 7 年,上汽通用一直在大數據技術方面不斷做新的嘗試,這個嘗試的根本目標之一是解決製造業的傳統數據倉庫無法支撐海量數據加載、分析的問題。

上汽通用的大數據開發經理徐雷,結合多年來負責上汽通用大數據平臺的建設以及相關開發工作經驗,在 7 月 12 日的 Kylin Data Summit 上,爲大家深入講解了這幾年上汽通用大數據平臺的設計、演進、發展歷程。

上汽通用大數據開發經理 徐雷

根據徐雷的演講,上汽通用自 2013 年開始搭建 Hadoop,開啓大數據平臺的建設步伐,到 2015年,上汽通用已經把 Hadoop 定位成企業級的應用平臺,2016 至 2017 年嘗試將 Hadoop 與數倉進行融合……

這兩年上汽通用又開始根據一些實時業務場景完善實時計算能力,同時,對於“大數據技術與傳統的數據倉庫應該如何融合?製造業目前關心的與物聯網相關場景和技術結合的點有哪些?”等問題,上汽通用也在探索中前進。

上汽通用的大數據平臺演進歷程解析

大數據開端:搭建 Hadoop+Kafka 大數據架構

搭建 Hadoop 平臺前,上汽通用已經有很多車聯網的場景,比如說安吉星系統,還有專門負責做車輛研發的車聯網技術,它們會把上汽通用汽車上的信號數據採集後傳送到傳統數據倉庫,這樣下來每天採集到的數據量非常大,數據分析的挑戰也非常大,傳統數倉無法支撐這種需求。

針對這樣的情況,上汽通用從 2013 年開始搭建 Hadoop+Kafka 大數據架構。在這套大數據架構下,我們構建了一套專門針對工程車輛的信號分析平臺,在線實時查看車輛的位置及每個點的信號情況、車況信息,而這些數據也可以爲工程部門對車況信息提供一些報表數據,這樣就等於原來不能做的基於車輛的信號數據分析基本上都能做了,而且整個數據傳輸的問題包括數據處理的問題也得到了解決。

在 Hadoop 平臺上搭建數據倉庫

Hadoop 平臺搭建之後,像 DMP、用戶行爲分析系統、智能推薦系統等等上汽通用都有嘗試去做,同時,我們還將 Hadoop 變成了上汽通用的企業級平臺。成爲企業級平臺後,下一步目標就是用 Hadoop 構建數據倉庫了。

在調研了包括 IBM 等傳統 IT 巨頭在內的許多公司後,我們發現大家理解的大數據與數據湖非常像,它和數據倉庫的關係更多的是按需提取,同時,數據倉庫放不下的數據會回到 Hadoop 中。在這個概念中,數倉容量略小、成本較高,只存放高價值的數據;而 Hadoop 的定位更像是廉價存儲,什麼樣的數據都可以放,但是開發成本很大,也存在一些查詢性能、更新等缺陷和問題。

儘管如此,我們還是做了一個決定:將所有數據都統一加載到 Hadoop 上。

Hadoop + Kyligence 解決高併發難題

我們在 Hadoop 上構建了數倉和數據提示,數倉在傳統的關係型數據庫和 Hadoop 之間同步,將上汽通用在用的 Data Stage 和 Hadoop 打通了,打通後,在當時時間不長、數據量與業務量不大的情況下,Data Stage 操作傳統的數據,Hadoop 裏面的數據則用 Hive 和 Spark 做,Impala 做 BI 查詢,整個搭配用起來效果還不錯。

但時間一長問題就暴露出來了。首先是 Hadoop 和傳統數倉之間的數據同步成本比較高,其次是 Impala 不支持高併發,因此併發量上去之後查詢性會顯著下降,再者由於涉及到非常多的技術組件,運維成本很高,爲此我們又在這個架構上做了一些其它的嘗試。

我們將原來的數倉和數據集市都整合到 Hadoop 之上,將 Hadoop 作爲上汽通用未來的底層數據存儲技術,同時,利用 Kyligence 的智能大數據分析平臺做明細數據的聚合結果,爲業務提供數據服務。這樣做不僅解決了高併發問題和查詢性能的問題,還摒棄了一些傳統技術,降低了技術複雜度,比如說我們用 Spark/Hive 代替了 Data Stage,ETL 的作業數也下降了。

原來傳統數倉做的很多事情是,數據集市不光有數據清洗的 ETL 工作,還有很多指標計算的 ETL 工作,都使用 Kyligence 的智能大數據分析平臺的話,我們指標的計算就可以更多的以模型規範約定,不需要做很多指標計算的工作了,這樣開發成本也會下降。

上汽通用大數據中臺的搭建

經過幾年的實踐,我們對於企業數字化轉型面臨的挑戰認識得越來越深刻,總結下來有三塊:數據服務化、分析平民化、數據資產化。

  1. 所謂數據服務化是指數據即服務(DaaS)。今天,大家都在提業務中臺、數據中臺,其實通過強大的數據、算法去服務中臺,滿足各類應用差異化的數據應用需求是非常重要的。

  2. 分析平民化主要指自主分析的普及化。此前,數倉的分析流程都有需求提出、IT開發、成果落地的一個過程,項目週期上長則半年、短則幾周;現在,我們希望這種運營模式轉化成IT能夠更快速地支持業務,爲用戶提供一站式的數據探索、機器學習、AI 平臺,實現數據選取、授權、訪問及各類工具算法一條龍服務,打造自主分析的場景

  3. 數據資產化是指充分挖掘數據價值,讓數據變成對業務有價值的資產,而不是數據垃圾。

圍繞這些概念,我們想構建一個靈活的、自助的、高性能的數據中臺,它與傳統數倉最大的區別就在服務接口層面和數據資產層面,包括數據砂箱、自助分析的平臺、數據中臺存儲等幾塊地方。

以前的數倉是面向少數用戶解決特定問題的,現在要解決各種應用的問題,同時滿足各種自助分析的需求,所以上汽通用做數據規劃的時候有一個策略叫“Hyper Ingestion”。根據這個策略我們把所有相關數據統一放在數據湖的貼源層,原數據的信息也同步在數據資產平臺上,這樣可以縮短數據的訪問過程,方便對數據定義進行快速分析。同時,我們也關注數據的接口問題,不光希望對外提供服務,也希望可以回收各種觸點的數據,形成一個閉環。

上汽通用大數據中臺整體架構

接下來我們從技術層面來看看我們的數據中臺具體是怎麼去搭建架構的。整個架構基本上分爲 3 層:

第一層是 Hyper Ingestion,它對接的是上汽通用能收集到的各類數據源:無論是外界的、批量的、實時的、IOT 的數據,還是關係型數據庫的數據。在這之上有實時計算平臺和離線計算平臺,這個平臺引入了 Kyligence Enterprise 滿足多維 OLAP 查詢及高併發訪問的需求,在 Kyligence 之上還有一個上汽通用自己發開的統一的數據對外出口服務層 Data API,用以實現應用數據層的快速接入。

大數據平臺賦能業務自助分析

以前,業務提出需求後,IT要從從需求分析開始,到開發交付、分析結果展現,整個週期全程跟進,不管是對業務還是對 IT 而已,都意味着極大的人力和時間成本,但上汽通用更希望開發人員聚焦在業務的實現上,而不用關注底層的數據組件,因此自助分析成爲大勢所趨。

這點在上汽通用的大數據平臺建好後得到了實現。有了大數據平臺後,IT 扮演的角色是針對每種業務場景建沙箱,在業務人員提出需求後,靈活地將業務需要的數據放到沙箱中,業務只要有分析能力和分析人員,就可以通過沙箱快速得到分析結果,IT 在這個過程中提供的是工具、分析方法和數據的支持,業務靈活度包括交付的週期都有很大的變化。

物聯網時代的大數據挑戰

上汽通用從 2017 年開始規劃物聯網平臺。此前,上汽通用絕大部分的分析需求是造車的質量分析、外部客戶反饋的輿情數據分析,但隨着工業互聯網的發展,物聯網的分析需求逐步產生並增多,例如製造業通過能耗分析知道什麼時候可以把電源切斷,什麼時候啓動降低能耗等,這就需要加裝非常多的傳感器去採集數據,幫助最後做分析。

實時分析:IOT 技術平臺建設+Kyligence 實時構建

2018 年,上汽通用開始正式建設 IOT 技術平臺,在這個平臺的底層我們可以提供 SDK、MQTT 協議、HPPT 協議的接入,在前面會有一個網關可以在互聯網上搜數據,對權限進行控制,同時還做了一些軟路由,消息可以通過這些路由到後臺的 Hbase,而 Hbase 會做一些報文的解析、設備的管理、Schema 的定義等。

這裏重點介紹一下IOT架構裏面比較關鍵的schema。接觸過Kafka的都知道,最早使用 Kafka 的時候大家把它當成消息平臺在用,在傳輸數據環節用Kafka存儲我們收到的消息,不過IOT平臺要考慮的點不是簡簡單單的數據留存問題,還有將Kafka作爲一個實時的數據HUB通道,對各種應用提供選擇。

所以整個 IOT 依賴於 Kafka 的消息是不是有一個很好的 schema 管理。我們研究了 Kafka 的架構後發現它包含了一套 schema 管理的組件工具,這套工具的好處是所有在外部接入的數據會在 Kafka 層面像數據庫一樣定義這套 schema,所有消費方會基於 schema 進行後端應用開發,上游如果任何的消息報文只要和 schema 不匹配就會被拒絕掉,所以後來我們就引進了這套組件。

整個IOT數據接入之後,我們也開始做一些應用。去年,上汽通用和 Kyligence 做了一些試點,我們將物聯網的數據接到 Kafka 之後,通過 Kyligence 實時構建 Hadoop 的方法,做實時的報表,這件事情以前我們覺得很難,但現在方便很多了,只要訂閱一下就可以快速地構建 Cube,目前時效性很不錯。

實時是未來新方向

當然,前面也提到了,由於上汽通用車聯網業務的發展在不斷加快,實時成爲我們目前和未來都需要大力去做的事情。我們現在更多的想規劃一個統一的實時集羣,包括是不是也能夠做一個工作臺在上面做二次開發,提供標準流程。原來我們有一個 Storm 集羣,當前的階段是首先把 Storm 淘汰掉,因爲不想組件太多,第二我們想引入 Flink,看能不能解決 Spark Streamig 的不足,在上層存儲上我們會用 Redis 做一些快速的實時查詢。當然我們會一步步來,先把一些監控報警、發佈管理等這些東西做掉。

以上就是上汽通用在大數據平臺建設的過程,在這個過程中我們走了不少彎路,但最終發現,要真正做好大數據平臺,有幾件事一定要做好:第一,把整個開發標準標準化;第二,在這個標準上可以通過配置產生的,要配置化;第三,能夠服務自主化的,能夠自己做的儘量讓它自己做。

原文地址
https://mp.weixin.qq.com/s/x3Z0b3sYQNw7_cwrSLRcuQ

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章