证券公司信息化_什么是大数据？大数据在证券公司的应用怎样？数据价值发掘的陷阱有哪些？

心血来潮搞24小时倒计时，把自己给逼住了。以后再不干这种傻事。花了几个小时，谈谈曾经有过的一些关于业务数据统计分析方面的感想。

半年前从微博上看到大数据概念，想着跟数据仓库概念相近。查了百度百科，说是Internet留下的海量Text被人搞去非结构化分析。跟结构化的数据仓库相去甚远。

但，就像“云计算”从最开始的Google的分布式数据处理的概念延伸到所有跟Internet服务端有关的事物一样，“大数据”也可能从海量非结构化分析领域延伸到所有跟“数据分析”有关的事物。广义“大数据”也就取代广义“数据仓库”的名气，变成了“对累积下来的大量历史数据进行查询统计得出有价值的分析结果”的眩目光环性质的噱头。

话说回来，炒概念还是有价值的。“水直清则无鱼”，朦胧概念刚刚兴起，最能激发想象空间和操作机会。就像这两年炒股，追概念股，大家都哪冲我就往哪冲。管你有没有道理，先捞一票再说！所以也就大言不惭的跟“大数据”概念扯点关系。

我把“大数据”在证券公司的应用理解为“如何更好的发掘证券公司业务数据的商业价值”。

证券公司的运作是高度信息化的运作模式。IT系统们产生了大量的业务数据（主要是客户的交易数据）。如何利用好这些数据；如何在中国证券公司同质化竞争严重的大背景下，增强自己的竞争优势，做到“知己知彼百战不殆”中的 “知己”；如何对自己拥有的数据要有完备精准前瞻性的了解；如何从“运行维护”的主要角色中提升起来，为公司提供“有价值”的商业决策依据，对CIO而言是一个及其诱人的新的历史使命。

又想起部委、地方政府，也喜欢炒概念，高铁、特高压、区域发展。有了诱人的概念，就能加大投资。有投资就有政绩。企业IT部也一样。能有“云计算”“大数据”这样的概念，就能好好搞点大投资，IT预算比什么都重要！

务实和务虚是有区别的，务虚是管理需要，是必须的。而梦想描绘之后，到实践阶段就会有大量的困难甚至陷阱。例如，现如今各部委和地方政府陷入庞大的债务陷阱。而IT部在推进这些务虚概念后，很可能的结局是：投资投下去，但效果非常不明显。搞不好就是虎头蛇尾，成了烂尾工程！

搞证券公司的业务数据利用也有几年时间，实践下来，发现在“业务数据发掘”领域存在以下陷阱？

1、 基本概念不清晰。
无论是大数据、还是数据仓库、还是商业智能、还是数据挖掘、还是ETL，基本概念存在不理解，或者实务不够。
可能有意无意，觉得有了新概念就能解决所有问题。但往往“它能解决你所有问题”的同时“它又不能解决你任何问题，…除非你告诉它怎么做”！在稀里糊涂时，最容易虎头蛇尾。

2、 期待一套“平台级的数据中心”解决所有数据来源、和数据一致性问题。
大量的管理部门的报表统计、查询分析、或者管理类数据都希望从这个“数据中心”获取。从而分离业务系统（主要指柜台系统）的角色，让它专注于客户资产簿记和实时交易。
但实际上这种“平台级数据中心”其实是一套完整的数据仓库系统，没有极大勇气、没有极大魄力、没有极大的公司资源调配能力，是无法完成这项工作的。

3、“数据中心”与“业务系统”中的数据，谁更完整全面？
我们想当然的会认为既然是建设一套涵盖公司所有业务数据的庞大无比的“数据仓库”，那么自然拥有粒度最小的数据细节。但实际上这是做不到的。任何数据细节一定是存在在业务系统中。从业务系统中提取所有数据的努力，都将是徒劳的。
这是一个大陷阱！感受非常深。

3、“数据中心”是否有独立与柜台系统数据库的数据结构。
如果数据中心仅仅是柜台系统的一套镜像，那么根本起不到“软件分层”的效果。任何一次业务系统的升级都将会导致数据中心的数据变动，自然建立在更上层的数据管理系统们也就需要调整数据采集口径。
如果数据中心有完全独立的数据结构，那么要有对业务系统的采集接口，也要有对管理系统的采集接口。这样数据中心有着某种“企业数据总线”的定位。
而由于不同公司的内部数据结构并不开放，所以“数据采集接口”的开发的难度，甚至不亚于开发一套新系统。
这就有个悖论：我明明是希望通过数据中心来降低数据交换的复杂度的，结果却增加了数据管理的复杂度。
我认为有个界限，如果数据中心上层的管理系统超过5个，那么“独立数据结构的数据中心”将是有价值的，否则，应该让这些管理系统直接从业务系统的数据镜像中提取数据更好。或者说：小券商就不要考虑数据中心了，大券商才有资源来搞这种“工业化大规模生产”模式下的IT系统。

