首先简单介绍一下项目背景，公司对合作商家提供一个付费级产品，这个商业产品背后涉及到数百人的研发团队协作开发，包括各种业务系统来提供很多强大的业务功能，同时在整个平台中包含了一个至关重要的核心数据产品，这个数据产品的定位是全方位支持用户的业务经营和快速决策。
这篇文章就聊聊这个数据产品背后对应的一套大型商家数据平台，看看这个平台在分布式、高并发、高可用、高性能、海量数据等技术挑战下的架构演进历程。
因为整套系统规模过于庞大，涉及研发人员很多，持续时间很长，文章难以表述出其中各种详细的技术细节以及方案，因此本文主要从整体架构演进的角度来阐述。
至于选择这个商家数据平台项目来聊架构演进过程，是因为这个平台基本跟业务耦合度较低，不像我们负责过的C端类的电商平台以及其他业务类平台有那么重的业务在里面，文章可以专注阐述技术架构的演进，不需要牵扯太多的业务细节。
此外，这个平台项目在笔者带的团队负责过的众多项目中，相对算比较简单的，但是前后又涉及到各种架构的演进过程，因此很适合通过文字的形式来展现出来。
下面几点，是这个数据产品最核心的业务流程：
基本上用户在业务系统使用过程中，只要数据一有变动，立马就反馈到各种数据报表中，用户立马就可以看到数据报表中的各种变化，进而快速的指导自己的决策和管理。
整个过程，大家看看下面的图就明白了。
看着上面那张图好像非常的简单，是不是？
看整个过程，似乎数据平台只要想个办法把业务系统的数据采集过来，接着放在MySQL的各种表里，直接咔嚓一下运行100多个几百行的大SQL，然后SQL运行结果再写到另外一些MySQL的表里作为报表数据，接着用户直接点击报表页面查询MySQL里的报表数据，就可以了！
其实任何一个系统从0到1的过程，都是比较low的，刚开始为了快速开发出来这个数据平台，还真的就是用了这种架构来开发，大家看下面的图。
其实在刚开始业务量很小，请求量很小，数据量很小的时候，上面那种架构也没啥问题，还挺简单的。
我们直接基于自己研发的数据库binlog采集中间件（这个是另外一套复杂系统了，不在本文讨论的范围里，以后有机会可以聊聊），感知各个业务系统的数据库中的数据变更，毫秒级同步到数据平台自己的MySQL库里；
接着数据平台里做一些定时调度任务，每隔几秒钟就运行上百个复杂大SQL，计算各种报表的数据并将结果存储到MySQL库中；
最后用户只要对报表刷新一下，立马就可以从MySQL库里查到最新的报表数据。
基本上在无任何技术挑战的前提下，这套简易架构运行的会很顺畅，效果很好。然而，事情往往不是我们想的那么简单的，因为大家都知道国内那些互联网巨头公司最大的优势和资源之一，就是有丰富以及海量的C端用户以及B端的合作商家。
对C端用户&#x
