分布式计算

对于第一个问题 ， 通常一个典型的 TiDB 做批量任务的流程是：下档（每日的交易记录通过文件的形式发布）-> 将这些记录批量写入到 TiDB 中 -> 计算（通过 SQL） -> 计算结果回填到 TiDB 的表中 。 档案记录可能是一大堆文本文件（例如 CSV）格式 ， 最简单的写入方式肯定就是直接一条条记录用 SQL Insert 的方式写入 ， 这个方式处理点小数据量问题不大 ， 但是数据量大的话 ， 其实是比较不划算的 ， 毕竟大多数导入都是离线导入 ， 虽然 TiDB 提供大事务（单个事务最大 10G） ， 但是站在用户的角度有几个问题：

1. 批量写入通常是离线的 ， 这种场景用户的核心诉求是：快！ 在这种场景下 ， 完整的走完分布式事务的流程是没必要的 。
2. 虽然有 10G 的边界 ， 对于用户来说也很难切割得精确 。
3. 大事务的写入过程中意味着需要更大的内存缓存 ， 这点常常被忽略 。

一个更好方式是支持物理导入 ， 直接分布式的生成底层存储引擎的数据文件 ， 分发给存储节点 ， 直接插入物理文件 ， 也就是 TiDB 的 Lightning 做的事情 。 在最近的一个真实用户的场景观察到 ， Lightning 使用 3 台机器 ， 大概在 72h 内完成了 ~30T 的原始数据的转码和导入工作 ， 大概导入吞吐能做到 380GB/h 。 所以在批量的场景中 ， 能使用 Lightning 物理导入模式的话 ， 通常是一个更快且更稳定的解 。
另外的一个痛点 ， 计算瓶颈（听起来还听不合理的 ， 哈哈哈） ， 在早期 TiDB 还不支持 MPP 的时代 ， TiDB 只支持 1 层的算子下推 ， 也就是 Coprocessor 分布在 TiKV 中的计算的结果只能汇总在一台 TiDB 节点上进行聚合 ， 如果中间结果过大 ， 超过了这个 TiDB 节点的内存 ， 就会 OOM ， 这也就是为什么过去 TiDB 需要引入 Spark 来进行更复杂的分布式计算的原因（尤其是大表和大表的 Join） ， 所以在过去对于复杂的批量业务还是需要引入一批 Spark 的机器通过 TiSpark 对 TiDB 的计算能力进行补充 。 但是在 TiDB 5.0 后引入了 TiFlash 的 MPP 模式 ， 可以通过多个 TiDB 节点进行计算结果聚合 ， 于是计算能力并不再是瓶颈了 ， 这意味着 ， 很有可能在一些 TiDB 的批量计算场景中 ， 5.0 能够节省一批 Spark 的机器 ， 意味着更简单的技术栈和更高的性能 。
更进一步 ， 引入 Spark 还有一个原因 ， 就是在计算结果回填的阶段 ， 由于 TiDB 的事务大小限制 ， 以及提升并发写入的效率 ， 我们会使用 Spark 来对 TiDB 进行分布式的数据插入 。 这个过程理论上也是可以通过 Lightning 改进的 ， TiFlash MPP 可以将结果数据输出成 CSV ， Lightning 是支持 CSV 格式的数据导入的 。
所以原来的链路理论上有可能变成：Lightning 导入数据到 TiDB -> TiDB 使用 TiFlash MPP 进行计算结果输出成 CSV -> 再次通过的 Lightning 将 CSV 结果写入到 TiDB 中；有可能比使用 TiSpark + 大事务的方案更快更省资源 ， 也更稳定 。
在这个方案上我们可以再延伸一下仔细想想 ， 上面的方案优化其实是利用了 Lightning 的大批量数据写入能力 ， 理论上有‘大写入压力’的数据导入场景 ， 都可以通过这个思路改进 。 我这里分享一个 TiDB 的用户真实反馈：这个客户业务系统上到 TiDB 后 ， 会有定期大表导入的场景 ， 他们希望先将大空表通过 Placement Rule 指定到特定空闲主机 ， 然后通过 Lightning 快速导入数据 ， 不需要考虑限流等措施也可以降低对整体集群的影响 ， 实现快速导入；相反的 ， 如果 TiDB 没有这个调度能力 ， 客户只能通过限流的方式保持集群稳定 ， 但是导入速度会很慢 。 这个例子是通过 Placement Rule + Lightning 实现了在线的批量写入 ， 也是很好的呼应了一下前面关于 Meta Feature 的描述 。