- 博客(4)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 flink相关
Flink 把多个无 shuffle 算子链在一起，减少线程切换、网络开销，提升性能。下游处理慢 → 队列堆积 → 自动限制上游发送速率，防止 OOM。表格维度数据是否重复可能重复不重复Barrier 对齐不需要必须对齐状态一致性状态不丢，但可重复更新状态严格只更新一次性能高略低（对齐 + 快照开销）实现复杂度简单复杂，依赖 2PC适用场景监控、日志、允许重复支付、对账、实时数仓、金融下游算子处理不过来 → 自动限制上游发送速度 → 防止队列溢出、OOM、任务崩溃。
2026-03-31 00:02:19
399
原创 数据湖相关
在对象存储之上，提供事务、ACID、增量更新、schema 演进、时间旅行的元数据层。Delta Lake数据湖低成本存储 + 数据仓库的 ACID、SQL、索引、性能一套架构同时支持BI 报表 + 数据挖掘 + 机器学习Hudi 更擅长实时更新、CDC 入湖， Upsert 成熟，适合流式写入。Iceberg 更擅长湖仓一体、多引擎兼容、Schema 自由，适合统一分析与联邦查询。“Hudi、Iceberg、Delta Lake 三者怎么选？
2026-03-30 23:58:21
411
原创 doris相关
Tablet 是 Doris 最小数据分片与管理单元。一张表会按分桶键哈希分成多个 Tablet，每个 Tablet 有多个副本分布在不同 BE。基于 base 表的预聚合物化视图，自动匹配查询，减少计算。适合固定报表、固定聚合维度。高可用：FE 主从选举 + BE 多副本 + 自动故障检测与副本修复，无单点。一致性：元数据类 Paxos 强一致；数据写入 Quorum 机制 + MVCC 版本控制 + 后台 Compaction 最终一致，保证读已提交、不丢不错。
2026-03-30 23:47:42
444
原创 数据开发总结
（2）方案上，有很大的区别，MR的shuffle是基于合并排序的思想，在数据进入reduce端之前，都会进行sort，为了方便后续的reduce端的全局排序，而Spark的shuffle是可选择的聚合，特别是1.2之后，需要通过调用特定的算子才会触发排序聚合的功能。（1）功能上，MR的shuffle和Spark的shuffle是没啥区别的，都是对Map端的数据进行分区，要么聚合排序，要么不聚合排序，然后Reduce端或者下一个调度阶段进行拉取数据，完成map端到reduce端的数据传输功能。
2024-10-24 15:36:15
1037
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人