通信数据分析平台（二）

前言

上期文章中开了个头，描述了平台的初代架构。作为研发人员，能够经历从无到有的开发过程，同时看到平台的上线，给用户的数据分析工作带来了一定的效率提升，真实的感受到了价值感和成就感。

然而随着业务方面的新需求不断的提出，平台需要接入的数据源类型不断增加，需要分析的网络规模不断扩大。经过对数据量的评估，发现现有的单库结构已经很难需求，于是，我们对数据库模块进行一次架构升级。

平台2016

首先给出16年设计的平台架构图：

参考了一些架构设计的概念，我觉得将平台架构按照分层理念来呈现，会更加的清晰。从底到上分为四层，依次为数据采集层，数据处理层，数据存储层和业务层。每层基本的功能在上期已经介绍过，这里就不再赘述。

这次的架构升级的外在驱动力就是数据量的暴增，评估了单次批处理任务生成的数据记录达到15亿条。这么巨大的数据量会导致load速度变得非常慢，而且后期的算法根本无法顺利执行。

遇到这样的瓶颈，其实是所有使用单机单库模式数据库的通病。而单机单库数据库的瓶颈，不必多说，就是在硬盘读写，这是无法改变的现实。

垂直扩展没有意思的话，何不做水平扩展，实现分库分表，尝试突破这个瓶颈。此时，mycat进入视线，一个开源的能实现分库分表的数据库中间件。

引入了mycat之后，经过一段时间的磨合，load和算法的处理速度得到了巨大的提升，基本验证了这个方向是没错的。

平台具备了处理大数据的能力之后，业务层面的算法就井喷式的涌现出来了。经过一段时间的开发，给用户推出了更多的分析功能。

经历了这次的架构升级，我的心得是业务需求和平台架构应该是相辅相成的。如果不是业务的需求，就不会有升级架构的驱动力，过多的设计其实是一种浪费，而且团队资源也是有限的。