[吐糟向][感悟向]说说呆在金融行业 IT 这几年

在金融行业 IT 呆着也到了 8 个年头，职位也上到架构师级了，吐点糟吧，说说我眼中的印象。

[印象一] 封闭，极端封闭。
这是个极端封闭的行业， N 年来应用架构方案只有有限几种: struts ， spring MVC ； EJB, spring ； hibernate ， mybatis 。数据库方案屈指可数: MS sqlserver, DB2, oracle.
有很大一部分是由于行业的极端需求决定的，对新技术的应用都非常谨慎。
不过现在也开始有些转变，部分公司的外围系统开始出现一些 hadoop ， node.js 之类的新兴技术框架。
其实我个人对此的观点是，应用架构都是领域驱动的，技术是一码事，新技术未必适合这个领域。片面追求技术是危险的。
不过有很多明显可以提高生产力的技术却没有得到应用，就有点让人觉得不可理解，这个印象三里会讲到。

[印象二] 不差钱，买买买。
所有东西都是“买买买”，从应用到维保。
我完全理解“专业的事情要交给专业人士处理”这种观点，并且认为这是种正确观点。
但是我不觉得光花钱就可以买来专业。

[印象三] 一些反思
这部分想说说曾经经手的几个项目，和一些反思，就当是回顾总结吧。
普通的应用项目，我觉得都不值一提， Java 的企业应用基本就那么回事吧，体现在对技术框架本身和业务理解上。

1. 某 DW/BI 项目
这个项目比较有意思，当时 Global 对这个 local 的项目并不是很感冒，所以没有资源支持，所以基本上一个人担纲设计到开发的所有任务，而且还没有预算。
项目的主要问题有 4:
数据源复杂: 公司运作了几十年，各种数据源都会有， AS400 ， Oracle ， MS SQLServer, Excel, Access, Txt （ CSV ）……
数据是有时限的: 有一堆特定数据是需要在特定时间导出的，简而言之，过了这个村，就没这店了。
没有数据内涵的 support: 其实这是最难的，给你一堆英文首字母组成的表名和列头，跟乱码有什么区别……对吧……
数据量大:这个是所有像样一点的 DW/BI 项目都会遇到的问题
所以当时做了这样的设计:
ETL 用了著名的 Spoon ，当时还叫 Kettle 。解决了复杂数据源问题。作为一个成熟的开源 ETL 工具，几乎完美的解决了多数据源问题（说几乎是因为我始终没能解决 AS400 的双字节乱码问题，最后是通过开发插件处理二进制流，部分解决的）。
定时抽取问题是 shell 脚本配合 cron 解决的，利用系统级定时调度器也是 spoon 官方推荐的方案。
数据内涵完全是靠表数据和业务数据逆向出来的，此过程之痛苦真难以用笔墨形容……一边对照业务流程操作，一边对比 spoon 增量更新数据，花了差不多两个月把大约 200 张表和业务的逻辑勾稽搞清楚了。
数据量大本来不是问题，但是当 global 对项目不怎么感冒，而且对应用管理严格的时候就成了个问题。不能在服务器上架设 policy 以外的数据库，开源数据库统统阵亡，因此可选的数据库只有 2 种（ MS SQLSERVER, oracle, 其实…… access 如果算数据库的话可以认为是 3 种），而 Oracle 的 license 不够，所以就只能选择 SQL server 。实话实说，巨硬产品相对来说还是比较靠谱的，最后把仓库架在了 SQL server 的多节点负载均衡上（别跟我说巨硬有 DW 专用组件，那个没买），当然其中使用了各种不愿再回想起来的奇技淫巧。
报表展现层其实有诸多选择，当时考虑的是开源项目中比较成熟的 Jasper Report 。开始用 Eclipse BIRT ，那玩意只能说是“勉强可用”。 BI 部分，在 DW 上架上了 SpangoBI, 但是只用了其中一小部分功能（ MDX 及其展现）。
当时报表和多维分析时效是 T+1 的，后来想想，既然有时间戳增量更新，其实可以做到 T+0 ，如果把数据模型细分，可以做到准实时，只不过当时没这样的要求罢了。
项目前后大约折腾了 3 个多月，主要时间还是花在逆向表数据上。
反思一下的话，如果用 PostgreSQL 性能应该更好些，可以避免很多奇技淫巧的坑。总的来说，没留下什么坑，也不怎么需要维护。不过前面所说的“封闭”，可见一斑。

2. 某数据分析项目
这个项目就更有意思了。项目详情不能透露，大体上是找麦肯锡做的咨询，花费是千万级的（不差钱，买买买）。
神奇的地方在于，麦肯锡给了 2 张无法实施的纸就拿走了千万。两张纸的模型精度是多少呢? 据说α=0.3 。看到这里估计有童鞋要喷老血了，这不是只比瞎蒙高那么一点么…… 好吧，项目还真就跟着这个比瞎蒙高一点的模型走下去了，看起来也像成功了……至于是不是真的成功那只有用的人自己知道了。
这个项目可反思的东西就多了。
建模方面看的话，觉得建模方法本身就有些问题。对于达到 TB 规模，变量超过几千的数据，我的感觉是传统的统计方法有一部分不再适用，并不是说统计没有用，而是方法需要转变。
这种情况下，我更倾向于先进行无监督聚类，再通过一定程度的抽样即可将现有数据都打上分类。模型生成方法更倾向于 AdaBoost 或者随机森林，速度快，精度也不低。
实际上有偷偷试过几下，裸数据聚类并分类生成的模型（ AdaBoost ）预测准确率大概在 76.4%左右，调整一下应该能上 80%。
不过呢，这事情有点微妙，你总不能说那千万都白花了吧。
架构方面看（……当然不是我搭的，当然，如果是我搭的糟点也许会更多也不一定），采用传统的 SAS+Java+Oracle 真是充满了糟点。完全可以采用 ETL+hadoop+RHadoop （对不起我是用 R 的，也许有更好更快的方案，比如 spark ）。首先，对一个没有遗留系统的项目，没有看出采用 SAS 的必要性；其次， Oracle procedure 处理的效率跟 hadoop 和相关组件根本不在一个数量级上。

（待续了）