您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

(doris怎么读)-fairy怎么读

数据,业务,用户(doris怎么读)-fairy怎么读

发布时间：2016-12-08加入收藏来源：互联网点击：

很多朋友想了解关于doris怎么读的一些资料信息，下面是小编整理的与doris怎么读相关的内容分享给大家，一起来看看吧。

Apache Doris（incubating）从2008年第一个版本开始到今天已经走过了11个年头。期间，Doris 从最初的只为解决百度凤巢报表的专用系统，已经成长为目前国内唯一的分析型数据库孵化项目。一路走来， Doris 的初心从未改变。

Apache Doris —— 为分析而生

从诞生之日起，Doris 的每一步都是为了解决切实的业务痛点，每一次转变都是在面对不同的业务挑战。一路上，Doris 砥砺前行，凝结了众多前辈的心血。相信未来，Doris 还会有更多的新鲜血液加入，我们一起走的更快、更远。

Doris 发展历程

Doris 自第一版诞生以来，经过了11年的发展，中间做过无数改进。这⾥只罗列对 Doris 发展来说比较重要的关键节点与事件。

#2008

Doris1，“筑巢引凤”的重要基石

早年，百度最主要的收入来源是广告。广告主需要通过报表服务来查看广告的展现、点击、消费等信息，并且能够需要通过不同维度来获得广告的消费情况，用以指导后续的广告的投放策略。

在 Doris1 诞生之前，百度使用 MySQL Sharding 方式来为广告主提供广告报表支持。随着百度本身流量的增加，广告流量也随之增加，已有的 MySQL Sharding 方案变得不再能够满足业务的需求。主要体现在以下几个方面：

第一，大规模数据导入会导致 MySQL 的读能大幅降低，甚至还有锁表情况，在密集导入数据的情况下尤为明显。同时在数据导入时，MySQL 的查询能大幅下降，导致页面打开很缓慢或者超时，用户体验很差；第二，MySQL 在大查询方面能很差，因此只能从产品层面来限制用户的查询时间范围，用户体验很差；第三，MySQL 对数据量的支持是有限的。单表存储的数据有限，如果过大，查询就会变慢。对此的解决方案只有拆表、拆库、迁移数据。随着数据量的快速增长，已经无法维护。

当时数据存储和计算成熟的开源产品很少，Hbase 的导入能只有大约2000条/秒，不能满足业务每小时新增的要求。而业务还在不断增长，来自业务的压力越来越大。在这种情况下，Doris1 诞生了，并且在2008年10月份跟随百度凤巢系统一起正式上线。

Doris1 的主要架构如上图所示。数据仍然通过用户 ID 进行 Hash，将同一个用户 ID 的数据交由一台机器处理。其中 Hm-Storage 负责数据的存储。ODP、OMG 负责将业务数据导入到 Hm-Storage 中。AS 负责解析、规划查询请求，并将查询请求发给 Hm-Storage 处理，并对 Hm-Storage 返回的数据进行一些业务相关的计算后将查询结果返回给用户。

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

首先，Doris1 的数据模型将数据分为 Key 列、Value 列。比如一条数据的 Key 列包括：用户 ID、时间、地域、来源等等，Value 列包括：展现次数、点击次数、消费额等。这样的数据模型下，所有 Key 列相同的数据 Value 列能够进行聚合，比如数据的时间维度最细粒度为小时，那同一小时多次导入的数据是能够被合并成一条的。这样对于同样的查询来说，Doris1 需要扫描的数据条目相比 MySQL 就会降低很多。

其次，Doris1 将 MySQL 逐条插入改成了批量更新，并且通过外围模块将同一批次数据进行排序以及预聚合。这样一个批次中相同 Key 的数据能够被预先聚合，另外排序后的数据能够在查询的时候起到聚集索引的作用，提升查询时候的能。

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

通过 Doris1 的工作，完全解决了 MySQL Sharding 遇到的问题。并于2008年10月在凤巢系统一起上线，完美地支撑了广告统计报表需求。

#2009

Doris2，解“百度统计”燃眉之急

2008年的百度统计服务大约有50-60台 MySQL，但是业务每天有3000万+条增量数据，由于 MySQL 的存储和查询能无法满足需求，对存量数据的支撑已经到了极限，问题频出，万般无奈之下百度统计甚至关闭了新增用户的功能，以减少数据量的增加。

Doris1 由于当时时间紧、任务重，所以设计、实现的时候只为了能够满足凤巢的业务需求，并没有兼顾其他的应用需求。由于 Doris1 方案对于凤巢成功的支持，百度统计同学开始基于 Doris1 打造 Doris2 系统，主要将 Doris1 进行通用化改造，包括支持自定义 schema 等，使 Doris 能够应用于其他产品。此外还进行一些优化以此来提升系统的查询、存储能。

2009年 Doris2 研发完成后上线百度统计，并且成功支撑百度统计后续的快速增长，成功助力百度统计成为当时国内规模最大，能、功能最强的统计平台。由于在凤巢、百度统计上的成功，公司内部后续其他类似统计报表类的需求也都由 Doris2 进行支持，比如网盟、联盟等报表服务。

#2010

Doris3 ，让查询再快一点

百度在2009-2011年发展迅猛，营收每年近100%的速度增长，与之相伴的是广告数据量也随之大幅增长。随着业务数据量的不断增长，Doris2 系统的问题也逐渐成为业务发展的瓶颈。

首先体现在 Doris2 无法满足业务的查询能需求，主要是对于长时间跨度的查询请求、以及大客户的查询请求。这是因为 Doris2 通过规则将全部数据按照用户 ID 进行 Sharding，这虽然能够将全部数据分散到多台机器上，但是对于单一用户的数据还是全部落在一台机器上。随着单一用户数据量增多，一些查询请求无法快速计算得到结果。

其次，Doris2 在日常运维方面基本上都需要停服后手动操作，比如 Schema Change、集群扩缩容等，一方面用户体验很差，一方面还会增加集群运维的成本。最后，Doris2 本身并不是高可用系统，机器故障等问题还是会影响服务的稳定，并且需要人肉进行复杂的操作来恢复服务。

为了解决 Doris2 的问题，团队开始了 Doris3 的设计、研发。Doris3 的主要架构如下图所示，其中 DT（Data Transfer）负责数据导入、DS（Data Seacher）模块负责数据查询、DM（Data Master）模块负责集群元数据管理，数据则存储在 Armor 分布式 Key-Value 引擎中。Doris3 依赖 ZooKeeper 存储元数据，从而其他模块依赖 ZooKeeper 做到了无状态，进而整个系统能够做到无故障单点。

在数据分布方面 Doris3 引入了分区的概念。首先数据会按照时间进行分区（比如天分区、月分区）；在同一个分区里，数据会根据用户 ID 再进行 Sharding。这样同一个用户的数据会落在不同的分区上，而在查询时多台机器就能够同时处理一个用户的数据了，实现了单用户的分布式计算能力。但是可能还会存在一个分区内部单个用户数据量过大的情况。对于这种情况 Doris3 设计了后续表功能，会将单个分区内大用户的数据进行拆分，导入到多个分片中，这样能够保证每个分片内单个用户的数据总量最高是有限度的。

另外 Doris3 在日常运维 Schema Change，以及扩容、缩容等方面都做了针对设计，使其能够自动化进行，不依赖线上人工操作。

 1/3    1 2 3 下一页 尾页