FusionInsight怎么幫「宇宙行」建一個好的「云數(shù)據(jù)平臺」？

注：本篇博客根據(jù)雷鋒網(wǎng)舉辦的《銀行業(yè)AI生態(tài)云峰會》演講內(nèi)容改編。

大數(shù)據(jù)技術(shù)的「演進趨勢」

大數(shù)據(jù)從2010年開始到現(xiàn)在各種新技術(shù)層出不窮，最近圍繞云基礎(chǔ)設(shè)施又有非常多的創(chuàng)新發(fā)展。

很多企業(yè)早期的數(shù)據(jù)分析系統(tǒng)主要構(gòu)建在數(shù)據(jù)倉庫之上，有的甚至連數(shù)據(jù)倉庫都沒有，使用TP類關(guān)系型數(shù)據(jù)庫直接對接BI系統(tǒng)實現(xiàn)。這類系統(tǒng)一般以物理機形態(tài)的一體機部署，分布式能力比較弱，隨著數(shù)據(jù)規(guī)模巨大增長，尤其是移動互聯(lián)網(wǎng)發(fā)展，傳統(tǒng)數(shù)據(jù)庫難以支撐這種大體量的數(shù)據(jù)分析需求。

在這個背景下，Hadoop技術(shù)應(yīng)運而生并飛速發(fā)展，有效地解決了大數(shù)據(jù)量的分析和處理需求。Hadoop最開始的應(yīng)用多用于日志類非關(guān)系型的數(shù)據(jù)處理，主要基于MapReduce編程模型，隨著SQL on Hadoop的發(fā)展，關(guān)系型數(shù)據(jù)的處理能力也越來越強。

早期的Hadoop主要基于物理機部署，一直到現(xiàn)在仍然是最成熟的部署模式。雖然Hadoop計算與存儲之間是解耦的，但是絕大部分實踐都還是會把計算與存儲進行一體化部署，Hadoop調(diào)度系統(tǒng)會把計算調(diào)到數(shù)據(jù)所在位置上進行就近計算，就近計算大大提高了系統(tǒng)的處理能力，后期Spark、flink等都繼承了這種架構(gòu)優(yōu)勢。

自從亞馬遜推出云IT基礎(chǔ)設(shè)施以來，越來越多的企業(yè)都將自己的IT業(yè)務(wù)遷移到云上，因此，在云上開展大數(shù)據(jù)業(yè)務(wù)順理成章?；旧纤械脑茝S家也都提供云上大數(shù)據(jù)解決方案。

那么，在云上部署大數(shù)據(jù)與原來基于物理機的on premise部署方式又有哪些不同呢？

首先，盡量利用云的計算資源，包括云虛機、容器以滿足資源的快速發(fā)放，包括裸金屬服務(wù)BMS以提供近似物理機的高性能處理計算資源。

其次，各云廠商都推出存算分離的大數(shù)據(jù)架構(gòu)，亞馬遜是最早實現(xiàn)對象存儲替代HDFS，因為對象存儲相對HDFS三副本成本相對較低。計算與存儲分離之后帶來了很多好處，但是也面臨著諸多挑戰(zhàn)。這個方向一直在不斷地完善，目前，云上大數(shù)據(jù)存算分離已經(jīng)發(fā)展的比較成熟。

Lakehouse是最近非常熱的一個大數(shù)據(jù)概念。2020年1月份databricks發(fā)表的一篇博客中首次提到Lakehouse這個概念。之后，在今年的1月份再次發(fā)表一篇論文，系統(tǒng)闡述如何構(gòu)建Lakehouse。

很多數(shù)據(jù)分析系統(tǒng)都構(gòu)建在數(shù)據(jù)倉庫、數(shù)據(jù)湖的基礎(chǔ)上，有些將兩者結(jié)合形成如圖的兩層架構(gòu)，大型企業(yè)后面這種形式更多。這種數(shù)據(jù)湖、數(shù)據(jù)倉庫的兩層架構(gòu)到底存在哪些問題呢？

可以看到，數(shù)據(jù)湖和數(shù)倉的很多數(shù)據(jù)是雷同的，這樣就會導(dǎo)致以下三個問題：

第一，數(shù)據(jù)要存儲兩份，相應(yīng)的存儲成本翻倍。

