據(jù) IDC 最新報(bào)告預(yù)測(cè)，2022 年中國 50% 以上的組織都將成為數(shù)字化堅(jiān)定者，依靠新的商業(yè)模式、數(shù)字化產(chǎn)品與服務(wù)實(shí)現(xiàn)業(yè)務(wù)增長。

面對(duì)數(shù)字化轉(zhuǎn)型的時(shí)代浪潮，青小云為大家準(zhǔn)備了一份硬核大禮 —— 《數(shù)字化轉(zhuǎn)型之路》，包含基礎(chǔ)設(shè)施、業(yè)務(wù)架構(gòu)、解決方案到行業(yè)實(shí)踐、未來探索五個(gè)部分，該系列是對(duì)數(shù)字化轉(zhuǎn)型理論與具體實(shí)踐路徑的系統(tǒng)梳理，希望幫助讀者全面準(zhǔn)確把握數(shù)字化轉(zhuǎn)型發(fā)展趨勢(shì)與前沿技術(shù)，促進(jìn)企業(yè)與組織能夠在變革的數(shù)字化世界中創(chuàng)造更大的價(jià)值，實(shí)現(xiàn)更強(qiáng)健的生命力。

今天與大家分享的是《數(shù)字化轉(zhuǎn)型之路》中解決方案篇——基于 QingStor? 對(duì)象存儲(chǔ)的數(shù)據(jù)湖解決方案。

以下是分享正文：

1

數(shù)據(jù)湖

大家非常熟悉大數(shù)據(jù)的概念，但可能沒聽說過數(shù)據(jù)湖。實(shí)際上，數(shù)據(jù)湖和大數(shù)據(jù)是緊密聯(lián)系在一起的。

數(shù)據(jù)湖在學(xué)術(shù)上的定義，是一種在系統(tǒng)或者存儲(chǔ)庫以自然格式存儲(chǔ)的方法。它有助于存儲(chǔ)各種模式和結(jié)構(gòu)形式的數(shù)據(jù)，通常是對(duì)象塊或者文件。

為什么現(xiàn)在會(huì)提出新的自然存儲(chǔ)格式方法？以前我們?nèi)绾未鎯?chǔ)數(shù)據(jù)？

在使用數(shù)據(jù)倉庫時(shí)，我們要經(jīng)過大量 ETL、數(shù)據(jù)標(biāo)準(zhǔn)化、數(shù)據(jù)整理的過程，換句話說，它要做大量數(shù)據(jù)的工作。

而正是因?yàn)榇髷?shù)據(jù)的產(chǎn)生，我們提出了數(shù)據(jù)湖的概念。

大數(shù)據(jù)來了，它就像水似的，我們無法把水存在傳統(tǒng)的倉庫里。一是它太大了，二是它很廉價(jià)，三是它的形態(tài)不一樣了。大數(shù)據(jù)速度太快，就像洪水一樣，一下過來了，在使用過程中沒法做減庫、入庫的動(dòng)作，要快速以自然的格式存儲(chǔ)。

因此，傳統(tǒng)數(shù)據(jù)倉庫存的是結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)湖里存的是非結(jié)構(gòu)化、半結(jié)構(gòu)化的數(shù)據(jù)。

2

數(shù)據(jù)湖最佳實(shí)踐報(bào)告

接下來是如何使用數(shù)據(jù)湖，以及使用數(shù)據(jù)湖會(huì)遇到什么問題。

這里引用 TDWI 的報(bào)告，這份報(bào)告統(tǒng)計(jì)了美國兩三百家企業(yè)，企業(yè)核心分布在金融、咨詢等主要偏傳統(tǒng)的各個(gè)行業(yè)，規(guī)模是 1 億美元以上到 100 億美元以下，算是中檔企業(yè)。

人們?yōu)槭裁从脭?shù)據(jù)湖？

采用數(shù)據(jù)湖的原因，一方面是剛才談到的大量非結(jié)構(gòu)化數(shù)據(jù)，從圖中可以看到現(xiàn)在有社交媒體、傳感器等數(shù)據(jù)。

另一方面原因是為了做機(jī)器學(xué)習(xí)和人工智能的分析使用。其中還有新的驅(qū)動(dòng)型實(shí)踐，比如數(shù)據(jù)探索和發(fā)現(xiàn)，傳統(tǒng)的數(shù)據(jù)倉庫更多的是看一個(gè)報(bào)表。

新的數(shù)據(jù)探索像數(shù)據(jù)科學(xué)家在數(shù)據(jù)湖里自由探索，而不是所有人都加工一個(gè)報(bào)表。

至于大數(shù)據(jù)產(chǎn)生的業(yè)務(wù)價(jià)值，數(shù)據(jù)湖的產(chǎn)生會(huì)把數(shù)據(jù)倉庫的一部分功能移植到數(shù)據(jù)湖中，數(shù)據(jù)湖的成本比數(shù)據(jù)倉庫的成本更低廉。

