有 10GB 的 CSV 文件，但只有 512MB 内存给你用，该咋办？
Sarveshkhamkar约 5 分钟情急之下提到Kafka，才勉强挽救了我的答案。
“假设你有一个10GB的超大CSV文件，计算资源却非常有限：内存只有512MB，CPU为单核。你要怎么完成数据预处理，并将文件转成其他格式？”
我停顿了一下，脑子飞速运转。
“逐行读文件？”——思路太直白了，肯定不是面试官想要的答案。
“用多线程？”——可资源本来就有限，多线程反而更耗资源。
“导入数据库处理？”——但数据库本身运行也需要内存啊。
我心里清楚，要说点有技术含量的内容才行。
一、我的第一版回答（剧透：答得不怎么样）
我先追问确认了一下：“这是什么类型的数据？是结构化数据吗？”
面试官回答：“就是标准的CSV文件，行和列规整排列。你需要做数据清洗，对部分字段做格式转换，最后保存成JSON或者Parquet格式。”
我思索了几秒，开口答道：
“可以将数据行分块迭代处理，同时记录每一块对应的字节偏移量。举个例子：每次读取一万行，在内存中完成处理后写入新文件，再跳转至下一处偏移位置继续处理。这样一来就不用一次性加载整个文件。”
面试官点了点头，但他的表情却说： “这还是太简单了。”
他紧跟着追问：
“如果每行数据量都很大，一次性读一万行还是会占满内存。而且这套方案没有容错能力，程序处理到一半崩了怎么办？你怎么实现断点续跑？”
我一下卡壳了，清楚自己的回答考虑得并不周全。
情急之下，我脱口而出：
“我对底层实现并不完全了解，但我知道这类问题通常会用Kafka、Flink这类流处理框架来解决。精确一次语义、数据分片、容错能力这些特性都是开箱即用的。”
面试官微微挑了下眉。他没说我答错了，可也没点头认可。
走出面试间的时候，我觉得自己算是勉强应付过去了，但并没有真正把这个问题答到位。
二、面试后我学到了什么
面试结束回家后，我特意去查了相关资料。其实这个问题非常经典：如何在内存受限的情况下处理超大文件。
标准答案其实根本不需要提到Kafka和Flink。单机处理单个文件，用这些框架完全是杀鸡用牛刀，真正的解决方案其实更简单优雅。
以下才是我当时本该说的答案。
三、最优思路：流式读取 + 分块处理 + 偏移量追踪
要用流式CSV读取工具，一次只读取一行数据。
在Java生态中，OpenCSV、Super CSV这类第三方库都原生支持这种读取模式；如果是简单场景，哪怕只用BufferedReader配合String.split(",")也完全够用。
尝试 （ BufferedReader 读者 = 新 BufferedReader （ new FileReader （ "large.csv" ))) {字符串线；当 （（line = reader.readLine（）） ！= 空 ） {processLine（line）； // 转换、验证等writeToOutput（line）； // 添加到新文件中}}
这种方式几乎不占内存，只需要放得下一行数据就行。
要是CSV解析本身开销不小，例如要做复杂的数据校验，可以一次批量处理1000到5000行。但这批数据的大小，不能超过可用内存的很小一部分。
List<String> batch = new ArrayList<>（ 5000 ）；当 （（line = reader.readLine（）） ！= 空 ） {批次。 添加 （行）；如果 （batch.size（） == 5000 ） {processBatch（批次）；batch.clear（）； // 释放内存}}
如果程序中途处理失败，不用从头开始。只需持续记录最后一条成功处理的行号，或是对应的字节偏移量就可以。
可以写一个小一点的检查点文件来保存进度：
offset = 1048576 # 当前已处理的字节数要是程序中途崩溃，就读取这个检查点的值，将文件指针跳转到对应的偏移位置，然后继续处理就行。
在Java中，可以通过RandomAccessFile类来实现指定字节位置的跳转：
RandomAccessFile raf = 新 RandomAccessFile （ "large.csv" , "r" ）；raf.seek（lastKnownOffset）； // 从这里继续
如果只有单核CPU，但还是想让磁盘I/O和数据处理并行起来，互不空等，可以开两个线程：
线程 1（生产者）：从文件中逐行读取数据，存入一个小队列中
线程 2（消费者）：从队列中取出数据行并进行处理
这样CPU在运算的同时，磁盘也能保持读写状态，把IO等待的时间利用起来。不过在资源极度受限的场景下，这套优化方案反而有点过度消耗资源。
四、但Kafka或Flink就完全不对吗？
如果题目里 “计算资源有限” 指的就是单台小型机器，那Kafka和Flink确实不是正解，因为它们自身运行就会带来额外的资源开销。
但如果文件存放在HDFS这类分布式文件系统上，且有一个由多台低配节点组成的集群，那Kafka+Flink（或是Spark Streaming）就再合适不过了。它们会对数据做分片、并行处理，还能提供精确一次的处理保障。
面试官当时想引导的，可能是流处理这个思路，而不是特指某几个工具。
我当时的失误就在于，只提到了工具名称，却没讲清背后的核心原理：
数据分片
检查点机制
精确一次语义
五、一句话版标准答案
要是能重来一次，我会这么回答：
“我会用流式CSV读取器逐行处理文件，每次只批量处理几千行，避免内存过载；同时定期保存字节偏移量来实现检查点机制，这样程序就算中途失败，也能从断点续跑，不用从头开始。”
如果面试官再追问分布式场景的解法，我就补充：
“如果文件分布在多台机器上，我会用Kafka+Flink这类流处理框架对数据做分片，每个分片独立处理，再依靠检查点机制保障容错能力。”
六、这次面试教会了我的事
在没理解问题之前，先不要急着跳到大框架上；
一定要问清楚场景：是单机一次性任务，还是集群实时流水线？
容错和断点续跑能力往往比单纯的处理速度更重要；
答错也未必没有价值，它会推着你去找正确的答案。
换作是你，会怎么回答？
你有没有在面试中碰到过这种 “大文件、小内存” 的经典问题？当时你是怎么答的？
欢迎在评论区留言分享。