数据集市项目的总结

本人毕业就在某银行信用卡中心工作，做了数据集市项目，据说投资3000万。后来在阿里做数据产品经理的工作，想把过去的工作总结一下，不管成功和失败，都是一种经历。于是有了下面的文字。

【项目概况】

项目立项花费时间：1年多

项目启动时间：2009年3月21日

实施公司：东南融通-菲奈特

硬件：忘了

数据库：DB2

ETL调度：Datastage

Olap服务器：hyperion

需求方/业务处：市场、风险、财务；客服、直营、电营、网营、催收、客服；监控处、操作处

项目经理：总行科技部出1人

项目管理：卡中心系统处出1人

业务咨询：决策管理处-数据仓库组（5人）

源系统：semacard核心计费系统、财务系统、信审无纸化系统、催收系统、客服系统、短信平台

甲方更换的项目经理：3人

甲方参与人数：决策管理处10人，系统处2人，业务处的经办20人，由此而牵涉到的开发公司源讯（核心系统）、信雅达（信审无纸化）、广东电信（客服）、华为（客服）等等。

牵涉到的最高层：副行长

经常涉及到的高层：卡中心总经理、副总经理、各业务处总监和主管

开会的频率：每两周至少一次大会，每天至少一次小会

乙方更换的项目经理：3人

乙方投入的人力：至少是20-30人的人力，持续做了2.5年。

我于2010年12月离职，当时一期还没有测试完成，据了解到2011年10月份的时候，所有的需求全部上线。

下面一一介绍，如果马上要想到一个词：痛苦。

【项目启动】

首先谈项目启动。据说用了一年多的时间。当时，广发一直有SAS组（后改名为决策管理处），分3个小组，报表组、仓库组、模型组，报表组处理各业务处的日常数据需求，包括简单报表、复杂分析、周期任务，甚至包括很多线上项目，仓库组负责中间层的建设，数据字典的维护，以及想推动数据集市建立，而成立的。模型组主要是维护评分卡项目，以及各业务处在风险及营销方面的客户评分等需求。成员中计算机背景的比例偏低，更多的是业务方面和数学功底。

有一套cognos的报表系统，为财务、风险、市场等部门提供基本的在线查询报表服务。但统计口径陈旧，没有进行数据更新，数据质量较差。

从系统架构上来看，报表组和仓库组有一台采集服务器，一台分析服务器，2台工作站作为存储，其余所有临时任务都在开发人员本地进行。模型组相对独立，有一台专门跑批评分卡的服务器，其余模型分析工作在开发人员本地进行。

开发环境：windows

开发语言：SAS

调度系统：用windows的任务计划

总体来讲，IT化程度较低，大部分工作（如需求的记录、需求分配、需求审核、bug记录、调度系统、导出结果数据、甚至扣费等涉及到钱的关键步骤）都通过人工来维护。此模式已经运行了8年之久，虽然比较落后，但也形成了一定的规模，满足日常业务处的数据需求，没有遇到多大的瓶颈。

但也有很多困扰，例如：

1）存储少，很多是月存储，没有日快照存储，很多业务分析由于无法追溯历史而不能进行

2）计算速度慢，大部分是在本地进行，本地的工作站虽然配置比一般的pc好一些，但跑批上G甚至上10G时，基本无法完成。而且计算资源分散，容易导致计算和存储资源的浪费。

3）数据质量不高，经常听到取错数据的消息甚至是处罚。数据质量的保证通过，交叉review和业务人员随机抽查计算来完成，很多关键的业务数据（分期付款的返回、积分的返回等）都是通过SAS组计算完成，然后将结果传输到核心系统进行处理。

4）调度系统落后，很多依赖关系没有解决，很多是通过跑批时长来估算，确定任务的开始时间。

5）需求管理混乱，需求的质量无法把控

6）没有发挥SAS的优势，把SAS当作SQL来大材小用。

