實時工業大資料產品實踐——上汽集團資料湖

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

講師簡介： 

侯鬆，上汽集團資深大資料架構師、Oracle ACE、PMP、北美壽險管理師，《高併發Oracle資料庫系統的架構與設計》作者，ACOUG社群、PG社群核心成員。現就職於上海汽車集團股份有限公司，負責大資料中心資料服務、智慧引擎、實時計算平臺的研發，產品化及推廣。所負責的上汽資料湖產品，已在上汽集團旗下多家企業實施，用以車聯網應用的落地。微信公眾號：madaiba，個人網站： http://www.housong.net

摘要：

立足於汽車製造與服務為代表的製造行業，服務於車聯網與工業大資料相融合的應用場景，採用開源軟體架構，自研發實時大資料整合平臺。降低企業使用大資料技術的成本，為資料分析師、業務分析師提供更高效易用的工具，加速資料應用的建設和推廣，並提供全欄位金融等級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三個資料庫的實時情況。

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2200308/，如需轉載，請註明出處，否則將追究法律責任。