Doris数据仓库介绍

目录

一、Doris简介

二、Doris的定位

三、产品定位

四、Doris的整体架构

五、Doris的数据分布

 六、Doris的关键性技术

6.1 数据可靠性

6.2 易于维护

6.3ROLLUP表

七、 Doris的数据模型

7.1 aggregate聚合模型

7.2 uniqu key模型

7.3 duplicate key模型

7.4  数据模型的选择建议

八、数据组织(存储原则)--按列存储

九、索引:

9.1 前缀索引:

9.2 智能索引

十、mysql数据导入doris

一、Doris简介

Doris(原百度 Palo)是一款 基于大规模并行处理技术的分布式 SQL 数据库。/基于 MPP 的交互式SQL数据仓库,可用于 OLAP 。MPP 是将任务并行的分散到多个服务器和节点上,在每个节点上计算完成后,将各自部分的结果汇总在一起得到最终的结果

二、Doris的定位
MPP 架构的关系型分析数据库
PB 级别大数据集,秒级/毫秒级查询
主要用于多维分析和报表查询
三、产品定位


四、Doris的整体架构


Doris的架构只设FE(Frontend)、BE(Backend)两种角色、两个进程,不依赖于外部组件,方便部署和运维。 

以数据存储的角度观之,FE存储、维护集群元数据;BE存储物理数据。
以查询处理的角度观之, FE节点接收、解析查询请求,规划查询计划,调度查询执行,返回查询结果;BE节点依据FE生成的物理计划,分布式地执行查询。
FE主要有有三个角色,一个是leader,一个是follower,还有一个observer。leader跟follower,主要是用来达到元数据的高可用,保证单节点宕机的情况下,元数据能够实时地在线恢复,而不影响整个服务。右边observer只是用来扩展查询节点,就是说如果在发现集群压力非常大的情况下,需要去扩展整个查询的能力,那么可以加observer的节点。observer不参与任何的写入,只参与读取。

数据的可靠性由BE保证,BE会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。

五、Doris的数据分布
        如果从表的角度来看数据结构,用户的一张 Table 会拆成多个 Tablet,Tablet 会存成多副本,存储在不同的 BE 中,从而保证数据的高可用和高可靠。

 六、Doris的关键性技术
6.1 数据可靠性
        元数据使用 Memory+Checkpoint+Journal ( 分别是什么?),使用 BTBJE ( 类似于 Raft ) 协议实现高可用性和高可靠性。元数据的每次更新,都首先写入到磁盘的日志文件中,然后再写到内存中,最后定期checkpoint到本地磁盘上。一般只有三个FE就可以保证高可靠性。

        Doris 内部自行管理数据的多副本和自动修复。保证数据的高可用、高可靠。在服务器宕机的情况下,服务依然可用,数据也不会丢失。

        总结:FE用一致性协议保证高可用,BE采用多副本保证高可用。

6.2 易于维护
        它不依赖于Hadoop,也不依赖其他的外部组件,只有FE跟BE两个进程,数据都是自成一体的,所以可以很方便地部署启动。

6.3ROLLUP表
解释:

         在Doris中,我们将用户通过建表语句创建出来的表称为base表(base table)。base表中保存中按用户建表语句指定的方式存储的基础数据。
        在base表之上,我们可以创建任意多个rollup表。这些rollup的数据是基于base表产生的,并且在物理存储是独立存储的。rollup表的基本作用,在于base表的基础上,获得更粗粒度的聚合数据。

作用:

        ROLLUP 最根本的作用是提高某些查询的查询效率(无论是通过在base表的基础上进一步建立rolllup表进一步聚合来减少数据量,还是修改列顺序以匹配前缀索引)。

例子:

select date, sum(nums) from a group by date;  -->.  38s

alter table a add rollup rollup 5(date, nums);--> 该rollup表只保留了每个date在nums上的sum数。

select date, sum(nums) from a group by date;(自动命中rollup5)。  0.2ms