有鉴于此，由SAS组老板，数据仓库组组长，总经理咨询师，一起推动数据集市项目的启动，耗时一年多，终于获得批准，并开始进行招标工作，最终东南融通PK掉了teradata等公司，成功拿到了开发权。（如果倒回到当时，不知道他们还想不想接这个项目）。

【成立项目组】

项目经理：由总行科技部的一个孙大哥出任项目经理，（此人既不懂信用卡，也不懂数据集市，也不了解卡中心组织架构，貌似也不懂项目管理）

项目副经理：由系统处的一个贾女士出任副经理。

业务专家：由数据仓库组姚女士

业务协调：由数据仓库组成员组成

业务方：每个业务处出一个经办作为该项目接口人。

乙方：项目总监、项目经理、架构师、前端java开发、ETL开发、业务咨询师、测试、hyperion工程师，浩浩荡荡，来来往往至少有50人。

项目开始了，大家充满信心和热情，对自己做一个3000万的项目感到由衷的满足感。

【需求访谈】

首先，乙方的项目总监把要实现的功能和解决方案，讲给总经理、副总经理、各业务处总监和主管、各业务处经办，讲解什么是多维，什么是交叉表，什么是灵活查询。当然，还有本公司在此方面的优秀案例，以及本公司成员的专业水平等等。

然后，开始进行需求的收集，各个业务处把日常分析的需求，想分析的东西，功能等都写成需求书，提交到数据仓库组进行统一整理，再进行需求访谈。各业务处分别有仓库组的各个人员作为协调者，协调开发公司和业务处经办进行工作开展。

结果很多业务方开完会回去之后，又打电话给数仓，我还是不清楚我要做什么，也不知道要交什么东西。结果得到了一通狠K，也不知道以什么样的形式提交出来，有鉴于此，开发公司提出先梳理业务分析思路，用mingmanager进行业务梳理（开发公司称之为“脑图”），根据脑图，开发公司的业务咨询师开始跟业务处经办一起学习和熟悉业务，并提出专业性的建议，然后再把“脑图”转换成多维和报表，可以供架构师进行系统设计和数据模型设计。

其中又出现很多戏剧场面，列举一二。1）监控处要求把IT需求（比如监控记录的收集）做到数据集市，是监控处总监要求的，每个工单流程节点的工作效率，检查每个业务处的执行情况；而且由于分管业务不同，互相不熟悉，一个业务处连续访谈了8个经办 2）禁止把数据字典交给开发公司，理由是泄露公司机密。（如果没有数据字典，那么如何开发程序呢）；3）客服得不到系统table的表结构和指标计算方法，说涉及到商业专利。

完成成报表和多维后，开始需求的串讲和反串讲，确定每个指标的算法，确定表样；期间，砍需求，改需求，增加需求，反复多次。一般是开发公司问到仓库组、仓库组问

到经办，经办再多方咨询确定，然后再陆续反馈回来进行修改。那段时期，开发公司的工程师经常工作到深夜2点，一周工作6天，非常辛苦。期间由于大家都提多维分析，结果开

发公司确定每个多维不须超过10个维度，而且最多做60个多维，结果，之前提的多维又都改成交叉报表。经过了很多波折，期间由于沟通次数多，各方业务理解不一致，层次审批

和传话，期间发生了不知道多少争吵，最终确定数据集市说明书，一个50MB的word文档，总经理签字完成。此时，半年时间已经过去。

【准备数据】

当时正赶上公司开始进行ISO27001的审批，各种工作都是安全第一。开发公司需要进行数据的研究，开始了数据的导出和加密工作，加密方案的设计，数据从备库的磁带之中导出（此工作由总行科技部来做，效率更慢，据说用了一两个月），结果经过庞大的处理工作，总共导出了4天的备份数据给到开发公司，以供给开发工程师进行数据check。包括数据关系、数据质量等等。

【设计和开发】