數(shù)據(jù)倉庫有大量的模型、ETL、數(shù)據(jù)治理等工作，數(shù)據(jù)湖比數(shù)據(jù)倉庫簡單，大家用更原始的方式堆到湖里，那么數(shù)據(jù)湖以后要替代數(shù)據(jù)倉庫嗎？

使用數(shù)據(jù)湖遇到的問題

Gartner 在一份報(bào)告中指出，沒有經(jīng)過數(shù)據(jù)治理的數(shù)據(jù)湖大部分會(huì)淪為數(shù)據(jù)沼澤。

為了更好的理解數(shù)據(jù)沼澤的問題，我舉一個(gè)例子，比如大家用手機(jī)拍照，可以隨便拍，但拍完后過一段時(shí)間會(huì)發(fā)現(xiàn)里面的大部分照片都沒什么用，有拍了風(fēng)景或者拍壞拍虛的照片，這些照片沒有經(jīng)過管理、沒有打上標(biāo)簽，最后整理照片是很痛苦的過程。

有大量數(shù)據(jù)時(shí)，你要找到所需照片時(shí)是很困難的。這就和今天的數(shù)據(jù)湖一樣，由于數(shù)據(jù)湖的價(jià)格低廉，收集的數(shù)據(jù)很多，大家在數(shù)據(jù)湖里堆積了大量重復(fù)數(shù)據(jù)以及數(shù)據(jù)質(zhì)量低下的數(shù)據(jù)，這就會(huì)淪為數(shù)據(jù)沼澤。

雖然有缺點(diǎn)，但如上圖，在調(diào)查過程中，接近一半的人認(rèn)為使用數(shù)據(jù)湖非常緊迫，四分之一的人認(rèn)為已經(jīng)部署了數(shù)據(jù)湖，另外四分之一的人會(huì)在一年內(nèi)部署數(shù)據(jù)湖。

很多人把傳統(tǒng)數(shù)據(jù)放在數(shù)據(jù)湖里，數(shù)據(jù)湖不光有原始數(shù)據(jù)，它也有大量的數(shù)據(jù)加工。它的數(shù)據(jù)量在不斷增加，逐步邁向 PB 級(jí)。

從數(shù)據(jù)管理來說，數(shù)據(jù)湖還是由傳統(tǒng)的數(shù)據(jù)倉庫團(tuán)隊(duì)管理和 IT 部門管理，業(yè)務(wù)部門只占少數(shù)。大部分是工程師、架構(gòu)師、分析師在用數(shù)據(jù)湖，業(yè)務(wù)員和非技術(shù)人員用得比較少。

從架構(gòu)和平臺(tái)的采納方面來說，目前數(shù)據(jù)湖以 Hadoop 為多，傳統(tǒng)數(shù)據(jù)可以采用關(guān)系型數(shù)據(jù)湖，二者結(jié)合使用的也很好。

3

云端數(shù)據(jù)湖解決方案

剛才分享的是機(jī)構(gòu)報(bào)告，現(xiàn)在我們講講云上的數(shù)據(jù)湖。

HashData 云端數(shù)據(jù)湖

在青云QingCloud 上的數(shù)據(jù)湖如上圖，包括幾塊：存儲(chǔ)、分析、搜索。

存儲(chǔ)我們用的是 QingStor?? 對(duì)象存儲(chǔ)。分析用的是 HaseData V2 版本計(jì)算引擎。數(shù)據(jù)攝取用的是 QingMR，結(jié)合 Kafka 做存儲(chǔ)。機(jī)器學(xué)習(xí)，我們除了配有 QingMR Steaming 和 SparkMR，還有一個(gè) SQL 機(jī)器學(xué)習(xí)的工具，下面逐一展開。

在存儲(chǔ)方面，大家對(duì)數(shù)據(jù)湖的需求是數(shù)據(jù)湖要存得住、存得起。

對(duì)象存儲(chǔ)支持海量的數(shù)據(jù)存儲(chǔ)，可以無限擴(kuò)展，存大數(shù)據(jù)沒問題。

存得起，就要我們提供一個(gè)經(jīng)濟(jì)實(shí)用的存儲(chǔ)。如上圖，對(duì)比了塊存儲(chǔ)，用的是磁盤和 SSD，和對(duì)象存儲(chǔ)，它們的成本有 5-10 倍差異。從存儲(chǔ)角度來看，如果用對(duì)象存儲(chǔ)會(huì)大幅降低數(shù)據(jù)湖的存儲(chǔ)成本。

其中有一個(gè)問題，存儲(chǔ)成本降下來了，如何保證你的計(jì)算性能？我們不能為了用更廉價(jià)的產(chǎn)品，讓客戶體驗(yàn)更差的服務(wù)。

