上个月被技术总监拉去开会，突然丢过来个大数据需求。客户要把电商平台的用户行为日志存起来分析，量级预估每天上亿条。当时整个项目组你看我我看你，全盯着我这个写了八年Java的老兵。

一、技术选型头大得很

我第一反应就是翻招聘网站。好家伙，大数据开发岗清一色要求Hadoop、Spark、Flink，我这Java老狗立马怂了。回家翻了三宿技术论坛，突然在Flink官网看到行小字——支持Java API，心跳直接飙到一百二。

连夜扒拉着官方文档做测试，把Java集合数据喂给Flink。没想到这玩意儿居然真能用Java写流处理逻辑：

• 数据源用Java自带的Socket凑合模拟
• 窗口统计逻辑照搬Java计时器那套思路
• 连水印机制都是Java时间戳改的

跑通demo那晚兴奋得灌了两罐红牛，三点还在改参数。

二、上生产被现实打脸

真正对接Kafka时才发现问题大了。原本以为Flink跟Java集合一样操作，结果线上数据量直接撑爆JVM。凌晨三点收到报警短信，二十台服务器堆内存全红。

硬着头皮翻故障日志，发现三个致命伤：

• 用Java对象存日志字段，一条数据吃掉300B内存
• 线程池配置照搬SpringBoot经验，Flink直接罢工
• 反序列化没压住流量，Kafka积压百万消息

第二天顶着黑眼圈改架构。字段全改成字节数组存储，自定义序列化器时发现个骚操作——把Java对象的getter方法强行改写成二进制操作，内存瞬间降了七成。

三、技术栈混搭求生记

搞完计算层又栽在存储上。HDFS那套命令看得我脑壳疼，结果发现老伙计Java早就留了后门：

• 用Hadoop Client的Java API直写HDFS
• HBase查数据全靠JDBC那套思路改
• 连YARN资源调度都偷用Java进程监控

最绝的是调度系统。本来打算学Python写Airflow，结果在GitHub刨到个Java版调度框架，连触发器代码都是熟悉的Spring定时任务语法。

四、实战血泪经验包

现在这套系统已经扛住双十一流量。总结下来三个核心发现：

Java写大数据就像开手动挡：发动机（Flink）用Java能启动，但变速箱（内存优化）得自己调。我整理的关键参数：

• 堆外内存必须占总量70%
• 并行度设置CPU核数两倍
• checkpoint间隔压到30秒内

混搭技术栈有隐藏福利：用Java调用大数据组件时，发现能直接把SpringCloud那套监控体系嫁接过来。Prometheus收集的JVM指标和Flink的吞吐量曲线在同一个Grafana面板跳动时，团队新人直呼魔幻。

别被岗位描述唬住：后来才知道甲方之所以批准技术方案，是因为他们用Scala写的实时计算模块总OOM。反而我们这套基于Java的改造方案，虽然启动慢了200毫秒，但三个月没出过内存故障。

插播真实狗血剧：

刚完成压力测试那周，合作方空降个技术总监。那货看着监控屏突然嗤笑："都202X年了还用Java搞大数据？"转头就招了两个自称精通Scala的工程师。结果上周听说新团队写的流处理作业把IDC机房带宽打满了，现在客户正拿着合同索赔。我们老组长在茶水间拍着我肩膀说："幸亏你小子当初没转行学Scala..."