随着云原生、微服务逐渐在各个行业落地，分布式链路追踪（Trace）也开始被越来越多的公司采用。对于Trace而言，最基础的能力是能够记录请求在多个服务之间调用的传播、依赖关系并进行可视化。
上下游分析：基于计算的Dependency信息，按照某个Service进行聚合，统一Service依赖的上下游的指标
可观测性的前期阶段，很多工作都是需要人工来完成，我们最希望的还是能有一套自动化的系统，在出现问题的时候能够基于这些观测的数据自动进行异常的诊断、得到一个可靠的根因并能够根据诊断的根因进行自动的Fix。现阶段，自动异常恢复很难做到，但根因的定位通过一定的算法和编排手段还是可以实施的。
专用分析型数据库产品选项众多，一个可选方案是使用两套系统来分别满足的OLTP和OLAP型需求，在两套系统中间通过数据同步工具等进行数据的实时同步。更进一步，用户甚至可以增加一层proxy，自动将TP型负载路由到MySQL上，而将分析型负载路由到OLAP数据库上，对应用层屏蔽底层数据库的部署拓扑。
这样的架构有其灵活之处，例如对于TP数据库和AP数据库都可以各自选择最好的方案，而且实现了TP/AP负载的完全隔离。但是其缺点也是显而易见的。
三家领先的商用数据库厂商，均同时采用了行列混合存储结合内存计算的技术路线，这是有其底层技术逻辑的：列式存储由于有更好的IO效率(压缩,DataSkipping,列裁剪)以及CPU计算效率(Cache Friendly), 因此要达到最极致的分析性能必须使用列式存储，
如此行列混合存储成为一个必选方案。但在行列混合存储架构中，行存索引和列存索引在处理随机更新时存在性能鸿沟, 必须借助DRAM的低读写延时来弥补列式存储更新效率低的问题。因此在低延时在线事务处理和高性能实时数据分析两大前提下，行列混合存储结合内存计算是唯一方案。
MySQL的架构在AP场景的缺陷
MySQL的实现架构在执行复杂查询时性能差有多个方面的原因，对比专用的OLAP系统，其性能瓶颈体现多个方面：
MySQL最常用的存储引擎都是按行存储，在按列进行海量数据分析时，按行从磁盘读取数据存在非常大的IO带宽浪费。其次行式存储格式在处理大量数据时大量拷贝不必要的列数据，对内存读写效率也存在冲击。
我们需要引入列式存储：
在分析场景经常需要访问某个列的大量记录，而列存按列拆分存储的方式会避免读取不需要的列。其次列存由于把相同属性的列连续保存，其压缩效率也远超行存，通常可以达到10倍以上。