根据需求，开始进行模型的设计和架构的设计，然后进行etl的开发工作。此时，我们组就没有多少事情了，只是回答一些业务疑问，更多的是想从开发的设计和开发中，学到一些东西，把团队的能力培训起来。

架构设计完成，开始ETL的开发工作。请注意：此时是在业务需求理解不清晰，而且各个指标没有确定数据定义（信息安全需要）时，然后由开发人员根据每张table的comment，然后根据自己的理解进行开发。

期间，仓库组和开发公司不停的沟通来确定需求当中的内容，因为实际的数据与业务的理解有很多出入。而且，需求访谈、设计、开发、测试分别是不同的团队，而且完成各自工作后，就离开项目组，奔向了下一个项目。有些问题，当时是怎么商量确定的，开发工程师看不明白需求说明书，想咨询细节的时候，发现没有人知道是什么情况，导致了很多未解谜团。又得重新与业务处确认需求，再改模型，开发等。

除了数据开发，前端管理界面，hyperion前端工程师也同步进入开发，这方面是我们所不了解的，而是想学习的，所以并没有发生多大的问题。

经过夜以继日的开发工作，经常工作到后半夜，最终在2010年初的时候，开发工作终于告一段落。可以进入测试工作。先是SIT测试，后是UAT测试。

【测试工作】

测试的内容包括功能测试和数据正确性测试，测试团队：每个业务处经办，每个仓库组成员，总计20多人在某一天的早晨，登录数据集市系统，然后进行数据的正确性（每张报表的正确性）和功能的校验（包括权限问题，查询速度问题，olap功能，导出功能等等）和压力测试（请注意此时，没有经过数仓内部测试，直接交给业务处进行测试）。

结果测试进行了1小时，就炸开了锅，据说只有一个指标（代扣费）是一致的，其余全部不准确，甚至错的离谱。仓库组的电话都被打爆了，业务方开始骂娘，都TM怎么算的，根本没法用，而且查询速度极慢。大家都慌了神，开始四处查找原因，马上停止测试工作，开始全面的复盘。经过很多讨论，乙方公司北方区总监贾总（以前是TD的，后来去东南了），亲自找到行领导，解释说，数据集市是支持分析用的，错误在百分之多少的范围内是可以接受的，希望可以降低测试标准，通过测试。结果广发方面严辞拒绝，说数都算不对要它何用。那么如何保证数据是正确的呢？风险总监提出，让SAS组根据需求把指标算一遍，再让开发公司计算一遍，两边全部核对上，则测试通过。此方案一提出，大家差点瘫软下去。如果我们都把需求开发一遍，那么又要开发公司做什么呢？而且得保证SAS开发的所有需求是完全正确的。

后来开始测试大数，不测试每个报表的明细。ok，当即开始了总体数据的核对。

PS：此时又发生了三件事情：

一是：ISO27001作为全公司的大项目，波及到了数据集市项目，开发公司要集中办公，而且封闭外网，所有数据不流出工作环境（哪怕是测试环境）。然后产生了一个壮观的场面，每个工程师有2台电脑，一台测试，一台开发。所有资料的交换都需要通过一台中转机进行中转。

二是搬家：所有卡部的工作人员搬迁至珠江新城，但开发公司留守。导致之后的沟通成本非常之高。咨询一个口径要打上几十分钟的电话。

三是数据仓库组的领导申请转岗，唯一一个有数据集市开发经验的人也离开了这个团队。

大数据测试依然不够乐观，领导们终于决定要从头梳理和排查错误。报表一张一张的过，多维也是一个维度一个指标的进行对比。SAS组每人分配工作量，将报表用SAS程序写一遍，将结果数据给到开发公司。开发公司沟通完统计口径，开始修改程序，跑出数据，与SAS的数据进行对比。自测通过后，SAS组将数据发给业务方，业务方在前台系统里导出线上

报表数据，进行手工比对，业务方说通过，即通过。