從計(jì)算層面，我們采用了 V2 架構(gòu)。

分享一個(gè)物聯(lián)網(wǎng)客戶的故事，我們當(dāng)時(shí)用了 v1 版本在塊存儲(chǔ)磁盤上，客戶大概有 2 萬的 IoT 傳感器設(shè)備，每時(shí)每刻都在不斷地產(chǎn)生數(shù)據(jù)，數(shù)據(jù)膨脹得非常厲害。他們說這樣做我們的預(yù)算有點(diǎn)超支，能否做一個(gè)方案把成本降下來？

當(dāng)時(shí)我們和青云一起討論做一個(gè)方案：能否把一部分?jǐn)?shù)據(jù)，比如近六個(gè)月的數(shù)據(jù)放在塊存儲(chǔ)上，把之前的歷史數(shù)據(jù)放在對(duì)象存儲(chǔ)上？

我們做了一個(gè)接口，通過手工的動(dòng)作存儲(chǔ)到對(duì)象存儲(chǔ)上，另一塊放在塊存儲(chǔ)上。這是一個(gè)簡單的數(shù)據(jù)溫度的管理，把冷數(shù)據(jù)放在對(duì)象存儲(chǔ)上，把熱數(shù)據(jù)放在塊存儲(chǔ)上。

我們把這個(gè)工作通過系統(tǒng)自動(dòng)完成，更頻繁一點(diǎn)，把成本降得更低一點(diǎn)，要知道六個(gè)月的數(shù)據(jù)也是很大的。通過計(jì)算引擎，先把數(shù)據(jù)存下來，當(dāng)跑運(yùn)算的時(shí)候會(huì)把它抓取。

接下來看一個(gè)測(cè)試，TPC-H 測(cè)試，這邊采用 100G 的數(shù)據(jù)。

我們用了八個(gè)節(jié)點(diǎn)虛機(jī)，用低廉的 4C8G 做 TPC-H 測(cè)試。

在測(cè)試過程中，我們的內(nèi)核使用 GreenPlum，GreenPlum 用了磁盤的塊存儲(chǔ)。HaseData（Cold）是我們新的 V2 架構(gòu)，藍(lán)色部分表示是第一次跑，黃色部分表示是跑完一次，第二次緩存抓住了。對(duì)象存儲(chǔ)比塊存儲(chǔ) IO 低很多，Q7 差一半左右。一旦緩存抓住后，Hot 的部分相差無幾。Q9 比傳統(tǒng)的塊存儲(chǔ)更好。

通過分級(jí)存儲(chǔ)機(jī)制，既大幅降低了存儲(chǔ)成本，又保證了查詢性能。

下面分享第二個(gè)故事。

我們?cè)谧鲇脩粜袨榉治?、網(wǎng)絡(luò)日志分析時(shí)，經(jīng)常會(huì)遇到這樣的情況：電信客戶有 1PB 的數(shù)據(jù)，是基于傳統(tǒng)塊存儲(chǔ)實(shí)現(xiàn)的（如 Hadoop、GreenPlum，給它配一兩百個(gè)節(jié)點(diǎn)）。大數(shù)據(jù)有一個(gè)特點(diǎn)，比如我有 1PB 的存儲(chǔ)，我分析時(shí) 99% 只分析一天的數(shù)據(jù)，可能只分析 1T 或者 100G，這是數(shù)據(jù)密度的問題。我們要解決存儲(chǔ)問題，所以要做計(jì)算存儲(chǔ)分離的架構(gòu)。

首先，把它存出來。計(jì)算層的計(jì)算量很少，如果配 100 個(gè)節(jié)點(diǎn)大多就浪費(fèi)了。我們?cè)诖鎯?chǔ)上把 1PB 存起來。計(jì)算時(shí)只用 10-20 個(gè)節(jié)點(diǎn)就可以完成計(jì)算任務(wù)，你會(huì)節(jié)省 80-90 臺(tái)機(jī)器，大量節(jié)省硬件資源。這是計(jì)算和存儲(chǔ)分離的意義。

我們的架構(gòu)繼承了 GreenPlum 體系，還是用 SQL 解決問題。這簡化了數(shù)據(jù)湖的使用，大家都喜歡用 SQL，我們進(jìn)一步面向業(yè)務(wù)人員。

大數(shù)據(jù)來了，其實(shí)時(shí)性要求比較高。除了傳統(tǒng)可以用對(duì)象存儲(chǔ)存 API 接口、Python 接口外。實(shí)時(shí)部分，大家用得比較多的三個(gè)工具：Storm、Spark Steaming 和 FLink。我們主要比較兩塊，Spark Steaming 和 Storm。

