上文提到我们对内部统一由third库来支持，时间久了之后，出现了越来越多的需求，我们通过目前的运营后台的开发已经无法快速的满足了。比如，运营做了一个活动，想快速的看数据；这个时候，你说我再给你开发一个数据报表那是一件很蠢的事儿，那时候技术一共也就十多人，如果把需求都花在这些碎片需求上，而不是打造核心用户价值上，那公司的节奏一定会慢很多。因此，我们做了个决定，我们将third库的读库权限交给产品运营，如果他们要看数据的话，我们来给他们写sql，并教他们来维护。
随着业务的快速发展，sql开始变得越来越复杂（早期的时候，我们都是把生产库的读库权限开放给运营、产品，让他们自己在上面跑sql看数据），有时候读库执行一个sql会导致数据库cpu出现了飙升，所幸我们没有将运营使用的读库给线上做读写分离，只是单纯给运营使用，所以对线上几乎没有什么影响。
伴随业务的快速发现，third库出现了以下几个问题。
- join查询：运营对关联查询的诉求越来越多，例如，运营在岗位信息的页面里，需要看到所有岗位的信息，包括岗位的浏览量等统计，这就需要我们在一个接口里，多次调用sql查询。
PS：这里你可能会提问，后台的系统里，简单用一下join就搞定了，没必要在后台还要遵循不能级联查询的规范吧；实际上凡是平台的业务，我们都不希望放开这个口子，因为你一旦放开了一个口子，并且没有一个特别明确的标准的话，是一件特别危险的事儿；千里之堤毁于蚁穴，这个隐患可能会越来越大，导致你的系统被慢sql占满；这个时候，你再去说，哪些是后台的sql、哪些是前台的sql，你确定能分得清？ - 模糊搜索：运营后台开始有一些模糊搜索的需求了，比如，模糊搜索岗位关键字。这类的需求明显用mysql来做是不大合适的，最左前缀不适合模糊搜索这个场景。
- 性能问题：因为third库依赖所有业务库的DTS的传输，因此，它必须具备很好的写的能力；我们知道mysql对于写的能力的扩展是很挫（别提分库分表，创业早期...），所以，我们对于third库的写的的能力提升的主要手段就是升级配置，最后我们已经把配置升级到了32核64G的水平了。虽然能满足平时业务的写的速度，但有一个情况会出现严重的问题，就是ddl；当一个大表做DDL的时候，会直接third阻塞住，导致DTS被打满同样阻塞住，third库出现了大量延时，最多的时候能阻塞近24小时，这是业务锁不能接受的。
为了解决这个问题，我们开始首次引入了hadoop来解决，当时团队里没有人会这块的东西，赶鸭子上架，我们一边学习，一边建设数仓。
以上就是我们引入了数仓后，通过数仓来解决上述的三个问题；这里数仓怎么建设的我就不赘述了，传统的四层结构，依赖于阿里云的maxcompute的引擎来解决这类问题。
在建设业务逻辑的同时，我们要开始做我们的埋点方案了，埋点方案我会写个专题文章来介绍从埋点1.0~4.0的整体架构思路，就不放在整体架构中做介绍了，这里我把埋点的图也一并贴出来。
以上，就是一直支撑我们到B轮完成的架构体系，可以说这个架构体系并没有什么太两点的地方，介绍这些架构的过程，更多的是陈述了一个企业发展过程中，技术的一个演变的过程；但并不是所有的企业都会走同样的路，例如，有些企业一开始就要走高大上的路线，第一年就要招满百人团队，那这套体系对他们来说，并不合适；这块我会在后续讲，当技术基本满足了业务需求的情况下，后续是如何演变的。
