目录
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 默认端口
Apache Doris 由百度大数据部研发(之前叫百度 Palo,2018 年贡献到 Apache 社区后, 更名为 Doris ),在百度内部,有超过 200 个产品线在使用,部署机器超过 1000 台,单一 业务最大可达到上百 TB。
Apache Doris 是一个现代化的 MPP(Massively Parallel Processing,即大规模并行处理)
分析型(OLAP)数据库产品。仅需亚秒级(一秒钟的十亿分之一)响应时间即可获得查询结果,有效地支持实时数据分析。
大规模并行处理:存储的数据量大、计算的数据量也很大。
Apache Doris 的分布式架构非常简洁,易于运维,并且可以支持 10PB 以上的超大数据集。
Apache Doris 可以满足多种数据分析需求,例如固定历史报表,实时数据分析,交互式数据分析和探索式数据分析等。
OLAP(联机分析处理)和OLTP(联机事务处理)是两种不同类型的数据库处理系统,它们存在的意义主要在于满足不同的业务需求和数据处理目标。
公司业务系统使用数据库的场景,针对业务系统数据库有大量随机的增删改查
高并发
速度要快
支持事务
在淘宝的网站上,OLTP系统用于处理用户的交易,包括浏览商品、下单、付款等。每个用户的交互都会影响数据库中的实时数据,例如库存数量、订单状态等。这确保了淘宝平台能够在高并发环境下迅速处理大量的交易请求。
公司的数据分析使用数据库的场景,对已经生成好的数据进行统计分析
一次操作都是针对的整个数据集
只有查这个动作,不会去增删改
查询的响应速度相对慢点也能接受
并发量要求不是太高
淘宝也需要使用OLAP系统来进行分析,以了解用户购物习惯、热门商品趋势、销售季节性等信息。通过OLAP,淘宝可以生成各种报告和可视化图表,帮助业务决策者更好地了解市场动态,并采取适当的策略,例如优化推荐算法、调整营销策略等。 OLAP还可以用于监测业务的整体健康状况,发现潜在的问题并及时采取行动。
OLTP |
OLAP |
|
数据源 |
仅包含当前运行日常业务数据 |
整合来自多个来源的数据,包括OLTP和外部来源 |
目的 |
面向应用,面向业务,支撑事务 |
面向主题,面向分析,支持分析决策 |
焦点 |
当下 |
主要面向过去,面向历史(实时数仓除外) |
任务 |
增删改查 |
主要是用于读,select查询,写操作很少 |
响应时间 |
毫秒 |
秒,分钟,小时,天,这些取决于数据量和查询的复杂程度 |
数据量 |
小数据,MB,GB |
大数据,TP,PB |
开源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 |
报表分析
实时看板 (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 中的数据,在避免数据拷贝的前提下,查询性能大幅提升
Doris 的架构很简洁,只设 FE(Frontend)前端进程、BE(Backend)后端进程两种角色、两个后台的服务进程,不依赖于外部组件,方便部署和运维,FE、BE 都可在线性扩展。
存储、维护集群元数据;负责接收、解析查询请求,规划查询计划,调度查询执行,返回查询结果。主要有三个角色:
Leader 和 Follower:主要是用来达到元数据的高可用,保证单节点宕机的情况下,元数据能够实时地在线恢复,而不影响整个服务。
注意点:follower的存活数量要超过半数才能正常执行。
Leader: ①生成sql的执行计划 ②修改,写入元数据 ③备份元数据
follower: ①生成sql的执行计划 ② 备份元数据 ③leader挂了以后,竞选leader
Observer:用来扩展查询节点,同时起到元数据备份的作用。如果在发现集群压力非常大的情况下,需要去扩展整个查询的能力,那么可以加 observer 的节点。observer 不参与任何的写入,只参与读取。
observer: ①生成sql的执行计划 ②备份元数据
负责物理数据的存储和计算;依据 FE 生成的物理计划,分布式地执行查询。数据的可靠性由 BE 保证,BE 会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。
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
一个独立的无状态进程。封装了文件系统接口,提供 Doris 读取远端存储系统中文件的能力,包括 HDFS,S3,BOS 等。
实例名称 |
端口名称 |
默认端口 |
通讯方向 |
说明 |
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之间的通信的端口 |