實時工業大數據產品實踐——上汽集團數據湖

【IT168 專稿】本文根據侯松老師在2018年5月12日【第九屆中國資料庫技術大會】現場演講內容整理而成。

講師簡介：

侯松，上汽集團資深大數據架構師、Oracle ACE、PMP、北美壽險管理師，《高並發Oracle資料庫系統的架構與設計》作者，ACOUG社區、PG社區核心成員。

現就職於上海汽車集團股份有限公司，負責大數據中心數據服務、智能引擎、實時計算平台的研發，產品化及推廣。所負責的上汽數據湖產品，已在上汽集團旗下多家企業實施，用以車聯網應用的落地。

?摘要

立足於汽車製造與服務為代表的製造行業，服務於車聯網與工業大數據相融合的應用場景，採用開源軟體架構，自研發實時大數據集成平台。

降低企業使用大數據技術的成本，為數據分析師、業務分析師提供更高效易用的工具，加速數據應用的建設和推廣，並提供全欄位金融等級3DES加密，自動無感知的密鑰更新，防止密鑰泄露。單元格級別許可權控制和數據脫敏訪問。

正文

對於技術人而言，沒有任何一項技術可以解決所有問題。很多時候，我們做資料庫和大數據產品要以落地為目的，因此在整個過程中，我們需要分清楚want和need是什麼。我今天給大家分享的主題就是我與整個團隊從無到有打造上汽數據湖的故事。

上圖左邊所示為某外國諮詢公司對製造行業大數據認知狀況的調研，70%的用戶表示並不知道大數據的概念。如上右圖是我假想的中國製造業公司對大數據的認知情況，但在互聯網企業，幾乎所有用戶對於大數據都有一定認知，專業人士可能還會說到多類型、高性能計算等關鍵詞。

在上汽數據湖的實踐過程中，我們總結了整個過程的痛點所在，這不一定適合所有行業，但在工業製造行業應該還是比較適合。第一個挑戰是數據集成，因為上汽旗下有多個汽車品牌，因此我們遇到的最大問題就是企業壁壘，當然這不僅僅是技術上的問題。

第二個挑戰是數據質量。以前在金融行業時，我們很少關心數據質量，因為金融領域的數據質量比較高。但是，製造業的數據質量比較凌亂，甚至可以說是一個很差的狀態。

第三個挑戰是技術成本。很多行業都習慣於依賴供應商的力量快速打造一個平台，但這樣做勢必會犧牲企業技術和人才沉澱的機會，久而久之會形成人才缺失。經過兩年的努力，上汽終於彌補了人才和技術層面的缺失。

經過整個團隊成員的頭腦風暴，我們設計了一個冰山模型，主要目的在於設計一個用於處理實時海量數據計算平台，關鍵在於加入了數據加密，也就是數據許可權管理等功能。因為如果要打破企業壁壘，一定要保證數據安全，因此需要通過多租戶技術實現用戶數據隔離。但是，依靠傳統的Hadoop等技術無法實現該功能，唯一能提供的就是kerberos安全認證，這對於用戶數據存儲意義不大。

基於上述幾點，我們研發了上汽數據湖。簡單來說，上汽數據湖的不同之處在於引入了多元化數據。對製造業而言，我們會有很多數據源，並且內部有各種傳統關係型資料庫、新型NoSQL資料庫甚至是一系列Excel表格、PDF文件等，我們面臨的這種多元化不僅僅是技術多元化，還有業務多元化。當數據實時接入進來以後，我們會對數據進行松耦合全量數據存儲。對傳統企業而言，數據耦合性非常強，領域建模的模型是存在的，並且數據在結構上具有相似性，需要數據架構師整理一套完整的數據字典。

整個過程，我們會根據規範避免將數據湖變為數據沼澤，因為數據沼澤內部存儲的內容比較亂，其實沒有什麼價值。企業更關心的往往是數據存入數據湖之後可以創造什麼價值，這也是我們做的比較多的工作。

對互聯網企業而言，大數據平台可能早就處於成長期或者成熟期，但是對於上汽而言，我們從無到有建立了整個大數據平台。我們將整個過程分為四個時期：蠻荒期、萌芽期、成長期和成熟期。

