doris总结
2022-06-29 14:32:45 3 举报
AI智能生成
Doris是一个开源的分布式OLAP(联机分析处理)查询引擎,专为海量数据和高并发查询设计。它支持多种数据导入方式,如HDFS、HBase、Kafka等,并能进行高效的数据分析和统计。同时,Doris还提供了灵活的数据模型和查询语言,用户可以轻松地进行复杂的数据操作和报表生成。此外,Doris还具有优秀的水平扩展性和高可用性,能够满足大规模企业级应用的需求。总的来说,Doris是一个强大而易用的大数据分析和报告工具,适用于各种业务场景。
作者其他创作
大纲/内容
部署
https://doris.apache.org/zh-CN/docs/get-starting/get-starting.html
https://doris.apache.org/zh-CN/docs/install/install-deploy.html
概述
Apache Doris是一个现代化的MPP分析型数据库产品。仅需亚秒级响应时间即可获得查询结果,有效地支持实时数据分析。Apache Doris的分布式架构非常简洁,易于运维,并且可以支持10PB以上的超大数据集。
Apache Doris可以满足多种数据分析需求,例如固定历史报表,实时数据分析,交互式数据分析和探索式数据分析等。令您的数据分析工作更加简单高效!
MPP
MPP ( Massively Parallel Processing ),即大规模并行处理,在数据库非共享集群中,每个节点都有独立的磁盘存储系统和内存系统,业务数据根据数据库模型和应用特点划分到各个节点上,每台数据节点通过专用网络或者商业通用网络互相连接,彼此协同计算,作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。简单来说,MPP 是将任务并行的分散到多个服务器和节点上,在每个节点上计算完成后,将各自部分的结果汇总在一起得到最终的结果 ( 与 Hadoop 相似 )。
Doris 主要解决 PB 级别的数据量(如果高于 PB 级别,不推荐使用 Doris 解决,可以考虑用 Hive 等工具),解决结构化数据,查询时间一般在秒级或毫秒级。
Doris 由百度大数据部研发 ( 之前叫百度 Palo,2018年贡献到 Apache 社区后,更名为 Doris ),在百度内部,有超过200个产品线在使用,部署机器超过1000台,单一业务最大可达到上百 TB。
百度将 Doris 贡献给 Apache 社区之后,许多外部用户也成为了 Doris 的使用者,例如新浪微博,美团,小米等著名企业。
数仓查询加速
PB级别数据毫秒/秒级延时
海量数据无缝应用
极大幅度提升查询效率
多源联邦查询
跨多数据源,统一查询入口
过滤条件下推,显著提升查询性能
满足业务人员多元化的查询需求
过滤条件下推,显著提升查询性能
满足业务人员多元化的查询需求
实时数仓构建
流式数据高效导入
实时业务数据洞察
统一大数据平台架构和数据流
实时业务数据洞察
统一大数据平台架构和数据流
交互式数据分析
结合BI构建交互式数据分析应用
对海量数据自助探查和多维度分析
实现对业务的深层探索和快速决策
对海量数据自助探查和多维度分析
实现对业务的深层探索和快速决策
核心优势
性能
高效列式存储引擎和现代化MPP架构,结
合多种加速方式,实现极致的查询性能
合多种加速方式,实现极致的查询性能
简单易用
完全兼容MySQL协议和标准SQL,用户使
用友好,能与已有系统框架轻松融合
用友好,能与已有系统框架轻松融合
场景丰富
在离线一体,通过灵活的资源配置策略可
同时支持高并发点查询和高吞吐大查询
同时支持高并发点查询和高吞吐大查询
稳定可靠
多种策略保证系统高可用,单点故障和系
统升级对线上业务无任何影响
统升级对线上业务无任何影响
架构
高度兼容MySQL协议
主从架构,不依赖任何其他组件
FE负责解析/生成/调度查询计划
FE 主要有有三个角色,一个是 leader,一个是 follower,还有一个 observer。leader 跟 follower,主要是用来达到元数据的高可用,保证单节点宕机的情况下,元数据能够实时地在线恢复,而不影响整个服务。
Observer 只是用来扩展查询节点,就是说如果在发现集群压力非常大的情况下,需要去扩展整个查询的能力,那么可以加 observer 的节点。observer 不参与任何的写入,只参与读取。
BE负责执行查询计划、数据存储
数据的可靠性由 BE 保证,BE 会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。
任何节点都可线性扩展
元数据
Doris 采用 Paxos 协议以及 Memory + Checkpoint + Journal 的机制来确保元数据的高性能及高可靠。元数据的每次更新,都首先写入到磁盘的日志文件中,然后再写到内存中,最后定期 checkpoint 到本地磁盘上。我们相当于是一个纯内存的一个结构,也就是说所有的元数据都会缓存在内存之中,从而保证 FE 在宕机后能够快速恢复元数据,而且不丢失元数据。Leader、follower 和 observer 它们三个构成一个可靠的服务,这样如果发生节点宕机的情况,在百度内部的话,我们一般是部署一个 leader 两个 follower,外部公司目前来说基本上也是这么部署的。就是说三个节点去达到一个高可用服务。以我们的经验来说,单机的节点故障的时候其实基本上三个就够了,因为 FE 节点毕竟它只存了一份元数据,它的压力不大,所以如果 FE 太多的时候它会去消耗机器资源,所以多数情况下三个就足够了,可以达到一个很高可用的元数据服务
Doris FE高可用方案:
如果你是离线业务,对高可用要求不是那么高可以使用 1 FE(Follower leader) + 1 FE(Observer)
如果你是实时在线业务,对高可用要求很高,建议使用 3 FE(Follower),会自动选举出一个 leader
数据分布及可靠性
Doris 数据主要都是存储在 BE 里面,BE 节点上物理数据的可靠性通过多副本来实现,默认是 3 副本,副本数可配置且可随时动态调整,满足不同可用性级别的业务需求。FE 调度 BE 上副本的分布与补齐。
如果说用户对可用性要求不高,而对资源的消耗比较敏感的话,我们可以在建表的时候选择建两副本或者一副本。比如在百度云上我们给用户建表的时候,有些用户对它的整个资源消耗比较敏感,因为他要付费,所以他可能会建两副本。但是我们一般不太建议用户建一副本,因为一副本的情况下可能一旦机器出问题了,数据直接就丢了,很难再恢复。我们在公司内部的话,一般是默认建三副本,这样基本可以保证一台机器单机节点宕机的情况下不会影响整个服务的正常运作
组件
Frontend(FE)
Java语言开发,Doris 系统的元数据管理和节点调度。在导入流程中主要负责导入 plan 生成和导入任务的调度工作,请求接入等
Backend(BE)
C++语言开发,Doris 系统的计算和存储节点,执行SQL计划等。在导入流程中主要负责数据的 ETL 和存储。
Broker
Broker 为一个独立的无状态进程。封装了文件系统接口,提供 Doris 读取远端存储系统中文件的能力,包括HDFS,S3,BOS等
Mysql Client
Doris 借助 MySQL 协议,用户使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客户端,都可以直接访问 Doris
Doris on ES
Doris-On-ES将Doris的分布式查询规划能力和ES(Elasticsearch)的全文检索能力相结合,提供更完善的OLAP分析场景解决方案:
ES中的多index分布式Join查询
Doris和ES中的表联合查询,更复杂的全文检索过滤
ODBC External Table Of Doris
ODBC External Table Of Doris 提供了Doris通过数据库访问的标准接口(ODBC)来访问外部表,外部表省去了繁琐的数据导入工作,让Doris可以具有了访问各式数据库的能力,并借助Doris本身的OLAP的能力来解决外部表的数据分析问题:
支持各种数据源接入Doris
支持Doris与各种数据源中的表联合查询,进行更加复杂的分析操作
通过insert into将Doris执行的查询结果写入外部的数据源
Spark Doris Connector
Spark Doris Connector 可以支持通过 Spark 读取 Doris 中存储的数据。
当前版本只支持从Doris中读取数据。
可以将Doris表映射为DataFrame或者RDD,推荐使用DataFrame。
支持在Doris端完成数据过滤,减少数据传输量。
Flink Doris Connector
Flink Doris Connector 可以支持通过 Flink 读取 Doris 中存储的数据。
可以将Doris表映射为DataStream或者Table
支持通过Flink table的方式使用doris数据
可以通过Flink table 方式方便的将数据通过insert into select方式将数据插入到doris表中
DataX doriswriter
DataX doriswriter 插件,用于通过 DataX 同步其他数据源的数据到 Doris 中。
这个插件是利用Doris的Stream Load 功能进行数据导入的。需要配合 DataX 服务一起使用。
这个扩展可以很方便的将业务数据库中的数据快速的抽取导入到doris数仓中
Doris output plugin
该插件用于logstash输出数据到Doris,使用 HTTP 协议与 Doris FE Http接口交互,并通过 Doris 的 stream load 的方式进行数据导入.
审计日志扩展
Doris 的审计日志插件是在 FE 的插件框架基础上开发的。是一个可选插件。用户可以在运行时安装或卸载这个插件。
该插件可以将 FE 的审计日志定期的导入到指定 Doris 集群中,以方便用户通过 SQL 对审计日志进行查看和分析。
存储
列示存储
数据按列连续存储,按需读取
多种编码方式和自适应编码
在编码基础上基于Lz4算法进行压缩
1:8数据压缩比
存储编码方式
文件格式
多副本存储,自动数据迁移、副本均衡
子主题
索引
自动写入的智能索引
前缀稀疏索引:快速定位起始行
Min Max 索引:等值/范围查询快速过滤
用户自主选择的二级索引
Bloom Filter 索引:高基数上实现等值查询
倒排索引:基于Bitmap位图快速精确查询
MPP
基于MPP的火山模型
利用多节点间并行数据处理
节点内并行执行,充分利用多CPU资源
算子优化
自适应的两阶段聚合算子,避免阻塞等待
大量优化Join算子,以Runtime Filter为例
为连接列生成过滤结构并下推,减少需要传输和对比的数据量
实现了In/Min Max/Bloom Filter等Filter类型,根据不同场景选择
节点自动穿透,将Filter穿透下推到最底层扫描节点
向量化执行引擎
向量化:一次对一组值进行运算的过程
充分提升CPU执行效率
进一步利用CPU SIMD指令加速计算效率
规则优化RBO
常量折叠
基于常量计算,利于分区分桶
裁剪以数据过滤
裁剪以数据过滤
子查询改写
将子查询改写成Join,利用
Join优化来提升查询效率
Join优化来提升查询效率
谓词下推
谓词下推至存储引擎,利用索
引进行数据过滤
引进行数据过滤
代价优化CBO
Join Reorder
自动调整Join顺序,降低中间
数据集大小
数据集大小
Colocation Join
利用数据分布情况在本地完成
join,避免数据Shuffle
join,避免数据Shuffle
Bucket Join
智能判断关联条件和数据分
布关系,减少Shuffle数据量
布关系,减少Shuffle数据量
数据模型
、
建表
定义 Key 维度列和 Value 指标列
选择数据模型:Agg /Uniq /Dup
选择数据分布方式: Partition 分区和 Bucket 分桶
指定副本数量和存储介质
子主题
模型
Unique Key主键唯一模型,Key唯一、不聚合,实现精准去重和行级别数据更新;
Aggregate聚合模型:相同key列其Value列合并(SUM,MIN,MAX,REPLACE),通过提前聚合显著提升查询性能
Duplicate Key明细模型,不提前聚合、实现快速排序
同时支持星型模型/雪花模型/宽表模型
导入
Broker Load
HDFS或所有支持S3协议的对
象存储
象存储
Stream Load
通过 HTTP 协议导入本地文
件或数据流中的数据
件或数据流中的数据
Routine Load
生成例行作业,直接订阅
Kafka消息队列中的数据
Kafka消息队列中的数据
Binlog Load *
增量同步用户在Mysql数据库
的对数据更新操作的CDC
的对数据更新操作的CDC
Flink Connector
在Flink中注册数据源,实现
对Doris数据的读写
对Doris数据的读写
Spark Load
通过外部的 Spark 资源实现
对导入数据的预处理
对导入数据的预处理
Insert Into
库内数据ETL转换或ODBC外
表数据导入
表数据导入
事务
多版本机制解决读写冲突
写入带版本、查询带版本
两阶段导入保证多表原子生效
支持并行导入
有冲突时按导入顺序生效,无冲突导入时并行生效
标准sql
Adhoc
单表聚合、排序、过滤
多表关联、子查询
复杂SQL、窗口函数、GroupingSet等高级语法
UDF、UDAF
高并发
通过分区分桶裁剪,减少查询对系统资源消耗
支持SQL/PartitionCache,降低重复查询对资源的消耗
子主题
资源隔离
同时支持节点和查询级别的资源划分
一套集群同时支持在线离线查询,解决资源抢占问题
多用户对集群资源更合理的划分
大数据生态
doris on es
ES中的多index分布式Join查询
Doris和ES联邦分析,更复杂的全文检索过滤
列式扫描/local优先/响应内容过滤
顺序扫描/提前终止
多源数据加载:HDFS、Kafka、本地数据
联邦数据查询:Spark
多源数据访问:ES、MySQL、HDFS
通用协议输出:JDBC、ANSISQL
性能保障
性能测试
基于标准SSB测试数据集
整体表现优异,基本1秒内返回结果
Doris在大数据量下的效果
10TB数据量下整体表现优异,1秒内返回结果
子主题
10TB数据量下整体表现优异,1秒内返回结果
子主题
Doris与Hive、Greenplum的对比
采用SSB数据集、120GB数据量,lineorder12亿条数据
同等环境配置下,所有查询均优于Hive和Greenplum
执行时间约为Hive的1/30、Greenplum的1/3~1/4
同等环境配置下,所有查询均优于Hive和Greenplum
执行时间约为Hive的1/30、Greenplum的1/3~1/4
性能保障:强一致的物化视图
选取任意维度对指标进行投影或上卷
即能对原始明细数据进行任意维度分析,也能快速对固定维度进行分析查询
物化视图自动更新,保证原始表和物化视图表的数据强一致性
根据用户查询的语句,自动选择最优的物化视图完成查询
即能对原始明细数据进行任意维度分析,也能快速对固定维度进行分析查询
物化视图自动更新,保证原始表和物化视图表的数据强一致性
根据用户查询的语句,自动选择最优的物化视图完成查询
SELECT date, SUM(pv) GROUP BY date ------ View 1
SELECT id, SUM(pv) GROUP BY id ------ View 2
SELECT id, SUM(pv) WHERE prov = “Beijing” GROUP BY id -------- Base
SELECT id, SUM(pv) GROUP BY id ------ View 2
SELECT id, SUM(pv) WHERE prov = “Beijing” GROUP BY id -------- Base
性能保障:两层分区与分级存储
两层分区
Partition 分区支持按Range和List的划分,Bucket 分桶将数据通过Hash进行水平划分,数据分片Tablet均匀在集群中打散。
以时间为维度进行分区,查询最新数据时可减少大量历史数据不必要的数据合并,节省了大量的IO和CPU开销
方便新旧数据分离,使用不同的存储介质(新数据SSD,历史数据HDD)
以时间为维度进行分区,查询最新数据时可减少大量历史数据不必要的数据合并,节省了大量的IO和CPU开销
方便新旧数据分离,使用不同的存储介质(新数据SSD,历史数据HDD)
分级存储
用户可以指定数据放到SSD上或者HDD盘上,也支持根据TTL将冷数据从SSD迁移到HDD上,高效利用SSD提高查询性能
示例
用户行为分析
统计报表
流量分析
来源分析
访问分析
访客分析
转化分析
优化分析
多维分析
用户洞察
留存分析
漏斗分析
留存分析
用户理解
电商
搜索上层应用业务对实时数据的需求
搜索整体数据的实时分析
AB实验效果的实时监控
热搜词的Top榜单以反映舆情的变化
所有数据需求都需要进行深度的下钻,维度细化需要到SKU粒度,同时还需要为下游用户输出不同层次的实时流数据
数据延迟在分钟级,查询响应时间在秒级
标准SQL交互引擎,降低使用成本
支持join操作,方便维度增加属性信息
流量数据可以近似去重,但订单行要精准去重
高吞吐,每分钟数据量在千万级记录,每天数百亿条新增记录
前端业务较多,查询并发度不能太低
使用最新维度对历史数据进行回溯计算,数据爆炸
历史数据每日刷新,以最新维度对历史数据进行回溯,失去了增量的意义。
每日回溯历史数据量大,10亿+的历史数据回溯。
数据计算耗时3小时+,存储1TB+,消耗大量计算存储资源,同时严重影响SLA的稳定性。
预计算的大量历史数据实际使用率低下,实际工作中对历史的回溯80%集中在近1个月左右,但为了应对所有需求场景,业务要求计算近半年以上的历史。
不支持明细数据的查询。
引入ROLAP
ROLAP
选型
0 条评论
下一页