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

[miemiekurisu]

在金融行业 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 和相关组件根本不在一个数量级上。

（待续了）

[xieyingli]

作为一个干房地产的我居然能看懂楼主说的大逻辑。。。虽然技术是一点都不懂。

[miemiekurisu]

@Madeline 我不太喜欢盗版...freeware 就凑合了...不能凑合还是得买...

[miemiekurisu]

@shakoon 当然甲方...乙方根本就无所谓, 觉得不爽要求换个条线就好了

[sndnyang]

所以我撤了， 马上辞掉 工资还可以， 加班不严重（有强制时间却不强制做什么事）的工作——原因若干， 很重要一点就是 真没意思， 对业务没兴趣的话， 感觉糟透了， 混了 2 年下来， 还是不乐意了解那些业务上的问题。

[shakoon]

@miemiekurisu 说实话我从你的语气中感受不到你有这么多年的银行工作经验，或者说你没有好好静下心思考技术和 IT 部门如何体现对银行的价值。业务与 IT 的融合才能使 IT 支出为银行企业带来相应的倍增回报，作为合格的银行系统架构师，是绝对不会以追求技术卓越为驱动的。

[ichigo]

@macemers 每年年底有内部岗位竞聘，我和一部分有投票权的同事平时关系搞得不错，然后我就转型了。

[hantsy]

现在传统金融公司都是往互联网上靠，什么 P2P ，配资啊等，，，呵呵。

无法避免的一个问题，他们比一般的互联网创业者更没耐性，都是想赚快钱，赚大钱，甚至打擦边球（其实都是违法的）赚钱。

做过一个金融项目之后，不再想做金融的了。

技术他们一点都不关心，面子更重要。招一些国内一线大公司过来的 SB ，什么都不会干也不要紧，出去的时候向别人介绍，我们的 XXX 是从 XXX 公司挖过来，好像自己是脱离传统金融的土包子，一下子进入互联网，瞬间就高大上了。这个项目中所见所闻几乎在我脑子里面留下后遗症，现在只看到一个招聘说是 BAT 大牛操刀的公司，我第一感觉就是这公司不靠谱。当然我希望只是我运气不好，遇到了一些极品 SB ，其它的真的是牛气冲天的大牛。

快速赚钱捷径实现是他们的关键，比如，他们什么东西都是倾向买现成的，要快，反正不差钱。但有些想法幼稚到了极点了，我常想到央视一个小品的那个面面，“把大象的基因移植到鸡腿上”，让人哭笑不得。

[hienchu]

看了这帖子才意识到，原来金融 IT 人还是不少的。。。而且貌似我司在技术上还算有追求，起码没主流甩太远。”买买买“的确是事实，我司的做法是，先”买买买“，然后各种自己封装和二次开发。个人理解，买主要是为了监管需求，万一出了事情好推脱干系。自己是做交易和市场数据相关的，从系统角度来看，理想状态是"稳定而不失灵活"，结果就是各种 hack on hack ，代码可维护性很差，很多时候为了一个快速改动能从底层（比如网络通信）一直 hack 到业务逻辑。

[miemiekurisu]

@shakoon (*´∇｀*)没错，我确实不是银行系统的。
首先我觉得挺失望的，因为每一篇类似的帖子下面总会有这样雷同的回复，看起来很有道理其实什么都没说；其次说到和业务结合的话…… hum ……我是这样看的，需要明确的是，由于银行 /保险核心和周边业务庞大且复杂，理论上不可能完全了解，但是一个智力处于正常范围内的人应该可以在 1-2 年内对所属条线的全部业务了如指掌，并且能通晓所有周边条线的业务并了解所有业务条线的概貌，大学本科才念了 4 年，对吧? 再次，精通业务只是前置，精通业务的最终目的是根据业务去构建和优化系统，利用技术知识和经验去设计和开发，并且为将来可预见到的业务变化和增长及留下足够的弹性设计，本质上是一个加快开发效率降低成本的过程。如果你认为这些事情可以被称之为“价值”，那么我的理解可能跟不太一样，我觉得这些事情属于不言自明的基本 sense 和技能之一，只不过是比天天写 if else 好那么一点罢了（对不起我是不是 map 了）。

[miemiekurisu]

@hantsy 技术只是手段，而且永远不会是目的

[macemers]

@ichigo 能不能透露一下转去做什么业务了呢？

[ichigo]

@macemers 一开始转到风控，后来做了两年研究员，现在在自营。

[macemers]

@ichigo 哇这个转型还是相当成功的我感觉。能不能透露一下行研或者自营，收入上来讲是不是远超码农？

[ichigo]

@macemers 谈不上远超，研究员月薪也就 15K 而已， V2 上大多数程序员都是大于这个数的。年终奖会多点，不过年头不好也就 100K 左右吧，赶不上创业公司。今年刚进自营，刚开始操作大资金，工作量会比行研轻点，压力大点，钱也多点，别的也没什么。

[miemiekurisu]

@paulagent 老大们的思路一般都是这样的: HP 的方案 500w ， 18 摸的方案 1000w ，肯定选贵的。万一出了事，如果用 HP 方案会被质疑当初为啥不买 18 摸，然后自己背锅，但是用了 18 摸就不一样了，已经是市面上最贵的商业解决方案了， 18 摸都出事，便宜的方案更会出事，这事就只能 10 摸去解决了，不用背锅了

[paulagent]

@miemiekurisu 这就是问题，你能证明用便宜的方案不会出事吗？ 出了事怎么办？

[xuqd]

在银行快两年了，无意中看到这个帖子，感慨啊

[bitdepth]

請問 DBA 方面和框架設計有什麼好的書推薦嗎？

[epson3333]

@ichigo 老哥,我可以加你的联系方式,问一些转行金融的问题吗,我的邮箱是 [e-mail],谢谢