簡單來說，蠻荒期就是只有一個資料庫或者數據倉庫，進行簡單的數據分析生成數據報表即可。

萌芽期，我們開始認識到HDFS和大數據平台的概念。我們自己找供應商搭建了一個大數據平台，把數據通過sqoop方式導入整個平台。

成長期，我們真正開始將資料庫跑不出來或者跑得較慢的的應用放到數據平台上。

成熟期，上汽第一次開始有了數據湖的概念，把很多下游企業的數據統一接入數據湖。並且可以保證數據的可靠性、安全性以及數據安全加密、數據許可權管理和多租戶雲服務。上汽數據湖的兩大亮點為實時數據接入和計算，數據安全性和多租戶管理。

整個數據湖的實現主要分為五個步驟：一是數據接入、異構數據融合和每秒百萬級數據接入。對於上汽而言，比較幸運的是Tbox的數據不像互聯網用戶日誌數據，它還是比較規整的，數據質量相對較高。二是數據備份及容災功能，數據快照及數據融合等；三是單位各級別統一許可權管理、金融級自動化數據加密和敏感數據脫敏；四是海量數據機器學習及數據挖掘系統；五是無間斷動態擴容、高壓縮文件存儲、標準SQL介面和靈活擴展。

上圖可以說是典型的傳統製造業向互聯網轉型的架構，中間是數據湖產品，左邊是信息系統也就是IT系統，主要存儲傳統關係型資料庫和NoSQL資料庫的數據，我們稱為結構化資料庫，因為這部分數據比較容易結構化。下面這部分數據大部分屬於半結構化數據，比如IOT數據、工業大數據等。

數據進來之後會經過一系列微服務控制進到中心湖區，中心湖區根據不同企業按租戶隔離數據，不同類型的數據按照不同的存儲要求放到不同湖區。這部分數據不區分價值密度，暫時不進行任何清洗。當數據進入中間層，『』我們開始進行數據加工，對數據質量進行干預和清洗，最終形成數據集市。

對於價值密度不是很大的工業化大數據，我們可以考慮採用低廉的存儲方式，但是性能可能會比較差。如果搭建集群，雖然存儲能力比較強，但是CPU和內存會成為弱點。對於價值密度較高的結構化數據，我們需要對CPU和內存能力進行較強控制，因此這個地方需要做到分而治之。

當數據加工之後，我們就可以把兩部分數據融合，外圍流域主要使用SandBox，因為傳統的Hadoop集群對用戶隔離以及多租戶實現並不友好。因此，我們實現了計算和存儲分離。搭建若干個集群作為存儲層，犧牲了部分性能做多租戶分離。傳統關係型資料庫基本就是典型的Oracle、DB2、SQL Server和MySQL四個，部分數據來源於這四大資料庫。

從邏輯上區分數據湖的概念，主要分為三個方面，一是數據接入；二是中心湖區存儲；三是外圍流域。簡單來說就是入、存、出的概念。

除了上述幾大資料庫，也有客戶希望可以將Mongo接入整個大數據平台，我們設計了涓流傳輸區，主要用於將數據從一個資料庫存儲到另一個目標，傳統方式主要有兩個過程：一是全量，二是增量。我們先通過全量方式將歷史數據傳輸過去，然後通過增量方式最終達到兩邊數據的一致。

但是，涓流傳輸基本打破了這個概念，全量和增量並行進行。因為大數據和資料庫應用是不同的，大數據在做統計分析時並不要求數據的絕對一致性，因此當數據量達到一定程度時，我可以犧牲部分一致性。

在存儲引擎部分，我們最開始依靠HBase，通過Hive外部表方式訪問HBase，或者通過Impala外部表方式訪問。但是，這種做法的性能會變得很差，因為關係型資料庫相對來說錶行數比較少，這種檢索還是比較有用的，但在大數據場景下並不適用。

因此，我們需要針對這類場景進行定製，如果我們把它放到region Server中，性能又會受到影響，我們通過分片根據實際情況將應用切分成多個region，但這種方式的性能依舊不佳，我們決定進行更深程度的定製。

