1.1.1 Doris应需而生

在Doris诞生之前，百度和大多数互联网公司一样，使用MySQL的Sharding为OLAP报表业务提供支持。在早些年，百度的主要收入来源是广告，广告主需要通过报表查看广告的展现效果、点击量、收入等信息，并且根据不同维度分析制定后续广告的投放策略。随着百度本身流量的增加，广告流量也随之增加，MySQL的Sharding方案无法满足业务需求，主要痛点如下。

❑大规模数据导入会导致MySQL的读性能大幅降低，有时还会出现锁表现象，导致查询超时，尤其在频繁导入数据时，问题更为明显。

❑MySQL在数据量达千万级别时性能很差，只能从产品层面来限制用户的查询时间，抑制了用户需求，增加了很多后台取数的需求。

❑MySQL单表存储的数据有限，如果数据量过大，查询就会变慢。而且随着数据量的快速增长，Sharding方案维护成本飙升。

上述痛点也是目前大多数未引入Doris的企业所面临的，特别是在互联网行业，数据量大，且较少采用商业软件，主要以开源MySQL为核心构建报表查询系统，需要将在线分析处理结果进行多次聚合，才能满足报表的查询需求。

在2008年那个时间点，处理数据存储和计算的成熟开源产品很少，HBase的导入性能只有约2000条/s，不能满足业务快速增长需求。另外，业务还在不断增加，数据存储和数据分析的压力越来越大。于是，百度选择了自主研发之路，Doris由此诞生。

在Doris 1版本中，数据仍然通过用户ID进行哈希分布，将同一个用户ID的数据交由一台机器处理，这样大量的Join操作都可以在本地完成。Doris 1架构包含数据存储、元数据管理、数据导入和API网关4个部分，其中数据存储组件负责数据的存储和读写，元数据管理组件负责数据文件的目录管理和表信息管理，数据导入组件负责写入外部导入的数据，API网关负责接收、解析、规划查询请求。

相比于MySQL的Sharding方案，Doris主要在如下几个方面进行了改进。

❑Doris 1的数据模型将数据分为Key列、Value列。比如一条交易数据的Key列包括用户ID、时间、地域、来源等，Value列包括展现次数、点击次数、消费额等。在这样的数据模型下，所有Key列相同的行对应的Value列能够进行聚合，比如数据的时间维度最细粒度为小时，那么同一小时内多次导入的数据能够合并成一条记录，这样对于同样的查询来说，Doris 1需要扫描的数据条目相比MySQL会少很多。

❑Doris 1将MySQL逐条插入的方式改为批量更新，并且通过外围模块将同一批次数据进行排序以及预聚合。这样一个批次中相同Key列的数据能够被预先聚合，另外排序后的数据能起到聚集索引的作用，提升查询性能。

❑Doris 1提供了天表、月表这种类似物化视图的功能。比如用户想将数据按天进行汇聚展现，那么可以通过天表来实现。而相对于小时表，天表数据量会少很多，相应的查询性能也会提升几倍。

至此，Doris已经有了聚合模型、物化视图、批量读写3个基本特点了。Doris 2主要将Doris 1进行通用化改造，包括支持自定义表结构等，使Doris能够应用于其他产品，拓展了一些应用场景。