学习笔记
数据采集分为实时采集和离线采集：
- 实时采集：用户买点数据，流入实时链路进行计算
- 离线采集：业务订单数据，按照小时和天采集到大数据库存储桶以供使用
问题及解决方案案例：
- 云台查询 Doris 间歇性报错
- 原因定位：用户提交了大量的查询，且包含一些大查询，导致 fragment 的 rpc 处理线程池满
- 解决方案：加大缓存容量，增加缓存命中率；下调查询时间，增加大查询拦截能力
- 准实时场景下，5分钟调度任务多个任务执行超时
- 原因定位：业务方提交了其他任务存在严重乱序，导致集群的整体写入吞吐变得很慢，影响了准实时场景
- 解决方案：将 Doris 任务及导入参数进行了优化，加强了Doris变更规范管控与审批流程，并正在实现业务多租户的隔离
稳定性保障的目标
- 少出事：容量规划、自动化能力、查询拦截能力、业务隔离、用户权限管控
- 快发现：发现能力
- 快恢复：故障快恢复能力
发现能力
- 表级监控，主要是监控表容量和状态
- 任务监控，针对导数任务状态进行监控
- 组件监控，针对服务指标（如查询、导数）、进程和机器指标进行监控
容量规划
容量梳理：
- 当前场景是实时还是离线
- 数据写入速度、分区情况
- 查询、存储要求
容量监控：CPU、内存、磁盘、doris_be_add_batch_task_queue_size、doris_fe_query_latency_ms、doris_be_plan_fragment_count
高可用能力
服务高可用：主要依赖Doris自身的能力，引入负载均衡绑定后端，实现连接数的均衡，以及读写高可用
链路高可用：支持异常重试和电话告警，数据支持幂等操作
其他保障能力
- 业务拦截能力：设置用户级别拦截能力，根据实际数量级、查询规模设置拦截规则；快速对异常 query 进行 kill 的能力
- 故障快速回复能力：分区数据的快速恢复能力，tablet 状态恢复能力
- 业务隔离：根据业务重要程度、数据类型属于实时还是离线，进行集群隔离、多租户
- 用户权限管控：Doris 自带的 RBAC
Doris 使用规范
- 建表
- 分桶数建议值 16 或 32，单个 tablet 约 1 G：反例，分桶设置得太小，导致单个 tablet 过大，则会导致执行 compact 很慢，集群吞吐变差）
- 表模型（优先使用 Aggregate / Duplicate）；前缀索引（根据查询条件设置）；分区字段（设置合理的生命周期）
- 高频写入表建议放在单独的数据库，避免事务数过多影响到同库的其他表
- Flink 写入
- 切勿使用自己的 jar，要用 flinksql：反例，使用自己的 jar，一条数据一个写入事务，导致集群吞吐变慢
- 数据无乱序（保证只有单个分区的数据）：反例，数据存在大量乱序，任务每次写入都涉及几十个分区，导致集群吞吐变慢
- 单个 batch 的发送数据量建议 Batch size >= 100MB 或 timeout = 2 - 5 min，单表批次导入实例并发 <= 2
- insert 写入
- insert into 执行成功后，还需等待版本发布后，数据才可见
- 删除
- 避免频繁删除，导致 Compaction 压力大，影响写入和查询性能
- delete 执行，数据可见性是异步
- drop 语句后不用加 force，这样出现误删除可在一段时间内召回
- 修改
- 一张表同时间只能执行一个 alter：反例，执行修改列类型，会对数据做遍历，耗时久，这段时间再次执行则会报错
- 支持增删列、修改列，不支持修改列名
- 新增 / 删除数据前停写入任务，且等待 5 分钟后再执行，防止数据不一致
- 查询
- 严谨不带过滤条件查询全量数据，且建议加上 limit 兜底
- Doris 不适用高并发 QPS 场景
- Doris 兼容 MySQL 协议，业务查询时可带 traceId，方便排查问题