技术积累-商业银行数据仓库架构及BI应用简述

Posted 2021-04-24 十年IT老兵

先发个图镇场子...

说来惭愧，虽然我从事数据开发工作8年之久，但我还真没有过系统性的梳理数据仓库架构，上图是我临时画出来的，这里面很多地方不够细化，但大体上还是可以描述出一般商业银行的数据仓库及在其基础上搭建的应用系统架构。

目前来看，金融业尤其银行业在大数据应用方面相对互联网行业还是比较薄弱的，这与行业特性有关，毕竟银行业更多讲的是“审慎经营”或“稳健经营”，既然是审慎、稳健，那势必在产品创新、技术创新、应用创新上会相对保守后滞后，当然目前有些大银行已经在大数据应用方面有所尝试，比如通过大数据分析制定营销策略，经过大数据分析执行风险控制等等，但是这些听起来高大上的技术应用，其实与真正的大数据应该发挥的作用还相距甚远，大数据在银行业还有很大的应用价值没有被发现或被落地使用。

我在入职平安银行之前曾在安硕信息任职，其中一个项目是浦发银行数据服务项目，做的事情就是ETL过程（数据提取、转换、加载）和报表开发，后面辗转到平安银行，同样做了很多“数据需求”方面的工作，包括这几年和身边多为老同事或朋友也聊过，单纯从技术上讲，总结起来其实大多数银行的数据仓库建设方法和使用方式都大体相同，至少建设思路是差不多的，最大的区别是使用的工具和具体实现的技术手段不同，比如浦发银行数据仓库用的是Teradata，平安银行用的是oracle，浦发银行报表工具用的是BIEE，平安银行用的是Cognos，同样的，基于数据仓库做出来的报表和应用子系统，思路也都差不多。

1. 数据仓库架构

目前数据仓库主要还是遵循“数据抽取—>数据存储—>数据集市—>数据应用”这个逻辑。

底层数据源来自多个业务系统或文件系统，经过ETL过程，将各类数据加载致ODS层存储，这时候数据基本还是原生态的，只是按来源做简单分类；到数据集市层，实际上已经按数据主题即业务需求或部门数据将数据进行再次整理，并逐步提高汇总程度，即粒度越来越大的过程；应用层实际才是被广泛使用的结构层次，当然这里并不是所应用使用的数据一定是经过加工汇总过的，目前数据使用者也越来越关心数据“最原始的样子及状态”即：明细数据，也有历史数据查询接口，实际查的大多是没经过任何加工的最小粒度额原始数据。

    2. 基于数据仓库开发的下游应用系统及报表

数据仓库传统应用主要是还是以BI（商业智能 Business Intelligence）为主，说的更加通俗点，BI最终落地的无非就是各类报表，当然目前在数据仓库及出上也构建了大量的下游子系统，比如上面列到的司法查询系统、风险预警/分析系统，历史数据查询系统等。对数据仓库的定义现在已经更为扩大化，用流行的叫法更喜欢叫“数据平台”或“数据中心”，并在此基础上发展出各类大数据应用产品。但对我们做技术的来讲，万变不离其宗，我们仍可把各类数据、各类应用、各类报表看成一个整体数据仓库解决方案或BI解决方案，只不过数据源更为广泛，ETL处理方式更加多样，把原来的各类报表变更一下展现方式，以提供系统性、多功能性、复杂权限控制等需求。

    3. BI应用热点

目前各类简单报表已经不能满足综合数据分析及复杂展现样式的需求，各类驾驶舱、地图展现、钻取分析等等，已经成为不可或缺的数据展现方式，近些年流行的“大屏技术”正广泛被各大企业所接受，这势必会成为BI应用的一个热点；将多种看似无关联性的多源数据通过集成分析，进一步挖掘数据内在价值，通过新技术手段如Hadoop等等，改造传统银行业数据仓库数据挖掘、分析、采集、加工技术，进一步提升数据处理能力和加工时效。