實(shí)時(shí)性，Spark Steaming 從計(jì)算模型來看是準(zhǔn)實(shí)時(shí)，它會(huì)等一秒鐘，比如來了 10 萬條數(shù)據(jù)，我一次性批量寫進(jìn)去。Storm 是實(shí)時(shí)的，你來一條數(shù)據(jù)，它處理一條實(shí)時(shí)數(shù)據(jù)。從延時(shí)來看，Storm 達(dá)到毫秒級(jí)，Spark Steaming 達(dá)到秒級(jí)。

存儲(chǔ)量，Spark Steaming 更大一點(diǎn)，它更符合大數(shù)據(jù)的處理。秒級(jí)接受，一般在我們碰到的應(yīng)用場景是可以接受的，比如它攢到 10 萬或者幾萬條，批量寫入，不需要每條寫。我們標(biāo)配是采用 Spark Steaming 做實(shí)時(shí)數(shù)據(jù)的攝取。

機(jī)器學(xué)習(xí)分析，Spark MLab 這一塊是通用的。我們更多的是做 MADlib，MADlib 是 Apache 的頂級(jí)開源項(xiàng)目，只在 PostgreSQL 和 GreenPlum 體系里可以用。

它的特點(diǎn)是基于 SQL，以前用 Spark 做機(jī)器學(xué)習(xí)，要么用 Python，要么用 Skyline 或者 R。SQL 是大部分都會(huì)用，學(xué)一兩周都會(huì)用，這種比較專業(yè)。

其特點(diǎn)是簡單上手，具體功能 Spark 能做的，它也可以做。同時(shí)，它是 In Database 的數(shù)據(jù)分析，我的數(shù)據(jù)湖就在我的平臺(tái)上，如果要采用另外的工具分析，它會(huì)先把數(shù)據(jù)拿過去，做完分析再拿過來，這里有大量的數(shù)據(jù)交換。它在 Base 里減少數(shù)據(jù)交換，并且可以充分利用 HaseData 的并行計(jì)算，可以保證其性能。

4

云端數(shù)據(jù)治理和數(shù)據(jù)安全

前面談到數(shù)據(jù)治理和數(shù)據(jù)安全。HaseData 秉承 PostgreSQL 和 GreenPlum 完整的權(quán)限管理，如 Table、Database、Funtcion 等。

角色結(jié)構(gòu)，在大企業(yè)里對(duì)幾千人進(jìn)行授權(quán)可以先到角色，通過角色再到具體的權(quán)限。

更安全的管理可以用視圖做隔離，用視圖精細(xì)到資源級(jí)的權(quán)限。這都是 PostgreSQL 和 GreenPlum 數(shù)據(jù)庫的部分。

元數(shù)據(jù)管理，存到 HaseData 里的表和字段，除了存到數(shù)據(jù)節(jié)點(diǎn)上之外，還會(huì)把元數(shù)據(jù)存到 Global Catalog 上，這時(shí)候數(shù)據(jù)治理工具或者 DPU 管理員清楚地知道我們存到數(shù)據(jù)湖里有哪些數(shù)據(jù)，什么時(shí)候存的，數(shù)據(jù)有多大都能一目了然，數(shù)據(jù)治理非常方便。

主要應(yīng)用場景，前面談到第一步應(yīng)用場景是工業(yè)數(shù)據(jù)湖，工業(yè)數(shù)據(jù)湖 IoT 有大量的數(shù)據(jù)做分析、預(yù)測(cè)性維修等。另一部分是電信用戶行為分析、日志分析。

其中還有一塊是交通大數(shù)據(jù)，比如卡口信息，在工作范圍大量拍照，拍照后人工智能攝像頭可以很方便地把牌照信息進(jìn)行結(jié)構(gòu)化處理解析出來，結(jié)構(gòu)化的存到 HaseData 上，如牌照、車牌顏色等都存在數(shù)據(jù)庫里，進(jìn)一步分析其流量、高速公路繳費(fèi)信息。

談到攝像頭，我們?cè)诎卜李I(lǐng)域有一些應(yīng)用，攝像頭拍攝人臉識(shí)別后會(huì)轉(zhuǎn)成結(jié)構(gòu)化數(shù)據(jù)，做查詢、分析時(shí)可以用到。

總結(jié)來說，HaseData 的優(yōu)勢(shì)是，我們把它放在對(duì)象存儲(chǔ)，成本降下來了，同時(shí)保證性能不變。

同時(shí)我們繼承了云的特點(diǎn)，通過鼠標(biāo)操作就可以在幾分鐘內(nèi)把集群起起來，不需要花一兩天的工夫安裝部署。技術(shù)生態(tài)秉承了原來 GreenPlum、PostgreSQL 這種用 SQL 解決問題的思路。彈性，我們支持在線擴(kuò)容，如果 10 個(gè)節(jié)點(diǎn)計(jì)算不夠，可以擴(kuò)到 20 個(gè)，需要多少用多少。