引言我们在谈到开源与闭源的时候，通常指的是一个软件本身，其源代码是否开放，但是在特定的软件中（如数据分析类软件），还有另一个问题，就是其是否采用开源的语言来编写应用这就带来多种情况，开源软件开源语言，闭源软件闭源语言，等等。
我们举其中两个最典型的例子来对比，那就是开源软件开源语言：Python，以及闭源软件闭源语言 SAS。
SAS Python R 对比[1]为什么大型金融机构用 SAS 居多？而互联网公司更倾向于 Python？1. 历史遗留问题Python 虽然早在1991年就诞生了，但是真正流行起来，并且用于商业应用的生产环境，也就是在近5年时间。
在此之前，金融机构的历史代码，特别是大型金融机构，很多还是用SAS写成的。为什么不要把老的 SAS 代码用 Python 重构呢？经验老到的开发会告诉你，如果你的代码跑得很好，千万不要重构它。
2. 人才梯队问题会SAS语言的人才比 Python 少得多，因为 SAS 相对来说，应用场景只在数据分析领域（因此也要求具备一定的数学、统计学基础），而 Python 的应用场景则更广，也没有对于数学等基础学科知识的要求。
下图虽然有些历史了（2016年发布的文章），但是鉴于美国的整体行业技术栈相较国内也领先几年，并且在同一时间维度横向比较各行业的偏好也是可以作为参考的：
不同行业对于 SAS R Python 的选择倾向[2]也就是说，极速扩张中的互联网公司不太可能把自己限制在这么小的人才范围上3. 稳定性与精度要求问题从应用场景上看，金融机构一般用于风控过程中的信用评估，或者投资决策、量化模型等，一旦出错，会造成直接且数额相当的损失；。
互联网机构，由于牌照的原因，绝大多数应用场景在于智能推荐以及产品运营，而这些是锦上添花的，出现错误并没有那么致命因此，对于运行稳定性和计算精度的要求，金融机构会高很多Python 底层代码包还有很多问题，比如 pandas，目前还有3k+ open issues：。
运气不好碰上一个，只能等开源社区响应了，这肯定比不上商业机构的7X24小时支持如果是报错或者导致了很明显的问题，其实倒还好，易于发现，马上修复排查即可最可怕的，是哪种最终数值上差了一点点，但是完全看不出错误的问题，甚至，开源的包里，不能排除被植入恶意代码的可能。
虽然遇上未解决的 bug 或者被植入恶意代码的概率很小，但是金融机构天生就是风险厌恶的，容错率很低，通常会选择更加安全的方案4. 信用背书问题商业化运营的公司，信用背书总是强于开源社区的，而强监管的金融行业，尤其需要信用背书。
拿上面提到的稳定性与精度要求问题来说，如果真的出现了此类问题，造成了损失，甚至引起了监管的注意，那么，用开源软件的机构，只能自己承担责任5. 成本问题听起来使用 SAS 的好处更多，可以保证运行的稳定性以及结果的精度，同时还可以提供信用背书，当然，这些都是有成本的，最后就体现在 SAS 的价格上。
License 按年续费，每年的维保还需要单独采购，这是一块不小的成本，并且，一旦采购，就会形成历史代码，就会产生持续的续费，中小金融机构很难下决心，而互联网公司，更希望用这些钱去烧一些用户量和月活回来，获取更多的融资。
Python 的成本更多是隐形的，比如线上出了问题造成的潜在损失等等，不过，随着研发队伍的不断成长，这个概率会越来越低难道没有折中方案吗？1. 金融机构自身的折中方案为了解决以上问题，金融机构通常会在建模过程用 Python，生产环境转写为 SAS，同时利用一些脚本和工具，将 Python 脚本转成 SAS 语言。
这样，既可以用得上会 Python 的人，解决人才梯度的问题，又可以解决稳定性和精度要求以及信用背书的问题不过，这个方案依然没有解决较高成本投入问题，SAS 的 license 和维保每年要买，甚至，还要养两套人马，懂 Python 的自不用说，还需要少量懂 SAS 的人来维护这套 Python 转 SAS 的工具，毕竟，任何一边升级了都可能导致脚本出错，转换环节越多，出错概率越大。
2. SAS 的折中方案SAS Viya 已经开始支持开源语言了，可以更好的解决人才梯队问题找不到会 SAS 的人？没关系，会 Python 也行，同时还可以由SAS提供环境的稳定性，以及完善的售后运营机制提供支持。
但同样，作为一款数据分析工具，SAS 的使用成本较高的问题依然存在3. 最关键的成本问题和历史遗留问题如何解决？生产上用 SAS 确实可以确保稳定性和精度，以及提供信用背书，并且，基于以上两个方案，人才梯队问题也可缓解。
那么，较高的成本问题和上面所提到的历史遗留问题如何解决呢？ 如果有一个成本比较合适的商业化软件，可以支持 SAS 代码，是否就可以解决历史遗留问题？还真有，笔者最近使用了一款叫做 WPS（此 WPS 非彼 WPS）的软件可以支持 SAS 语言，也支持开源语言 Python。
这其实就可以解决历史遗留问题，假设某家机构，有很多历史代码是用 SAS 写的，但是由于某些原因，不想续费了（可能是因为真的很贵），但是又不想把这些历史代码用 Python 重构（毕竟风险真的很高，万一出岔子谁来承担责任），那就可以用 WPS 来管理历史代码，万一需要微调，也可以直接在上面实现，风险可控。
WPS 最近被另一家软件公司 Altair 收购了，这个公司应该也是看到了这个场景的价值，既能保证使用 SAS 语言构建的历史模型平稳运行，又可以更高效地帮助公司向开源+闭源混合语言体系结构过渡，且能以更低的成本，保留和利用闭源软件+闭源语言的最大优势。
参考资料[1] r-vs-python-vs-sas: https://medium.com/@akeriasolutions/r-vs-python-vs-sas-8224d2a426ae[2] SAS R Python analytics pros prefer:
https://www.kdnuggets.com/2016/07/burtchworks-sas-r-python-analytics-pros-prefer.html
亲爱的读者们，感谢您花时间阅读本文。如果您对本文有任何疑问或建议，请随时联系我。我非常乐意与您交流。
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。