導讀 本文將分享中原銀行在敏捷 BI 平臺上的建設實踐。文中主要講解中原銀行如何從零到 1 建設整個 BI 體系。
將圍繞下面四個方面展開：
1. 平臺建設業務目標
2. 敏捷BI平臺建設
3. 業務場景支撐
4. 未來展望
分享嘉賓｜許耀輝 中原銀行 BI平臺負責人
編輯整理｜吳葉國 微言科技
出品社群｜DataFun
中原銀行敏捷 BI 平臺的建設目標為滿足不同人群對資料查詢、分析和探索的需求，為管理和業務提供資料依賴和決策支撐。
不同的企業對於 BI 是有不同的訴求的。中原銀行對 BI 的訴求，是滿足行內不同人群對資料查詢、分析和探索的需求，從而為管理和業務提供資料依賴和決策支撐。（1）第一類是管理決策層。讓管理決策層能夠看到準確、實時的資料，並依據資料去進行科學的決策。（2）第二類是普通業務人員。比如針對業務資料統計，業務人員會在業務運營過程中涉及一些比如手工報表、人工統計、逐級取數等操作，使用 BI 平臺可以提升他們的日常資料統計效率，讓業務更多關注業務問題本身。（3）第三類是技術人員或分析人員。透過打通各個業務系統，提供統一的查詢服務，提升這類人員的日常資料分析效率。這是我們對 BI 的整體訴求，依據這個業務目標，我們建設了 BI 平臺。
中原銀行在 2019 年之前，使用的是採購的第三方報表系統。業務人員也已經養成看報表的習慣，現在整個行內有上千張報表，業務人員每天都會查詢這些報表資料。從 2019 年開始，為了實現之前提到的業務目標，中原銀行開始建設整個的敏捷 BI 體系。2019 年，把資料取數從線下轉為線上，提升安全提數效率。可以滿足一些比如日常的監管報送，或者領導臨時的資料需求，並提升操作效率。2020 年，針對業務人員提升資料統計的效率。開始建設智慧拼表，低程式碼加工和視覺化分析工具，可以讓業務人員在無需藉助比如 SQL 加工的方式下可以完成資料的加工。這裡補充一下，智慧拼表是結合中原銀行的業務特點，允許業務透過低程式碼的方式進行報表拼接。2021 年，為了提升 IT 人員或者技術人員的分析效率，構建了我們自己的報表系統，資料大屏等。2022 年，構建了我們自己的業務指標庫和資料門戶。以上是我們整個 BI 平臺的建設歷程，逐步完善整個 BI 體系。敏捷 BI 平臺覆蓋資料分析全流程，提供一站式、全鏈路資料分析解決方案。下面來介紹我們整個 BI 平臺的整體概覽。
（1）資料庫，包括關係型資料庫如業務資料庫、大資料叢集和數倉等。然後基於這些資料，我們會一站式提供 8 個核心功能，包括：（2）低程式碼資料加工。用於支撐資料統計人員的工作。（3）SQL 資料分析。用於支撐於技術人員和資料分析人員的工作。（4）視覺化分析。可以以更直觀的低程式碼方式進行資料分析，展示資料結果。（5）資料分發補錄。用於本地資料線上化、資料分發確認。（6）業務指標管理。是我們的指標庫，建設構建唯一確定的沒有二元性的指標，供業務日常的查詢使用。（7）個性化門戶。是為了統一資料出口，把報表視覺化看板以及大屏統一輸出在一個門戶中，供業務人員日常查詢使用。（8）資料下載。提供線上化的資料下載，簡化下載流程。基於這 8 個功能，我們構建了 6 個核心的資料應用，包括固定報表、資料大屏、視覺化看板，安全提數、指標庫以及資料門戶，針對不同的人員提供不同的資料應用，基於這些應用進行能力輸出，給業務使用。在業務應用場景方面，包括管理駕駛艙、營銷效果分析、業績考核監測、日常資料通報、系統監測分析以及業務風險預警。
上圖可以更好的幫助我們理解前面介紹的平臺架構，把 8 個核心功能分佈到資料分析的 4 個流程內，支撐資料分析的全流程覆蓋。（1）資料準備。平臺支援多種資料來源，包括業務資料庫、核心資料庫、數倉內的資料庫、資料湖內資料庫、本地資料庫以及使用者收集的資料。（2）資料加工。平臺可以提供兩種資料加工方式：一種是低程式碼拖拉拽的方式，整合常規的資料加工方式，供業務人員進行低程式碼加工；第二種是針對專業分析人員進行 SQL 的資料加工。（3）資料分析。資料分析也可以歸結為兩類：一種是固定式的報表分析，基於報表平臺所建立出來的報表；另一種是業務自助式的分析，可以基於看板或者是大屏，進行篩選、關聯、跳轉以及資料的上卷下鑽等等。（4）資料應用。我們提供多種的資料應用方式，包括資料大屏、資料看板、固定報表以及資料門戶整合，所有資料應用的結果都可以進行預覽、下載、分享等。下面具體介紹幾個核心的功能。首先介紹固定報表的開發。
之前我們購買的第三方報表平臺，使用中會存在一些問題：一個是平臺架構比較老，查詢效能上經常會出現 CPU 或者記憶體不足的情況；第二個是我們會有一些個性化的改造，這種改造通常需要一兩個月才能開發完成，不僅成本非常高，而且需要進行排期。針對以上幾個問題，我們規劃開發我們自己的報表平臺，供業務日常查詢使用。主要是做一些中國式的複雜報表，包括一些非常複雜的表頭等等。（1）資料來源。就是我們能夠連線到的資料來源，比如常規的 Oracle、MySQL，還有我們的大資料叢集使用的 Gauss，以及 StarRocks、ClickHouse 等。（2）資料加工。透過 SQL 進行資料加工，這裡強調一點，在 SQL 資料集中不會有太多複雜的 SQL，因為大部分邏輯已經是在數倉內透過跑批任務完成了，在報表裡面更多的是查詢已有的資料，我們使用專屬的獨立叢集提升查詢效率。（3）報表製作。我們把報表歸結為 4 類：第一類是即席查詢類，就是 SQL 資料集裡面加工的邏輯直接動態查詢；第二類是類透視表，類似 Excel 中的透視分析，透過選擇行列和指標進行維度的組合篩選；第三類是 Excel 表格，專門去製作一些複雜表頭，或者是帶 Excel 公式的電子表格類報表；第四類是剛實現的視覺化類報表，當前常規的表格展示不能直觀有效地表現資料的結果，因此我們引入一些圖形化的比如折線圖、條形圖等做一些視覺化報表。（4）報表釋出。第一，由於行內對資料安全的嚴格管控，需要進行資料脫敏，否則是不能進行正常的報表釋出的；第二，安全審批，需要走一個報表釋出的流程；第三，報表版本管理，報表有兩個版本，一個是製作的版本，一個是線上的版本，製作的版本只有透過釋出審批之後才會把線上的版本覆蓋掉。（5）業務應用。我們行內把報表歸結為 4 大類：對公類、零售類、財務類和績效類。在這裡會進行報表的知識庫構建，比如報表目錄管理，報表技術及業務口徑維護，報表關鍵字搜尋等等。
低程式碼資料加工的建設，針對的是普通業務人員，為了簡化資料統計分析的難度，平臺透過整合常見的加工方式，讓他們可以透過低程式碼的方式進行常規的資料加工。我們整合了 10 種資料加工方式，比如欄位設定、分類彙總、資料篩選、新增欄位（基於已有的欄位進行加減乘除運算）、資料排序、透視分析、查詢替換、列轉行，這些是比較好理解的。還有上下合併和左右合併，是為了在低程式碼方式下合併兩張表，一種是上下合併，一種是左右合併，類似於 Left Join 的方式。透過整合這 10 種加工方式，業務進行資料加工的過程中，他可以按需選擇其中幾種加工方式。我們在程式碼實踐過程中，透過 Pipeline 管道模式組合，生成最終的 SQL 邏輯，以完成低程式碼的資料加工。
在視覺化方面的建設，包括資料大屏、視覺化看板等等，透過一些拖拉拽的方式去快速製作圖表，幫助業務快速分析和洞察業務的趨勢。這部分很好理解，最開始的是資料來源；然後資料加工有兩種方式，一種是專業人員的 SQL 資料加工，還有一種是低程式碼透過拖拉拽的方式去進行資料的基礎加工；然後根據這些基礎資料去進行資料圖表的製作，我們支援 Echarts、AntV 這種常規的圖表元件，還支援圖表屬性的自定義設定，後面會涉及到一些比如指標計算和資料下鑽；圖表製作完成之後，就會涉及到圖表組合，支援視覺化拖拉的方式去進行圖表的組合，最終制作出來的大屏和視覺化看板是支援結果分享、多端檢視以及支援單 URL 訪問嵌入等，最終支撐我們的視覺化能力。這部分我們是站在巨人肩膀上，也就是基於開源，再加上我們自己的個性化改造實現的。這些個性化改造，包括資料來源的對接，圖形元件的自定義等。業務在圖表製作過程中，如果常規圖表不能滿足需求，會提需求讓 BI 平臺開發比較個性化的圖表元件。
下面是安全提數的建設，為了規範資料下載流程，不會讓資料輕易流出，需要在保證資料安全的前提下，促進資料的使用和價值釋放。（1）事前預防。制定取數規範，進行安全宣導、事件通報等等。（2）事中干預。進入平臺之後，同樣會進行干預，一部分是對錶許可權的控制，表許可權的申請審批，書寫 SQL 的規範評分等；還有一部分是對敏感資料的脫敏以及過濾。（3）事後審計。包括日常使用者的操作日誌記錄、風險的上報以及事後的安全審計等等。
資料門戶作為最終統一結果輸出的地方，把報表、視覺化看板，資料大屏以及第三方頁面整合組合到一起。個人可以設定個人的資料門戶，滿足千人千面的個性化看數需求，獲得清晰、直觀、美觀且沉浸式的看數體驗。
第八個是指標庫的建設，我們把它歸結為 4 個步驟：（2）指標整合。整合是按照數倉的星型模型構建的，構建我們的業務指標寬表。（3）指標上架。在我們平臺上進行指標上架後，業務能夠正常的去查詢，檢視這些指標的口徑。（4）指標應用。結合自助低程式碼方式和視覺化分析能力去滿足業務後續的分析需求。比如藉助低程式碼能力，可以進行基於指標表的自助加工；藉助視覺化能力，可以製作基於指標表的視覺化分析。上面主要介紹了平臺整體架構以及核心能力，接下來將介紹一些具體使用場景，也就是業務人員或者資料分析人員在平臺上做了一些什麼工作。
（1）第一類個人自助分析。個人會有一些日常的資料查詢需求，比如報表查詢、資料統計，資料臨時下載等等。（2）第二類賦能業務系統。就是支撐業務系統對接整合，把我們的視覺化能力，報表能力輸出給業務系統整合，支撐他們去整合我們的視覺化能力，降低他們的開發成本。（3）第三類專題分析。針對於某一問題或者是某一措施之後的專項分析，評價其好壞，比如常規的營銷效果分析，就是一類專題分析。（4）第四類管理駕駛艙。是使用比較多的一個場景，做出一些看板報表，供領導管理層基於資料的科學決策。下面看一下 4 個場景裡面的具體內容，比如在個人自助統計分析裡面，我們將其歸結為 4 類：（1）報表、大屏及看板的日常查詢。常規需求，大部分人員就是為了看資料，只有少部資料分析人員才會真正的去製作這些報表。（2）業務日常通報、業績考核。這是涉及到業務類的，之前是透過線下 Excel 的方式去進行彙總加工出來，然後每天都要繁瑣的去做這項工作，現在透過我們平臺就可以一次製作自動更新，免除他們日常繁瑣的資料統計工作。（3）總行支行資料上報。就是由總行下發任務，讓分支行的人員進行資料的填報，之前是透過郵件的方式，一層層總行發給分行，分行發給支行，支行再發到對應的業務經理，流程是比較繁瑣的。（4）資料分析及臨時提數。針對一些資料的分析人員，要去寫 SQL 去進行日常查詢，還有一部分是會涉及到一些臨時的提數等等，這個是個人的資料統計。我們的研發效能洞察平臺，就是透過整合我們的視覺化能力去展示決策檢視或者度量報告，算是我們平臺能力的輸出。這樣一些業務平臺就不需要另外去開發類似的視覺化功能了。對於場景化的專題分析，針對某一問題或者是某一舉措後的專題分析。以銀行某一產品為例，從經營現狀、資產質量、還款結構、轉化流程以及渠道來源等去進行各個角度的分析展示。視覺化大屏，我們需要在一些比如業務風險會議或者是業務監控裡面會有大屏的展示。這裡有兩個例子，風險疫情大屏以及會計運營大屏，能夠掛到某一個地方，領導或者同事能夠日常的進行一些資料的查詢。
接下來介紹的是一個解決方案，是針對實時 BI 的解決方案。它是有對應的業務需求的，比如我們的管理駕駛艙，營銷效果分析以及風險預警等等，這些對實時資料是有比較強的訴求的。他們之前資料都是 T+1 的資料，這對預警場景來說已經是比較落伍了，T+1 的資料已經對於該場景已經沒有什麼效果了，所以我們會依據這些場景去構建實時 BI 的解決方案。常規的資料來源傳送訊息到訊息佇列 Kafka 裡面，然後 Kafka 將訊息傳送到計算引擎 Flink 裡面，Flink 把計算後的結果寫到我們的儲存引擎 StarRocks中。不同的業務場景可以使用不同的儲存引擎，我們全部使用的是 StarRocks。同時 StarRocks 作為我們 OLAP 引擎作為後續的 BI 的一個查詢引擎，比如我們的實時報表、實時大屏和實時看板，實現對資料的秒級實時分析，這是我們的實時大屏解決方案。
整個流程就是使用者在平臺上提出問題後，後臺在問答知識庫進行匹配，如果匹配上的話直接會給出答案，如果沒有匹配上就會有經過相似度模型跟其他的問答去進行匹配，看是否是相似的問題，透過閾值判斷，如果超過閾值，就認為它們是相似的問題，就可以返回相應的答案，如果沒有，會經過 NL2SQL 模型去構建對應的查詢 SQL 給出相應的結果。這個是我們在智慧化方面的一個建設，不過目前因為資料量比較少，只能針對於單個固定式的那種場景去進行查詢，是我們的一個嘗試和探索。
（1）第一部分是完善我們自身平臺能力，整個 BI 的功能完善。（2）第二部分是平臺的推廣運營。酒香也怕巷子深，很多人是不瞭解平臺工具能夠做什麼事情的。目前我們平臺大概有上千人使用，月活也有上千人，我們後續會更大量地推廣介紹我們的平臺。（3）第三部分是使用者使用的平滑過渡。這裡指的是傳統 BI 到敏捷 BI 的一個過渡。更低的學習成本、更順手的操作流程。（4）第四部分是資料分析思維培養。不像網際網路公司，所有的銀行應該都會有這樣的現狀，分析還是依靠專業分析人員，在中原銀行是依靠資料建模師。業務人員更多的是做一些資料統計上的工作，不會具體去分析這個現象為什麼會產生、這個問題為什麼會出現以及我需要怎麼去做。這就需要我們進行一些資料分析的思維的培養，也是我們正在做的一個工作。
（1）第一個是平臺的智慧化建設。透過融合 AI、NLP、模型演算法等技術去簡化使用者的分析的難度。比如我們智慧問答的嘗試；後續會做一些智慧洞察分析，是透過平臺去自動發現問題，定位問題；另外是自動視覺化，比如發現問題之後，怎麼透過視覺化展示這些問題，讓使用者可以看到這些問題，這是我們未來在智慧化方面要探索的內容。（2）第二個是平臺的開放化建設。把我們的能力進行輸出。我們的視覺化能力，是每個平臺都會有的一個需求，我們後續會慢慢的開放我們的 SDK，我們的 API 以及我們的頁面嵌入能力，能夠去支撐更多的業務場景。Q1：資料下載審批，審批流程有分不同的重要等級，走不同的審批流程嗎？有的話等級是怎麼標準？A1：這個等級我們在資料資產中會有標記，把資料劃分為 4 個等級，三四級是最高的。如果涉及到三四級資料的時候，敏感程度比較高，會涉及相應領導和安全人員的審批，如果涉及普通的一二級資料，只需要對應的表 Owner 審批就可以了。Q2：整套系統裡面是外採還是自營的，分別是哪些部分是外採，哪些是自營的？A2：這個就是剛才講的第一頁的內容，我們 BI 系統的建設歷程。我們從 2019 年開始研發自己的整個 BI 體系，現在所有這裡面的東西都是我們自主研發的，涉及的 8 個核心功能都是我們自己在做的。報表平臺是外採的，現在還在用，但是現在我們有自己的報表平臺了，後續也會慢慢的會棄用掉外採平臺。Q3：為什麼不用 ClickHouse 或者 Doris 做多維分析工具？A3：我們選用 StarRocks 也是多個團隊一起合作的，涉及到一些跑批叢集也會用，比如我們的資料開發、資料中臺也會用；我們的報表涉及的主要是查詢，所以他們會綜合考慮到查詢效能以及跑批寫入的效能，以及我們對實時 BI 的需求。基於有這幾點的考慮，所以最終選擇是 StarRocks。還有一點就是，StarRocks 不需要自研或者外採，不用花太多的錢。A4：行裡面對整個科技是投入比較高的，採用的是行員 + 廠商協同開發的模式。A5：我們低程式碼去實現的功能，跟常規的那種拖拉生成表格還不一樣，我們這種是針對資料加工分析而做的，常規的你需要寫 SQL 去進行加工，但是我們對低程式碼的一個定位，是使用者進行拖拉拽，我們平臺去生成對應的 SQL。A6：低程式碼平臺，我們的定位就是資料分析，我們不會涉及到比如常規的生成表格或者是生成業務表單等功能。我們只針對分析場景，針對性的把業務常用的幾種加工方式整合進來，然後業務肯定是需要這些功能去做資料加工的。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2944661/，如需轉載，請註明出處，否則將追究法律責任。