第二，數(shù)據(jù)湖和數(shù)倉的數(shù)據(jù)存兩份，就需要維護數(shù)據(jù)的一致性，這個過程主要通過ETL來保證，維護代價比較高，而且往往很難保持一致，可靠性不是很高。

第三，數(shù)據(jù)的時效性。數(shù)據(jù)湖將大批量的數(shù)據(jù)集成起來并不容易。由于數(shù)據(jù)湖大多基于Hive來管理，而其底層HDFS存儲并不支持修改，所以數(shù)據(jù)僅支持追加的模式來集成。而業(yè)務(wù)生產(chǎn)系統(tǒng)的數(shù)據(jù)變化不是只有追加的數(shù)據(jù)，還有很多更新的操作，如果要對數(shù)據(jù)湖的數(shù)據(jù)進行更新，就需要按分區(qū)先合并后重寫。這樣就增加了數(shù)據(jù)合并處理的難度，更多的時候只能通過一天合并一次的T+1的模式，T+1的模式也就意味著大部分數(shù)據(jù)對后端應(yīng)用的可見性差了一天，當前看到的數(shù)據(jù)實際上是昨天的，意味著數(shù)倉里面的數(shù)據(jù)始終并不新鮮。

LakeHouse就是期望解決數(shù)據(jù)湖與數(shù)倉的融合分析的問題。LakeHouse提出通過提供ACID的開放格式存儲引擎來解決數(shù)據(jù)的時效性問題，開放格式另一個好處在于數(shù)據(jù)湖里的數(shù)據(jù)可以面向多種分析引擎，如Hive、Spark、Flink等都可以對數(shù)據(jù)進行訪問分析,而且AI引擎也可以訪問Lakehouse數(shù)據(jù)做高級分析。

對于諸如Hudi、Iceberg、DeltaLake增量數(shù)據(jù)管理框架，由于其提供了ACID的能力，數(shù)據(jù)可以進行更新操作以及并發(fā)讀寫，因此對存儲數(shù)據(jù)存儲要求也更高，比如需要支持時間旅行、零拷貝等能力，才能保證數(shù)據(jù)隨時可以回溯。

Lakehouse除了支撐傳統(tǒng)的BI以及報表類的應(yīng)用，還要支持高級的AI類的分析，數(shù)據(jù)分析師、數(shù)據(jù)科學家可以直接在Lakehouse進行數(shù)據(jù)科學計算和機器學習。

另外，Lakehouse的最佳實踐是基于存算分離架構(gòu)來構(gòu)建。存算分離最大的問題在于網(wǎng)絡(luò)，各云廠家以及大數(shù)據(jù)廠家，都探索了很多的手段來解決云存儲本身訪問的性能問題，如提供本地緩存功能來提高數(shù)據(jù)處理的效率。

Lakehouse架構(gòu)可以實現(xiàn)離線與實時的融合統(tǒng)一，數(shù)據(jù)通過ACID入湖。

如圖所示是經(jīng)典的大數(shù)據(jù)的Lampda架構(gòu)，藍色的處理流是批處理，紅色的則是流處理，在應(yīng)用層形成實時合并視圖。這個架構(gòu)存在的問題就是批處理和流處理是割裂的，數(shù)據(jù)管理之間的協(xié)同比較麻煩，而且不同的開發(fā)工具對開發(fā)要求的能力不同，對系統(tǒng)維護工程師和數(shù)據(jù)開發(fā)人員都是較大的挑戰(zhàn)。

針對這種的情況，Lakehouse架構(gòu)可以將批處理和流處理合并成一個Lakehouse view，通過CDC把業(yè)務(wù)生產(chǎn)系統(tǒng)數(shù)據(jù)實時抽取到數(shù)據(jù)湖，實時加工后送到后端OLAP的系統(tǒng)中對外開放，這個過程可以做到端到端的分鐘級時延。

Lakehouse本身的概念比較新，大家都還在做著各種各樣的實踐以進行完善。

FusionInsight在工商銀行實踐的三大階段

工行早期主要以O(shè)racle 、Teradata構(gòu)建其數(shù)據(jù)系統(tǒng)。數(shù)倉為Teradata，數(shù)據(jù)集市是Oracle Exadata。

2013年開始，我們在工行上線了銀行業(yè)第一個大數(shù)據(jù)平臺，當時的大數(shù)據(jù)平臺以單一的應(yīng)用為主，例如一些日志分析、TD的新業(yè)務(wù)卸載和明細查詢。

