最近跟朋友交流，公司正在为大数据技术选型烦恼，主要是不同的团队基于不同的诉求，要求结果不一样。比如说有从稳定性考虑，有从维护性考虑，有从使用便利性考虑，也有从成本考虑，还有从团队能力模型考虑的。

不管哪种维度，理由说起来都对，然后决策时，大佬们的出发点如果不一样，就会陷入僵局。对应目前的公司，其实大同小异、问题如出一辙。

我们先看看基础大数据平台选型时，针对以上几个维度的考虑逻辑及相关影响。

首先是稳定性：这是基础大数据平台的根，没有稳定性，则地基不稳，最终就会成为水中月、镜中花，业务团队一用事故一大堆。这也是最有核心价值的地方，评价一个团队是否具备很强的技术能力，就是在技术框架、工程平台、部署运维中不断提升的SLA，在满足业务需求后稳定性越高，则具备更高更实用的技术能力。先进与否，前沿与否只是技术领先性的指标，是在稳定性之上考虑其他维度，稳定性才是技术深度强度的可靠证明。

其次是开放性：目前基础大数据平台构建有几种方式，一种基于大厂构建大数据技术架构平台进行数据开发，属于使用者模式；另外一种是基于开源自建大数据技术架构平台进行数据开发，属于掌握者模式。如果是小公司，定位为使用者的角色，快速利用大厂的商业大数据平台（含基础架构、工程平台、运维监控等）构建大数据处理中心是比较好的方式。如果是有非常大体量的数据处理，有非常多的个性化需求，是一个有技术追求的团队，有着自己的大数据平台理想，就不要依赖于大厂，建立自己的研发团队，构建自己的大数据平台，在满足需求上将会得到比较好的收益，包括技术积累、人才提升、定制需求满足等等。

开放性，对于使用者模式来说基本上不会有什么架构上的扩展，主要是针对基于开源的掌控者模式来说的。即做大数据是满足业务诉求的，业务诉求会有很多的定制需求，通用开源的版本不一定能满足，所以要做一些定制开发，比如SaaS的多租户体系的处理机制，一般的通过大数据都不支持，在应用处理时，一定要定制开发才行，否则处理时效、处理性能都无法满足客户要求，如果选择使用者模式，基本就是个不可用的系统或者会有非常多的限制。因此开放性是在选型大数据技术平台的核心要求，一定要很好的满足。

再次是团队：一般小公司，投入有限，很难有专业大数据团队，所以选择大厂平台是最合适的。但对于大公司来说，实际上是有资源的，只不过资源可能在不同的团队中。比如一般情况都会有专门做大数据的平台部门，与业务无关属于基础支撑技术团队，也有和业务团队一起生长的大数据架构部门，结合业务慢慢生长，从基础平台到工程开发平台到质量监控到运维比较体系化。大家都在做平台的构建，重复的建设带来的是资源的浪费和平台版本的混乱，数据处理依然是孤岛，融合非常困难，历史版本债务非常严重，成本效益非常低下。但不管是哪种团队模式，对于团队本质上来说是要具备相应的技术能力，要具备专业的人才。当然基于开源的模式对于人才的需求会更大，要求也会更高，需要具备专业的大数据架构能力。反过来说，如果团队能力不够，那就老老实实用大厂的大数据基础和开发平台，省时省力还能省折腾的钱。

最后是成本：包括产品成本、人力成本、运维成本等等。产品成本直接了解商品定价就好，如果开源自建，则转化为硬件成本，是固定的。当然商业的定价模式会有2种，按量付费和固定包月模式，一般情况下按量付费会高出一个30%左右，同时资源利用率方面无法削峰填谷，利用率无法发挥到极致。当然，如果自建，虽然可以离线实时交替，但难度非常大，实际操作的可能性及成功安例不是太多，因为相比稳定性，成本还是占在次要的位置。其次是人力成本，前几年大数据人才的费用还是非常高的，最近整体环境回归趋于理性，会好一些，但相对来说还是贵的。最后是运维成本，这个其实涉及到产品的应用形态，如果只是SaaS公有云，则是可控的，如果私有化部署的场景非常多，则运维成本会非常大，也可能在选型时起到决定性的作用。

大数据技术架构选型除上上面的4个维度之外，其实还有一些，比如业务场景、公司发展阶段、当前技术储备、易用性等等，但本质上还是定位，核心就是产品、团队的定位，比如说你是想做一个使用者还是要当一个掌握者，确定后基本就决定了大的方向。做为有追求的技术人，倾向于后者。