大数据 - Doris系列《一》- Doris简介

大规模并行处理：存储的数据量大、计算的数据量也很大。并发其实不是很高

面试题：

如果我把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之间的通信的端口