由此，开始了艰苦漫长的比对工作，期间发生的事情，大家可想而知，面对一个几千行的excel，几万个数据进行手工比对，任何一个环节出现错误，都将导致大量的排查和工作量。

【项目完成】

如此进行，到2010年底时，第一批的报表和多维共120张基本通过。后来听我的同事说，到2011年的10月份，基本上第二批和第三批的报表和多维也已通过上线。卡中心全部接管了数据集市的维护工作，开发公司退出。

此时，卡中心的总经理已经易主；东南融通由于会计问题，在美国退市，公司走向了破产；数据仓库组的人员与项目启动时相比，也只剩下了一半，新进了几个新生力量；决策管理处的组织架构也发生了改变；开发公司有几个人也由东南跳槽到了广发；仓库的上线仅仅是第一步，后续又开始了仓库的推广和维护更新等工作。

所以，历时两年半的项目终于有一个里程碑。回想起来，不知道为什么做成这样，做的如此苦大仇深，做的如此痛苦，我相信有很多值得我们吸取的东西，也有很多借鉴的经验。不懂得反思就没有进步，历史带给我们的教训往往比经验更加珍贵。我希望将这些写出来，没有对项目组人员的任何不恭，只是以史为鉴，面向未来，给今后的工作给予指导，不要产生无谓的浪费，不要踏着历史的车轮，不断重复过去的错误。同样，我觉得也不能妄自菲薄，觉得一无是处。就像中国的发展是伴随着越来越多的批评，但它依然在发展。

所以，我们首先要弄清楚到底发生了什么，而不要看到了就去评判。一个事物发展了，必定有做对的地方，有做错的地方，那么哪些是对的，哪些是错的，要把他找出来。否则，就像先生说的那样，踏着历史的车轮，不断的重复过去的悲剧。不知道的时候，可以摸石头，但总不能总摸石头，有时可以看清楚一下路的。

【先说需要改进的】

1.为什么要建立数据集市？你指望它解决多少问题？数据仓库和数据集市是什么？

这个是所有公司的领导要问的第一个问题。公司的数据现状是什么？瓶颈是什么？

就我基于对公司现状的理解，确实需要数据集市。理由如下：1）分析已经规模庞大，需求管理和数据质量问题凸显，需求质量参差不齐，代码的管理太过人工，调度系统粗糙，数据质量低下，口径管理混乱 2）硬件难以维持日益增长的计算和存储需求 3）当前的分析指标，固定跑批的报表已经足够丰富，可以通过整合优化，通过系统方式提供给业务方，提供取数的效率。

数据仓库至少可以规范各个系统的数据，在同一平台下，可以方便的访问到不同系统的数据，有统一的标准。数据集市，可以针对部门级的应用，作出适合于业务分析的分析框架，

同时，都有完善的调度系统，和元数据管理。保证数据的有序正确产出，从粗放的管理走向集约。

但公司问题在于，没有把这些工作落实，而有了一个大致的方向，就开始投入大量的资源，当真正落地，去coding的时候，才发现有些东西没有想明白。所看到的数据仓库和数据集市远不是自己当初想象的那样。

现有需求的迁移问题，元数据管理，数据集市与模型组和报表组的服务问题，历史数据的修复问题，节约下来的人力资源的安排问题等等，这些都是需要想清楚才能，拿到想要的结果。如果在集市启动之前，我们先把现有需求梳理一遍，与业务方沟通清楚，该下线的下线，该整合的整合，该增加的增加，整理出现有产出的指标，也就是说清楚自己到底有什么产出的情况下，以此为基础，请一些业务专家和模型专家，设计出自己心目中的集市，然后再开始集市的建设，至少会做到有的放矢。一定要想到，业务人员是如何使用数据这个场景，心中的任何疑问都有比较清晰的答案时，再下手去拿结果。

2.策略要以需求为导向