在最終方案中，我們選擇使用HBase，但在其中加入數據加密功能。這部分的靜態數據使用Parquet，動態數據則是自定義的文件格式，最後拼合Parquet和動態文件以支持SQL查詢。最終方案的整體性能基本可以達到Spark on Parquet的程度，而且可以實現部分Kudu的功能。

整個過程相對來說比較複雜，我們通過任務適配器也稱為任務匯流排控制整個過程，我們將數據字典的信息存放在Zookeeper之中，最終通過Zookeeper維護，包括整個過程產生的多源數據，整個任務匯流排會生成工作流引導數據存儲，模擬數據會通過嵌入式開發存放到SQLlite之中，最後的數據輸出和用戶應用通過SandBox實現。

在輸出和查詢方面，我們主要有兩種方式：一是Hive，二是Spark。雖然Hive的性能一般，但是為了保留兼容性，我們最終選擇將Hive留下。當然，如果追求性能，Spark依舊是最好的選擇。

此外，大家可能比較關心IOT數據如何存儲。除了數據湖，我們還構建了日誌湖和文件湖，由於TBox數據比較規整，因此我們將其定義為日誌湖。對於半結構化數據應該如何呈現呢？

很多人可能會考慮使用MongoDB，當數據量不是特別大時，MongoDB是比較好用的，當數據達到一定量級，MongoDB雖然說是分散式的，但它會形成MongoDB集群，最後通過特定格式存儲到資料庫中，這個過程稱為入庫，需要保持數據的一致性，整個過程需要耗時良久且存儲下來的數據量甚至大於原始數據量。因此，我們最終決定通過kafka的方式完成並預先對數據進行壓縮。

我們知道HDFS存儲默認是三份，就算手動調成兩份，存儲量依舊非常大，成本很高，但是整體上來說一定是最經濟的解決方案，這時我們需要犧牲部分查詢性能，從而實現查詢過程中對zip文件的訪問。

我相信大家一定都聽過CSV解決方案，其實這個方案就相當於把csv做成zip包，因為做zip數據統計分析並不是並發很高的事情，原始數據需要通過工作流中的個別join輸出到一定格式後才可以訪問。

接下來，我來介紹一下文件湖，相比於結構化數據湖和日誌湖，文件湖的重要性不是那麼高，文件湖同樣是企業數據資產存儲的一部分，同樣在HBase中做，最後轉換成文本存儲下來。

SandBox的概念不是上汽第一個提出來的，上汽也不會是最後一個使用者，SandBox在上汽主要經過了兩個階段，我們有兩大集群：存儲集群和計算集群。計算集群按照不同的功能通過Spark on Mesos的方式實現一些Spark SQL 、Spark R 、PY Spark 、Scala等計算，但對於數據科學家而言，他關心的可能只是用到的演算法，比如Tensorflow等等。

我們工作台的原形是 jupyter?notebook ，它可以做一些個性化定製。存儲部分，我們主要使用Kubernete管理docker，把需要存儲的內容以docker image方式存放，然後通過kubernete編排、管理。針對Docker存在的數據狀態問題，我們開發了用戶數據回寫功能，用戶數據需要提供一個目錄，我們用Docker映射本地目錄，通過HDFS協議把它回寫到HDFS，甚至會有一些第三方的HBase。

SandBox 2.0時期，我們會有一些資料庫應用，我們將用戶數據回寫並生成報表，我們使用Kylin做聚合產品會比較快，使用Ignite跑一些Spark SQL，因為它是一個分散式內存資料庫並支持Spark介面。

上圖是一個性能對比，橙色為Hive（Parquet），藍色的為Spark（Parquet），紫色部分是DataLake，這不是最新版本的性能測試，但可以看出一些差距。通過TPC-H基準查詢，我選擇了三個經典場景q1、q7、q13，我們可以看到就查詢性能而言，DataLake的查詢性能是Hive的10-20倍，與Spark（Parquet）差不多。

在實時接入方面，上圖的波形變化體現了接入Oracle、MySQL、SQL Server三個資料庫的實時情況。

在安全管理層面，我們的數據安全管理頁面可以完成加密方式、脫敏控制、列訪問許可權、行查詢許可權的設置，可以達到單元格級別的加密。

IT168企業級

讓一部分人先看到企業IT的未來

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！