随着大数据技术的成熟，涌现了非常多的成熟框架和技术，在大数据存储查询引擎方面也有非常多的优秀产品。为什么出现这么多的优秀产品，为什么不是一款功能非常全面的产品，一劳永逸地解决所有问题呢？下面来看看结合实际的应用情况的分析结论。

1、从需求说起

SAAS软件模式+微服务的架构，最终导致数据分散在每一个DB中，每个DB对应1个或多个领域，数据分散带来的问题就是无法跨领域去进行分析和统计；由于团队独立，产品规划也可能没有整体考虑业务规划，最终结果是业务不通、数据不通，客户无法看到数据，特别是实时看到数据就更困难了。

基于上述的架构，需求有哪些呢，常见的有以下几类：

1）数据洞察分析：一般借助于可视化报表工具，比如帆软、PowerBI，基于清洗好的数仓数据，进行拖拉拽的报表报告设计，满足定制化报表分析及洞察分析的要求。有2个基本要求，1个是数据要清洗准备到位，1个是报告报表的自助化、定制化，而2者的结合点就是如何快速高效的将数仓里面的数据获取出来，即使拖拉拽生成的SQL语句复杂、性能差、条件随意、关联表多，客户需求必须满足。

2）数据导出：同数据洞察分析类似，客户希望将查询报表中的明细数据，导出到本地或已有报表分析系统中，进一步分析或与已有数据进行融合分析，就需要将报表中生成的数据导出Excel，其逻辑与报表的逻辑一样，一样是SQL语句复杂、性能差、条件随意、关联表多。

3）提供营销自动化数据支撑：为业务赋能，基本CDP提供客户圈选，提供数据服务的支持能力，实现层面依然是拖拉拽。

基于拖拉拽的操作模式，以及无法提前清晰知道SQL语法，提供什么样的DB引擎非常重要。

2、救星OLAP

业务系统一般用OLTP事务型数据库，能保证业务逻辑的完整，并且有非常好的优势支撑高并发，长期以来都是业务系统DB的首选。早期的数仓，在数据量不是特别大的情况下，也是用OLTP进行数仓处理的。

随着业务数据量的增大，数仓使用OLTP作为计算过程已经基本退出了历史舞台，取而代之的是大数据的计算存储组件，数仓存储也会根据不同的使用场景要求，采取不同的存储引擎以满足客户的要求。

对于大数据量查询且时效性高的场景来说，OLAP是目前的首选，比如ADB、Kylin、DWS、ClickHouse、Doris等，当然为了进一步提升查询性能和并发度，引入缓存级的数据存储Redis等也是非常好的一种方式，但缓存级的DB只能满足数据量不太大的场景。

对于这些OLAP，ADB非常好的支撑起定制SQL的查询，无需增加任何索引，可以利用潜在机制及MPP的架构，满足查询要求；Kylin有着非常好的预计算机制，通过高效的汇总层、主题层，降低对于资源的使用，提升查询性能；ClickHouse有着非常好的单表查询性能，但是关联查询无法达到实践级的要求。总的来说，没有一款产品能满足所有要求，银弹确实很难找。

所要做的就是根据不同的业务使用场景，寻找合适的OLAP引擎，并通过适当的缓存级DB提升不断增长的需求。

3、新的业务高并发问题，OLTP？

基于上述的洞察分析场景，OLAP基本是可以满足要求的，确实比较解决了定制化制作报告的问题，收到了良好的反馈。

随着业务的深入应用，业务也需要用到数仓（特别是实时数仓）的数据，用于业务之间的逻辑处理。通过数据服务开放API是可以满足相应的要求的，但是核心问题是业务应用的高并发，ToB的业务还好，ToC的业务量对于OLAP的数据库来说，高并发无法满足相应要求。只要高并发的新功能上线，DB宕机的概率非常大，这是非常大的挑战。

如何应对？有几个思路：

1）增加OLAP的硬件资源，硬抗。

2）在第1种的情况下，进行分库分表的思路，所有SAAS在一个库中相互影响太大，可以分几个或多个，比如分级数据中心，极限是私有化；

3）引入OLTP数据库（同样支持分布式），以提升高并发的支撑度，满足实际客户的需求。相当于2种场景，2类存储，2份数据，也会带来数据不一致的问题，最终造成数据准确性方面的问题。

尝试的过程中，确实可以收获很多的惊喜，确实是可以解决相应场景的问题的，继续探索，继续突破。

总结下，不管是满足一线、客户的定制化需求使用OLAP满足快速高效的查询需求，还是满足业务应用之间逻辑处理的场景需求，都没有一款DB产品可以解决单个场景的所有问题，都是具体问题具体分析，针对性解决。当然，2类不同场景更是这个道理了。我们希望找到银弹，但这个证明好像不太现实，唯有继续努力！