【乾貨分享】馬洪賓:大數據分析的雲原生趨勢

編者按:

9 月 10 日晚,七牛雲主辦的「雲加數據,智驅未來」數據科學系列論壇如期舉行。在直播中,Kyligence 創始合夥人 & 研發副總裁馬洪賓爲我們帶來了主題爲《大數據分析的雲原生趨勢》的精彩分享。

嘉賓簡介

馬洪賓,Kyligence 創始合夥人 & 研發副總裁,Apache Kylin 核心開發者及項目管理委員會成員 (PMC)。專注於大數據相關的基礎架構和平臺設計。在從事大數據和數據倉庫相關工作之前,曾經是微軟亞洲研究院的圖數據庫 Trinity 的核心貢獻者。目前擔任 Kyligence 企業級產品的研發負責人,幫助客戶從傳統數據倉庫升級到雲原生的、低 TCO 的現代數據倉庫。

首先爲了讓大家有一個更強的代入感,馬老師先介紹一個典型客戶。這是一個快速增長的 SaaS 公司,在 40 多個國家有 1800 多個客戶,其中覆蓋了世界 500 強的 1/3,這些客戶會每年帶來超過 80 億條的交易記錄,所以說它是有一個非常大量的數據需要進行分析和挖掘。那麼對他來說,他需要爲這1800個客戶提供豐富的報表來供他的這些客戶進行分析。

他們把所有的數據放在了 AWS 的 RDS 中。顯然 RDS 是沒有辦法滿足目前的併發和性能需求的,所以這位客戶不得不做了很多物化視圖來加速它的 Dashboard。即便如此,現狀仍然是有很多的查詢需要花五秒以上的時間。因爲這些報表都是由終端客戶去使用,所以五秒的時間並不是特別可以被接受。除此之外,每天還需要花四個小時以上的時間去刷新所有的物化視圖,數據準備的時間也會非常的長。更主要的是,目前 1800+ 的客戶有可能是會在每天的差不多同時間去訪問他的這些報表,但是基於目前的方案,可能只能支撐十個左右的併發。這意味着它的大部分的這個客戶可能需要進行排隊或者是花很長的時間才能刷出他的報表。

這個客戶的核心需求是在雲上做核心數據分析。這些需求主要包含以下幾點。第一點是希望能夠給終端用戶一些靈活的報表。第二點是希望所有的報表能夠提供一個比較好的性能,而且能夠提供比較好的併發度。期望可以實現 100 個左右用戶的併發。接下來的比較大的訴求是希望這套新的這個方案能夠比較好的 scale。客戶同時也提出了對數據準備的時間和對數據安全的要求。最主要的,是希望整個方案仍然可以像過去一樣是 totally 在 AWS 上運作的,這樣他不需要考慮多個環境的問題。當然出於成本的考慮,也提到了希望就最後整個方案是有一個比較低的 TCO。最後也提到了對數倉或者數據平臺的選型是一個開放式的平臺,這樣將來能夠接入一些機器學習或者是數據挖掘的這個能力。

帶着這個客戶的基本情況,馬老師爲我們拓展到未來數據分析與雲原生趨勢的解讀,分享在數據分析領域或者是在數倉裏面看到的雲原生的趨勢。當今,要不要上雲已經沒有歧義,但是可能有的人還會想,數據分析或者是我的數據資產,我的數倉,要不要上雲。

上圖是從 Google Trend 上獲取的近五年的關於 Data Warehouse(藍色)、Data Lake(紅色)、Redshift(黃色,AWS 的著名雲原生數據倉庫)和 Hadoop (綠色)這四個關鍵字的熱度趨勢。可以觀察到,最近的五年內,Hadoop 關鍵字的熱度迅猛下降,Data Warehouse 的熱度保持穩定,而 Data Lake 和 Redshift 的熱度都有顯著提升。另外值得一提的是,早在 2016 年初前後,Redshift 的熱度就已經超過了 Data Warehouse,並且在最近超過了疲態明顯的 Hadoop。

這也與我們的觀察和感受一致:越來越多的企業客戶正在從 On-Premise 的數倉方案,轉向基於雲(包含公有云和私有云)的解決方案,這種趨勢在美國 2B 市場已經被廣泛接受,在國內 2B 市場也已方興未艾。由於無可取代的彈性擴展性、容災性、低 TCO 和幾乎無限量的存儲空間,基於雲平臺的數據倉庫技術正在逐漸讓所有人相信擁抱雲原生纔是數據倉庫技術以及相關數據分析技術未來。雲原生的巨浪正在席捲全球的軟件產業,包括開源軟件和商業軟件。在數據倉庫這個細分領域,我們能明顯的感受到數據倉庫正在經歷以下幾代體系的演進:

第一代:傳統的數據倉庫

最早出現的是數據庫一體機,是由單獨的硬件軟件所構成,這種數倉的問題主要在兩個方面:第一,它需要專有的硬件,成本較高;第二,它的擴展性不高。在過去這樣的問題是可以被用戶接受的,但是在現今的大數據時代,有很多開源的技術可以用來在普通硬件上構建大數據平臺,不願意被單獨的供應商或者硬件平臺綁定,所以一體機模式的數倉越來越難得到普及。

這樣的背景很自然地催生了第二類數據倉庫的興起:

第二代:基於通用硬件的分佈式數據倉庫