数据仓库的建设是一个长期的事情，不能建2年再拿出一个产品，然后让用户去用，一般的公司是以利润为导向，以结果为导向的，一个产品想生存下去，在组织里得到认可，是需要客户的，哪怕很少。所以，找到业务处的痛点，痒处，然后，一个问题一个问题的去解决，客户认可，然后再解决下一个痛点，也就是在客户的不断认可下，同事实现了自己的规划。

降低客户的期望，不要承诺太多，当你做出的超越客户的期望时，客户会越加的欣赏，也不会提出无理的要求。双方都在一个彼此信任的基础上，找到工作的节奏，拿到大家期望的结果，双方的日子会非常好过。否则，经常好心办坏事，业务处不满意，自己得到抱怨和投诉，而且得不到认可，团队自然也不会健康。

所以，我们没有以需求为导向，而是为了做项目而做项目，大家都上数据集市，我们不上有点落伍，说起来都不好意思说自己是数据仓库组。也许，当时我们没有判断能力，而是在追求心中未知的美好，在做一块别人画出来的大饼，以为自己由土变洋了，能做出一个别人没有见过的olap，就可以代替多少开发人力，在业务上产生良好的效果。所以，解决实在的问题，满足业务方的需求，是建设此项目的唯一价值所在。而不是我们的平台有多NB，架构有多先进，效率有多高等等。

3.数据质量是老生常谈

现在说数据质量，据说在中国，把统计做准，是一件永远也完不成的任务。我们的GDP每年的公布是可信的吗？每年的GDP、CPI是怎么收集数据的？计算方法是怎么样的？一个企业的数据尚且统计不准确，更何况一个国家呢？

在SAS经常听到的故障，就是数据错误。短信发送错误，有时甚至到总经理出面为客户道歉的级别；不良率计算有误，据说银监会都因为这个过来审查；卡量统计有误，导致营销员工资没有发对，被一线的员工骂的狗血喷头，好像不只一次两次了。这些是生产数据对外报送数据，那日常的MIS、分析的需求，就不知道里面有多少数据是所谓的“正确”的，老板拿到的分析报告，市场处、财务处、风险处都有可能存在差异。这些都是数据质量的问题。

这个问题出现的太多，甚至有些麻木了，从个人角度来看，这是一个关乎生死存亡的问题。但公司活的好好的，就是有些可以避免的麻烦而已。所以，这个问题还没有上升到一定的高度，来触动老总和部门总监的神经。晴天的时候最适合修屋顶，这是前人总结出来的经验。在数据质量问题还没有产生恶劣影响时，关注数据质量，建立保障体系，是功在千秋的伟业。而且，越到后面，修复成本越高，越不愿意梳理，直至大家都无法忍受，那时，有可能修复的成本比重建的成本还要高。

就像软件的bug一样，数据质量有太多的原因，以后我会专门讨论这个事情。粗看起来，有几方面：

1）系统本身的数据错误

2）业务理解与实际的计算逻辑有差异，即统计口径有误

3）开发错误，工程师的代码有bug

4）需求管理不一致，同一个指标多种算法，导致每个数据正确，但互相不一致。有人对数据质量有一个观点，即使错，也要错的一样。有一道理。

从数量上来讲，2、3、4是最常见的。解决这个问题，是需要多管齐下。

1）要有一个监控系统，检测KPI数据和异常数据，就是要及时发现错误，修复和改正工作是后面的事情，否则只能是等到影响业务的时候，我们才能发现此类错误，要做华佗他大哥，而不要做华佗

2）有元数据管理系统，对每个字段的解释做到位，尤其是经常用的关键字段。

3）需求管理，规范指标的使用，让业务方也重视数据质量。

4）开发工程师的工作习惯，double check，review，抽查数据好像都不是什么好办法，唯有提高工程师的责任心和工作习惯，并且将数据质量作为一项重要考核才能从根本上提高数据质量。

4.项目管理永远是关键之一

