Toggle navigation
直到世界的尽头
主页
搜索
DorisDB调研
计算机相关
2021-11-18 18:38:42.0
结论： 实际业务场景测试结果看, DorisDB和ClickHouse性能和成硬件本均秒杀TIDB, 同时DorisDB性能优于ClickHouse且是本次测试中硬件配置最差的. DorisDB支持MySQL协议, 标准SQL, 对于研发的代码改动量更少, 易用性更佳。 官网 https://www.starrocks.com/zh-CN/download DorisDB简介 本文通过对DorisDB进行概要描述，从产品简介、发展历程、架构介绍、产品特性、使用场景、产品版本、横向压测对比、用户&案例、后续发展几个层面进行简要说明，部分内容引用。因接触doris时间较短，文中错误，欢迎勘正。 1. 产品简介 一直以来，一众大厂分布式数据库产品层出不穷，唯有BAT中的百度，一直没有什么大的动作。然而，我还是错了，先给百度道个歉。只因百度太低调，只因对百度的关注较少。自从发现主角DorisDB，他入座Apache Doris顶级项目，他成立商业公司鼎石，他祭出DorisDB，同百度产品Palo双线运行，OLAP层面压测PK ClickHouse、TiDB、Redshfit、Snowflake等。才发现惊天之作，啧啧耀眼，且听娓娓道来。 DorisDB简介 图1 Doris业务模型 DorisDB是由Apache Doris核心研发团队打造的新一代企业级MPP数据库。它继承了Apache Doris项目十多年研发成果，累积了线上数千台服务器稳定运行经验，并在此基础上，对传统MPP数据库进行了开创性的革新。DorisDB重新定义了MPP分布式架构，集群可扩展至数百节点，支持PB级数据规模，是当前唯一可以在大数据规模下进行在线弹性扩展的企业级分析型数据库。DorisDB还打造了全新的向量化执行引擎，单节点每秒可处理多达100亿行数据，查询速度比其他产品快10—100倍！ 2. 发展历程 DorisDB简介 图2 Doris部分编年史 脱胎于百度凤巢 2008年左右，整个大数据分析领域都处于Hive时代，Spark/Presto/Impala还没有诞生。当时的百度凤巢需要支持广告主进行快速灵活的OLAP多维分析，并且需要支持实时，还需要支持高并发。于是，一群工程师有了一个疯狂的想法：抛弃Hadoop，从零打造一个全新的MPP分析型数据库Doris！ 迈入Apache顶级项目 从2010年以后，当整个互联网都在大力研发Hadoop大数据平台时，这群人却始终相信新型MPP分析型数据库才是未来，不断埋头研发和改进Doris，一干就是十年。在2018年进入Apache基金会后，Apache Doris迅速成为了很多大型互联网厂商的数据分析平台的根基，成为了国内OLAP分析方向的佼佼者。 DorisDB孵化 2020年，这群人又有了一个更疯狂的想法，打造更新一代的DorisDB，将更先进的产品推向美国硅谷，推向日本和欧洲，成为全球范围内的领军者。于是，这群人成立了鼎石纵横科技。公司的成员均来自于百度，阿里，微软，美团，京东，小米，字节跳动等互联网头部公司的基础架构和大数据团队。Apache Doris的核心开发人员大部分都在鼎石纵横科技数据库团队任职。 百度数据仓库Doris/Palo 数据仓库Doris/Palo是基于Apache Doris（百度自研分析型数据库引擎）构建的企业级MPP云数据仓库，Doris全面兼容MySQL协议，提供快捷查询UI，易于使用；支持高并发低延时查询，支持PB级以上的超大数据集，可有效地支持在线实时数据分析。在使用百度智能云托管的Palo服务时，额外搭配一个前端控制台用于进行一些集群管理操作。目前提供新用户3个月免费试用开放申请中，手把手教你快速上手Doris/Palo！ 经历先进生产力考验 Apache Doris是一个支持对海量大数据进行快速分析的MPP数据库。在项目捐献给Apache基金会后，各大互联网头部公司都已经开始使用Doris作为各自企业内数据分析系统的基石。目前Doris数据库的头部用户包括：美团，京东，小米，百度，360，快手，作业帮等。2020年以来，一些非互联网行业的企业也开始使用Doris数据库，包括华为，中国移动等等。 3. 架构介绍 DorisDB架构和Palo核心架构相同，Palo 拥有非常简洁优雅的系统架构。其核心组件仅包括两类有状态的组件和一个可选的无状态组件。而在使用百度智能云托管的Palo服务时，额外搭配一个前端控制台用于进行一些集群管理操作。 DorisDB简介 图3 Palo架构示意图 如上图所示，中间部分即是Palo的核心组件，主要包括以下几个模块： Leader Node Leader Node也被称作Frontend（FE）。在其他文档中，这些名称指代的都是同一个组件。Leader Node主要负责用户请求连接的接入、元数据的存储和管理、查询语句的解析和查询计划的生成、集群节点状态管理，以及各类用户提交的和系统内部的作业任务调度。 Leader Node内置了MySQL协议层和Http Server。用户可以根据操作的不同，选择不同的协议连接到Leader Node。同时，Leader Node来自带了一个UI界面。用户可以在前端控制台页面右上角的Palo UI按钮点击进入。 一个Palo集群内的Leader Node通常为1个或3个。当数量为3时，Leader Node会自动组成一个节点组来保证组件的高可用。 Compute Node Compute Node也被称作Backend（BE）。在其他文档中，这些名称指代的都是同一个组件。Compute Node主要负责查询计划的执行，以及数据的存储和管理。Compute Node可以由1个或多个节点共同组成节点组，Palo集群的整体算力和存储容量，和Compute Node的节点数量成正比。 Leader Node和Compute Node之间通过RPC进行交互。 Broker Broker 是一个无状态的进程。其主要是帮助Palo以类Unix文件系统接口的方式，访问外部数据源如百度对象存储（BOS）或HDFS上的数据。比如应用于数据导入或者数据导出操作中。 在百度智能云托管的Palo集群中，默认会安装这个组件，您可以通过使用MySQL协议连接到Palo集群后，执行SHOW BROKER命令查看。而在私有化部署场景下，该组件可以是一个可选的组件。 4. 产品特性 极速SQL查询 全新的向量化执行引擎，亚秒级查询延时，单节点每秒可处理多达100亿行数据。 强大的MPP执行框架，支持星型模型和雪花模型，极致的Join性能。 综合查询速度比其他产品快10-100倍。 实时数据分析 新型列式存储引擎，支持大规模数据实时写入，秒级实时性保证。 支持业务指标实时聚合，加速实时多维数据分析。 新型读写并发管理模式，可同时高效处理数据读取和写入。 高并发查询 灵活的资源分配策略，每秒可支持高达1万以上的并发查询。 可高效支持数千用户同时进行数据分析。 轻松管理大数据 支持在大数据规模下进行在线弹性扩展，扩容不影响线上业务。集群可扩展至数百节点，PB量级数据。 集群运行高度自治化，故障自恢复，运维成本低。 国产核心软件 完全自主创新，全球领先。 更完善的本地化专家服务体系。 5. 使用场景 Doris的强大之处在于数据分析场景，在实时管理驾驶舱、BI数据分析、用户行为分析、业务运营分析、营销效果分析、业财一体分析等。 DorisDB简介 图4 DorisDB分析场景 6. 产品版本 目前Doris共4个版本: Apache Doris版本、DorisDB标准版、DorisDB企业版、Pola版本。 其中Apache Doris作为Apache Doris顶级项目进行开源； DorisDB标准版、DorisDB企业版作为鼎石商业版本运行，在Apache Doris版本上有了巨大提升和完善，而标准版可免费使用，企业版作为商业化付费使用，功能相比标准版有较大提升； Pola版本作为百度凤巢系统的一部分，由百度内部使用，提供私有云和公有云版本。 下面为Apache Doris版本、DorisDB标准版、DorisDB企业版功能对比： DorisDB简介 图5 Doris功能对比 7. 横向压测对比 7.1 DorisDB vs Clickhouse SSB性能测试对比报告 1) 测试方法 Star schema benchmark（以下简称SSB）是学术界和工业界广泛使用的一个星型模型测试集（来源论文），通过这个测试集合可以方便的对比各种OLAP产品的基础性能指标。Clickhouse 通过改写SSB，将星型模型打平转化成宽表，改造成了一个单表测试benchmark（参考链接）。本报告记录了DorisDB、ApacheDoris和Clickhouse在SSB单表和多表数据集上进行了性能对比测试的结果。 2) 测试结论 在单表测试的13个查询中，Apache Doris耗时最长；有9个查询DorisDB查询速度最快，另外4个查询Clickhouse速度最快。 单表测试中，13个查询Clickhouse总耗时是DorisDB 的1.33倍。 在多表测试的13个查询中，DorisDB 平均比Apache Doris快6.8倍，部分查询快10倍以上。 注：由于Clickhouse对多表Join支持有限，所以在多表测试中并未将Clickhouse加入测试。 3) 测试详情 https://www.dorisdb.com/zh-CN/blog/1.8 7.2 实际业务SQL对比测试ClickHouse、TIDB和DorisDB 1) 测试说明 本次测试使用的SQL语句为公司实际业务SQL, 出于数据安全考虑不做SQL和表结构展示；进行本次测试时对DorisDB了解甚微, 表结构有待优化, 没有使用DorisDB提供的任何特性, 没有改写SQL(clickhouse需要做一些改写)； 本次测试由于服务器资源有限, 没有严格遵循单一变量原则进行测试； 本次测试TIDB没有部署TIFlash。 2) 测试结论 TIDB 优点: 持标准SQL; 支持MySQL协议; 数据自动分片无需人工维护, 易用性不错; 支持窗口函数; 支持高并发 缺点: 成本最高, 性能最差(仅针对OLAP领域); 没有物化视图功能; 仅能覆盖20% OLAP场景; ClickHouse 优点: 单机性强悍, 性价比最高; 单表查询速度极快; 有物化视图功能 缺点:不支持标准SQL; 不支持MySQL协议; 作分片后关联需注意SQL写法, 小表要写到最后; 增加分片数据无法自动rebalance, 人工维护成本高; 函数学习成本较高; 不支持高并发 DorisDB 优点: 支持标准SQL; 支持MySQL协议; 提供Colocation Join, 分析函数, 布隆过滤, 物化视图, bitmap索引等特性, 增加分片数据自动rebalance; 多表关联性能较好; 支持高并发 缺点: 新型数据库, Apache Doris发展已有11年历史, 17年前由百度捐献给Apache, 目前仍在孵化中, 社区比较活跃, 有很多互联网公司应用案例用户, 但DorisDB应用案例还较少, 还需持续观望; 从实际业务场景测试结果看, DorisDB和ClickHouse性能和成硬件本均秒杀TIDB, 同时DorisDB性能优于ClickHouse且是本次测试中硬件配置最差的. DorisDB支持MySQL协议, 标准SQL, 对于研发的代码改动量更少, 易用性更佳。 3) 测试详情 https://forum.dorisdb.com/t/topic/114 7.3 DorisDB、TiDB/TiFlash、ClickHouse性能对比-单表监控场景 1) 测试说明 随着数据库集群数的快速上涨，监控的数据分析变得越发的重要，例如： 快速分析指定集群、指定时间段的监控值的情况 快速分析所有集群、指定时间的分类监控Top10，例如最近1天写Top10、读Top10。 对于以上需求，需要分析型的数据库来支持~例如目前业界最火的3款： DorisDB ClickHouse TiDB/TiFlash 当前监控数据已经落地在TiDB数据库，条数 8亿+，本次只对这3种数据库进行性能测试，同时涉及： DorisDB集群，并行度/桶对执行SQL的影响 ClickHouse单实例、集群对SQL执行的影响 TiDB 版本、SSD磁盘与 闪存卡磁盘对SQL执行的影响 2) 测试结论 注：绿色时间最短，红色最长 时间均为：秒 DorisDB简介 3) 测试详情 https://forum.dorisdb.com/t/topic/104 7.4 DorisDB、TiDB/TiFlash、ClickHouse性能对比- SSB测试-单多表场景 1) 测试说明 因分析型业务猛烈增长，本文将对3种OLAP列存数据库进行性能对比，功能及易运维等方面此次先不讨论， 涉及： DorisDB集群 ClickHouse单实例，集群 TiDB/TiFlash集群 Star schema benchmark（以下简称SSB）是学术界和工业界广泛使用的一个星型模型测试集 ， 通过这个测试集合可以方便的对比各种OLAP产品的基础性能指标。 2) 测试结论 单表/多表查询，DorisDB总体时间均最短 单表查询：DorisDB最快次数最多，ClickHouse次之 多表查询：DorisDB所有执行均最快 TiDB/TiFlash总体时间单表/多表查询均最长 TiDB执行计划多数走TiKV，导致执行时间长，且数据量越多，执行时间越长 TiDB强制走TiFlash ，单表多数提速多，多表多数变慢，但4.0.10 版本的执行计划多数不走 ClickHouse多表查询需要更改SQL，使类型一致才可以，且字段名、表名区分大小写 ClickHouse单机性能强悍，性价比较高 多表join场景比单表查询时间长 ClickHouse大单表查询方式效率好，多表关联效率降低明显 DorisDB多表关联效率好 ClickHouse分布式表Join 比 全本地单表Join 的查询快 ClickHouse小表不推荐使用分布式表Join，只大表进行分布式表Join，执行时间均变短 3) 测试详情 https://forum.dorisdb.com/t/topic/105 8. 用户及案例 国内用户 DorisDB对外发布以来，市值或者估值超过十亿美金的大型用户快速达到了几十家，其中也不乏海外大型客户,目前国内部分国内用户详见如下： DorisDB简介 案例 序号 用户 案例简介 案例详情 1 京东 通过一年多时间的生产环境使用，Doris满足了京东日常使用的需求，并通过了多次节日大促的考验 Apache Doris在京东广告的应用实践 https://www.dorisdb.com/zh-CN/blog/jingdong DorisDB简介 2 美团外卖 本文主要介绍一种通用的实时数仓构建的方法与实践 美团外卖实时数仓建设实践 https://www.dorisdb.com/zh-CN/blog/meituan DorisDB简介 3 作业帮 通过引入Doris，解决了明细&聚合数据查询不统一的问题，奠定了整个数据中台在查询侧的基石 作业帮基于Apache Doris的数仓实践 https://www.dorisdb.com/zh-CN/blog/zuoyebang DorisDB简介 4 小米 Doris在小米从2019年9月上线接入第一个业务至今，已经在海内外部署近十个集群，每天完成数万个在线分析查询，承担了我们包括增长分析和报表查询在内的大多数在线分析需求 基于Apache Doris的小米增长分析平台实践 https://www.dorisdb.com/zh-CN/blog/xiaomi DorisDB简介 5 搜狐 搜狐智能媒体数据仓库体系建设实践，会对数据仓库中的基本概念进行简单梳理，明确数据仓库体系建设涵盖的相关流程，主要划分为批量( 非实时 )数据处理和实时数据处理 搜狐智能媒体数据仓库体系建设实践 https://www.dorisdb.com/zh-CN/blog/souhu DorisDB简介 6 一点资讯 一点资讯自媒体平台的主要业务内容与自媒体、内容、审核、MCN、CPM、profile相关。一点资讯自媒体平台将从工程业务的角度来分享使用Doris的经验 Apache Doris在一点资讯自媒体平台的应用 https://www.dorisdb.com/zh-CN/blog/yidianzixun DorisDB简介 7 新浪微博 基于对业务数据关注的希望，微博团队从17年初开始做数据方面的建设。目前系统已经应用了Kafka、HDFS、Spark等，当然还有Doris在其中起到重要的作用 Apache Doris在新浪微博的应用 https://www.dorisdb.com/zh-CN/blog/weibo DorisDB简介 8 美团点评 本次美团点评的同学将主要从技术选型、典型应用、平台化建设和功能改造这4个方面给大家带来Doris的使用分享 Doris在美团点评的应用 https://www.dorisdb.com/zh-CN/blog/meituan2 DorisDB简介 9.后续发展 9.1 商业发展 注:本小节引用自 :https://www.jianshu.com/p/092e713e4181 从2020年仅用了不到一年时间，我们就实现了对ClickHouse的全面超越（具体见：《致ClickHouse用户的一封信》）。从零打造的新一代向量化MPP计算引擎，以强悍的性能重新定义了全球第一的OLAP分析性能，向世界证明了中国团队也能做出顶级的分析型数据库！ 这仅仅是一个开始，我们正在全面出击，挑战新的“不可能”： 研发新一代列式存储引擎，让实时高并发更新对数据查询延迟无干扰！ 进一步提升OLAP分析性能，大幅领先Redshfit和Snowflake，实现5倍以上的极致性价比。 深入优化复杂查询，性能达到Presto的5-10倍，重新定义adhoc查询速度！ 数据库内部完美融合table和stream语义，处理性能大幅领先Spark和Flink，重新定义流批一体化！ 研发比Snowflake更先进的云原生架构，让高性能和弹性完美结合！ 大型客户和顶级投资人的认可，是我们另一个自信来源。我们已经完成A轮融资，融资金额高达数千万美金（具体信息请关注后续融资新闻），世界顶级投资人也开始助力我们的梦想！ 9.2 技术发展 本小节引用自 :https://www.modb.pro/db/50399 1) 向量化执行引擎 Doris 一直以易用性和功能性著称、并且在高并发点查询、多表 Join 等复杂多维分析场景有良好的性能表现。 但是在单纯的算子性能方面依然有非常大的优化空间。今年我们会将查询层所有执行算子实现向量化，该工作预计将Doris的整体性能提升5倍左右。 2) 稳定性改进 随着Doris用户的增长，一些稳定性方面的共性问题也开始凸显。这些问题主要集中在内存OOM、查询耗时不稳定，以及一些新功能合入后引发的系统稳定性问题。Doris今年也会重点提升Doris的稳定性，包括更合理的内存管理、更精细的线程调度等。 同时我们将尝试引入更加规范的单元测试和回归测试框架以进一步提升代码质量。 3) 查询优化器的改进 Doris 现有的查询优化器源自早期版本的 Impala 查询优化器。但随着多年的不断迭代、修复和功能升级，目前的优化器已经和Impala社区有很大的不同，并且因为一些历史原因导致当前的优化器框架在扩展性和维护性方面都存在问题。所以在现有框架上增加更高级的优化器功能时往往会引发更多的问题。 因此，我们计划引入一套新的查询优化器框架来改善这个问题。新的优化器可能会和现有优化器在很长一段时间内同时存在，以期通过社区用户的反馈和迭代来不断完善。系统瓶颈无法排查等问题。我们将尝试引入如 OpenTelemetry 等标准化的 tracing 框架来改善这个问题，希望能够帮助运维人员更快的定位系统问题。 4) 复合类型的支持 部分业务会有包括Array、Map、Struct等复合类型的需求。比如在用户画像和用户行为分析中经常使用的 Array 类型。Doris 社区目前已经完成了部分复合类型的工作，今年我们将会继续推进这方面的研发。 5) 大数据生态建设 随着ES、Flink、Pulsar、数据湖等新一代的大数据组件的流行，Doris 也在不断的和这些系统进行整合。目前社区已经完成了部分 Flink 相关的工作。 我们也在推进和其他系统的整合。这个工作能够帮助Doris更好的和企业现有的数据基础组件进行打通，进一步降低Doris的接入成本。 6) 多租户和存储计算分离 多租户从两个角度出发，一方面是企业对于多业务线权限管理的需求，另一方面是对不同租户资源隔离的需求。目前很多企业在使用 Doris 时都不得不分别建立一套离线集群和一套在线集群，以隔离不同的业务场景防止资源上的相互抢占，这样也极大的增加了数据维护成本。 我们将会在今年尝试通过两种途径来解决这个问题，一个是通过资源标签的方式将Doris集群进行节点级的划分，并限制不同的用户只能使用指定资源标签下的节点，从而达到在一个集群内物理隔离的效果。 第二个途径是存储计算分离，采用存储资源共享，计算资源独立的方式来满足业务需求。 7) 可观测性 系统的可观测性直接影响到运维人员对系统的把控程度。如一些用户反馈的慢查询无法定位、节点运行状态不透明、系统瓶颈无法排查等问题。我们将尝试引入如 OpenTelemetry 等标准化的 tracing 框架来改善这个问题，希望能够帮助运维人员更快的定位系统问题。 10.小结 对于已发展13年之久的DorisDB而言，经过百度打磨，OLAP方面功能强劲，也存在或多或少的问题，如不支持字段级别的数据更新、市场推广不足等。无论是技术、运营、推广、认证、生态建设等层面还有更多的路要走，面对众多支持HATP的国产分布式数据库，单打OLAP的DorisDB将走向何方，我们拭目以待。 原文链接 ：http://www.dreamwu.com/post-20411.html