七、 Doris的数据模型
7.1 aggregate聚合模型
维度列key: 没设置aggregationtype

指标列value:设置了aggregationtype

当我们导入数据的时候,对于key列相同的行会聚合成一行,而value列会按照设置的aggregationtype进行聚合。aggregationtype目前有一下四种聚合方式:

sum:求和,多列的value值进行累加;
Max:保留最大值
Min:保留最小值
Replace:替代,下一批数据中的value会替换之前导入过的行中的value。在同一个批次中的数据,对于replace这种聚合方式,替换顺序不做保证。
优点:我们会按维度列去聚合数据,如果维度列数据相同我们会把这些数据合并(compaction)起来。也就相当于在数据库里面存储的其实是一个合并之后的结果,这个结果对于统计分析来说是很有效果的。因为广告报表只关心这种统计之后的数据,现在我们把大量的数据聚合,比如一天的数据可能有一千条,我们聚合成一条,相当于整个的I/O节省一千倍,效果非常明显。

缺点:有些业务场景分析的时候,是需要明细数据的,它不太关心统计的结果,而是更关心流程分析,更关心的是我要拿着历史的全量数据跟现在的数据做对比。

7.2 uniqu key模型
        我们提供一个唯一Key模型,在整个历史数据导入的时候,我们保证Key的唯一,不聚合。

        Unique Key的模型主要面向留存分析或者订单分析的场景,他们需要一个Unique Key的约束去保证整个数据不丢不重。

7.3 duplicate key模型
        数据完全按照导入文件中的数据进行存储,不会有任何聚合。即使两行数据完全相同,也都会保留。 而在建表语句中指定的 DUPLICATE KEY,只是用来指明底层数据按照那些列进行排序。

        数据可能重复,对于有些日志分析它不太在意数据多几条或者少几条,可能只关心排序,这个时候可能重复Key的模型会更加有效果。/这种数据模型适用于既没有聚合需求,又没有主键唯一性约束的原始数据的存储。

7.4  数据模型的选择建议
        
因为数据模型在建表时就已经确定,且无法修改。所以,选择一个合适的数据模型非常重要。

Aggregate 模型可以通过预聚合,极大地降低聚合查询时所需扫描的数据量和查询的计算量,非常适合有固定模式的报表类查询场景。但是该模型对 count(*) 查询很不友好。同时因为固定了 Value 列上的聚合方式,在进行其他类型的聚合查询时,需要考虑语意正确性。

Uniq 模型针对需要唯一主键约束的场景,可以保证主键唯一性约束。但是无法利用 ROLLUP 等预聚合带来的查询优势(因为本质是 REPLACE,没有 SUM 这种聚合方式,rollup只是用来调准列顺序命中前缀索引)。

Duplicate 适合任意维度的 Ad-hoc 查询。虽然同样无法利用预聚合的特性,但是不受聚合模型的约束,可以发挥列存模型的优势(只读取相关列,而不需要读取所有 Key 列)
 

八、数据组织(存储原则)--按列存储
好处:对分析的场景来说,多数时候用户只关心几列的数据,这个时候如果用一个列存的话,它可以只访问查询涉及的列,大量降低I/O,达到一个比较好的一个I/O的效果。

1、Doris 的数据是按列存储的,每一列单独存放。

2、查询时,只访问查询涉及的列,大量降低 I/O。

3、按列存储,数据类型一致,方便压缩。

4、数据包建索引,数据即索引。

5、利用原始过滤条件以及 min、max 和 sum 等智能索引技术,将数据集查询范围尽可能地缩小,大大减少 I/O,提升查询效率。

