目录
🐶1.1 Doris 概述
🐶1.2 OLAP和OLTP(面试)
1. 应用场景
🥙联机事务处理OLTP(On-Line Transaction Processing)
🥙联机分析处理OLAP(On-Line Analytical Processing)
2. OLAP和OLTP比较--“用户行为日志数据”
3. 常见的开源OLAP引擎
🐶1.3 使用场景
🐶1.4 优势
🐶1.5 架构
1.🥙FE(Frontend)
2. 🥙BE(Backend)
3. 🥙MySQL Client
4. Broker:
🐶1.6 默认端口
🐶1.1 Doris 概述
Apache Doris 由百度大数据部研发(之前叫百度 Palo,2018 年贡献到 Apache 社区后, 更名为 Doris ),在百度内部,有超过 200 个产品线在使用,部署机器超过 1000 台,单一 业务最大可达到上百 TB。
Apache Doris 是一个现代化的 MPP(Massively Parallel Processing,即大规模并行处理)
分析型(OLAP)数据库产品。仅需亚秒级(一秒钟的十亿分之一)响应时间即可获得查询结果,有效地支持实时数据分析。
大规模并行处理:存储的数据量大、计算的数据量也很大。并发其实不是很高
面试题:
如果我把doris作为一个业务系统的数据库,合适吗?doris的并发跟不上,有办法解决吗?
解决方案:
doris作为一个olap场景下的数据库,你却非要把它作为oltp场景下的数据库,本身这样的出发点就是不对的。当然了,既然已经这样做了,问题既然产生了,那么必须要解决。可以通过增加FE和BE的机器来改善这一点,增加FE可以提高并行度,而增加BE可以降低查询的延迟。
Apache Doris 的分布式架构非常简洁,易于运维,并且可以支持 10PB 以上的超大数据集。
Apache Doris 可以满足多种数据分析需求,例如固定历史报表,实时数据分析,交互式数据分析和探索式数据分析等。
🐶1.2 OLAP和OLTP(面试)
1. 应用场景
OLAP(联机分析处理)和OLTP(联机事务处理)是两种不同类型的数据库处理系统,它们存在的意义主要在于满足不同的业务需求和数据处理目标。
🥙联机事务处理OLTP(On-Line Transaction Processing)
公司业务系统使用数据库的场景,针对业务系统数据库有大量随机的增删改查
-
高并发
-
速度要快
-
支持事务
在淘宝的网站上,OLTP系统用于处理用户的交易,包括浏览商品、下单、付款等。每个用户的交互都会影响数据库中的实时数据,例如库存数量、订单状态等。这确保了淘宝平台能够在高并发环境下迅速处理大量的交易请求。
🥙联机分析处理OLAP(On-Line Analytical Processing)
-
公司的数据分析使用数据库的场景,对已经生成好的数据进行统计分析
-
一次操作都是针对的整个数据集
-
只有查这个动作,不会去增删改
-
查询的响应速度相对慢点也能接受
-
并发量要求不是太高
淘宝也需要使用OLAP系统来进行分析,以了解用户购物习惯、热门商品趋势、销售季节性等信息。通过OLAP,淘宝可以生成各种报告和可视化图表,帮助业务决策者更好地了解市场动态,并采取适当的策略,例如优化推荐算法、调整营销策略等。 OLAP还可以用于监测业务的整体健康状况,发现潜在的问题并及时采取行动。
2. OLAP和OLTP比较--“用户行为日志数据”
OLTP | OLAP | |
数据源 | 仅包含当前运行日常业务数据 | 整合来自多个来源的数据,包括OLTP和外部来源 |
目的 | 面向应用,面向业务,支撑事务 | 面向主题,面向分析,支持分析决策 |
焦点 | 当下 | 主要面向过去,面向历史(实时数仓除外) |
任务 | 增删改查 | 主要是用于读,select查询,写操作很少 |
响应时间 | 毫秒 | 秒,分钟,小时,天,这些取决于数据量和查询的复杂程度 |
数据量 | 小数据,MB,GB | 大数据,TP,PB |
3. 常见的开源OLAP引擎
开源OLAP引擎 | 优点 | 缺点 | 技术融合成本 | 易用性 | 使用场景 | 运维成本 | 引擎类型 |
ClickHouse | 列式存储 单极性彪悍 保留明细数据 | 分布式集群在线扩展支持不佳 运维成本极高 | 高 | 非标协议接口 | 全面 | 高 | 纯列存OLAP |
Druid | 实时数据摄入 列式存储和位图索引 多租户和高并发 | OLAP性能分场景表现差异大 使用门槛高 仅支持聚合查询 | 高 | 非标协议接口 | 局限 | 高 | MOLAP |
TiDB | HTAP混合数据库 同时支持明细和聚合查询 高度兼容mysql | 非列式存储 OLAP能力不足 | 低 | SQL标准 | 全面 | 低 | 纯列存OLAP |
Kylin | 与计算引擎,可以对数据一次聚合多次查询 支持数据规模超大 易用性强,支持标准sql 性能强,查询数据快 | 需要依赖hadoop生态 仅支持聚合查·询 不支持adhoc查询 不支持join和对数据的更新 | 高 | SQL标准 | 局限 | 高 | MOLAP |
Doris | GooleMesa+Apache Impa+ORCFile/Parquet 主键更新 支持Rollup Table 高并发和高通图的Ad-hoc查询 支持聚合+明细数据查询 无外部系统依赖 | 成熟度不够 | 低 | 兼容mysql访问协议 | 全面 | 低 | HOLAP |
🐶1.3 使用场景
-
报表分析
-
实时看板 (Dashboards)
-
面向企业内部分析师和管理者的报表
-
面向用户或者客户的高并发报表分析(Customer Facing Analytics)。比如面向网站主的站点分析、面向广告主的广告报表,并发通常要求成千上万的 QPS ,查询延时要求毫秒级响应。著名的电商公司京东在广告报表中使用 Apache Doris ,每天写入 100 亿行数据,查询并发 QPS 上万,99 分位的查询延时 150ms。
-
-
即席查询(Ad-hoc Query):面向分析师的自助分析,查询模式不固定,要求较高的吞吐。小米公司基于 Doris 构建了增长分析平台(Growing Analytics,GA),利用用户行为数据对业务进行增长分析,平均查询延时 10s,95 分位的查询延时 30s 以内,每天的 SQL 查询量为数万条。
-
统一数仓构建 :一个平台满足统一的数据仓库建设需求,简化繁琐的大数据软件栈。海底捞基于 Doris 构建的统一数仓,替换了原来由 Spark、Hive、Hbase、Phoenix 组成的旧架构,架构大大简化。
-
数据湖联邦查询:通过外表的方式联邦分析位于 Hive、Hudi 中的数据,在避免数据拷贝的前提下,查询性能大幅提升
🐶1.4 优势
🐶1.5 架构
Doris 的架构很简洁,只设 FE(Frontend)前端进程、BE(Backend)后端进程两种角色、两个后台的服务进程,不依赖于外部组件,方便部署和运维,FE、BE 都可在线性扩展。
1.🥙FE(Frontend)
存储、维护集群元数据;负责接收、解析查询请求,规划查询计划,调度查询执行,返回查询结果。主要有三个角色:
-
Leader 和 Follower:主要是用来达到元数据的高可用,保证单节点宕机的情况下,元数据能够实时地在线恢复,而不影响整个服务。
注意点:follower的存活数量要超过半数才能正常执行。
-
Leader: ①生成sql的执行计划 ②修改,写入元数据 ③备份元数据
-
follower: ①生成sql的执行计划 ② 备份元数据 ③leader挂了以后,竞选leader
-
-
Observer:用来扩展查询节点,同时起到元数据备份的作用。如果在发现集群压力非常大的情况下,需要去扩展整个查询的能力,那么可以加 observer 的节点。observer 不参与任何的写入,只参与读取。
-
observer: ①生成sql的执行计划 ②备份元数据
-
2. 🥙BE(Backend)
负责物理数据的存储和计算;依据 FE 生成的物理计划,分布式地执行查询。数据的可靠性由 BE 保证,BE 会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。
3. 🥙MySQL Client
Doris 借助 MySQL 协议,用户使用任意 MySQL 的 ODBC/JDBC 以及 MySQL 的客户端,都可以直接访问 Doris。
mysql -uroot -p -P9030 -hhadoop01
Mysql 本地主机名:localhost 端口号:3306
Mysql linux本地主机名或IP地址:hadoop01 hadoop02 hadoop03 192.168.252.101/192.168.252.102/192.168.252.103
4. Broker:
一个独立的无状态进程。封装了文件系统接口,提供 Doris 读取远端存储系统中文件的能力,包括 HDFS,S3,BOS 等。
🐶1.6 默认端口
实例名称 | 端口名称 | 默认端口 | 通讯方向 | 说明 |
BE | be_port | 9060 | FE-->BE | BE 上 thrift server 的端口,用于接收来自 FE 的请求 |
BE | webserver_port | 8040 | BE<-->FE | BE 上的 http server 端口 |
BE | heartbeat_service_port | 9050 | FE-->BE | BE 上心跳服务端口,用于接收来自 FE 的心跳 |
BE | brpc_prot* | 8060 | FE<-->BE,BE<-->BE | BE 上的 brpc 端口,用于 BE 之间通信 |
FE | http_port | 8030 | FE<-->FE ,用户<--> FE | FE 上的 http_server 端口 |
FE | rpc_port | 9020 | BE-->FE ,FE<-->FE | FE 上 thirft server 端口 |
FE | query_port | 9030 | 用户<--> FE | FE 上的 mysql server 端口 |
FE | edit_log_port | 9010 | FE<-->FE | FE 上 bdbje 之间通信用的端口 |
Broker | broker_ipc_port | 8000 | FE-->BROKER,BE-->BROKER | Broker 上的 thrift server,用于接收请求 |
常用端口号
端口号 | 作用 |
8030 | FE的Web UI端口 |
8040 | BE的Web UI端口 |
9030 | MYSQL客户端连接Doris的端口 |
9050 | BE上心跳服务端口,用于接收来自FE的心跳 |
9010 | FE之间的通信的端口 |