Osheep

时光不回头,当下最重要。

数据架构设计浅谈

在入职后的几个月内,怎么也没有想到,在业务需求的逼迫下,技术转型如此之快。

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 写于深夜

点赞