4、“数据中心”本身是否产生数据？
这里应该有个原则：“数据仓库”永远不产生自己的业务数据，只提取。相同性质的业务要素，在不同系统中会打架。例如客户资料，按理说柜台系统是最全面的，但法人清算系统和CRM系统都有。就会打架。很多时候，想通过数据中心来维护一套“最权威”的数据来源。这个诱惑必须抵制，一定要清楚，只要产生新业务数据的系统，就是业务系统，而不是“数据仓库”。

5、“数据中心”是“数据仓库”还是“企业数据总线”？
“数据仓库”是所有静态数据的集大成者，侧重点是静态和历史。而“企业数据总线”更多的是实时业务数据的交换。侧重点不同，关注特征也不同。前者跟BW、BI、ETL相关，后者跟EAI、SOA、DataBus相关。一定不能放在同一个系统里解决。
特别注意的是，很难抵挡由数据仓库提供给其他业务系统统一口径的业务信息的诱惑。
注意以下定义：只要产生新业务数据的系统就是“业务生产系统”，生产系统之间的数据交换由企业数据总线完成；完全不产生新业务数据的以查询统计为目的的系统是“纯管理类系统”，纯管理类系统可以从数据仓库中提取数据。
CRM是个非常容易混淆的范畴，事务型CRM系统（例如呼叫中心）是生产系统智能从企业数据总线交换客户信息，而分析型CRM（纯客户行为研究）是管理系统可以从数据仓库提取数据。

6、对数据仓库的ETL过程的复杂度严重估计不足。
刚才说过，数据接口的开发的难度往往不亚于开发一套新系统。同样，包罗万象的数据仓库要从各个不同的业务系统提取数据的难度也可能远远超出人们的想象。主要难点在于：业务系统是不断变化的。
记得印度人搞数据仓库项目收费奇高，就是要花费大量人力去了解各业务系统的数据结构。说着容易做着难，有几个人真正了解柜台系统数百张表的每个字段的业务定义是什么呢？你费了九牛二虎之力搞清楚了，也就成了业务数据分析专家了。你把你的知识通过ETL固化下来放进你的数据仓库。你还得费九牛二虎之力把你的理解解释给别人听。然后，让业务系统升级，这两个九牛二虎又得从来一次！
本身IT系统就是一个业务模式固化系统。你要从一个固化下来的系统中打开黑盒子，解析里边最细节都东西，再用你自己的固化系统把你的知识装成一个黑盒子。然后，再打开自己的黑盒子，让别人理解你这里边最细节的东西！
尼玛！说着容易做着难，我什么都懂了，什么都做了，你用得轻松就觉得这事简单。呵呵。所以数据仓库这种东西只能说，不能真正去做的，它是一个深不见底的沼泽地，吃人不吐骨头。

7、业务系统的DBA。
你说公司内部谁更了解业务数据？应该是柜台系统的DBA。合格的DBA不仅仅是对数据库进行维护，还要有设计和修改的能力。起码的要求就是对数据粒度最细细节的了解。
刚才说过，公司内部最细节的数据不是在数据仓库中，而是在生产系统里。不可能也没必要把生产系统的所有细节拿到数据仓库中，所以真正的最细节的知情者是业务系统的DBA。

8、需求不足。
数据仓库项目是绝对的需求推动型的项目。在很多很多情况下，我们明明知道那是一个大金矿，但怎么用好这个金矿却一无所知。就像上边说过：“它能解决你所有问题”的同时“它又不能解决你任何问题，…除非你告诉它怎么做”！
我们知道业务数据的发掘一定能带来极大的商业价值。问题是哪些商业价值需要通过数据发掘来获得？
会想当然的认为，业务部门一定有很多需求等着我们给答案。鬼！他们大多数情况下等着商业智能告诉他们怎么做呢！你们不是号称自己决策支持吗，那就来告诉我怎么决策吧。
这是一个非常普遍的现象：业务部门把IT当成一种业务再造的管理咨询角色来看待。

9、业务考核的统计需求。
业务考核的业务数据统计需求是最直接，也是最普遍的。直接跟奖金挂钩嘛，谁都得重视。就是出报表。营业部考核报表，经纪人考核报表。
报表是死的，一会一个格式。你可能会建议他们用智能报表，横着竖着可以灵活定义抬头栏目。这些都不懂，或者说不想去懂，不想惹麻烦事。
再说一遍，业务驱动不足是最大的陷阱！