2015年之后，對數(shù)據(jù)系統(tǒng)進行整合合并，包括通過GaussDB替代Teradata數(shù)倉，形成了融合數(shù)倉，在工行被稱之為一湖兩庫，以FusionInsight構(gòu)建數(shù)據(jù)湖底座以支持全量的數(shù)據(jù)加工，同時實時分析、交互式分析等業(yè)務(wù)也在其中得以開展。

2020年初，開始構(gòu)建云數(shù)據(jù)平臺，將整個數(shù)據(jù)湖遷移到云上以實現(xiàn)大數(shù)據(jù)的云化和服務(wù)化，同時構(gòu)建存算分離的架構(gòu)。另外還引入AI技術(shù)。

工行的技術(shù)演進方向是從單一走向多元、從集中式走向分布式、從孤立系統(tǒng)走向融合、從傳統(tǒng)IT走向云原生的過程。

第一代大數(shù)據(jù)平臺更多的是根據(jù)應(yīng)用需求按需建設(shè)，這個時期對Hadoop究竟能解決什么問題并沒有很深的認知。

首先想到的是解決業(yè)務(wù)創(chuàng)新，以及在數(shù)倉里做不出來的業(yè)務(wù)，比如把大批量的數(shù)據(jù)合并作業(yè)卸載到Hadoop系統(tǒng)里。

這個時期缺少系統(tǒng)規(guī)劃，導(dǎo)致單集群規(guī)模小，集群數(shù)量不斷增多，維護成本較高，資源利用率低。另外，很多數(shù)據(jù)是需要在多個業(yè)務(wù)間共享的，需要在集群間進行拷貝遷移，大量冗余的數(shù)據(jù)增加了資源的消耗。同時，數(shù)據(jù)需要根據(jù)不同的場景存儲在不同的技術(shù)組件中，利用不同的技術(shù)組件進行處理，也導(dǎo)致ETL鏈路較長、開發(fā)效率低，維護的代價高。因此，需要對整個大數(shù)據(jù)平臺的架構(gòu)進行優(yōu)化。

第二階段將多個大數(shù)據(jù)集群進行了合并，形成數(shù)據(jù)湖，其特點在于數(shù)據(jù)處理層統(tǒng)一規(guī)劃，集中入湖、集中管理。使得整體的管理、維護、開發(fā)效率得到極大提升。

將原始數(shù)據(jù)入湖之后，還會對數(shù)據(jù)進行一些加工處理以形成匯總數(shù)據(jù)和主題數(shù)據(jù)，并在數(shù)據(jù)湖里進行集中治理，數(shù)據(jù)加工處理后送到數(shù)倉或者數(shù)據(jù)集市，以及后端的其他系統(tǒng)里。

基于這種架構(gòu)，數(shù)據(jù)湖的應(yīng)用效率得以極大提升。經(jīng)過幾年發(fā)展，當前集群規(guī)模已經(jīng)達到1000多節(jié)點，數(shù)據(jù)量幾十PB，日均處理作業(yè)數(shù)大概是10萬，賦能于180多個總行應(yīng)用和境內(nèi)外41家分行及子公司。

但是，將所有數(shù)據(jù)存進一個集中的數(shù)據(jù)湖也帶來了很多管理方面的難題。

數(shù)據(jù)湖支撐的業(yè)務(wù)和用戶對SLA高低的要求不盡相同，如何給不同部門、不同業(yè)務(wù)線、以及不同用戶的作業(yè)進行統(tǒng)一管理比較關(guān)鍵，核心是多租戶能力，Hadoop社區(qū)YARN調(diào)度功能早期并不是很強，上千個節(jié)點的管理能力較弱，雖然現(xiàn)在的新版本得以改進。

早期的集群到幾百個節(jié)點后，調(diào)度管理系統(tǒng)就難以支撐。因此我們開發(fā)了 Superior的調(diào)度器加以完善。工行的1000節(jié)點集群在銀行業(yè)算是比較大的數(shù)量級。我們在華為內(nèi)部構(gòu)建了從500到幾千直到10000節(jié)點的一個集群，這個過程已經(jīng)對大集群的管理能力提前進行鋪墊，在工行的應(yīng)用就相對比較順利。

