我要评论目录
🥙联机事务处理oltp(on-line transaction processing)
🥙联机分析处理olap(on-line analytical processing)
🐶1.1 doris 概述
apache doris 由百度大数据部研发（之前叫百度 palo，2018 年贡献到 apache 社区后， 更名为 doris ），在百度内部，有超过 200 个产品线在使用，部署机器超过 1000 台，单一 业务最大可达到上百 tb。
apache doris 是一个现代化的 mpp（massively parallel processing，即大规模并行处理）
分析型（olap）数据库产品。仅需亚秒级（一秒钟的十亿分之一）响应时间即可获得查询结果，有效地支持实时数据分析。
apache doris 的分布式架构非常简洁，易于运维，并且可以支持 10pb 以上的超大数据集。
apache doris 可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等。
🐶1.2 olap和oltp（面试）
1. 应用场景
olap（联机分析处理）和oltp（联机事务处理）是两种不同类型的数据库处理系统，它们存在的意义主要在于满足不同的业务需求和数据处理目标。
🥙联机事务处理oltp(on-line transaction processing)
公司业务系统使用数据库的场景，针对业务系统数据库有大量随机的增删改查
-
高并发
-
速度要快
-
支持事务
🥙联机分析处理olap(on-line analytical processing)
-
公司的数据分析使用数据库的场景，对已经生成好的数据进行统计分析
-
一次操作都是针对的整个数据集
-
只有查这个动作，不会去增删改
-
查询的响应速度相对慢点也能接受
-
并发量要求不是太高
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：主要是用来达到元数据的高可用，保证单节点宕机的情况下,元数据能够实时地在线恢复，而不影响整个服务。
-
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 -hhadoop014. 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之间的通信的端口 |
发表评论