10、证券公司绝大多数数据统计查询分析的需求来源于证监会的要求。
这是几年下来最深的感受。证监会的要求有：
加强客户分类管理！（怎么分类？谁来分类？是分析型的分类还是事物型的分类，是分在柜台系统中还是CRM系统中，还是所谓的数据仓库中？）
加强客户保证金数据报送！（一帮人在中央清算公司搞全国的数据仓库，一个公司的数据一致性都如此难以为继，可以想象全国的数据是多么混乱不堪，但一定会下文要求公司提高报送质量）
异动监控！（交易所自己监控还不够，把责任往前推，要证券公司监控各种异动模式。这些所谓异动模式还有点数据挖掘的味道）
开放监控端口！（证监局也有意思，非得看到每个客户的每笔委托这样的细节，也许稽查大队就能不上门也能获取可疑数据，也许仅仅是一种威慑：小心点！我盯着你的）
各种稽核需求（查监管部门禁止的一些行为，对敲之类，查拖拉机账户，这个真是数据挖掘的典范）
大额可疑数据的报送（厚厚的一本数据接口，尼玛到哪里去找这么详细的数据需求？所以嘛，要需求，直接去参加人行的培训。）
证监会、证监局的各种统计报表。（10多张报表，说实话设计的很烂，一看就知道是拍脑壳设计出来的，很多栏目重复，或者栏目设置不合逻辑。不知道他们有没有用过EXCEL数据透视表功能，你那些报表完全可以通过上报一些相对明细的数据，自动生成你那些报表嘛！数据一致性还能保证！）

11、不同的部门不同系统出来的报表结果不同。
以前老说地方GDP统计数据跟中央的GDP统计数据打架。我搞了几年数据统计就知道，这是再正常不过的事情。
就例如说：“整个公司客户保证金有多少”这个简单的统计，我可以打包票两个IT人员拿出来的结果是完全不同的。
为什么？因为很多含混的业务要素没定义好哇，算外币吗？算QFII吗？算休眠户吗？等等
“业务口径从最细节上的定义”（而不是所谓的底层数据质量）是决定统计质量的决定性因素。而两个不同途径统计上来的结果的不同，一定是两个途径对业务口径的理解出现偏差！
要消除这种偏差是不可能也没有意义的。
就像外国人说我们的GDP统计数据，以前不信，现在认为：只要你的统计方法固定，那么增减量本身就能说明问题。

12、不同系统出来的统计结果的不同会严重影响领导对数据质量的信心。
这是一个巨大的陷阱。要避免这种挫败感就是严格的只通过一个口子往外提供数据报表。
而现实是，不同部门一定想要自己专属的统计系统。数据就会打架。这需要公司管理上的严格的配合。

13、不同的统计报表系统总希望拥有自己的小型数据仓库。
上边说过，公司平台级的数据中心是一个很难实现的目标。那么大多数IT公司提供自己的统计分析工具的时候，都需要底层的数据。管理上协调不好，很容易就直接从柜台采集数据了。
每个报表系统都是一个“黑盒子”，封装了自己的算法。当出现对统计结果的质疑的时候，只有找到最核心的那个人才能打开盒子解析最细节上的差异。

5000字，应该可以交差了。赶紧来总结：

1、“大数据”是新的模糊概念，存在巨大的机会，IT部应该利用这个机会多搞预算；
2、“大数据”是“数据仓库”的新包装，本质是利用现有业务数据，发掘商业价值；
3、“数据中心”的概念太模糊，要素界定不清的情况下，烂尾工程不可避免；
4、“数据仓库”的建立和维护需要付出极大的代价，最好只说不做；
4.5、数据接口的开发难度不亚于新系统的开发，“黑盒子”的解析是不可能完成的任务；
5、“数据仓库”和“企业数据总线”的角色不能混淆；
6、不要试图让数据仓库拥有生产系统的所有数据；
8、“生产系统”产生新业务数据“数据仓库系统”不产生新业务数据；
8、不能指望业务部门提出有前瞻性的业务需求，IT比业务更懂业务的；
9、保守经营是普遍现象，需求不足是数据商业价值利用的最大硬伤；
10、证监会的各种规范是证券公司数据再利用的最主要的推动力和需求来源；
11、“业务口径从最细节上的定义”是决定统计质量的决定性因素。
12、统计差异一定存在，不可避免；
13、管理问题是数据应用系统分割的根本原因。任何IT项目，根本上是管理问题。