如圖所示，我們把整個的資源管理按照部門多級資源池進行管理，通過superior調(diào)度器，按照不同的策略進行調(diào)度以支撐不同的SLA。整體效果而言，資源利用率得以成倍提升。

還有一些其它組件，尤其是像HBase的region server是基于JAVA的JVM來管理內(nèi)存，能利用的內(nèi)存很有限，物理機資源基本用不滿，資源不能充分利用。

為了解決這個問題，我們實現(xiàn)在一個物理機上可以部署多實例，盡量將一個物理機的資源充分利用，ES也是按照這種方式來處理。

集群變大之后，其可用性和可靠性也存在著很大的問題。大集群一旦出現(xiàn)問題導(dǎo)致全面癱瘓，對業(yè)務(wù)影響非常大。所以，銀行業(yè)必須全面具備兩地三中心的可靠性。

首先是跨AZ部署的能力，AZ實際是屬于云上的一個概念，傳統(tǒng)的 ICT機房里更多的是跨DC數(shù)據(jù)中心的概念，跨AZ部署意味著一個集群可以跨兩個AZ或者三個AZ進行部署。

Hadoop本身具備多副本機制，以多副本機制為基礎(chǔ)，可以將多個副本放置在不同的機房里。但是以上條件并非開源能力可以支撐，需要補充一些副本放置和調(diào)度的策略，在調(diào)度時要感知數(shù)據(jù)究竟放置在哪個AZ，任務(wù)調(diào)度到相應(yīng)的AZ保證數(shù)據(jù)就近處理，盡量避免AZ之間由于數(shù)據(jù)傳輸帶來的網(wǎng)絡(luò)IO。

另外，容災(zāi)能力還可以通過異地主備來實現(xiàn)，跨AZ能力要求機房之間的網(wǎng)絡(luò)時延達到毫秒級，時延太高可能無法保證很多業(yè)務(wù)的開展。異地的容災(zāi)備份，即一個主集群和一個備集群。平時，備集群并不承擔業(yè)務(wù)，僅主集群承載業(yè)務(wù)，一旦主集群發(fā)生故障，備集群隨之進行接管，但是相應(yīng)的代價也會較大，比如有1000個節(jié)點的主集群，就要構(gòu)建1000個節(jié)點的備集群，所以多數(shù)情況下，主備容災(zāi)更多的是僅構(gòu)建關(guān)鍵數(shù)據(jù)關(guān)鍵業(yè)務(wù)的備份，并非將其全部做成主備容載。

大數(shù)據(jù)集群需要不斷擴容，隨著時間的推移，硬件會升級換代，升級換代之后必然出現(xiàn)兩種情況，其中之一就是新采購機器的CPU和內(nèi)存能力，以及磁盤的容量，都比原來增大或者升高了，需要考慮如何在不同的跨代硬件上實現(xiàn)數(shù)據(jù)均衡。

換盤的操作也會導(dǎo)致磁盤的不均衡，如何解決數(shù)據(jù)均衡是一個很重要的課題。

我們專門開發(fā)了按照可用空間放置數(shù)據(jù)的能力，保證了數(shù)據(jù)是按照磁盤以及節(jié)點的可用空間進行放置。同時，對跨代節(jié)點按規(guī)格進行資源池劃分，對于早期比較老舊且性能相對差一些的設(shè)備，可以組成一個邏輯資源池用于跑Hive作業(yè)，而內(nèi)存多的新設(shè)備組成另一個資源池則用來跑spark，資源池通過資源標簽進行區(qū)分隔離，分別調(diào)度。

集群變大之后，任何變更導(dǎo)致業(yè)務(wù)中斷的影響都非常大。所以，升級操作、補丁操作都需要考慮如何保證業(yè)務(wù)不會中斷。

比如對1000個節(jié)點集成進行一次版本升級。如果整體停機升級，整個過程至少需要花費12個小時。

滾動升級的策略可實現(xiàn)集群節(jié)點一個一個滾動分時升級，逐步將所有節(jié)點全部升級成最新的版本。但是開源的社區(qū)跨大版本并不保證接口的兼容性，會導(dǎo)致新老版本無法升級。因此我們研發(fā)了很多的能力以保證所有版本之間都能滾動升級。從最早的Hadoop版本一直到Hadoop3，所有的組件我們都能保證滾動升級。這也是大集群的必備能力。

