公司刚上线的新业务系统每天产生上亿条用户行为日志，传统数据库查起来越来越慢，报表经常卡顿。运维团队开会讨论时，有人提了一句：要不我们搞个数据湖？当时我还在想，这词听着挺高大上，真能解决问题吗？后来一步步做下来，发现其实没那么玄乎。
数据湖不是新仓库，而是灵活的“停车场”
很多人一听“湖”，就觉得得建个庞大的存储中心。其实数据湖更像一个大型停车场，不管轿车、货车、电动车，先停进来再说。结构化数据、半结构化的JSON日志、甚至原始的CSV文件，都能直接扔进去。不像以前非要先定义表结构，等业务变了还得改 schema，费时又容易出错。
我们用的是基于对象存储的方案，底层是S3兼容的MinIO，上面搭了Delta Lake做元数据管理。这样既能利用廉价存储存原始数据，又能通过事务支持保证数据一致性。
怎么把数据“倒”进湖里？
一开始我们用Flume收集日志，但配置复杂，小文件太多。后来换成Fluent Bit + Kafka 的组合，前端服务把日志发到Kafka，再由Flink消费并批量写入数据湖。这种方式削峰填谷效果明显，凌晨三点的流量高峰也不怕了。
比如用户的点击事件，格式可能是这样的：
{"user_id": "u10086", "action": "click", "page": "home", "timestamp": "2024-04-05T10:23:10Z"}这些数据直接以Parquet格式写入湖中，按日期分区，查询时只读需要的部分，效率提升很明显。
查询性能不能靠堆硬件
数据进来了，怎么查得快才是关键。我们试过直接用Spark SQL查原始目录，结果一次全表扫描要二十多分钟。后来引入了Hive Metastore做元数据服务，并配合Trino做联邦查询，连通MySQL里的用户画像表，一张SQL就能出分析报表。
还加了Z-Order索引对 user_id 和 timestamp 做排序，同样的查询时间从20分钟降到90秒以内。别小看这个优化，运营同事再也不用催着问“报告好了没”。
权限和生命周期也得管
数据湖放开了写，但不能谁都能看。我们在中间加了一层Alluxio，配合Ranger做细粒度权限控制。财务部门只能访问脱敏后的汇总表，开发人员看不到敏感字段。
另外设置了生命周期策略，原始日志保留180天，之后自动归档到低频存储。既满足合规要求，又省下了不少存储费用。
现在每周五上午十点，自动化流水线会把上周的数据跑一遍质量检测，发现问题及时告警。这套流程跑顺了，大家反而觉得数据湖也没那么神秘，就是个靠谱的工具而已。