一、平臺建設業務目標

中原銀行敏捷 BI 平臺的建設目標為滿足不同人群對數據查詢、分析和探索的需求，為管理和業務提供數據依賴和決策支撐。

1、核心訴求：滿足不同人群對數據的需求

不同的企業對于 BI 是有不同的訴求的。中原銀行對 BI 的訴求，是滿足行內不同人群對數據查詢、分析和探索的需求，從而為管理和業務提供數據依賴和決策支撐。

主要是針對三類人群：

?（1）第一類是管理決策層。讓管理決策層能夠看到準確、實時的數據，并依據數據去進行科學的決策。

（2）第二類是普通業務人員。比如針對業務數據統計，業務人員會在業務運營過程中涉及一些比如手工報表、人工統計、逐級取數等操作，使用 BI 平臺可以提升他們的日常數據統計效率，讓業務更多關注業務問題本身。

（3）第三類是技術人員或分析人員。通過打通各個業務系統，提供統一的查詢服務，提升這類人員的日常數據分析效率。

這是我們對 BI 的整體訴求，依據這個業務目標，我們建設了 BI 平臺。?

2、中原銀行 BI 建設歷程

中原銀行在 2019 年之前，使用的是采購的第三方報表系統。業務人員也已經養成看報表的習慣，現在整個行內有上千張報表，業務人員每天都會查詢這些報表數據。

從 2019 年開始，為了實現之前提到的業務目標，中原銀行開始建設整個的敏捷 BI 體系。

2019 年，把數據取數從線下轉為線上，提升安全提數效率。可以滿足一些比如日常的監管報送，或者領導臨時的數據需求，并提升操作效率。

2020 年，針對業務人員提升數據統計的效率。開始建設智能拼表，低代碼加工和可視化分析工具，可以讓業務人員在無需借助比如 SQL 加工的方式下可以完成數據的加工。這里補充一下，智能拼表是結合中原銀行的業務特點，允許業務通過低代碼的方式進行報表拼接。

2021 年，為了提升 IT 人員或者技術人員的分析效率，構建了我們自己的報表系統，數據大屏等。

2022 年，構建了我們自己的業務指標庫和數據門戶。

以上是我們整個 BI 平臺的建設歷程，逐步完善整個 BI 體系。

二、敏捷 BI 平臺建設

敏捷 BI 平臺覆蓋數據分析全流程，提供一站式、全鏈路數據分析解決方案。下面來介紹我們整個 BI 平臺的整體概覽。

1、中原銀行敏捷 BI 平臺架構

上圖是整體平臺架構。

?自下而上來介紹，最下面是接入數據：

（1）數據庫，包括關系型數據庫如業務數據庫、大數據集群和數倉等。

（2）業務人員收集或者填報的數據。

（3）第三方業務系統暴露出來的 API 接口。

（4）本地文件數據的導入。

然后基于這些數據，我們會一站式提供 8 個核心功能，包括：

（1）固定報表開發。

（2）低代碼數據加工。用于支撐數據統計人員的工作。

（3）SQL 數據分析。用于支撐于技術人員和數據分析人員的工作。

（4）可視化分析。可以以更直觀的低代碼方式進行數據分析，展示數據結果。

（5）數據分發補錄。用于本地數據線上化、數據分發確認。

（6）業務指標管理。是我們的指標庫，建設構建唯一確定的沒有二元性的指標，供業務日常的查詢使用。

（7）個性化門戶。是為了統一數據出口，把報表可視化看板以及大屏統一輸出在一個門戶中，供業務人員日常查詢使用。

（8）數據下載。提供線上化的數據下載，簡化下載流程。

基于這 8 個功能，我們構建了 6 個核心的數據應用，包括固定報表、數據大屏、可視化看板，安全提數、指標庫以及數據門戶，針對不同的人員提供不同的數據應用，基于這些應用進行能力輸出，給業務使用。