數(shù)據(jù)湖的構(gòu)建解決了工行的數(shù)據(jù)管理的難題，但同時也面臨著很多新的挑戰(zhàn)和問題。

一般而言，很多大企業(yè)的硬件都是集中采購，并沒有考慮到大數(shù)據(jù)不同場景對資源訴求的不一，而且計算與存儲的配比并未達到很好的均衡，存在較大的浪費。

其次，不同批次的硬件之間也存在差異，有些可能還會使用不同的操作系統(tǒng)版本，導(dǎo)致了一個集群內(nèi)有不同的硬件、不同的操作系統(tǒng)版本。雖然可以用技術(shù)手段解決硬件異構(gòu)、OS異構(gòu)的問題，但是持續(xù)維護的代價相當高。

再次，大數(shù)據(jù)手工部署效率低。往往開展一個新業(yè)務(wù)的時候，從硬件的采購到網(wǎng)絡(luò)配置、再到操作系統(tǒng)安裝，整個系統(tǒng)交付周期至少需要一個月。

最后，資源彈性不足，如果上新業(yè)務(wù)時面臨資源不足，就需要擴容。申請采購機器和資源導(dǎo)致上線的周期較長，我們有時給客戶部署一個新業(yè)務(wù)，往往大多時間是在等到資源到位。另外，不同資源池之間的資源無法共享，也存在著一定的浪費。

所以工行要引入云的架構(gòu)。

FusionInsight很早就上了華為云，即華為云上的MRS服務(wù)。

當下工行和其他很多銀行都在部署云平臺，將大數(shù)據(jù)部署到云平臺上。但大規(guī)模的大數(shù)據(jù)集群部署到云上還存在著一些挑戰(zhàn)，基于云原生的存算分離架構(gòu)來部署大數(shù)據(jù)業(yè)務(wù)有很多優(yōu)勢。

首先，將硬件資源池化，資源池化之后對上層就是比較標準的計算資源，計算和存儲可以靈活的擴展，利用率相對較高。

其次，基于云平臺的大數(shù)據(jù)環(huán)境搭建，全部自動化，從硬件資源準備到軟件安裝，僅用一小時完成。

再次，在申請集群擴容資源彈性時，無需準備，可以很快的在大資源池進行統(tǒng)一調(diào)配。一般而言，云上只要預(yù)留了資源，空間資源可以很快加入到大數(shù)據(jù)的資源池里，新業(yè)務(wù)上線也會變得非常敏捷。

再說存算分離，存儲主要是以對象存儲為主，用低成本的對象存儲替代原來HDFS的三副本的能力，對象存儲一般提供兼容HDFS的接口，在此基礎(chǔ)上，對象存儲可以給大數(shù)據(jù)、 AI等提供一個統(tǒng)一的存儲，降低存儲成本，運維的效率得以提高。

但是，對象存儲的性能不是很好，需要圍繞大數(shù)據(jù)的業(yè)務(wù)特點解決以下問題。

第一個，就是元數(shù)據(jù)，因為大數(shù)據(jù)是個重載計算，在計算的過程中讀IO很高。讀取數(shù)據(jù)的過程中。對象存儲的元數(shù)據(jù)性能是個很大的瓶頸，因此需要提升元數(shù)據(jù)的讀寫能力。

第二個，網(wǎng)絡(luò)帶寬，存儲與計算之間的網(wǎng)絡(luò)IO對網(wǎng)絡(luò)帶寬的需求比較高。

第三個，網(wǎng)絡(luò)時延，大數(shù)據(jù)計算是就近計算，數(shù)據(jù)在哪里相應(yīng)的計算就會在哪里，存儲數(shù)據(jù)是優(yōu)先讀本地盤，之后是讀網(wǎng)絡(luò)。時延存在一定的敏感性。

我們主要是從緩存、部分計算下推上做一些優(yōu)化，整體上而言，存算分離架構(gòu)的性能跟一體化相比，除了個別用例有差距，整體性能都更高，尤其是寫場景，因為寫對象存儲是寫EC，而不用寫三副本，寫1.2個副本就可以了。

最后，整體的 TCO大概得到30%~60%的下降。整體的性能與周邊其他產(chǎn)品對比還是具有很大的優(yōu)勢。

