0
| 本文作者： 周舟 | 2021-02-21 14:45 |
銀行在構(gòu)建大數(shù)據(jù)架構(gòu)的同時(shí)，面臨著諸多問題和挑戰(zhàn)。
華為云FusionInsight首席架構(gòu)師徐禮峰認(rèn)為，很多大企業(yè)的硬件都是集中采購(gòu)，并沒有考慮到大數(shù)據(jù)不同場(chǎng)景對(duì)資源訴求的不一，而且計(jì)算與存儲(chǔ)的配比并未達(dá)到很好的均衡，存在較大的浪費(fèi)。不同批次的硬件之間也存在差異，雖然可以用技術(shù)手段解決硬件異構(gòu)、OS異構(gòu)的問題，但是持續(xù)維護(hù)的代價(jià)相當(dāng)高。
此外，大數(shù)據(jù)手工部署效率低、系統(tǒng)交付周期長(zhǎng)、資源池之間的資源無(wú)法共享等問題，都會(huì)給銀行造成浪費(fèi)。
面對(duì)這些挑戰(zhàn)，許多銀行都選擇將大數(shù)據(jù)部署到云平臺(tái)上。
徐禮峰表示：“基于云原生的存算分離架構(gòu)來(lái)部署大數(shù)據(jù)業(yè)務(wù)有很多優(yōu)勢(shì)?！?/p>
“首先，硬件資源池化后，計(jì)算和存儲(chǔ)可以靈活的擴(kuò)展，利用率相對(duì)較高；其次，基于云平臺(tái)的大數(shù)據(jù)環(huán)境搭建，全部自動(dòng)化，從硬件資源準(zhǔn)備到軟件安裝，僅用一小時(shí)完成；再者，云上只要預(yù)留了資源，空間資源可以很快加入到大數(shù)據(jù)的資源池里，新業(yè)務(wù)上線也會(huì)變得非常敏捷?！?/p>
以工商銀行為例，2020年初，在華為云的幫助下，工商銀行開始構(gòu)建云數(shù)據(jù)平臺(tái)，將整個(gè)數(shù)據(jù)湖遷移到云上以實(shí)現(xiàn)大數(shù)據(jù)的云化和服務(wù)化，并在金融同業(yè)中首家推出了大數(shù)據(jù)風(fēng)險(xiǎn)信息服務(wù)產(chǎn)品融安e信，成功服務(wù)了260家金融機(jī)構(gòu)和4.6萬(wàn)家企業(yè)。
近日，雷鋒網(wǎng)《銀行業(yè)AI生態(tài)云峰會(huì)》邀請(qǐng)到徐禮鋒作為「大數(shù)據(jù)平臺(tái)」賽道的科技專家，為大家?guī)?lái)其多年在金融大行服務(wù)的大數(shù)據(jù)平臺(tái)設(shè)計(jì)理念和交付實(shí)踐。
以下為徐禮鋒的演講內(nèi)容，雷鋒網(wǎng)AI金融評(píng)論作了不改變?cè)獾木庉嫞?/strong>
感謝雷鋒網(wǎng)舉辦這個(gè)活動(dòng)，讓我有機(jī)會(huì)分享華為FusionInsight在工行的實(shí)踐。
大數(shù)據(jù)從2010年開始到現(xiàn)在各種新技術(shù)層出不窮，最近圍繞云基礎(chǔ)設(shè)施又有非常多的創(chuàng)新發(fā)展。
很多企業(yè)早期的數(shù)據(jù)分析系統(tǒng)主要構(gòu)建在數(shù)據(jù)倉(cāng)庫(kù)之上，有的甚至連數(shù)據(jù)倉(cāng)庫(kù)都沒有，使用TP類關(guān)系型數(shù)據(jù)庫(kù)直接對(duì)接BI系統(tǒng)實(shí)現(xiàn)。這類系統(tǒng)一般以物理機(jī)形態(tài)的一體機(jī)部署，分布式能力比較弱，隨著數(shù)據(jù)規(guī)模巨大增長(zhǎng)，尤其是移動(dòng)互聯(lián)網(wǎng)發(fā)展，傳統(tǒng)數(shù)據(jù)庫(kù)難以支撐這種大體量的數(shù)據(jù)分析需求。
在這個(gè)背景下，Hadoop技術(shù)應(yīng)運(yùn)而生并飛速發(fā)展，有效地解決了大數(shù)據(jù)量的分析和處理需求。Hadoop最開始的應(yīng)用多用于日志類非關(guān)系型的數(shù)據(jù)處理，主要基于MapReduce編程模型，隨著SQL on Hadoop的發(fā)展，關(guān)系型數(shù)據(jù)的處理能力也越來(lái)越強(qiáng)。
早期的Hadoop主要基于物理機(jī)部署，一直到現(xiàn)在仍然是最成熟的部署模式。雖然Hadoop計(jì)算與存儲(chǔ)之間是解耦的，但是絕大部分實(shí)踐都還是會(huì)把計(jì)算與存儲(chǔ)進(jìn)行一體化部署，Hadoop調(diào)度系統(tǒng)會(huì)把計(jì)算調(diào)到數(shù)據(jù)所在位置上進(jìn)行就近計(jì)算，就近計(jì)算大大提高了系統(tǒng)的處理能力，后期Spark、flink等都繼承了這種架構(gòu)優(yōu)勢(shì)。
自從亞馬遜推出云IT基礎(chǔ)設(shè)施以來(lái)，越來(lái)越多的企業(yè)都將自己的IT業(yè)務(wù)遷移到云上，因此，在云上開展大數(shù)據(jù)業(yè)務(wù)順理成章?；旧纤械脑茝S家也都提供云上大數(shù)據(jù)解決方案。
那么，在云上部署大數(shù)據(jù)與原來(lái)基于物理機(jī)的on premise部署方式又有哪些不同呢？
首先，盡量利用云的計(jì)算資源，包括云虛機(jī)、容器以滿足資源的快速發(fā)放，包括裸金屬服務(wù)BMS以提供近似物理機(jī)的高性能處理計(jì)算資源。
其次，各云廠商都推出存算分離的大數(shù)據(jù)架構(gòu)，亞馬遜是最早實(shí)現(xiàn)對(duì)象存儲(chǔ)替代HDFS，因?yàn)閷?duì)象存儲(chǔ)相對(duì)HDFS三副本成本相對(duì)較低。計(jì)算與存儲(chǔ)分離之后帶來(lái)了很多好處，但是也面臨著諸多挑戰(zhàn)。這個(gè)方向一直在不斷地完善，目前，云上大數(shù)據(jù)存算分離已經(jīng)發(fā)展的比較成熟。
Lakehouse是最近非常熱的一個(gè)大數(shù)據(jù)概念。2020年1月份databricks發(fā)表的一篇博客中首次提到Lakehouse這個(gè)概念。之后，在今年的1月份再次發(fā)表一篇論文，系統(tǒng)闡述如何構(gòu)建Lakehouse。
很多數(shù)據(jù)分析系統(tǒng)都構(gòu)建在數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖的基礎(chǔ)上，有些將兩者結(jié)合形成如圖的兩層架構(gòu)，大型企業(yè)后面這種形式更多。這種數(shù)據(jù)湖、數(shù)據(jù)倉(cāng)庫(kù)的兩層架構(gòu)到底存在哪些問題呢？
可以看到，數(shù)據(jù)湖和數(shù)倉(cāng)的很多數(shù)據(jù)是雷同的，這樣就會(huì)導(dǎo)致以下三個(gè)問題：
第一，數(shù)據(jù)要存儲(chǔ)兩份，相應(yīng)的存儲(chǔ)成本翻倍。
第二，數(shù)據(jù)湖和數(shù)倉(cāng)的數(shù)據(jù)存兩份，就需要維護(hù)數(shù)據(jù)的一致性，這個(gè)過程主要通過ETL來(lái)保證，維護(hù)代價(jià)比較高，而且往往很難保持一致，可靠性不是很高。
第三，數(shù)據(jù)的時(shí)效性。數(shù)據(jù)湖將大批量的數(shù)據(jù)集成起來(lái)并不容易。由于數(shù)據(jù)湖大多基于Hive來(lái)管理，而其底層HDFS存儲(chǔ)并不支持修改，所以數(shù)據(jù)僅支持追加的模式來(lái)集成。而業(yè)務(wù)生產(chǎn)系統(tǒng)的數(shù)據(jù)變化不是只有追加的數(shù)據(jù)，還有很多更新的操作，如果要對(duì)數(shù)據(jù)湖的數(shù)據(jù)進(jìn)行更新，就需要按分區(qū)先合并后重寫。這樣就增加了數(shù)據(jù)合并處理的難度，更多的時(shí)候只能通過一天合并一次的T+1的模式，T+1的模式也就意味著大部分?jǐn)?shù)據(jù)對(duì)后端應(yīng)用的可見性差了一天，當(dāng)前看到的數(shù)據(jù)實(shí)際上是昨天的，意味著數(shù)倉(cāng)里面的數(shù)據(jù)始終并不新鮮。
LakeHouse就是期望解決數(shù)據(jù)湖與數(shù)倉(cāng)的融合分析的問題。LakeHouse提出通過提供ACID的開放格式存儲(chǔ)引擎來(lái)解決數(shù)據(jù)的時(shí)效性問題，開放格式另一個(gè)好處在于數(shù)據(jù)湖里的數(shù)據(jù)可以面向多種分析引擎，如Hive、Spark、Flink等都可以對(duì)數(shù)據(jù)進(jìn)行訪問分析,而且AI引擎也可以訪問Lakehouse數(shù)據(jù)做高級(jí)分析。
對(duì)于諸如Hudi、Iceberg、DeltaLake增量數(shù)據(jù)管理框架，由于其提供了ACID的能力，數(shù)據(jù)可以進(jìn)行更新操作以及并發(fā)讀寫，因此對(duì)存儲(chǔ)數(shù)據(jù)存儲(chǔ)要求也更高，比如需要支持時(shí)間旅行、零拷貝等能力，才能保證數(shù)據(jù)隨時(shí)可以回溯。
Lakehouse除了支撐傳統(tǒng)的BI以及報(bào)表類的應(yīng)用，還要支持高級(jí)的AI類的分析，數(shù)據(jù)分析師、數(shù)據(jù)科學(xué)家可以直接在Lakehouse進(jìn)行數(shù)據(jù)科學(xué)計(jì)算和機(jī)器學(xué)習(xí)。
另外，Lakehouse的最佳實(shí)踐是基于存算分離架構(gòu)來(lái)構(gòu)建。存算分離最大的問題在于網(wǎng)絡(luò)，各云廠家以及大數(shù)據(jù)廠家，都探索了很多的手段來(lái)解決云存儲(chǔ)本身訪問的性能問題，如提供本地緩存功能來(lái)提高數(shù)據(jù)處理的效率。
Lakehouse架構(gòu)可以實(shí)現(xiàn)離線與實(shí)時(shí)的融合統(tǒng)一，數(shù)據(jù)通過ACID入湖。
如圖所示是經(jīng)典的大數(shù)據(jù)的Lampda架構(gòu)，藍(lán)色的處理流是批處理，紅色的則是流處理，在應(yīng)用層形成實(shí)時(shí)合并視圖。這個(gè)架構(gòu)存在的問題就是批處理和流處理是割裂的，數(shù)據(jù)管理之間的協(xié)同比較麻煩，而且不同的開發(fā)工具對(duì)開發(fā)要求的能力不同，對(duì)系統(tǒng)維護(hù)工程師和數(shù)據(jù)開發(fā)人員都是較大的挑戰(zhàn)。
針對(duì)這種的情況，Lakehouse架構(gòu)可以將批處理和流處理合并成一個(gè)Lakehouse view，通過CDC把業(yè)務(wù)生產(chǎn)系統(tǒng)數(shù)據(jù)實(shí)時(shí)抽取到數(shù)據(jù)湖，實(shí)時(shí)加工后送到后端OLAP的系統(tǒng)中對(duì)外開放，這個(gè)過程可以做到端到端的分鐘級(jí)時(shí)延。
Lakehouse本身的概念比較新，大家都還在做著各種各樣的實(shí)踐以進(jìn)行完善。
工行早期主要以O(shè)racle 、Teradata構(gòu)建其數(shù)據(jù)系統(tǒng)。數(shù)倉(cāng)為Teradata，數(shù)據(jù)集市是Oracle Exadata。
2013年開始，我們?cè)诠ば猩暇€了銀行業(yè)第一個(gè)大數(shù)據(jù)平臺(tái)，當(dāng)時(shí)的大數(shù)據(jù)平臺(tái)以單一的應(yīng)用為主，例如一些日志分析、TD的新業(yè)務(wù)卸載和明細(xì)查詢。
2015年之后，對(duì)數(shù)據(jù)系統(tǒng)進(jìn)行整合合并，包括通過GaussDB替代Teradata數(shù)倉(cāng)，形成了融合數(shù)倉(cāng)，在工行被稱之為一湖兩庫(kù)，以FusionInsight構(gòu)建數(shù)據(jù)湖底座以支持全量的數(shù)據(jù)加工，同時(shí)實(shí)時(shí)分析、交互式分析等業(yè)務(wù)也在其中得以開展。
2020年初，開始構(gòu)建云數(shù)據(jù)平臺(tái)，將整個(gè)數(shù)據(jù)湖遷移到云上以實(shí)現(xiàn)大數(shù)據(jù)的云化和服務(wù)化，同時(shí)構(gòu)建存算分離的架構(gòu)。另外還引入AI技術(shù)。
工行的技術(shù)演進(jìn)方向是從單一走向多元、從集中式走向分布式、從孤立系統(tǒng)走向融合、從傳統(tǒng)IT走向云原生的過程。
第一代大數(shù)據(jù)平臺(tái)更多的是根據(jù)應(yīng)用需求按需建設(shè)，這個(gè)時(shí)期對(duì)Hadoop究竟能解決什么問題并沒有很深的認(rèn)知。
首先想到的是解決業(yè)務(wù)創(chuàng)新，以及在數(shù)倉(cāng)里做不出來(lái)的業(yè)務(wù)，比如把大批量的數(shù)據(jù)合并作業(yè)卸載到Hadoop系統(tǒng)里。
這個(gè)時(shí)期缺少系統(tǒng)規(guī)劃，導(dǎo)致單集群規(guī)模小，集群數(shù)量不斷增多，維護(hù)成本較高，資源利用率低。另外，很多數(shù)據(jù)是需要在多個(gè)業(yè)務(wù)間共享的，需要在集群間進(jìn)行拷貝遷移，大量冗余的數(shù)據(jù)增加了資源的消耗。同時(shí)，數(shù)據(jù)需要根據(jù)不同的場(chǎng)景存儲(chǔ)在不同的技術(shù)組件中，利用不同的技術(shù)組件進(jìn)行處理，也導(dǎo)致ETL鏈路較長(zhǎng)、開發(fā)效率低，維護(hù)的代價(jià)高。因此，需要對(duì)整個(gè)大數(shù)據(jù)平臺(tái)的架構(gòu)進(jìn)行優(yōu)化。
第二階段將多個(gè)大數(shù)據(jù)集群進(jìn)行了合并，形成數(shù)據(jù)湖，其特點(diǎn)在于數(shù)據(jù)處理層統(tǒng)一規(guī)劃，集中入湖、集中管理。使得整體的管理、維護(hù)、開發(fā)效率得到極大提升。
將原始數(shù)據(jù)入湖之后，還會(huì)對(duì)數(shù)據(jù)進(jìn)行一些加工處理以形成匯總數(shù)據(jù)和主題數(shù)據(jù)，并在數(shù)據(jù)湖里進(jìn)行集中治理，數(shù)據(jù)加工處理后送到數(shù)倉(cāng)或者數(shù)據(jù)集市，以及后端的其他系統(tǒng)里。
基于這種架構(gòu)，數(shù)據(jù)湖的應(yīng)用效率得以極大提升。經(jīng)過幾年發(fā)展，當(dāng)前集群規(guī)模已經(jīng)達(dá)到1000多節(jié)點(diǎn)，數(shù)據(jù)量幾十PB，日均處理作業(yè)數(shù)大概是10萬(wàn)，賦能于180多個(gè)總行應(yīng)用和境內(nèi)外41家分行及子公司。
但是，將所有數(shù)據(jù)存進(jìn)一個(gè)集中的數(shù)據(jù)湖也帶來(lái)了很多管理方面的難題。
數(shù)據(jù)湖支撐的業(yè)務(wù)和用戶對(duì)SLA高低的要求不盡相同，如何給不同部門、不同業(yè)務(wù)線、以及不同用戶的作業(yè)進(jìn)行統(tǒng)一管理比較關(guān)鍵，核心是多租戶能力，Hadoop社區(qū)YARN調(diào)度功能早期并不是很強(qiáng)，上千個(gè)節(jié)點(diǎn)的管理能力較弱，雖然現(xiàn)在的新版本得以改進(jìn)。
早期的集群到幾百個(gè)節(jié)點(diǎn)后，調(diào)度管理系統(tǒng)就難以支撐。因此我們開發(fā)了 Superior的調(diào)度器加以完善。工行的1000節(jié)點(diǎn)集群在銀行業(yè)算是比較大的數(shù)量級(jí)。我們?cè)谌A為內(nèi)部構(gòu)建了從500到幾千直到10000節(jié)點(diǎn)的一個(gè)集群，這個(gè)過程已經(jīng)對(duì)大集群的管理能力提前進(jìn)行鋪墊，在工行的應(yīng)用就相對(duì)比較順利。
如圖所示，我們把整個(gè)的資源管理按照部門多級(jí)資源池進(jìn)行管理，通過superior調(diào)度器，按照不同的策略進(jìn)行調(diào)度以支撐不同的SLA。整體效果而言，資源利用率得以成倍提升。
還有一些其它組件，尤其是像HBase的region server是基于JAVA的JVM來(lái)管理內(nèi)存，能利用的內(nèi)存很有限，物理機(jī)資源基本用不滿，資源不能充分利用。
為了解決這個(gè)問題，我們實(shí)現(xiàn)在一個(gè)物理機(jī)上可以部署多實(shí)例，盡量將一個(gè)物理機(jī)的資源充分利用，ES也是按照這種方式來(lái)處理。
集群變大之后，其可用性和可靠性也存在著很大的問題。大集群一旦出現(xiàn)問題導(dǎo)致全面癱瘓，對(duì)業(yè)務(wù)影響非常大。所以，銀行業(yè)必須全面具備兩地三中心的可靠性。
首先是跨AZ部署的能力，AZ實(shí)際是屬于云上的一個(gè)概念，傳統(tǒng)的 ICT機(jī)房里更多的是跨DC數(shù)據(jù)中心的概念，跨AZ部署意味著一個(gè)集群可以跨兩個(gè)AZ或者三個(gè)AZ進(jìn)行部署。
Hadoop本身具備多副本機(jī)制，以多副本機(jī)制為基礎(chǔ)，可以將多個(gè)副本放置在不同的機(jī)房里。但是以上條件并非開源能力可以支撐，需要補(bǔ)充一些副本放置和調(diào)度的策略，在調(diào)度時(shí)要感知數(shù)據(jù)究竟放置在哪個(gè)AZ，任務(wù)調(diào)度到相應(yīng)的AZ保證數(shù)據(jù)就近處理，盡量避免AZ之間由于數(shù)據(jù)傳輸帶來(lái)的網(wǎng)絡(luò)IO。
另外，容災(zāi)能力還可以通過異地主備來(lái)實(shí)現(xiàn)，跨AZ能力要求機(jī)房之間的網(wǎng)絡(luò)時(shí)延達(dá)到毫秒級(jí)，時(shí)延太高可能無(wú)法保證很多業(yè)務(wù)的開展。異地的容災(zāi)備份，即一個(gè)主集群和一個(gè)備集群。平時(shí)，備集群并不承擔(dān)業(yè)務(wù)，僅主集群承載業(yè)務(wù)，一旦主集群發(fā)生故障，備集群隨之進(jìn)行接管，但是相應(yīng)的代價(jià)也會(huì)較大，比如有1000個(gè)節(jié)點(diǎn)的主集群，就要構(gòu)建1000個(gè)節(jié)點(diǎn)的備集群，所以多數(shù)情況下，主備容災(zāi)更多的是僅構(gòu)建關(guān)鍵數(shù)據(jù)關(guān)鍵業(yè)務(wù)的備份，并非將其全部做成主備容載。
大數(shù)據(jù)集群需要不斷擴(kuò)容，隨著時(shí)間的推移，硬件會(huì)升級(jí)換代，升級(jí)換代之后必然出現(xiàn)兩種情況，其中之一就是新采購(gòu)機(jī)器的CPU和內(nèi)存能力，以及磁盤的容量，都比原來(lái)增大或者升高了，需要考慮如何在不同的跨代硬件上實(shí)現(xiàn)數(shù)據(jù)均衡。
換盤的操作也會(huì)導(dǎo)致磁盤的不均衡，如何解決數(shù)據(jù)均衡是一個(gè)很重要的課題。
我們專門開發(fā)了按照可用空間放置數(shù)據(jù)的能力，保證了數(shù)據(jù)是按照磁盤以及節(jié)點(diǎn)的可用空間進(jìn)行放置。同時(shí)，對(duì)跨代節(jié)點(diǎn)按規(guī)格進(jìn)行資源池劃分，對(duì)于早期比較老舊且性能相對(duì)差一些的設(shè)備，可以組成一個(gè)邏輯資源池用于跑Hive作業(yè)，而內(nèi)存多的新設(shè)備組成另一個(gè)資源池則用來(lái)跑spark，資源池通過資源標(biāo)簽進(jìn)行區(qū)分隔離，分別調(diào)度。
集群變大之后，任何變更導(dǎo)致業(yè)務(wù)中斷的影響都非常大。所以，升級(jí)操作、補(bǔ)丁操作都需要考慮如何保證業(yè)務(wù)不會(huì)中斷。
比如對(duì)1000個(gè)節(jié)點(diǎn)集成進(jìn)行一次版本升級(jí)。如果整體停機(jī)升級(jí)，整個(gè)過程至少需要花費(fèi)12個(gè)小時(shí)。
滾動(dòng)升級(jí)的策略可實(shí)現(xiàn)集群節(jié)點(diǎn)一個(gè)一個(gè)滾動(dòng)分時(shí)升級(jí)，逐步將所有節(jié)點(diǎn)全部升級(jí)成最新的版本。但是開源的社區(qū)跨大版本并不保證接口的兼容性，會(huì)導(dǎo)致新老版本無(wú)法升級(jí)。因此我們研發(fā)了很多的能力以保證所有版本之間都能滾動(dòng)升級(jí)。從最早的Hadoop版本一直到Hadoop3，所有的組件我們都能保證滾動(dòng)升級(jí)。這也是大集群的必備能力。
數(shù)據(jù)湖的構(gòu)建解決了工行的數(shù)據(jù)管理的難題，但同時(shí)也面臨著很多新的挑戰(zhàn)和問題。
一般而言，很多大企業(yè)的硬件都是集中采購(gòu)，并沒有考慮到大數(shù)據(jù)不同場(chǎng)景對(duì)資源訴求的不一，而且計(jì)算與存儲(chǔ)的配比并未達(dá)到很好的均衡，存在較大的浪費(fèi)。
其次，不同批次的硬件之間也存在差異，有些可能還會(huì)使用不同的操作系統(tǒng)版本，導(dǎo)致了一個(gè)集群內(nèi)有不同的硬件、不同的操作系統(tǒng)版本。雖然可以用技術(shù)手段解決硬件異構(gòu)、OS異構(gòu)的問題，但是持續(xù)維護(hù)的代價(jià)相當(dāng)高。
再次，大數(shù)據(jù)手工部署效率低。往往開展一個(gè)新業(yè)務(wù)的時(shí)候，從硬件的采購(gòu)到網(wǎng)絡(luò)配置、再到操作系統(tǒng)安裝，整個(gè)系統(tǒng)交付周期至少需要一個(gè)月。
最后，資源彈性不足，如果上新業(yè)務(wù)時(shí)面臨資源不足，就需要擴(kuò)容。申請(qǐng)采購(gòu)機(jī)器和資源導(dǎo)致上線的周期較長(zhǎng)，我們有時(shí)給客戶部署一個(gè)新業(yè)務(wù)，往往大多時(shí)間是在等到資源到位。另外，不同資源池之間的資源無(wú)法共享，也存在著一定的浪費(fèi)。
所以工行要引入云的架構(gòu)。
FusionInsight很早就上了華為云，即華為云上的MRS服務(wù)。
當(dāng)下工行和其他很多銀行都在部署云平臺(tái)，將大數(shù)據(jù)部署到云平臺(tái)上。但大規(guī)模的大數(shù)據(jù)集群部署到云上還存在著一些挑戰(zhàn)，基于云原生的存算分離架構(gòu)來(lái)部署大數(shù)據(jù)業(yè)務(wù)有很多優(yōu)勢(shì)。
首先，將硬件資源池化，資源池化之后對(duì)上層就是比較標(biāo)準(zhǔn)的計(jì)算資源，計(jì)算和存儲(chǔ)可以靈活的擴(kuò)展，利用率相對(duì)較高。
其次，基于云平臺(tái)的大數(shù)據(jù)環(huán)境搭建，全部自動(dòng)化，從硬件資源準(zhǔn)備到軟件安裝，僅用一小時(shí)完成。
再次，在申請(qǐng)集群擴(kuò)容資源彈性時(shí)，無(wú)需準(zhǔn)備，可以很快的在大資源池進(jìn)行統(tǒng)一調(diào)配。一般而言，云上只要預(yù)留了資源，空間資源可以很快加入到大數(shù)據(jù)的資源池里，新業(yè)務(wù)上線也會(huì)變得非常敏捷。
再說(shuō)存算分離，存儲(chǔ)主要是以對(duì)象存儲(chǔ)為主，用低成本的對(duì)象存儲(chǔ)替代原來(lái)HDFS的三副本的能力，對(duì)象存儲(chǔ)一般提供兼容HDFS的接口，在此基礎(chǔ)上，對(duì)象存儲(chǔ)可以給大數(shù)據(jù)、 AI等提供一個(gè)統(tǒng)一的存儲(chǔ)，降低存儲(chǔ)成本，運(yùn)維的效率得以提高。
但是，對(duì)象存儲(chǔ)的性能不是很好，需要圍繞大數(shù)據(jù)的業(yè)務(wù)特點(diǎn)解決以下問題。
第一個(gè)，就是元數(shù)據(jù)，因?yàn)榇髷?shù)據(jù)是個(gè)重載計(jì)算，在計(jì)算的過程中讀IO很高。讀取數(shù)據(jù)的過程中。對(duì)象存儲(chǔ)的元數(shù)據(jù)性能是個(gè)很大的瓶頸，因此需要提升元數(shù)據(jù)的讀寫能力。
第二個(gè)，網(wǎng)絡(luò)帶寬，存儲(chǔ)與計(jì)算之間的網(wǎng)絡(luò)IO對(duì)網(wǎng)絡(luò)帶寬的需求比較高。
第三個(gè)，網(wǎng)絡(luò)時(shí)延，大數(shù)據(jù)計(jì)算是就近計(jì)算，數(shù)據(jù)在哪里相應(yīng)的計(jì)算就會(huì)在哪里，存儲(chǔ)數(shù)據(jù)是優(yōu)先讀本地盤，之后是讀網(wǎng)絡(luò)。時(shí)延存在一定的敏感性。
我們主要是從緩存、部分計(jì)算下推上做一些優(yōu)化，整體上而言，存算分離架構(gòu)的性能跟一體化相比，除了個(gè)別用例有差距，整體性能都更高，尤其是寫場(chǎng)景，因?yàn)閷憣?duì)象存儲(chǔ)是寫EC，而不用寫三副本，寫1.2個(gè)副本就可以了。
最后，整體的 TCO大概得到30%~60%的下降。整體的性能與周邊其他產(chǎn)品對(duì)比還是具有很大的優(yōu)勢(shì)。
大數(shù)據(jù)部署到云上，對(duì)于大集群而言，虛機(jī)并沒有太大優(yōu)勢(shì)，因?yàn)閿?shù)據(jù)池子夠大，虛機(jī)還會(huì)帶來(lái)性能的損耗，而且其性能與物理機(jī)有一定差距。而且，基于SLA隔離要求，大數(shù)據(jù)資源池在私有云部署，很多時(shí)候還是需要獨(dú)占，其資源無(wú)法和別的業(yè)務(wù)共享。
而裸金屬服務(wù)實(shí)際上可以很好的解決這些問題，它的性能接近物理機(jī)，而且可以分鐘級(jí)完成裸金屬服務(wù)器的發(fā)放，包括整個(gè)網(wǎng)絡(luò)配置，OS安裝。
網(wǎng)絡(luò)部分有專門的擎天網(wǎng)絡(luò)加速卡，對(duì)裸機(jī)網(wǎng)絡(luò)進(jìn)行管理，而且網(wǎng)絡(luò)性能比原來(lái)的物理網(wǎng)卡的性能更高，在裸金屬服務(wù)器上開展大規(guī)模大數(shù)據(jù)業(yè)務(wù)是云上的最佳部署方案。
工行和我們也在探索湖倉(cāng)一體的解決方案。
華為云湖倉(cāng)一體在存算分離的基礎(chǔ)上，將數(shù)據(jù)管理層獨(dú)立出來(lái)，其中包含了幾個(gè)部分，第一個(gè)是數(shù)據(jù)集成，數(shù)據(jù)從各種各樣的外部系統(tǒng)入湖。第二個(gè)是元數(shù)據(jù)集成，由于Hadoop數(shù)據(jù)湖上的元數(shù)據(jù)通過Hive管理，我們提供一個(gè)兼容Hive Metastore的獨(dú)立元數(shù)據(jù)服務(wù)。第三個(gè)是數(shù)據(jù)的授權(quán)以及脫敏這些安全策略，我們要將其在Lake Formation這一層進(jìn)行統(tǒng)一閉環(huán)。
數(shù)據(jù)的底座構(gòu)建好之后，數(shù)據(jù)分析服務(wù)如大數(shù)據(jù)的服務(wù)、數(shù)倉(cāng)的服務(wù)、圖計(jì)算、AI計(jì)算都是在同樣的一個(gè)數(shù)據(jù)視圖上進(jìn)行計(jì)算處理。數(shù)倉(cāng)DWS的服務(wù)本質(zhì)是本地存儲(chǔ)，數(shù)倉(cāng)也可以通過它的一個(gè)引擎訪問Lakehouse中的數(shù)據(jù)。這樣數(shù)倉(cāng)自己在本地有一個(gè)加速的數(shù)據(jù)層，同時(shí)也可以訪問Lakehouse。
在此基礎(chǔ)上我們通過一個(gè)架構(gòu)來(lái)實(shí)現(xiàn)這三種湖，持續(xù)演進(jìn)。
藍(lán)色數(shù)據(jù)流是離線數(shù)據(jù)流，實(shí)現(xiàn)離線數(shù)據(jù)湖能力，數(shù)據(jù)通過批量集成，存儲(chǔ)到Hudi，再通過Spark進(jìn)行加工。
紅色數(shù)據(jù)流是實(shí)時(shí)流，數(shù)據(jù)通過CDC實(shí)時(shí)捕獲，通過Flink實(shí)時(shí)寫入Hudi；通過Redis做變量緩存，以實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)加工處理，之后送到諸如Clickhouse 、Redis、Hbase等專題集市里對(duì)外提供服務(wù)。
同時(shí)，我們還開發(fā)了HetuEngine數(shù)據(jù)虛擬化引擎，將數(shù)據(jù)湖里面的數(shù)據(jù)以及其他專題集市里的數(shù)據(jù)進(jìn)行多數(shù)據(jù)源關(guān)聯(lián)分析，形成邏輯數(shù)據(jù)湖。
雖然HetuEngine可以連接不同的數(shù)據(jù)源，但并不意味著所有應(yīng)用只能通過HetuEngine來(lái)訪問數(shù)據(jù)，應(yīng)用還是可以通過各數(shù)據(jù)源原生接口進(jìn)行訪問。僅需要不同專題數(shù)據(jù)之間進(jìn)行聯(lián)合分析時(shí)，才需要通過HetuEngine統(tǒng)一訪問。
如下是具體的實(shí)施計(jì)劃：
第一個(gè)，引入Hudi，構(gòu)建一個(gè)數(shù)據(jù)湖的數(shù)據(jù)管理，每年大概可以節(jié)省幾百萬(wàn)。
第二個(gè)，引入HetuEngine，實(shí)現(xiàn)數(shù)據(jù)湖內(nèi)的數(shù)據(jù)免搬遷的查詢分析。避免一些不必要的ETL過程。
第三個(gè)，引入ClickHouse，ClickHouse在OLAP領(lǐng)域有著非常好的處理性能和很多優(yōu)勢(shì)，因此考慮將其在工行落地。
數(shù)據(jù)湖以Hive作為存儲(chǔ)，采用一天一次批量集成、批量合并的方案，即T+1的數(shù)據(jù)處理模式。這種模式存在幾個(gè)比較大的業(yè)務(wù)痛點(diǎn)：
第一，數(shù)據(jù)延時(shí)比較高，后端服務(wù)看到的數(shù)據(jù)并不是最新的。
第二，跑批作業(yè)在夜里進(jìn)行，而白天資源利用率較低，但集群資源是按照高峰期需求來(lái)構(gòu)建，造成很大的資源浪費(fèi)。
第三， Hive不支持更新，數(shù)據(jù)合并需要開發(fā)較多代碼實(shí)現(xiàn)，如把新數(shù)據(jù)臨時(shí)表與原Hive表進(jìn)行左右關(guān)聯(lián)后覆蓋原來(lái)整表或者部分分區(qū)表，開發(fā)成本比較高，業(yè)務(wù)邏輯復(fù)雜。
引入Hudi就可以在很大程度上解決這些問題。數(shù)據(jù)通過CDC入湖，通過Spark或者Flink寫入Hudi，支持實(shí)時(shí)更新，端到端可以做到分鐘級(jí)的時(shí)延。數(shù)據(jù)以非常小的微批形式合并到數(shù)據(jù)湖，分散跑批使得資源白天和晚上都能得到充分利用，數(shù)據(jù)湖集群TCO預(yù)計(jì)可以下降20%。此外，數(shù)據(jù)集成腳本開發(fā)可以利用Hudi的Update能力，原來(lái)Hive要寫幾百行的代碼，只需一行腳本即可完成，開發(fā)效率提升很大。
工行數(shù)據(jù)湖使用Hive來(lái)承載靈活查詢業(yè)務(wù)，如SAS使用Hive SQL來(lái)訪問數(shù)據(jù)湖，訪問效率比較低，響應(yīng)時(shí)間長(zhǎng)，并發(fā)能力也不足。
另外數(shù)據(jù)湖與數(shù)倉(cāng)的兩層架構(gòu)導(dǎo)致了大量的重復(fù)數(shù)據(jù)，有較多關(guān)聯(lián)分析需求，關(guān)聯(lián)處理必然涉及到湖倉(cāng)之間大量ETL。比如為了支撐BI工具的分析訴求，需要數(shù)據(jù)湖和數(shù)倉(cāng)數(shù)據(jù)關(guān)聯(lián)處理加工，并將加工之后的數(shù)據(jù)導(dǎo)入OLAP引擎。整體數(shù)據(jù)鏈路比較長(zhǎng)，分析效率和開發(fā)效率都很低。
通過HetuEngine數(shù)據(jù)虛擬化實(shí)現(xiàn)湖倉(cāng)協(xié)同分析，一方面替代Hive SQL訪問 Hive的數(shù)據(jù)，只需1/5的資源即可支撐大概原來(lái)5倍并發(fā)，同時(shí)訪問時(shí)延降到秒級(jí)。另一方面可同時(shí)訪問Hive和DWS提供秒級(jí)的關(guān)聯(lián)查詢，可以減少80%的系統(tǒng)間的數(shù)據(jù)搬遷，大量的減少 ETL的過程。
傳統(tǒng)的OLAP方案一般用MySQL、Oracle或者其他的OLAP引擎，這些引擎因其處理能力有限，數(shù)據(jù)一般按照專題或者主題進(jìn)行組織后與BI工具對(duì)接，導(dǎo)致BI用戶和提供數(shù)據(jù)的數(shù)據(jù)工程師脫節(jié)。比如BI用戶有一個(gè)新的需求，所需的數(shù)據(jù)沒有在專題集市中，需要將需求給到數(shù)據(jù)工程師，以便開發(fā)相應(yīng)的ETL任務(wù)，這個(gè)過程往往需要部門間協(xié)調(diào)，時(shí)間周期比較長(zhǎng)。
現(xiàn)在可以將所有明細(xì)數(shù)據(jù)以大寬表的形式加載Clickhouse，BI用戶可以基于Clickhouse大寬表進(jìn)行自助分析，對(duì)數(shù)據(jù)工程師供數(shù)要求就會(huì)少很多，甚至大部分情況下的新需求都不需要重新供數(shù)，開發(fā)效率和BI報(bào)表上線率都會(huì)得到極大提升。
這套方法論在我們內(nèi)部實(shí)踐效果非常好，原來(lái)我們基于傳統(tǒng)OLAP引擎建模，受限于開發(fā)效率，幾年才上線了幾十個(gè)報(bào)表。但是切到Clickhouse后，幾個(gè)月之內(nèi)就上了大概上百個(gè)報(bào)表，報(bào)表開發(fā)效率極大提升。（雷鋒網(wǎng)）
欲了解更多活動(dòng)詳情，可聯(lián)系作者周舟（微信：18811172358）。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