在業務應用場景方面，包括管理駕駛艙、營銷效果分析、業績考核監測、日常數據通報、?系統監測分析以及業務風險預警。

2、數據分析全流程覆蓋

上圖可以更好的幫助我們理解前面介紹的平臺架構，把 8 個核心功能分布到數據分析的 4 個流程內，支撐數據分析的全流程覆蓋。

我們把數據分析的流程歸結為以下 4 部分：

（1）數據準備。平臺支持多種數據來源，包括業務數據庫、核心數據庫、數倉內的數據庫、數據湖內數據庫、本地數據庫以及用戶收集的數據。

（2）數據加工。平臺可以提供兩種數據加工方式：一種是低代碼拖拉拽的方式，集成常規的數據加工方式，供業務人員進行低代碼加工；第二種是針對專業分析人員進行 SQL 的數據加工。

（3）數據分析。數據分析也可以歸結為兩類：一種是固定式的報表分析，基于報表平臺所創建出來的報表；另一種是業務自助式的分析，可以基于看板或者是大屏，進行篩選、關聯、跳轉以及數據的上卷下鉆等等。

（4）數據應用。我們提供多種的數據應用方式，包括數據大屏、數據看板、固定報表以及數據門戶集成，所有數據應用的結果都可以進行預覽、下載、分享等。

3、固定報表開發

下面具體介紹幾個核心的功能。首先介紹固定報表的開發。

之前我們購買的第三方報表平臺，使用中會存在一些問題：一個是平臺架構比較老，查詢性能上經常會出現 CPU 或者內存不足的情況；第二個是我們會有一些個性化的改造，這種改造通常需要一兩個月才能開發完成，不僅成本非常高，而且需要進行排期。

針對以上幾個問題，我們規劃開發我們自己的報表平臺，供業務日常查詢使用。主要是做一些中國式的復雜報表，包括一些非常復雜的表頭等等。

我們把報表制作分為 5 個步驟：

（1）數據源。就是我們能夠連接到的數據源，比如常規的 Oracle、MySQL，還有我們的大數據集群使用的 Gauss，以及 StarRocks、ClickHouse 等。

（2）數據加工。通過 SQL 進行數據加工，這里強調一點，在 SQL 數據集中不會有太多復雜的 SQL，因為大部分邏輯已經是在數倉內通過跑批任務完成了，在報表里面更多的是查詢已有的數據，我們使用專屬的獨立集群提升查詢效率。

（3）報表制作。我們把報表歸結為 4 類：第一類是即席查詢類，就是 SQL 數據集里面加工的邏輯直接動態查詢；第二類是類透視表，類似 Excel 中的透視分析，通過選擇行列和指標進行維度的組合篩選；第三類是 Excel 表格，專門去制作一些復雜表頭，或者是帶 Excel 公式的電子表格類報表；第四類是剛實現的可視化類報表，當前常規的表格展示不能直觀有效地表現數據的結果，因此我們引入一些圖形化的比如折線圖、條形圖等做一些可視化報表。

（4）報表發布。第一，由于行內對數據安全的嚴格管控，需要進行數據脫敏，否則是不能進行正常的報表發布的；第二，安全審批，需要走一個報表發布的流程；第三，報表版本管理，報表有兩個版本，一個是制作的版本，一個是線上的版本，制作的版本只有通過發布審批之后才會把線上的版本覆蓋掉。

（5）業務應用。我們行內把報表歸結為 4 大類：對公類、零售類、財務類和績效類。在這里會進行報表的知識庫構建，比如報表目錄管理，報表技術及業務口徑維護，報表關鍵字搜索等等。

4、低代碼數據加工

低代碼數據加工的建設，針對的是普通業務人員，為了簡化數據統計分析的難度，平臺通過集成常見的加工方式，讓他們可以通過低代碼的方式進行常規的數據加工。