大數(shù)據(jù)部署到云上，對于大集群而言，虛機并沒有太大優(yōu)勢，因為數(shù)據(jù)池子夠大，虛機還會帶來性能的損耗，而且其性能與物理機有一定差距。而且，基于SLA隔離要求，大數(shù)據(jù)資源池在私有云部署，很多時候還是需要獨占，其資源無法和別的業(yè)務(wù)共享。

而裸金屬服務(wù)實際上可以很好的解決這些問題，它的性能接近物理機，而且可以分鐘級完成裸金屬服務(wù)器的發(fā)放，包括整個網(wǎng)絡(luò)配置，OS安裝。

網(wǎng)絡(luò)部分有專門的擎天網(wǎng)絡(luò)加速卡，對裸機網(wǎng)絡(luò)進行管理，而且網(wǎng)絡(luò)性能比原來的物理網(wǎng)卡的性能更高，在裸金屬服務(wù)器上開展大規(guī)模大數(shù)據(jù)業(yè)務(wù)是云上的最佳部署方案。

未來展望：湖倉一體

工行和我們也在探索湖倉一體的解決方案。

華為云湖倉一體在存算分離的基礎(chǔ)上，將數(shù)據(jù)管理層獨立出來，其中包含了幾個部分，第一個是數(shù)據(jù)集成，數(shù)據(jù)從各種各樣的外部系統(tǒng)入湖。第二個是元數(shù)據(jù)集成，由于Hadoop數(shù)據(jù)湖上的元數(shù)據(jù)通過Hive管理，我們提供一個兼容Hive Metastore的獨立元數(shù)據(jù)服務(wù)。第三個是數(shù)據(jù)的授權(quán)以及脫敏這些安全策略，我們要將其在Lake Formation這一層進行統(tǒng)一閉環(huán)。

數(shù)據(jù)的底座構(gòu)建好之后，數(shù)據(jù)分析服務(wù)如大數(shù)據(jù)的服務(wù)、數(shù)倉的服務(wù)、圖計算、AI計算都是在同樣的一個數(shù)據(jù)視圖上進行計算處理。數(shù)倉DWS的服務(wù)本質(zhì)是本地存儲，數(shù)倉也可以通過它的一個引擎訪問Lakehouse中的數(shù)據(jù)。這樣數(shù)倉自己在本地有一個加速的數(shù)據(jù)層，同時也可以訪問Lakehouse。

在此基礎(chǔ)上我們通過一個架構(gòu)來實現(xiàn)這三種湖，持續(xù)演進。

藍色數(shù)據(jù)流是離線數(shù)據(jù)流，實現(xiàn)離線數(shù)據(jù)湖能力，數(shù)據(jù)通過批量集成，存儲到Hudi，再通過Spark進行加工。

紅色數(shù)據(jù)流是實時流，數(shù)據(jù)通過CDC實時捕獲，通過Flink實時寫入Hudi；通過Redis做變量緩存，以實現(xiàn)實時數(shù)據(jù)加工處理，之后送到諸如Clickhouse 、Redis、Hbase等專題集市里對外提供服務(wù)。

同時，我們還開發(fā)了HetuEngine數(shù)據(jù)虛擬化引擎，將數(shù)據(jù)湖里面的數(shù)據(jù)以及其他專題集市里的數(shù)據(jù)進行多數(shù)據(jù)源關(guān)聯(lián)分析，形成邏輯數(shù)據(jù)湖。

雖然HetuEngine可以連接不同的數(shù)據(jù)源，但并不意味著所有應(yīng)用只能通過HetuEngine來訪問數(shù)據(jù)，應(yīng)用還是可以通過各數(shù)據(jù)源原生接口進行訪問。僅需要不同專題數(shù)據(jù)之間進行聯(lián)合分析時，才需要通過HetuEngine統(tǒng)一訪問。

如下是具體的實施計劃：

第一個，引入Hudi，構(gòu)建一個數(shù)據(jù)湖的數(shù)據(jù)管理，每年大概可以節(jié)省幾百萬。

第二個，引入HetuEngine，實現(xiàn)數(shù)據(jù)湖內(nèi)的數(shù)據(jù)免搬遷的查詢分析。避免一些不必要的ETL過程。

第三個，引入ClickHouse，ClickHouse在OLAP領(lǐng)域有著非常好的處理性能和很多優(yōu)勢，因此考慮將其在工行落地。

