平安银行上海分行数据治理项目--项目整体介绍

这是我第一次把真是项目经历搬上公众号，第一篇文章先对数据治理项目做个粗略的介绍，以及项目要解决哪些问题和如何解决这些问做了概括说明，后面我会陆续对这个项目做细节性说明，因为某些内容可能涉及商业秘密及敏感信息，这里不便详细披露，有机会我会用适当的方式在文章里逐渐解释说明。

================================

项目起止时间：2017年3月至2017年9月

项目投入人力：18人月

项目范围：数据质量治理，下游报表改造，下游系统改造。

项目背景：

至2017年初，我所在上海分行ODS数据仓库表量已经超过700张，累计数据量超过20TB，每日增量数据大于70GB，并且增量数据呈线性增长，对存储要求、结算效率、数据库备份、统计信息收集都产生了极大负担，在这种情况下，我应势向领导提出上马分行数据仓库数据治理项目，并得到领导支持（写到这多说一句，作为传统金融机构，IT项目立项极具技巧性，后面可以专门写个文章，说说银行IT人员的KPI和IT项目立项的那些事儿）。

问题梳理：

一个项目要顺利开展，就必须对现存问题有个准确的掌握和认知，梳理系统现状和存在的问题就成为一个基础性工作，因为分行数据仓库是我一手建立起来并跟踪维护的，对这个系统我可以说早已了如指掌，下面就是对系统目前情况的概要梳理，也是驱动此次项目立项的内在原因。

1.存量数据量大，每日增量数据多

银行业务非常复杂，数据量也非常庞大，14-16年短短三年分行数据量就实现了从2TB到20TB的跨越，入库数据量由日增量5GB增加到日增量70GB并持续快速增长，按目前增速，1年内，日增量数据就能突破100GB，年增量数据即超过40TB，这种爆炸式数据增长就目前的数据使用需求和管理能力来讲是无法承受的。

2.数据结构复杂

平安银行发展比较曲折，历史上有个两次银行并购重组，多次核心系统升级，尤其在2016年，整个核心系统被完全推翻重建，多年历史问题积聚，导致银行数据结构异常复杂。

3.无效低效数据量极大

这让我想起了股市里的二八定律，说的是股市里只有20%的股民挣钱或者不亏钱，80%的股民是亏钱的，在银行的海量数据（与互联网公司相比，可能我们分行几十TB的数据量还不算海量）里，实际有效数据或者被高频使用的数据甚至远远达不到20%，大多数数据趴在数据库里睡大觉。

4.历史数据管理不规范

上面说了数据结构复杂，但就历史数据而言，因历次银行合并系统整合之后，历史数据就变得异常难于管理，这里有系统反复建设产生的历史数据数据孤岛，也有切分时点不同导致的历史数据时间边界模糊问题。

5.数据分层不清晰

因为分行数据仓库建设是伴随着业务需求不断增量建设起来的，开始的时候需求少，数据量小，很多报表都是直接在基础表上计算生成而来，或N多报表各自结算各自的数据，导致数据层次结构不清晰，常用汇总数据被反复计算，久而久之，形成了一个数据层次不清晰，结算效率不高的运行现状。

================================

上面问题分析清楚了，项目需求也就明确了，下面就是对应的解决问题的办法，也就是我们本次项目要做的事情。

解决方案：

1.开源节流

这里说的可不是经费或者预算，对数据仓库而言，开源即广泛接纳各种数据源，即包括各个业务系统源也包括各类数据源的接入，比如数据库、数据文件等，这在数据仓库发展过程中是必须且持续要做的事情，节流，即有效控制数据导入，严格控制数据在数据仓库里的存放周期，这项工作是立竿见影的，掐住若干张大表这个数据流入的七寸，就可以有效管控数据导入规模，极大避免数据无需膨胀。

2.质量控制

垃圾数据其实只是数据质量控制一个非常小的方面，毕竟数据由业务系统接入到数据仓库，传递过来的垃圾数据的量是非常非常小的，甚至小到几乎可以忽略不计，质量控制更多的是控制存量数据里的冗余数据，这些冗余数据并非垃圾数据，而是访问频次非常低甚至从来不会被访问到的数据，这部分数据占据了整个数据仓库数据量的80%左右，当然不能排除某些数据在未来某一时期随时可能被用到，所以这清理这些数据就要适当的折中或者取舍。

3.大表治理和数据迁移

关于部分大表，比如余额表、交易流水表，单表数据量都要超过几个TB级别，这么大的表，查询或者计算的效率可想而知，这部分数据是没办通过“节流”来控制入库数据量的，因为这些数据对我们而言是“刚需”数据，每天都要用到的数据，对于这种超级大表，最有效的办法就是按发生时间做数据切分，即拆表，我们都知道，1年前的数据报表需求是很少的，2年前的访问就更少了，所以我当时的思路就是建设归档库，把大表低频访问数据丢进归档库，给生产库减压。

4.数据分层

数据分层这件事情是非常难做的，有以下几个难点，1.报表量大，结算逻辑错综复杂，使用字段多种多样；2.人心复杂，每个人都担心在数据分层实施过程中影响到自己的报表，程序员天生就有对“别人写的程序不放心”的毛病，一旦在实施过程中，因统计口径或其他原因导致自己的报表数据不准，那可是影响KPI的大事情。遗憾的是，即便我们花费很大的力气跟各个开发人员讲述数据分层的多种好处，在项目实施中仍然遇到了非常大的阻力，最终的解决办法是从相对独立的系统开始，逐步推开公共数据分层结算逻辑。

5.提高结算效率

大量的报表多是基于底层数据做加工结算，导致CPU和IO资源被大量抢占，数据结算效率低，时常出现不能在业务要求的时间内结算完成报表，解决结算效率有几个办法，为了能有立竿见影的效果，我第一步做的是抓重点效率低下的SQL，优化SQL逻辑，效果可以说是出奇的好，这竟然能解决掉90%以上的超时结算问题。剩下的，就只能依靠数据分层、优先配置计算资源、等其他方式逐渐解决。

作者：刘阳  

来源：十年IT老兵