我們集成了 10 種數據加工方式，比如字段設置、分類匯總、數據篩選、新增字段（基于已有的字段進行加減乘除運算）、數據排序、透視分析、查找替換、列轉行，這些是比較好理解的。還有上下合并和左右合并，是為了在低代碼方式下合并兩張表，一種是上下合并，一種是左右合并，類似于 Left Join 的方式。

通過集成這 10 種加工方式，業務進行數據加工的過程中，他可以按需選擇其中幾種加工方式。我們在代碼實踐過程中，通過 Pipeline 管道模式組合，生成最終的 SQL 邏輯，以完成低代碼的數據加工。

5、可視化能力：數據大屏及可視化看板

?在可視化方面的建設，包括數據大屏、可視化看板等等，通過一些拖拉拽的方式去快速制作圖表，幫助業務快速分析和洞察業務的趨勢。

這部分很好理解，最開始的是數據來源；然后數據加工有兩種方式，一種是專業人員的 SQL 數據加工，還有一種是低代碼通過拖拉拽的方式去進行數據的基礎加工；然后根據這些基礎數據去進行數據圖表的制作，我們支持 Echarts、AntV 這種常規的圖表組件，還支持圖表屬性的自定義設置，后面會涉及到一些比如指標計算和數據下鉆；圖表制作完成之后，就會涉及到圖表組合，支持可視化拖拉的方式去進行圖表的組合，最終制作出來的大屏和可視化看板是支持結果分享、多端查看以及支持單 URL 訪問嵌入等，最終支撐我們的可視化能力。

這部分我們是站在巨人肩膀上，也就是基于開源，再加上我們自己的個性化改造實現的。這些個性化改造，包括數據源的對接，圖形組件的自定義等。業務在圖表制作過程?中，如果常規圖表不能滿足需求，會提需求讓 BI 平臺開發比較個性化的圖表組件。

6、交互式 SQL 分析及安全提數

下面是安全提數的建設，為了規范數據下載流程，不會讓數據輕易流出，需要在保證數據安全的前提下，促進數據的使用和價值釋放。

我們在平臺里面做了三個步驟的控制：

（1）事前預防。制定取數規范，進行安全宣導、事件通報等等。

（2）事中干預。進入平臺之后，同樣會進行干預，一部分是對表權限的控制，表權限的申請審批，書寫 SQL 的規范評分等；還有一部分是對敏感數據的脫敏以及過濾。

（3）事后審計。包括日常用戶的操作日志記錄、風險的上報以及事后的安全審計等等。

7、數據門戶

數據門戶作為最終統一結果輸出的地方，把報表、可視化看板，數據大屏以及第三方頁面集成組合到一起。個人可以設置個人的數據門戶，滿足千人千面的個性化看數需求，獲得清晰、直觀、美觀且沉浸式的看數體驗。

8、指標庫建設

第八個是指標庫的建設，我們把它歸結為 4 個步驟：

（1）指標梳理。自頂向下構建指標體系。

（2）指標整合。整合是按照數倉的星型模型構建的，構建我們的業務指標寬表。

（3）指標上架。在我們平臺上進行指標上架后，業務能夠正常的去查詢，查看這些指標的口徑。

（4）指標應用。結合自助低代碼方式和可視化分析能力去滿足業務后續的分析需求。比如借助低代碼能力，可以進行基于指標表的自助加工；借助可視化能力，可以制作基于指標表的可視化分析。

三、業務場景支撐

上面主要介紹了平臺整體架構以及核心能力，接下來將介紹一些具體使用場景，也就是業務人員或者數據分析人員在平臺上做了一些什么工作。

1、數據分析場景全覆蓋

我們把數據分析的場景歸結為 4 大類：

（1）第一類個人自助分析。個人會有一些日常的數據查詢需求，比如報表查詢、數據統計，數據臨時下載等等。

（2）第二類賦能業務系統。就是支撐業務系統對接集成，把我們的可視化能力，報表能力輸出給業務系統集成，支撐他們去集成我們的可視化能力，降低他們的開發成本。