數(shù)據(jù)湖以Hive作為存儲，采用一天一次批量集成、批量合并的方案，即T+1的數(shù)據(jù)處理模式。這種模式存在幾個比較大的業(yè)務(wù)痛點：

第一，數(shù)據(jù)延時比較高，后端服務(wù)看到的數(shù)據(jù)并不是最新的。

第二，跑批作業(yè)在夜里進行，而白天資源利用率較低，但集群資源是按照高峰期需求來構(gòu)建，造成很大的資源浪費。

第三， Hive不支持更新，數(shù)據(jù)合并需要開發(fā)較多代碼實現(xiàn)，如把新數(shù)據(jù)臨時表與原Hive表進行左右關(guān)聯(lián)后覆蓋原來整表或者部分分區(qū)表，開發(fā)成本比較高，業(yè)務(wù)邏輯復(fù)雜。

引入Hudi就可以在很大程度上解決這些問題。數(shù)據(jù)通過CDC入湖，通過Spark或者Flink寫入Hudi，支持實時更新，端到端可以做到分鐘級的時延。數(shù)據(jù)以非常小的微批形式合并到數(shù)據(jù)湖，分散跑批使得資源白天和晚上都能得到充分利用，數(shù)據(jù)湖集群TCO預(yù)計可以下降20%。此外，數(shù)據(jù)集成腳本開發(fā)可以利用Hudi的Update能力，原來Hive要寫幾百行的代碼，只需一行腳本即可完成，開發(fā)效率提升很大。

工行數(shù)據(jù)湖使用Hive來承載靈活查詢業(yè)務(wù)，如SAS使用Hive SQL來訪問數(shù)據(jù)湖，訪問效率比較低，響應(yīng)時間長，并發(fā)能力也不足。

另外數(shù)據(jù)湖與數(shù)倉的兩層架構(gòu)導(dǎo)致了大量的重復(fù)數(shù)據(jù)，有較多關(guān)聯(lián)分析需求，關(guān)聯(lián)處理必然涉及到湖倉之間大量ETL。比如為了支撐BI工具的分析訴求，需要數(shù)據(jù)湖和數(shù)倉數(shù)據(jù)關(guān)聯(lián)處理加工，并將加工之后的數(shù)據(jù)導(dǎo)入OLAP引擎。整體數(shù)據(jù)鏈路比較長，分析效率和開發(fā)效率都很低。

通過HetuEngine數(shù)據(jù)虛擬化實現(xiàn)湖倉協(xié)同分析，一方面替代Hive SQL訪問 Hive的數(shù)據(jù)，只需1/5的資源即可支撐大概原來5倍并發(fā)，同時訪問時延降到秒級。另一方面可同時訪問Hive和DWS提供秒級的關(guān)聯(lián)查詢，可以減少80%的系統(tǒng)間的數(shù)據(jù)搬遷，大量的減少 ETL的過程。

傳統(tǒng)的OLAP方案一般用MySQL、Oracle或者其他的OLAP引擎，這些引擎因其處理能力有限，數(shù)據(jù)一般按照專題或者主題進行組織后與BI工具對接，導(dǎo)致BI用戶和提供數(shù)據(jù)的數(shù)據(jù)工程師脫節(jié)。比如BI用戶有一個新的需求，所需的數(shù)據(jù)沒有在專題集市中，需要將需求給到數(shù)據(jù)工程師，以便開發(fā)相應(yīng)的ETL任務(wù)，這個過程往往需要部門間協(xié)調(diào)，時間周期比較長。

現(xiàn)在可以將所有明細數(shù)據(jù)以大寬表的形式加載Clickhouse，BI用戶可以基于Clickhouse大寬表進行自助分析，對數(shù)據(jù)工程師供數(shù)要求就會少很多，甚至大部分情況下的新需求都不需要重新供數(shù)，開發(fā)效率和BI報表上線率都會得到極大提升。

這套方法論在我們內(nèi)部實踐效果非常好，原來我們基于傳統(tǒng)OLAP引擎建模，受限于開發(fā)效率，幾年才上線了幾十個報表。但是切到Clickhouse后，幾個月之內(nèi)就上了大概上百個報表，報表開發(fā)效率極大提升。

FusionInsight 應(yīng)用平臺ROMA

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。