TL;DR

这篇文章不讲模型训练，不讲太底层的技术细节，只整理 AI 应用层最常见的一批名词。目标不是把每个词讲得非常学术，而是用尽量通俗的方式，把它们之间的关系讲清楚。

TL;DR

本文基于 Flink 1.20 源码，梳理 yarn-application 模式下一个任务从提交到运行起来的完整过程。

重点会放在这几件事上：

• 命令是怎么启动的
• Client 侧到底做了什么
• Yarn 上的 ApplicationMaster / JobManager 是怎么启动的
• TaskManager 是怎么向 Yarn 申请并拉起的
• 用户 main()、JobGraph 生成、submitJob() 分别发生在哪个角色里

为了避免范围过大，本文只聚焦 run-application -t yarn-application 这条主链路，不展开 Web 提交、Session 模式以及 SQL Gateway。

以一个最常见的启动命令为例：

1
2
3
4
5
6
7

./bin/flink run-application \
  -t yarn-application \
  -Djobmanager.memory.process.size=2048m \
  -Dtaskmanager.memory.process.size=4096m \
  -c com.example.WordCount \
  /path/to/job.jar \
  arg1 arg2

TL;DR

本文基于 Flink 1.20 源码，不再泛泛讨论“什么是流式计算”，而是聚焦两个问题：

1. 为什么 Flink 会成为主流流式处理引擎？
2. Flink 到底靠哪些关键机制，把无界数据流变成可按时间计算、可故障恢复、可做到 exactly-once 的系统？

如果把答案压缩成一句话，那就是：

Flink 真正领先的地方，不是单独提出了 window 或 watermark，而是把 事件时间、watermark、window、trigger、state、checkpoint 这些能力拼成了一套完整且能落地的运行时体系。

本文重点看两条主线：

• Flink 如何处理时间：event time、watermark、window、trigger
• Flink 如何保证精准一次：state、checkpoint barrier、snapshot、恢复

TL;DR

简单实现了一个基于 Rust 实现的分布式 KV 系统，底层共识算法使用 Raft，具体实现依赖 OpenRaft。

代码地址： distribute_kv_openraft

最近在网上冲浪的刷博客的时候, 看到一个题目.

总共有25匹马, 一共有5个赛道, 现在要选出跑的最快的5匹马, 至少需要比赛几次?

这个问题刚看到的时候, 看了一眼下面的答案就略过去了, 但是后面突然回想到这道题, 然后没有想通为什么是这样, 特此记录一下.

前言

这篇文章会介绍一下, SeaTunnel如何在不同环境下进行安装部署, 以及一些可以去调节的参数配置. 这里仅设计Zeta引擎的相关内容, Spark, Flink引擎的提交不需要搭建集群, 所以不会涉及.

趁着这次博客迁移, 更新记录下当前博客的写作, 同步, 发布方案.