Mini项目课程前置学习笔记（第一轮）
时间：5.20 ~ 5.23
项目基本介绍
项目 B. 指标监控服务重构
指标的收集与展示是后台系统监控中非常重要的一环，很可惜大而全的全链路监控方案并不适合我们，于是就有了本 mini 项目。本项目需要完成 go 语言的后台 SDK 开发、指标收集服务开发，并在我们提供的样例后台服务中使用 SDK 完成指定的 SRE 上报，并在 grafana 中配置相应的监控报表。挑战性在于保证资源消耗尽可能低的同时尽量提高查询性能，需要对比、验证在两种 otel-collector 下不同 clickhouse 数据表架构及不同索引下的性能差异。
-
目的：指标的收集与展示 是后台系统监控中非常重要的一环，很可惜大而全的全链路监控方案并不适合我们，于是就有了本 mini 项目。本项目需要完成
clickhouse 的 schema 设计和调优、go 语言的后台 SDK 开发、指标收集服务开发，并在我们提供的样例后台服务中使用 SDK 完成指定的 SRE 上报，并在grafana 中配置相应的监控报表。挑战性在于保证资源消耗尽可能低的同时尽量提高查询性能，需要对比、验证不同数据表架构、索引的设计实现。 -
负责人：oliverdding 助手：kevineluo
-
意义：
- 对于实习生的意义：go 后台编程、clickhouse 数据库使用、clickhouse 性能调优、grafana 使用、SRE 概念与落地实现
- 对于公司的意义：抛弃 PostgreSQL 服务，升级监控模块，降低交付成本
-
用户群体（画像）：
- 职位：测试、研发、区技
- 职级: 工程师
-
使用具体场景：
- 日常 SRE 报表
- 服务监控
-
先导知识与先导知识的学习方式，素材
-
博客/网页
-
SRE：简单了解
- SLI
- SLO
- SLA
-
ClickHouse：主要打交道的 OLAP 数据库
-
Altinity Knowledge Base：极其有用的 ClickHouse 运维、调优相关文档
-
-
推荐书本
- The Site Reliability Workbook：SRE 书籍，用到再翻
-
推荐开源项目
- uptrace：全链路监控方案，可以参考表实现、SDK 实现和表结构
- open telementry metrics：参考指标类型
-
基础项目介绍
- 架构设计文档：
- 功能介绍文档：
- 代码目录文档：
- 数据流文档：
- 宣传文档：
-
-
组织要求：参与人数与角色
- 总体人数：5~7
-
角色：1~2 SDK 测开；3～4 后台测开；1 组长；
理解项目需求和技术栈
SRE
SRE is what you get when you treat operations as if it's a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google's public services --- Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few --- with an ever-watchful eye on their availability, latency, performance, and capacity.
当您将操作视为软件问题时，您会得到 SRE。我们的使命是保护、提供和改进支持所有 Google 公共服务（Google 搜索、广告、Gmail、Android、YouTube 和 App Engine 等）的软件和系统，并时刻关注它们的可用性、延迟、性能和容量。
chatgpt prompt
你作为一位有多年开发经验的高级软件开发兼架构工程师，可以给出SRE（Site Reliability Engineering）的概念和基本例子吗
当谈到网站可靠性工程时，SRE(Site Reliability Engineering) 是一个广泛使用的概念，它涵盖了确保网站高可用性、可扩展性和安全性的一系列技术和策略。
SRE 的核心目标是提高网站的可用性和性能，同时降低维护成本。为了实现这个目标，SRE 团队通常会执行以下任务:
- 监控网站的性能、可用性和安全性，并识别和解决潜在的问题。
- 实施和维护网站的基础架构，例如服务器、网络、存储和负载均衡器等。
- 确保网站的可扩展性，以便在需要时能够轻松增加或缩小服务器规模。
- 实施安全性措施，例如防火墙、访问控制和漏洞扫描等，以保护网站免受攻击。
- 优化网站的性能和可访问性，例如实施缓存、负载均衡和域名解析等。
一个简单的例子是，SRE 团队可能会创建一个监控脚本，以自动检测网站的性能问题。如果性能下降，该脚本将发送一封警报邮件给 SRE 团队，以便他们可以立即采取行动解决问题 。另一个例子是，SRE 团队可能会实施负载均衡器，以确保网站的最大可用性和性能，同时减少服务器的负载。负载均衡器可以将流量分配到多个服务器上，以确保每个服务器都得到公平的流量负载。
总之，SRE 是一个高度技术性的领域，它涉及了许多不同的技术和策略，以提高网站的可用性和性能。作为一名 SRE 工程师，需要具备扎实的技术技能、良好的项目管理能力和良好的沟通能力，才能成功地执行 SRE 任务。
继续介绍一下SLI、SLO、SLA的概念和例子
SLI、SLO、SLA 是三个与服务质量相关的术语，它们通常在 SRE 中用于监控和保证网站的可用性和性能。
- SLI (Service Level Agreement):服务级协议
SLI 是一种与服务质量相关的协议，它定义了客户端与服务器之间通信的标准。SLI 通常是以百分比的形式定义的，例如"99.99%"的可用性，表示在服务的整个生命周期中，服务器将只能处于忙碌状态 (即不可用) 的时间不能超过 0.01%。
为了达成 SLI,SRE 团队需要进行以下工作:
- 设计和实施服务器和网络基础设施，以确保它们能够满足 SLI。
- 监控网站的性能和行为，并识别任何可能影响 SLI 的问题。
- 确保网站的可靠性和可用性，例如实施负载均衡、缓存和容错技术等。
- SLO (Service Level Objective):服务级别目标
SLO 是与服务质量相关的目标，它们描述了网站在特定时间段内的性能表现。SLO 通常以秒或分钟为单位定义，例如"10ms"的响应时间，表示服务器必须在接收到客户端请求后的 10 毫秒内返回响应。
为了达成 SLO,SRE 团队需要进行以下工作:
- 设计和实施服务器和网络基础设施，以确保它们能够满足 SLO。
- 监控网站的性能和行为，并识别任何可能影响 SLO 的问题。
- 实施优化技术，例如缓存、负载均衡和请求拦截等，以缩短响应时间。
- SLA (Service Level Agreement):服务级别协议
SLA 是一种合同，它定义了客户端和服务器之间的服务标准。SLA 通常包括 SLI 和 SLO，并且通常由客户和服务提供商之间签订。
SLA 可以帮助服务提供商确保他们能够提供高质量的服务，同时也可以帮助客户评估服务提供商的可靠性和可用性。
例如，一个在线零售商可能会签订 SLA，以承诺在顾客付款后 24 小时内提供货物。SLA 还可以包括退款保证，承诺在顾客申请退款后 24 小时内将退款到达顾客账户。
可以横向对比一下SLI、SLO、SLA的特点和区别吗，以表格形式，只需要一个表格
好的，以下是一个表格展示:
| 术语 | SLI (Service Level Agreement) | SLO (Service Level Objective) | SLA (Service Level Agreement) |
|---|---|---|---|
| 特点 | 定义了客户端与服务器之间通信的标准，通常以百分比的形式定义，例如"99.99%"的可用性 | 描述了网站在特定时间段内的性能表现，通常以秒或分钟为单位定义，例如"10ms"的响应时间 | 一种合同，它定义了客户端和服务器之间的服务标准，通常包括 SLI 和 SLO，并且通常由客户和服务提供商之间签订 |
| 区别 | SLI 只定义了客户端与服务器之间的可用性，而 SLO 则定义了在特定时间段内的性能表现 | SLO 通常是以秒或分钟为单位定义的，而 SLI 通常是以百分比的形式定义的 | SLA 是客户和服务提供商之间签订的合同，通常包括 SLI 和 SLO |
Go
- 在线博客
- 官方文档
- chatgpt
ClickHouse
快速入门
1.在线文档
2.部署
sh
sudo docker run -d \
--name clickhouse-server \
--privileged=true \
--ulimit nofile=55122:262144 \
-p 55123:8123 \
-p 55124:9000 \
-p 55125:9009 \
yandex/clickhouse-server:latest
sudo docker cp clickhouse-server:/etc/clickhouse-server/config.xml /home/xzx/docker/clickhouse/config/config.xml
sudo docker cp clickhouse-server:/etc/clickhouse-server/users.xml /home/xzx/docker/clickhouse/config/users.xml
sudo docker rm -f clickhouse-server
# 修改配置文件，配置用户+密码
sudo docker run -d \
--name xzx-clickhouse-server \
--ulimit nofile=55122:262144 \
--privileged=true \
--restart=always \
-p 55123:8123 \
-p 55124:9000 \
-p 55125:9009 \
-v /home/xzx/docker/clickhouse/data:/var/lib/clickhouse:rw \
-v /home/xzx/docker/clickhouse/log:/var/log/clickhouse-server:rw \
-v /home/xzx/docker/clickhouse/config/config.xml:/etc/clickhouse-server/config.xml \
-v /home/xzx/docker/clickhouse/config/users.xml:/etc/clickhouse-server/users.xml \
yandex/clickhouse-server:latest3.可视化界面
下载Clickhouse的可视化界面DBM
使用GoLand连接Clickhouse
4.数据类型
- 整型
- 浮点型
- 布尔型
- Decimal型
- 字符串
- 枚举类型
- 时间类型
- 数组
5.表引擎
- TinyLog：磁盘保存，不支持索引，并发
- Memory：内存保存，不支持索引
- MergeTree：支持索引分区
- partition by 分区（可选）：加速检索，并行处理，合并
- primary key 主键（可选）：一级索引，不是唯一约束
- order by（必选）
- 二级索引
- 数据TTL：生命周期
- ReplacingMergeTree：分区内去重，自动合并，保留最新记录
- SummingMergeTree：聚合
6.SQL操作
-
Insert
-
Update 和 Delete：Mutation查询
Mutation每次修改或者删除都会导致放弃目标数据的原有分区，重新构建新分区。所以尽量做批量的变更，不要进行频繁小数据的操作。 -
查询操作与标准SQL差别不大
-
Alter，同MySQL的修改字段基本一致
-
导出数据
7.副本
8.分片集群
高级
1.Explain查看执行计划
- PLAIN：执行计划
- AST：语法树
- SYNTAX：语法优化
- PIPELINE
2.建表优化
-
数据类型
-
能用时间字段表示就不要用字符串，DateTime不需要经过函数转换处理，执行效率高，可读性好。
-
使用默认字段表示空，或者自行指定一个在业务中无意义的值
-
-
分区和索引
- 分区粒度不宜过粗或过细，一般选择按天分区
- 必须指定索引列（排序列-order by）,满足高级列在前、查询频率大的在前原则
-
表参数
-
写入和删除优化
- 尽量不要单条或小批量
- 不要一次写入太多分区，或数据写入太快
-
常见配置
- CPU资源
- 内存资源
- 存储
3.语法优化规则
基于RBO(Rule Based Optimization)
-
COUNT优化
-
消除子查询重复字段
-
谓词下推：having 过滤会下推到 where 提前过滤
-
聚合计算外推
-
聚合函数消除
-
删除重复的order by key
-
删除重复的limit by key
-
删除重复的using key
-
标量替换
-
三元运算优化
4.查询优化
- 单表查询
- Prewhere替换where
- 数据采样
- 列裁剪与分区裁剪
- orderby 结合 where、limit
- 避免构建虚拟列
- uniqCombined替换distinct
- 使用物化视图
- 其他注意事项
- 多表关联
- 用IN代替JOIN
- 大小表JOIN：小表在右
- 分布式表使用GLOBAL
- 使用字典表
- 提前过滤
5.数据一致性
6.物化视图
普通视图不保存数据，保存的仅仅是查询语句 ，查询的时候还是从原表读取数据，可以将普通视图理解为是个子查询。物化视图则是把查询的结果根据相应的引擎存入到了磁盘或内存中，对数据重新进行了组织，你可以理解物化视图是完全的一张新表。
监控与备份
Go客户端库的选择
Selecting a client library depends on your usage patterns and need for optimal performance. For insert heavy use cases, where millions of inserts are required per second, we recommend using the low level client ch-go. This client avoids the associated overhead of pivoting the data from a row-orientated format to columns, as the ClickHouse native format requires. Furthermore, it avoids any reflection or use of the
interface{}(any) type to simplify usage.选择客户端库取决于您的使用模式和最佳性能需求。对于每秒需要数百万次插入的大量插入用例，我们建议使用低级客户端 ch-go。该客户端避免了将数据从面向行的格式转换为列的相关开销，正如 ClickHouse 本机格式所要求的那样。此外，它避免了任何反射或使用接口{}（任何）类型以简化使用。
For query workloads focused on aggregations or lower throughput insert workloads, the clickhouse-go provides a familiar
database/sqlinterface and more straightforward row semantics. Users can also optionally use HTTP for the transport protocol and take advantage of helper functions to marshal rows to and from structs.对于专注于聚合或低吞吐量插入工作负载的查询工作负载，clickhouse-go 提供了熟悉的数据库/sql 接口和更直接的行语义。用户还可以选择使用 HTTP 作为传输协议，并利用辅助函数将行编组到结构和从结构中编组。
Ch-go
Grafana
