在入职后的几个月内，怎么也没有想到，在业务需求的逼迫下，技术转型如此之快。
No.1
2016年4月入职后，拿到一个简单的业务需求：从A厂商提供的HTTP数据接口获取到实时数据，并对其进行持久化。
在看到这个需求后，想到沉重的java而感到心累，这是否是java攻城狮的疲劳综合症。
事实上在我入职之前，技术团队内一名稚嫩的DBA拿着一本Node.js教程，996一周时间勉强编写了一个服务端用来接收此接口，留下了一个连接数日均过万的生产灾难。然后我端起这本书，花了3天时间改进并搭建了一个用了前端数据分析用的web展示平台。
至此，一个极端简陋还算实用的数据中心完成了...
初代数据平台（如果勉强称得上的话...）
我要羞耻说明的是，当第三方需要从这个平台拿取数据的时候，我们的方案当时只有：1、直接下放到磁盘文件自行取走。2、开一个vip级别的MongoDB账号，请尽管拿走数据。
No.2
在以上的日子里，刚刚沉浸在“大功告成”的小确幸中，我们迎来了业务需求的地震：现在数据源不止A厂商提供了，B、C甚至D厂商也蜂拥而至。在暗中祈祷的加持下，果然，BCD厂商的数据源接入形式几乎完全不同，此刻我决定重新拿起java，编写一套数据接入程序。
Node.js作为以轻量级应用为目的的代价，此刻成为了数据孤岛。
花了一个月时间，为每个数据源编写好代码，最终上线，然而此刻的数据量从之前单一数据源的日均几十万级别，增长到日均千万的量级。所有的数据存储在MongoDB中，再也不是一个聚合函数十秒轻轻松松出数据的量级了。
此刻团队中的DBA（是的你没有看错，团队只有两个人，我和DBA...）提来了一个方案，何不把mongo中的数据，每天午夜导入到PostgreSQL中，听说pgsql可以轻松处理千万级数据，又是关系型数据库，好处理的很。这个方案如今看来多么可怕...当时却莫名地鼓起了干劲...
可怕的二代数据平台
上面这个二代大改之后数据平台，放大了初代的缺点，并没有解决将来可能出现的E、F、G等厂商数据接入的问题，唯一值得欣慰的是，它暂时解决了当时的问题，只是这个暂时，很快就被打破了...
No.3
2016年10月以后，在第三方数据合作与接踵而来的E、F、G等厂商数据接入的业务需求形势下，在数据量逼近日均过亿的严峻形势下，痛定思痛，决定完全抛弃之前的数据平台，搭建一整套大数据数据处理平台。
在参阅了业界为数不多的大数据平台方案之后，我决定将此架构设计为：
三代数据架构DEMO
依旧很丑陋，但是对于当时的技术储备来说，已经可以证明是可行的解决方案。之后的一个月，虚拟机搭建了如上图的实验局，踩过N个坑之后，艰难的迁移了一小块业务，终于跑通。于是我们将所有的业务，迁移到了正式的生产环境。基于flume友好的二次开发特性，使得数据接入可以无惧多种形式变化，基于kafka强大的性能与消息队列特性，使得亿级数据量可灵活对外开放，稳定接入并持久化。不过真的是万里长征第一步，这个架构，要丰富的还有太多...
2017年初，为了让自己全身心投入大数据架构的设计开发，招来两个帮手，彻底交接了web方面的业务（是的你没看错，整个技术团队终于超过2个人了...）。在两个月左右的业务驱动下，整体架构完善了很多地方。
三代数据架构
该平台日均pv量级为2亿左右，在数据分析可视化的需求影响下，尝试应用了Presto和Kylin开源数据引擎，效果可喜。
写在最后
虽然过去的一年里面临着人员紧张、诸事繁多的种种困扰，但确实得到了一个相对自由的发挥空间，从而建立了一套紧贴合业务需求的大数据平台，希望此文能给同样面对相关业务需求而头痛的同志们一点帮助。
——2017.05.31 写于深夜
网友评论