博客

冷热分层是将冷热数据分别存储在成本不同的存储介质上，例如热数据存储在成本更高的 SSD 盘上、以提高时效数据的查询速度和响应能力，而冷数据则存储在相对低成本的 HDD 盘甚至更为廉价的对象存储上，以降低存储成本。我们还可以根据实际业务需求进行灵活的配置和调整，以满足不同场景的要求。

Apache Doris 作为基于 MPP 架构的 OLAP 数据库，数据从磁盘加载到内存后，会在算子间流式传递并计算，在内存中存储计算的中间结果，这种方式减少了频繁的磁盘 I/O 操作，充分利用多机多核的并行计算能力，可在性能上呈现巨大优势。

Apache Doris 借鉴了信息检索的核心技术，在存储引擎上实现了面向 AP 场景优化的高性能倒排索引，对于字符串类型的全文检索和普通数值、日期等类型的等值、范围检索具有更高效的支持，相较于 Elasticsearch 实现性价比 10 余倍的提升，以此为日志存储与分析场景提供了更优的选择。

融合统一的分析范式为 Apache Doris 能承载的工作负载带来了挑战，也让我们更加系统化地去思考如何更好地满足用户在此类场景的业务需求。基于以上思考，在即将发布的 2.0 版本中，我们在原有功能基础上引入了一系列面向点查询的优化手段，单节点可达数万 QPS 的超高并发，极大拓宽了适用场景的能力边界。

作为一款极速易用的开源实时 OLAP 数据库，[Apache Doris ](https://github.com/apache/doris)自 0.15 版本即开始尝试在 Apache Iceberg 之上探索与数据湖的能力结合。而经过多个版本的优化迭代，Apache Doris 在数据湖分析已经取得了长足的进展，一方面在数据读取、查询执行以及优化器方面做了诸多优化，另一方面则是重构了整体的元数据连接框架并支持了更多外部存储系统。因此 Apache Doris 已经完全具备了构建极速易用的 Lakehouse 架构的能力，并且也已在多个用户的真实业务场景中得到验证和推广。

LSM-Tree（ Log Structured-Merge Tree）是数据库中最为常见的存储结构之一，其核心思想在于充分发挥磁盘连续读写的性能优势、以短时间的内存与 IO 的开销换取最大的写入性能，数据以 Append-only 的方式写入 Memtable、达到阈值后冻结 Memtable 并 Flush 为磁盘文件、再结合 Compaction 机制将多个小文件进行多路归并排序形成新的文件，最终实现数据的高效写入。

数值运算是数据库中十分常见的需求，例如计算数量、重量、价格等，为了适应多样化运算场景，数据库系统通常支持精准的数字类型和近似的数字类型，当我们需要精确地表示小数并计算小数时，通常会考虑使用 Decimal 数据类型。区别于浮点小数，Decimal 作为定点小数类型，可以支持高精度的小数运算，因此适用于各种高精度计算的场景，常见的应用场景有以下几种：

我们在使用各个 SQL 引擎时，会遇到纷繁复杂的查询需求。一部分可以通过引擎自带的内置函数去解决，但内置函数往往具有一定通用性，在部分特殊场景下内置函数可能无法满足需求，所以一般 SQL 引擎会提供 UDF 功能，方便用户通过自己写逻辑来满足特定的需求，Apache Doris 也不例外。在 Java UDF 之前，Apache Doris 提供了原生 UDF 。由于是使用 C++ 来编写的，执行效率高、速度更快，但是在实际使用中也会存在一些问题：

在实时数据仓库的业务场景中，能够友好支持数据的实时更新是一个非常重要的能力。例如在数据库同步（CDC）、电商交易订单、广告效果投放、营销业务报表等业务场景中，面对上游数据的变化，通常需要快速获取到变更记录并针对单行或多行数据进行及时变更，保证业务分析师及相关分析平台能快速捕捉到最新进展，提升业务决策的及时性。

自 Apache Doris 1.1.0 版本发布距今已经有数月之久，在这一期间，我们重新思考并确立了社区新版本发布的流程，正式引入了 LTS （Long-Term Support，长周期支持）版本的概念，在 1.1.x 系列版本中不再引入大的功能 Feature、仅提供问题修复和稳定性改进，力求满足更多社区用户在稳定性方面的高要求。值得高兴的是，这一行动已经有了明显的成效，目前 1.1.x 系列最新版本的稳定性经受了众多用户生产环境的考验。