无论做什么项目，都少不了项目管理。项目的管理能力和项目组成员的执行力可能是这个团队能力的最重要的体现，能打硬仗的团队，不一定是能力很强的人组成，但一定是执行力最强的人组成的。有需求，就有了目标，有了人就有了资源，拿到什么样的结果，就看leader的管理能力了。有人说，中国目前不缺少idea，不缺少梦想，不缺少摇旗呐喊的人，更不缺少点评的人，缺的更多的是做实事的人，敢于承担责任的人。

项目也是如此，项目管理，跟管人不太一样，是对要做的事情有清晰明确的认识，然后再根据现有的人力去安排各自的角色，制定计划，到期拿到相应的结果。从这个角度来看，这个集市的项目管理很有问题，有可能是此项目成败的最关键因素，当然这和职位和power也是密切相关的。甲方公司错误的估计了自己的水平，而对开发公司不够信任，甚至处处刁难，把自己身上的责任往外推，貌似保护了本方利益，其实是大大伤害了自己，得到的是小恩小惠，失去的是团队能力的提高和市场上的口碑。

具体来讲，1）项目组成员太多，虚名太多，真正干活的就那几个，项目的leader控制力太差，职位太低，获得的授权太少，专业能力差 2）项目的进程和计划没有想清楚，或者说没有落到足够细，导致只能是推着干，然后解决过程中出现的问题，然后又跳出新问题，再解决问题等等。3）互相推诿现象，各方都在维护自己的利益，抱怨的太多，配合的太少，敢于承担责任的部门更少，这有可能是公司所有项目的通病 4）项目工作流程不够规范，比如需求访谈，是以什么样的方式，什么样的标准，什么样的交付物，没有统一。测试环节的流程，交付的数据格式等。5）执行力不够，而且惩罚力度不够，很多人都可以把工作延滞，然后找出很多冠冕堂皇的理由，导致项目组工作效率很差。

5.多方合作才能发挥真正价值

这方面是对整个的数据分析工作来讲的，有了集市，要有应用，产生实际的市场效果才能判定集市是好的，集市在项目完成之后，工作不会变少，反而会更多。我认为整个数据平台已经要包括数据仓库、数据集市、报表系统、KPI系统、模型部署、专项数据产品、复杂的高级分析、决策系统，分别面对不同的客户群体，包括高层、业务专家、业务执行人员等客户，其中系统稳定、数据质量、计算效率、用户体验、BI分析、业务应用这几方面都发挥作用时，各个角色紧密配合，这时才能体现数据平台的真正价值。

数据集市建立好之后，要在此集市基础上开发分析体系、KPI体系监控、BI的闭环应用、部署模型等，同业务方一起，双方共同进步，每天的工作就是看数据，看报告，思考业务改进点，思考创新点，产生落地方案实施，然后再看数据，定策略，…………，如此循环。

有人说，有价值吗？是从事数据分析相关工作的人自己YY，还是售前在不断炒作，还是很多公司在跟风？数据真正能帮到公司吗？答：不一定。数据分析只适用与某些类型的公司的某些阶段。而且，数据只是支持作用，做决策的还是人，数据只是能真实的反应一些状况，不会总是“拍脑袋”和“想点子”，能避免错的，就能降低一些风险，少走一些弯路。而且数据依然是数据，上升到信息-->知识-->决策，是需要人去看的，那里是鱼翅还是萝卜，就看各位的水平了。

【吐槽完了，再说说好的地方】

1）分析的历史悠久，用SAS用了将近10年，比别的公司更注重依据数据进行决策，在此基础上积累了很多宝贵经验，很多公司才开始做数据分析，而我们已经有2000份左右的报表在run了

2）有些业务专家水平很高，分析的角度非常新颖，而且非常全面，这也是分析组之福，开发者能不能学到一二，就看各自的造化了。

3）在这样的环境里，依然有很多踏踏实实做事的人，这些人是公司的财富，也是希望。