九、索引:
9.1 前缀索引:
        不同于传统的数据库设计,Doris不支持在任意列上创建索引。Doris这类mpp架构的olap数据库,通常都是通过提高高并发,来处理大量数据的。

        本质上,Doris的数据存储在类似sstable的数据结构中,该结构是一种有序的数据结构,可以按照指定的列进行排序存储。在这种结构上,以排序列作为条件进行查找,会非常高效。而前缀索引,即在排序的基础上,实现的一种根据给定前缀列,快速查询数据的索引方式。我们将一行数据的前36个字节作为这行数据的前缀索引。       前缀索引遇到varchar类型数据失效。

9.2 智能索引
Doris存储引擎对于排序列,会存储min/max/sum等智能索引技术,将数据集扫描范围尽可能地缩小,减少磁盘I/O,提升查询性能。比如说这一列排过序了,然后我在这一列的十万行所组成的一个粒度上面,给它加一个min/max,然后这样查询的时候,它就可以快速去过滤这个十万行,这会大大地减少整个数据的扫描量,从而减少I/O。

十、doris数据导入hive
方式一:封装spark程序

def mysqToDoris(session:SparkSession, url:String, user:String,
                password:String, tableName:String):DateFrame = {
 
        val temMap = new Properties()
        temMap.setProperty("user", user)
        temMap.setProperty("password", password)
        val frame: DateFrame = session.read.jdbc(url,tableName,temMap) //官方API
        frame
}
下一步,在开发代码里直接调用该方法:

mysqlToDoris(session, url, user, password, "test").createOrReplaceTempView("doris_test")

insert overwrite table 表名 select * from doris_test

