首先回顾《选型篇》的内容，虽然大公司的做法是，打点以日志落盘，再通过日志收集器转送到HADOOP，进行离线数据计算与分析。那么这条线路的技术栈实在太多，就好像一台电脑，我们要DIY的东西很多。那么这套东西的核心在哪里呢，两点：解耦 与 离线。
那我们针对这两点进行分析，通过打日志的方式，让系统异步落盘，可以做到完美与业务系统及数据库解耦，那说道解耦，（最好的是“无埋点”方案，但这种方案会产生大量的无效数据，并占用大量磁盘空间，并不划算，因此我们抛弃无埋点。）我们可以采用前端异步化落盘的方式。那么就说道离线就要说到OTLP，以前我们最常用的OTLP就是hadoop了，特点是运算量大、扩展性好，虽然现有很多storm、spark都在侵占hadoop的市场，但在海量数据计算上，hadoop还是保留着其自己的海量复杂计算的优势。那么，对于埋点的运算，真的需要那么复杂的计算吗？其实并不需要，起码我们现有的业务上，对埋点数据没有复杂到那个程度，只是一些简单的 sum count groupby等操作。那么有还有必要选择hadoop来做OTLP吗？这里我就要提一个当初提过的技术，new sql。
网上阐述new sql的文章数不胜数，并且也成为目前争论的核心，我们抛开这些争论，只观察其是否适合与我们。我们看看new sql的特点：
1、支持水平扩容。
2、少量数据下的表现不比mysql差，而随着数据量达到亿级以上，性能秒杀mysql单标。这里，我做了个测试，在某张表3个亿的数据的前提下，mysql需要36秒跑的一个sql，hybrid for mysql（new sql的一种，阿里云提供）只需要1.3秒即可。性能方面，每个分区在3000-20000的qps也同样相当优秀。
3、分布式事务，目前hybrid只支持到分区（distributedId分区KEY）内的事务，暂不支持跨区事务
在这里我不再去赘述new sql的产品之一Hybrid for mysql的价值了，请参考上一篇文章。那么满足这三点，几乎可以确认，他完全适合我们的打点系统，甚至，我曾经有想过，是否可以用它来做我们的业务库呢？我没有去实验，因为在更适合业务库的分布式系统oceanbase摆在那里，在可用性上，专家给我的回复是，oceanbase更高，而对海量数据的支持，则是 Hybrid 更好。
缺点是他的成本比较高，必须用512G以上的SSD，8核16G的内存，来满足聚合运算带来的开销。
目前我们的库已经数十亿的数据，在性能和稳定性上都有良好的表现。写了一点，又要去忙了，下次我会给大家讲讲，如何建表以及业务中带来的价值。