（3）第三類專題分析。針對于某一問題或者是某一措施之后的專項分析，評價其好壞，比如常規的營銷效果分析，就是一類專題分析。

（4）第四類管理駕駛艙。是使用比較多的一個場景，做出一些看板報表，供領導管理層基于數據的科學決策。

2、個人自助統計分析

下面看一下 4 個場景里面的具體內容，比如在個人自助統計分析里面，我們將其歸結為 4 類：

（1）報表、大屏及看板的日常查詢。常規需求，大部分人員就是為了看數據，只有少部數據分析人員才會真正的去制作這些報表。

（2）業務日常通報、業績考核。這是涉及到業務類的，之前是通過線下 Excel 的方式去進行匯總加工出來，然后每天都要繁瑣的去做這項工作，現在通過我們平臺就可以一次制作自動更新，免除他們日常繁瑣的數據統計工作。

（3）總行支行數據上報。就是由總行下發任務，讓分支行的人員進行數據的填報，之前是通過郵件的方式，一層層總行發給分行，分行發給支行，支行再發到對應的業務經理，流程是比較繁瑣的。

（4）數據分析及臨時提數。針對一些數據的分析人員，要去寫 SQL 去進行日常查詢，還有一部分是會涉及到一些臨時的提數等等，這個是個人的數據統計。

3、業務系統集成

我們的研發效能洞察平臺，就是通過集成我們的可視化能力去展示決策視圖或者度量報告，算是我們平臺能力的輸出。這樣一些業務平臺就不需要另外去開發類似的可視化功能了。

4、場景化的專題分析

對于場景化的專題分析，針對某一問題或者是某一舉措后的專題分析。以銀行某一產品為例，從經營現狀、資產質量、還款結構、轉化流程以及渠道來源等去進行各個角度的分析展示。

5、可視化大屏

可視化大屏，我們需要在一些比如業務風險會議或者是業務監控里面會有大屏的展示。這里有兩個例子，風險疫情大屏以及會計運營大屏，能夠掛到某一個地方，領導或者同事能夠日常的進行一些數據的查詢。

6、實時 BI 解決方案

接下來介紹的是一個解決方案，是針對實時 BI 的解決方案。

它是有對應的業務需求的，比如我們的管理駕駛艙，營銷效果分析以及風險預警等等，這些對實時數據是有比較強的訴求的。他們之前數據都是 T+1 的數據，這對預警場景來說已經是比較落伍了，T+1 的數據已經對于該場景已經沒有什么效果了，所以我們會依據這些場景去構建實時 BI 的解決方案。

常規的數據源發送消息到消息隊列 Kafka 里面，然后 Kafka 將消息發送到計算引擎 Flink 里面，Flink 把計算后的結果寫到我們的存儲引擎 StarRocks中。不同的業務場景可以使用不同的存儲引擎，我們全部使用的是 StarRocks。同時 StarRocks 作為我們 OLAP 引擎作為后續的 BI 的一個查詢引擎，比如我們的實時報表、實時大屏和實時看板，實現對數據的秒級實時分析，這是我們的實時大屏解決方案。

7、智能問答機器人

智能問答機器人是我們在智能化方面的一個建設。

整個流程就是用戶在平臺上提出問題后，后臺在問答知識庫進行匹配，如果匹配上的話直接會給出答案，如果沒有匹配上就會有經過相似度模型跟其他的問答去進行匹配，看是否是相似的問題，通過閾值判斷，如果超過閾值，就認為它們是相似的問題，就可以返回相應的答案，如果沒有，會經過 NL2SQL 模型去構建對應的查詢 SQL 給出相應的結果。

這個是我們在智能化方面的一個建設，不過目前因為數據量比較少，只能針對于單個固定式的那種場景去進行查詢，是我們的一個嘗試和探索。

四、未來展望

最后一部分是我們平臺的未來展望。

1、正在做的

我們目前正在做的工作可以歸結為四大部分：

?（1）第一部分是完善我們自身平臺能力，整個 BI 的功能完善。

