本页目录 使用方式 阶段一：SQL、查询计划与数据库边界 阶段二：数仓、列式存储与数据湖 阶段三：调度、CDC 与数据质量 阶段四：权限、成本与备份恢复 常见误区 参考链接 读完自测 相关条目 数据平台值班的难点不是“某个任务失败”，而是任务失败、数据延迟、口径变化、权限越界和成本失控会互相伪装。这条路径按数据从进入到被消费的生命周期组织：先会查数和读计划，再懂存储与数仓，然后管住调度和质量，最后处理权限、成本和恢复。
四个阶段建议按顺序推进，每个阶段都在一次性环境或只读数据上练习：
先读 ：读页面时盯住数据新鲜度、口径、资源消耗和失败后的可恢复性。再做 ：所有写操作都在测试库或临时目录完成；生产只做查询、只读核对和审批后的变更。后测 ：每个阶段留下一份可复核产物：查询报告、表设计说明、DAG 运行记录或权限成本清单。
数据平台的“正常”要同时满足三条：数据按时到、口径正确、成本可解释。只让任务变绿不算过关。
目标 ：能独立完成分析查询，读懂执行计划和资源消耗，判断慢在扫描、连接、排序、锁还是连接池，而不是看到慢就加索引或加机器。
阅读顺序 ：
duckdb — 用嵌入式分析库在本地验证 SQL 和文件格式。sqlite3 — 轻量数据库的查询、导入和元数据查看。psql-vs-mysql — PostgreSQL 与 MySQL 在语法、事务和类型上的差异。postgres-cheatsheet — PostgreSQL 常用 SQL、权限和运维命令。mysql-cheatsheet — MySQL 常用 SQL、执行计划和运维命令。pg_stat_statements — 按总耗时和调用次数找高消耗 SQL。proxysql — MySQL 连接池、读写分离和查询规则路由。trino — 跨数据源的分布式 SQL 查询与连接器边界。clickhouse-query-memory — 查询内存超限与大聚合的拆分方式。mysql-slow-query — 慢查询日志、执行计划和索引选择。
动手任务 ：准备一份百万行级的样例数据，分别在 DuckDB 和 PostgreSQL 中执行同一个聚合查询，用 EXPLAIN (ANALYZE, BUFFERS) 对比扫描行数、内存和耗时；再在 PostgreSQL 中开启 pg_stat_statements，找出总耗时最高的一条 SQL 并写出优化假设。
duckdb /tmp/demo.duckdb -c "SELECT count(*), sum(amount) FROM orders;"
psql -c "EXPLAIN (ANALYZE, BUFFERS) SELECT customer_id, sum(amount) FROM orders GROUP BY 1 ORDER BY 2 DESC LIMIT 20;"
psql -c "select query, calls, total_exec_time, mean_exec_time from pg_stat_statements order by total_exec_time desc limit 10;"
clickhouse-client --query "SELECT query, memory_usage FROM system.query_log ORDER BY memory_usage DESC LIMIT 10"
过关标准 ：
能读懂执行计划里的扫描方式、连接方式、估算行数与实际行数差异。
能区分慢在全表扫描、排序落盘、锁等待、连接池排队还是网络传输。
能解释为什么列式库适合大范围聚合，却不适合高频点更新和复杂事务。
优化前后有同口径的耗时、扫描量和内存对比，而不是只凭体感。
知道对生产库只做只读诊断，索引和参数变更要走评审与回滚预案。
目标 ：能按查询模式选择行存、列存、对象存储和湖仓组件，理解分区、副本、分片和 parts 对写入与查询的影响。
阅读顺序 ：
build-clickhouse — 用 Operator 搭建带分片和副本的分析集群。build-starrocks — 搭建实时分析集群并验证导入与查询。clickhouse-client — 原生协议客户端、查询和导入参数。clickhouse-server — 服务端配置、日志和启动检查。starrocks — 实时分析数据库的表模型、导入和查询。doris — Apache Doris 的建表、导入和物化视图。hive — Hive 元数据、分区表和批处理 SQL。spark-sql — Spark SQL 的批处理、分区裁剪和资源参数。minio — S3 兼容对象存储的部署、桶和生命周期边界。rclone — 对象存储之间的同步、校验和挂载。clickhouse-too-many-parts — 小批量频繁写入导致的 parts 堆积与合并压力。
动手任务 ：建一张按日期分区的明细表，分别用单条大批量和小批量高频两种方式导入同一批数据，记录 parts 数量、合并耗时和查询延迟；再把一份冷数据同步到对象存储，验证校验和与按日期前缀读取。
clickhouse-client --query "CREATE TABLE demo.events (dt Date, uid UInt64, amount Decimal(10,2)) ENGINE=MergeTree PARTITION BY toYYYYMM(dt) ORDER BY (dt, uid)"
clickhouse-client --query "INSERT INTO demo.events SELECT today(), number, number % 100 FROM numbers(1000000)"
clickhouse-client --query "SELECT partition, count() FROM system.parts WHERE table='events' GROUP BY partition"
clickhouse-client --query "OPTIMIZE TABLE demo.events FINAL"
rclone sync /data/cold remote:bucket/cold --checksum --progress
过关标准 ：
能根据查询模式解释行存与列存的取舍，以及为什么分析表通常按时间分区。
能说出分片、副本、分区和 parts 分别解决什么问题，不能互相替代。
导入方案考虑了批量大小、去重、幂等和合并压力，而不是“能写进去就行”。
冷热分层有生命周期、校验和恢复路径，不把对象存储当成无限且永久的归档。
表结构变更前评估了旧数据、下游查询和回滚方式。
目标 ：能让数据管道按时、幂等、可回填地运行；当任务失败、数据漂移或 schema 变化时，能快速定位是调度、依赖、源端还是质量规则的问题。
阅读顺序 ：
airflow — DAG、Executor、调度器和元数据库的职责。build-airflow — 搭建可用的 Airflow 环境并跑通一条 DAG。dagster — 以数据资产为中心的依赖、分区和血缘。temporal — 长流程、重试和状态持久化的工作流模型。temporal-vs-airflow — 定时批处理与长事务编排的选型边界。crontab — 最小调度单元的时区、环境和并发陷阱。debezium — 从 binlog/WAL 捕获行级变更写入 Kafka。canal — MySQL binlog 订阅与增量同步。kafka-connect — 连接器、任务分布和偏移量管理。schema-registry — schema 演进、兼容性级别和序列化约束。evidently — 数据漂移、数据质量和模型监控报告。dvc — 数据与模型版本管理，保证回填和实验可复现。
动手任务 ：写一条每天 02:00 运行、带重试和超时的 DAG，任务读取源表、做去重聚合、写入分区表，并在结束时校验行数、空值率和主键唯一性；手动触发一次失败重跑和一次七天回填，确认结果幂等。
airflow dags list
airflow tasks test daily_orders transform 2026 -10-18
airflow dags trigger daily_orders
airflow backfill create --dag-id daily_orders --from-date 2026 -10-01 --to-date 2026 -10-07
dagster asset materialize -f definitions.py --select daily_revenue
curl -s http://connect:8083/connectors/mysql-source/status | jq '.connector.state, .tasks[].state'
过关标准 ：
每个任务都有明确的时间窗口、重试次数、超时和失败告警，重跑不会产生重复数据。
回填使用隔离的并发和资源配额，并验证下游分区没有被重复覆盖。
能区分调度延迟、依赖未完成、源端无数据和任务本身失败四种“没产出”。
CDC 链路检查了 binlog/WAL 配置、快照模式、schema history 和删除事件。
质量规则至少覆盖行数、空值、唯一性、枚举范围和新鲜度，并接入告警。
目标 ：能用最小权限和租户隔离保护数据，按团队和负载解释成本，并证明备份真的能恢复，而不是只看到“备份成功”。
阅读顺序 ：
rbac — Role、ClusterRole、Binding 和 kubectl auth can-i 的验证。multi-tenancy — 命名空间、网络、配额和软硬租户隔离。serviceaccount — Pod 身份、令牌投影和工作负载身份。linux-permission-cheatsheet — 属主、权限位、ACL 和 umask。keycloak — OIDC/SAML 单点登录、用户联邦和角色映射。oauth2-proxy — 给内部数据服务加统一登录和 header 身份传递。finops — 成本分摊、预算告警和优化优先级。cost-optimization-checklist — 闲置、规格、存储和网络成本检查。opencost — 按命名空间、工作负载和 Pod 拆分集群成本。infracost — 变更前的云成本预估。pgbackrest — PostgreSQL 全量、增量和时间点恢复。lab-postgres-pitr — 在一次性环境里完成误删后的 PITR 恢复。
动手任务 ：为一条数据管道创建独立 ServiceAccount 和最小权限 Role，用 auth can-i 验证它能读自己的配置、不能读其他命名空间的 Secret；再输出该管道一周的成本拆分，最后按 PITR 演练恢复一个被误删的分区并核对行数。
kubectl create serviceaccount pipeline -n data
kubectl auth can-i get configmaps --as = system:serviceaccount:data:pipeline -n data
kubectl auth can-i get secrets --as = system:serviceaccount:data:pipeline -n other
kubectl get rolebinding,clusterrolebinding -A | grep pipeline
pgbackrest --stanza = app check
pgbackrest --stanza = app --type = time --target = '2026-10-18 10:00:00' restore
过关标准 ：
每个管道、每个人和每个服务都有明确身份，权限按命名空间和资源收敛，没有共享管理员账号。
能证明高权限绑定只存在于必要范围，并用 auth can-i 留下验证记录。
成本报告能回答“哪个团队、哪条管道、哪类资源花得最多”，并给出量化优化项。
备份任务有恢复演练记录，RPO、RTO 和数据一致性校验都写清楚。
删除、导出和跨租户访问都有审批或二次确认，操作留痕。
把 SQL 慢都归因于“数据量大”，不看执行计划、锁等待、连接池和返回行数。
分析库按行存思路建表，频繁点更新，最后被 parts 合并和写放大拖垮。
调度任务没有幂等设计，失败重跑就产生重复数据或重复计费。
回填直接在生产高峰跑，抢走查询资源，也不限制并发。
只监控任务成功失败，不监控数据新鲜度、行数波动和空值率。
CDC 只看连接器状态，不检查 schema 演进、删除事件和下游消费延迟。
权限用共享超级账号图省事，出问题后无法追溯到人。
成本优化只看单价折扣，不看闲置、重复存储、跨区流量和长期保留。
备份显示成功就认为可恢复，从不做恢复演练和一致性校验。
合上页面，先回答，再展开对照。
一条分析查询变慢，如何判断是扫描量大、连接方式差、内存不足还是锁等待？
调度任务为什么要幂等？回填时最容易造成什么事故？
数据平台的权限和成本为什么要一起治理？举出两个相互影响的例子。
答案
先看执行计划里的扫描方式、估算行数与实际行数、连接算法和排序是否落盘，再看查询日志的内存与耗时；如果计划和资源都正常，检查锁等待、连接池排队和返回给客户端的数据量。列式库还要看分区裁剪和 parts 数量。
任务可能因为超时、重试、补数或人工重跑执行多次，不幂等就会重复写入、重复聚合或重复计费。回填最容易在生产高峰抢占资源、覆盖下游分区、重复触发告警，甚至把错误数据扩散到整条链路，因此要限制并发、使用隔离窗口并先验证小分区。
权限越宽，成本越难归属：共享管理员账号让资源创建无法追溯到团队，账单只能摊派；成本压力又会促使团队申请更大配额和更高权限，进一步扩大风险。反过来，按租户做配额和命名空间隔离，既限制越权，也让成本可按团队拆分。
