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

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

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

以下是分享正文：

1

數(shù)據(jù)湖

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

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

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

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

而正是因為大數(shù)據(jù)的產(chǎn)生，我們提出了數(shù)據(jù)湖的概念。

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

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

2

數(shù)據(jù)湖最佳實踐報告

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3

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

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

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

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

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

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

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

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

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

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

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

當時我們和青云一起討論做一個方案：能否把一部分數(shù)據(jù)，比如近六個月的數(shù)據(jù)放在塊存儲上，把之前的歷史數(shù)據(jù)放在對象存儲上？

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

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

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

我們用了八個節(jié)點虛機，用低廉的 4C8G 做 TPC-H 測試。

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

通過分級存儲機制，既大幅降低了存儲成本，又保證了查詢性能。

下面分享第二個故事。

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

首先，把它存出來。計算層的計算量很少，如果配 100 個節(jié)點大多就浪費了。我們在存儲上把 1PB 存起來。計算時只用 10-20 個節(jié)點就可以完成計算任務，你會節(jié)省 80-90 臺機器，大量節(jié)省硬件資源。這是計算和存儲分離的意義。

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

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

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

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

機器學習分析，Spark MLab 這一塊是通用的。我們更多的是做 MADlib，MADlib 是 Apache 的頂級開源項目，只在 PostgreSQL 和 GreenPlum 體系里可以用。

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

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

4

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

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

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

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

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

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

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

談到攝像頭，我們在安防領域有一些應用，攝像頭拍攝人臉識別后會轉(zhuǎn)成結(jié)構(gòu)化數(shù)據(jù)，做查詢、分析時可以用到。

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

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