;

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
目录 译者序 审、译者简介 前言 第1章 决策支持系统的发展 1 1.1 演化 1 1.2 直接存取存储设备的产生 2 1.3 个人计算机/第四代编程语言技术 3 1.4 进入抽取程序 3 1.5 蜘蛛网 4 1.6 自然演化体系结构的问题 5 1.6.1 数据缺乏可信性 5 1.6.2 生产率问题 8 1.6.3 从数据到信息 10 1.6.4 方法的变迁 11 1.7 体系结构设计环境 12 1.7.1 体系结构设计环境的层次 13 1.7.2 集成 14 1.8 用户是谁 15 1.9 开发生命周期 15 1.10 硬件利用模式 16 1.11 建立重建工程的舞台 16 1.12 监控数据仓库环境 17 1.13 小结 19 第2章 数据仓库环境 20 2.1 数据仓库的结构 22 2.2 面向主题 23 2.3 第1天到第n天的现象 26 2.4 粒度 28 2.4.1 粒度的一个例子 29 2.4.2 粒度的双重级别 31 2.5 分割问题 34 2.6 样本数据库 34 2.7 数据分割 35 2.8 数据仓库中的数据组织 37 2.9 数据仓库—标准手册 41 2.10 审计和数据仓库 41 2.11 成本合理性 41 2.12 清理仓库数据 42 2.13 报表和体系结构设计环境 42 2.14 机遇性的操作型窗口 43 2.15 小结 44 第3章 设计数据仓库 45 3.1 从操作型数据开始 45 3.2 数据/过程模型和体系结构设计环境 49 3.3 数据仓库和数据模型 50 3.3.1 数据模型 52 3.3.2 中间层数据模型 54 3.3.3 物理数据模型 58 3.4 数据模型和反复开发 59 3.5 规范化/反规范化 60 3.6 数据仓库中的快照 65 3.7 元数据 66 3.8 数据仓库中的管理参照表 66 3.9 数据周期 67 3.10 转换和集成的复杂性 70 3.11 触发数据仓库记录 71 3.11.1 事件 72 3.11.2 快照的构成 72 3.11.3 一些例子 72 3.12 简要记录 73 3.13 管理大量数据 74 3.14 创建多个简要记录 75 3.15 从数据仓库环境到操作型环境 75 3.16 正常处理 75 3.17 数据仓库数据的直接访问 76 3.18 数据仓库数据的间接访问 76 3.18.1 航空公司的佣金计算系统 76 3.18.2 零售个性化系统 78 3.18.3 信用审核 80 3.19 数据仓库数据的间接利用 82 3.20 星型连接 83 3.21 小结 86 第4章 数据仓库中的粒度 87 4.1 粗略估算 87 4.2 粒度划分过程的输入 88 4.3 双重或单一的粒度? 88 4.4 确定粒度的级别 89 4.5 一些反馈循环技巧 90 4.6 粒度的级别—以银行环境为例 90 4.7 小结 95 第5章 数据仓库和技术 96 5.1 管理大量数据 96 5.2 管理多介质 97 5.3 索引/监视数据 97 5.4 多种技术的接口 97 5.5 程序员/设计者对数据存放位置的控制 98 5.6 数据的并行存储/管理 99 5.7 元数据管理 99 5.8 语言接口 99 5.9 数据的高效装入 99 5.10 高效索引的利用 100 5.11 数据压缩 101 5.12 复合键码 101 5.13 变长数据 101 5.14 加锁管理 102 5.15 单独索引处理 102 5.16 快速恢复 102 5.17 其他的技术特征 102 5.18 DBMS类型和数据仓库 102 5.19 改变DBMS技术 104 5.20 多维DBMS和数据仓库 104 5.21 双重粒度级 109 5.22 数据仓库环境中的元数据 109 5.23 上下文和内容 111 5.24 上下文信息的三种类型 111 5.25 捕获和管理上下文信息 113 5.26 刷新数据仓库 113 5.27 小结 114 第6章 分布式数据仓库 116 6.1 引言 116 6.2 局部数据仓库 118 6.3 全局数据仓库 119 6.4 互斥数据 121 6.5 冗余 123 6.6 全局数据存取 124 6.7 分布式环境下其他考虑因素 126 6.8 管理多个开发项目 127 6.9 开发项目的性质 127 6.10 分布式数据仓库 130 6.10.1 在分布的地理位置间协调开发 131 6.10.2 企业数据分布式模型 132 6.10.3 分布式数据仓库中的元数据 134 6.11 在多种层次上建造数据仓库 134 6.12 多个小组建立当前细节级 136 6.12.1 不同层不同需求 138 6.12.2 其他类型的细节数据 140 6.12.3 元数据 142 6.13 公用细节数据采用多种平台 142 6.14 小结 143 第7章 高级管理人员信息系统 和数据仓库 144 7.1 一个简单例子 144 7.2 向下探察分析 146 7.3 支持向下探察处理 147 7.4 作为EIS基础的数据仓库 149 7.5 到哪里取数据 149 7.6 事件映射 152 7.7 细节数据和EIS 153 7.8 在EIS中只保存汇总数据 154 7.9 小结 154 第8章 外部数据/非结构化数据与 数据仓库 155 8.1 数据仓库中的外部数据/非结构化数据 157 8.2 元数据和外部数据 158 8.3 存储外部数据/非结构化数据 159 8.4 外部数据/非结构化数据的不同 组成部分 160 8.5 建模与外部数据/非结构化数据 160 8.6 间接报告 161 8.7 外部数据归档 161 8.8 内部数据与外部数据的比较 161 8.9 小结 162 第9章 迁移到体系结构设计环境 163 9.1 一种迁移方案 163 9.2 反馈循环 167 9.3 策略方面的考虑 168 9.4 方法和迁移 171 9.5 一种数据驱动的开发方法 171 9.6 数据驱动的方法 172 9.7 系统开发生命周期 172 9.8 一个哲学上的考虑 172 9.9 操作型开发/DSS开发 173 9.10 小结 173 第10章 数据仓库的设计复查要目 174 10.1 进行设计复查所涉及的问题 175 10.1.1 谁负责设计复查 175 10.1.2 有哪些议事日程 175 10.1.3 结果 175 10.1.4 复查管理 175 10.1.5 典型的数据仓库设计复查 176 10.2 小结 185 附录 186 技术词汇 215 参考文献 222

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值