1. 前言
如果你在业务中常常被报表，大数据量查询，慢SQL困扰，那么你就也可考虑使用OLAP数据库来解决这些困扰，本篇文章我们就来一起探究一下OLAP数据库的选型。
首先我们会从数据库的分类入手，让大家了解什么是OLAP，然后我们再去详细介绍一下OLAP的使用场景和一些主流的OLAP数据库产品，对比其优劣，给大家的选型做参考。
2. 数据库分类
数据库可以分为OLTP、OLAP和HTAP三种，他们分别针对不同的数据处理场景和需求。
2.1. OLTP
OLTP（联机事务处理）数据库是专门针对事务处理工作的，也是我们最常用到的数据库例如MySQL、Oracle。
OLTP数据库的主要特点是高并发、低延迟和高事务吞吐量。它们通过支持ACID（原子性、一致性、隔离性和持久性）特性来确保数据的一致性和可靠性。
OLTP数据库通常基于行存储，通过B树、B+树、哈希表构建索引。
2.2. OLAP
OLAP（联机分析处理）数据库是专注于决策支持和分析的，我们工作中可能会接触到，也可能接触不到，一般在大数据领域会比较常见，常常被用于处理大量数据的复杂分析和报表生成。常见的OLAP数据库有StarRocks、Apache Doris、ClickHouse、Apache Kylin、Hive等等。
OLAP数据库通常采用了针对分析查询优化的特殊数据结构，如多维数据模型（如星型或雪花模型）和列存储技术。此外，OLAP数据库还提供了灵活的查询语言和数据切片、切块、钻取等功能，以支持交互式的数据分析和探索。
在企业中，通常需要将OLAP与OLTP结合起来使用。
2.3. HTAP
HTAP（混合事务/分析处理）数据库，随着时代的发展，需求的转变，人们就在考虑是否能将OLTP和OLAP数据库的优点结合起来，以同时满足事务和分析的需求。HTAP的主要代表有OceanBase、TiDB、CockroachDB等。
HTAP数据库通常采用了内存计算、分布式架构和智能查询优化等技术，以保证高性能和灵活性。
3. OLAP数据库
3.1. 为什么选OLAP数据库
一般项目选OLAP数据库是因为报表数据查询困难，耗时长，慢SQL影响业务数据库的性能，或者有大量数据分析需求。
3.2. OLAP数据库产品介绍
随着互联网，大数据的不断发展，OLAP数据库迎来的大的发展，产品也是层出不穷。
常见的OLAP数据库有StarRocks、Apache Doris、ClickHouse、Apache Kylin、Presto、Druid
- StarRocks：是开源的新一代快速全场景MPP（Massive Parallel Processing，大规模并行处理Data Warehouse）数据库。它采用新一代的弹性MPP架构，可以高效支持大数据量级的多维分析、实时分析、高并发分析等多种数据分析场景。
- Apache Doris：是一个易用、高效、稳定的开源MPP数据仓库系统，支持近实时的多维数据分析和OLAP类型的查询。
- ClickHouse：是一个用于在线分析处理的开源列式数据库管理系统，能够使用SQL查询实时生成分析数据报告。
- Apache Kylin：是一款开源的分布式分析引擎，提供了对多维数据分析的支持，并且特别适用于大数据环境。
- Presto：是 Facebook 推出的一个开源的分布式SQL查询引擎，数据规模可以支持GB到PB级，主要应用于处理秒级查询的场景。
- Druid：是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。
3.3. 主流OLAP数据库产品优劣点
3.3.1. StarRocks
优势：
- 新一代极速全场景MPP数据库，支持多种数据分析场景的极速分析；
- 架构简洁，采用了全面向量化引擎，并配备全新设计的 CBO 优化器，查询速度（尤其是多表关联查询） ；
- 很好地支持实时数据分析，对实时更新数据的高效查询， 还支持现代化物化视图，以进一步加速查询；
- 用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型；
- 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理；
- 支持无缝的水平扩展，可以轻松处理大规模数据库；
- 可以直接查询Hive、HDFS、Kafka等多种数据源；
- 提供了很多企业级特性，包括安全性、监控和管理工具；
劣势：
- 相对较新，社区和生态可能不如其他成熟（感觉活跃度还是挺高的）；
- 资源消耗比较高，需要更多的计算资源和内存；
3.3.2. Apache Doris
优势：
- 为OLAP场景优化，提供快速的数据分析能力
- 支持实时数据导入和低延迟查询
- 简化数据建模过程，用户可快速上手
- 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理；
劣势：
- 虽然社区正在增长，但是想必其他更成熟的项目，还是不够强大；
- 为了支持高性能，资源消耗比较大；
3.3.3. ClickHouse
优势：
- 基于列式存储，优化了大量数据的读取速度，特别适合分析和聚合大数据集；
- 列式存储允许高效的数据压缩，减少存储成本；
- 支持近乎实时的数据插入和查询，使得最新数据可以迅速被分析；
- 通过添加更多节点来轻松扩展系统，适合处理PB级别的大数据量；
- 充分利用现代CPU的多核架构和向量指令，提升查询效率。
- 支持SQL查询，使得从其他数据库系统迁移过来的用户可以很容易上手；
劣势：
- 多表关联查询性能差；
- 数据生效存在延迟，写入数据需要进行异步的数据合并，无法确保立即可见；
3.3.4. Apache kylin
优势：
- 通过预计算大量的聚合，在查询时提供非常快的响应；
- 支持大数据集；
- 可以与Hadoop、Hive等组件无缝集成；
劣势：
- 预计算时间长，特别是对于非常大的数据集；
- 资源消耗大，预计算和存储需要大量的资源；
3.3.5. Presto
优势：
- 联合查询，可以跨多种数据源执行查询，如Hive、Kafka、关系型数据库；
- 分析和查询进行优化，提供良好的性能；
- 基于分布式架构，易于扩展；
劣势：
- 由于基于内存的处理，对内存需求高很多；
- 不适合存储，它不是一个存储系统，依赖外部数据源；
3.3.6. Druid
优势：
- 实时分析，支持流数据实时摄取和查询；
- 可以处理大量并发；
- 具有故障转移和恢复机制；
劣势：
- 架构复杂，部署和管理成本高；
- 写入优化有限，适合读多写少的场景；
4. 总结
通过对各个OLAP数据库的了解，我们在做技术选型时，主要可以参考自己对以下需求是否强烈，根据自己业务的需求，再结合每种产品的特点，相信大家可以做出合适的选择。
- 是否需要实时查询？
- 是否需要支持数据存储？
- 是否关注于平滑迁移，减少学习成本？
- 是否关注多表join？
- 是否需要结合其他大数据组件？
- 是否需要商业化的支持？
如果大家感觉有帮助，请大家点赞收藏+ 关注，如果有问题可以在评论区进行讨论交流。
本篇文章仅供大家参考，选型时还需要参考更多的资料进行论证。
感谢大家的阅读！
