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