（2）第二部分是平臺的推廣運營。酒香也怕巷子深，很多人是不了解平臺工具能夠做什么事情的。目前我們平臺大概有上千人使用，月活也有上千人，我們后續會更大量地推廣介紹我們的平臺。

（3）第三部分是用戶使用的平滑過渡。這里指的是傳統 BI 到敏捷 BI 的一個過渡。更低的學習成本、更順手的操作流程。

（4）第四部分是數據分析思維培養。不像互聯網公司，所有的銀行應該都會有這樣的現狀，分析還是依靠專業分析人員，在中原銀行是依靠數據建模師。業務人員更多的是做一些數據統計上?的工作，不會具體去分析這個現象為什么會產生、這個問題為什么會出現以及我需要怎么去做。這就需要我們進行一些數據分析的思維的培養，也是我們正在做的一個工作。

2、未來努力方向

未來努力的方向有兩個方面：

（1）第一個是平臺的智能化建設。通過融合 AI、NLP、模型算法等技術去簡化用戶的分析的難度。比如我們智能問答的嘗試；后續會做一些智能洞察分析，是通過平臺去自動發現問題，定位問題；另外是自動可視化，比如發現問題之后，怎么通過可視化展示這些問題，讓用戶可以看到這些問題，這是我們未來在智能化方面要探索的內容。

（2）第二個是平臺的開放化建設。把我們的能力進行輸出。我們的可視化能力，是每個平臺都會有的一個需求，我們后續會慢慢的開放我們的 SDK，我們的 API 以及我們的頁面嵌入能力，能夠去支撐更多的業務場景。

五、問答環節

Q1：數據下載審批，審批流程有分不同的重要等級，走不同的審批流程嗎？有的話等級是怎么標準？

A1：這個等級我們在數據資產中會有標記，把數據劃分為 4 個等級，三四級是最高的。如果涉及到三四級數據的時候，敏感程度比較高，會涉及相應領導和安全人員的審批，如果涉及普通的一二級數據，只需要對應的表 Owner 審批就可以了。

Q2：整套系統里面是外采還是自營的，分別是哪些部分是外采，哪些是自營的？

A2：這個就是剛才講的第一頁的內容，我們 BI 系統的建設歷程。我們從 2019 年開始研發自己的整個 BI 體系，現在所有這里面的東西都是我們自主研發的，涉及的 8 個核心功能都是我們自己在做的。

報表平臺是外采的，現在還在用，但是現在我們有自己的報表平臺了，后續也會慢慢的會棄用掉外采平臺。

Q3：為什么不用 ClickHouse 或者 Doris 做多維分析工具？

A3：我們選用 StarRocks 也是多個團隊一起合作的，涉及到一些跑批集群也會用，比如我們的數據開發、數據中臺也會用；我們的報表涉及的主要是查詢，所以他們會綜合考慮到查詢性能以及跑批寫入的性能，以及我們對實時 BI 的需求。基于有這幾點的考慮，所以最終選擇是 StarRocks。還有一點就是，StarRocks 不需要自研或者外采，不用花太多的錢。

Q4：關于人才建設，是一個什么樣的大致規劃？

A4：行里面對整個科技是投入比較高的，采用的是行員 + 廠商協同開發的模式。

Q5：低代碼后臺實際還是 SQL 數據集嗎？

A5：我們低代碼去實現的功能，跟常規的那種拖拉生成表格還不一樣，我們這種是針對數據加工分析而做的，常規的你需要寫 SQL 去進行加工，但是我們對低代碼的一個定位，是用戶進行拖拉拽，我們平臺去生成對應的 SQL。

Q6：低代碼平臺使用的場景是不是比較有限？

A6：低代碼平臺，我們的定位就是數據分析，我們不會涉及到比如常規的生成表格或者是生成業務表單等功能。我們只針對分析場景，針對性的把業務常用的幾種加工方式集成進來，然后業務肯定是需要這些功能去做數據加工的。