這類的數倉方案通常可以基於通用硬件(Commodity Hardware),在可擴展性上相比較傳統的數倉有了質的飛躍。在筆者看來,這類的數倉也可以分爲兩大類,即 MPP 數倉(在商用數倉軟件的代表是 Greenplum,在開源數倉的代表有 Presto 等)和批處理數倉(典型代表是 Hive 和 Spark)。MPP 和批處理的區別有點超出本文的主要範圍,在此就不展開了。值得注意的是,和 Hadoop 有近親關係的 Hive 雖然非常有可能隨着 Hadoop 的巨輪一起慢慢消失,但是它卻爲第二類數倉帶來了一種極其通用的數據表元數據定義的標準,並被 Presto,Spark 等技術全面地沿襲,成爲了事實上的標準。

第二類的數據倉庫獲得了巨大的成功,放眼國內,無論是一線大廠還是不知名的小公司,都圍繞這類技術開發除了完整的數倉和分析平臺,大大地提高了大小企業對數據資產的發掘能力。但是這類數倉的弊端也慢慢地暴露出來:因爲數據不斷增加,需要不斷增加節點,導致企業不得不自行投入擴建機房,繼而進行全面的遷移數據工作。運維團隊和業務團隊無奈承受着背後的繁瑣和低效,苦不堪言。此時不斷成熟的雲廠商給大家帶來了新的可能:

第三代:第一代雲原生的數據倉庫

以 Amazon Redshift, Azure SQL DW 爲代表,在雲計算開始之初,雲廠商就爲用戶準備好了用於分析型業務的雲上數據倉庫產品。這類數倉產品一般都需要申請一個固定節點數量的集羣,都配有列式存儲技術、分佈式查詢等特性。但是,由於雲上有無限的計算節點資源可以申請,用戶可以隨時調節集羣中的計算節點數量。無論是集羣的啓停、擴容、升級,這些操作都可以在雲廠商的界面上通過幾次點擊完成,已經在雲原生度上與第二類數倉有顯著差異。

這一類數倉依託雲上無限擴容的基礎硬件設施,免除了運維人員在集羣規模擴容時的空間困擾,需要更多的資源只需要在網頁界面上點擊即可完成。但是這類數倉數據和計算沒有完成分離,會導致什麼問題呢?比如某個用戶已經申請了一個 10 臺機器的節點,這 10 個節點每個都有計算資源(CPU)和存儲資源(磁盤)。由於 workload 的增加,用戶發現需要增加更多的計算資源才能滿足,於是不得不把數倉配置從 10 個節點升級爲 15 個。但是,這額外的 5 個節點的存儲資源也是要收費的,即便用戶的數據在原來的 10 個節點中完全夠存。在這種情況下,用戶的訴求是買更多的計算資源,但實際情況是他不僅購買了更多的計算資源,還購買了用不上的存儲資源。這就大大增加了這樣的數倉方案的 TCO,限制了企業在數據資產的有效利用。

第四代:新一代的雲原生數據倉庫

以 Snowflake, Amazon Athena, Azure Synapse, Amazon Redshift Spectrum(嚴格地說 Amazon Redshift Spectrum 只是一個 Redshift 的插件)爲代表的新一代雲原生的數據倉庫,進一步實現了雲上數倉計算與存儲的分離。在第三類數倉中,即使用戶已經在對象存儲中準備好數據,仍然需要將數據導入到數倉後,才能進行查詢。而第四類數倉可以直接查詢用戶在對象存儲中的數據。在第三類數倉中,用戶如果發現集羣空間不足,不得不對集羣進行擴容,這樣不僅是在爲更多的存儲支付成本,而且在爲更多的計算支付成本,即使他不缺少計算資源。而在第四類數倉中,用戶在對象存儲中的數據按量計費,在數倉節點中的計算按量計費,兩者相互獨立。

這種新一代的存儲和計算分離的數倉架構催化了我們耳熟能詳的數據湖數倉架構體系。在這種架構下,所有的數據都可以可靠、廉價、方便地存儲到對象存儲上(Amazon S3,Azure blob storage, ADLS),雲廠商提供了完整的配套工具來確保用戶的應用數據庫、日誌、APP 的數據可以順利地落地到對象存儲上。這種區別於塊存儲和文件系統的存儲方式從根本上決定了雲原生數倉的存儲形態乃至設計形態:數據不再保存在某個節點的磁盤中,存儲和計算天然分離,計算所需的一切存儲,都來自遙遠的、無限的、透明的對象存儲中。


那總結一下,我們觀察到數倉或者是數據分析在雲上的趨勢,首先是充分的利用雲上的技術架構。不需要去操心機房的事情,不需要操心硬件的問題。第二點是會充分的利用雲上的對象存儲。第三點是會充分的利用雲上彈性計算資源的這個特點,根據你的需要申請更多的資源或者是釋放資源。經過一番梳理,我們可以看到數據倉庫正在慢慢向雲原生的、存儲計算分離的方向上發展。企業做技術選型,以及我們自身做技術戰略投入的時候,自然也需要尊重並擁抱這樣的時代趨勢。

現在,再回過頭來看這位我們最開始提到的美國客戶。通過雲原生的方案,我們基本已經解決了大部分的問題,再結合 Kyligence 的方案,針對高性能、高併發的痛點,也給出了比較好的解決方案。

Kyligence 的方案主要給用戶解決兩大關鍵的問題。一個是在雲原生解決方案當中的性能問題。一個是在雲原生的解決方案中語義層的問題,也就是數據口徑一致的問題。目的是爲了確保同一個公司內大家對數據的理解是一致的。

通過我們在 Apache Kylin 上的積累與在新技術上的探索,以及在 Data Placement 的智能優化。從設備層面,會做 RAM,SSD 和對象存儲之間的切換。從數據解決層面,在列式存儲,多維數據集等爲主的數據結構上進行切換。在服務層面,使用到Spark,ClickHouse 等計算中間件來完成用戶的計算需求。同時也希望通過自動化的手段幫助用戶減少手動調參或手動介入的必要。

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