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