摘要：现在做数据的朋友估计都头疼一个事，Lakehouse这架构明明好用，开放又省钱，已经成了数据平台的主流，可它有个绕不开的短板，数据时效最多就到分钟级。企业要做秒级实时分析，就得额外加Kafka这类流存储。
现在做数据的朋友估计都头疼一个事，Lakehouse这架构明明好用，开放又省钱，已经成了数据平台的主流，可它有个绕不开的短板，数据时效最多就到分钟级。企业要做秒级实时分析，就得额外加Kafka这类流存储。
结果呢成本上去了不说，数据一致性还难保证，治理起来更是头大，刚好前段时间，InfoQ搞的QCon全球软件开发大会（北京站）上，阿里云的高级开发工程师罗宇侠做了个专题演讲，讲的就是“Fluss湖流一体”怎么让Lakehouse架构实现实时化。
说实话这内容对正在头疼流存储和Lakehouse割裂的人来说，算是及时雨了，另外提一嘴，10月23到25号QCon上海站有个“DataInfraforAI”专题，会聊LLM、多模态数据湖这些方向，感兴趣的朋友可以留意下。
AI时代对数据的要求早就不一样了，Lakehouse的价值越来越明显，它能存的东西多，结构化数据和文本、图像这类非结构化数据都能装，正好满足大模型训练的需求。而且它有个统一的Catalog，所有数据的来源、权限都能管到，大模型用的数据质量和可追踪性就有保障了。
更关键的是，它靠OSS、S3这种便宜存储，数据量再怎么指数级涨，存储成本也扛得住，不过光有Lakehouse还不够，AI时代没实时数据可不行。实时数据能更新知识库，不然模型用的还是老数据，accuracy肯定上不去。
它还能抓用户的实时状态，比如通过传感器拿数据，这样服务用户才精准另外，模型想在线学习、靠用户反馈优化推理能力，都得靠实时数据。就拿电商推荐来说，用户刚浏览完某类商品，实时数据能让模型马上捕捉到这个行为，推荐的东西才对胃口。
其实现在不少公司都在试湖流融合，比如Kafka背后的Confluent搞了Tableflow，能把Kafka的数据实时导进数据湖，还不用手动管Flink作业。还有个叫RedPanda的公司，估值都超十亿美元了，他们提的IcebergTopic能把数据转成Iceberg格式，方便分析。
国内的AutoMQ、Pulsar背后的StreamNative也有类似思路，可这些方案都有个通病，都是在现有消息队列基础上改的。就拿Kafka来说，它没Schema，也没分区概念，可数据湖的格式是有Schema和分区的，这俩根本对不上。
相当于给旧机器装新零件，再怎么调，融合也不够直接，我之前跟做数据架构的朋友聊，他们说用这些方案时，光让数据格式对齐就得花不少功夫，特别麻烦。既然现有方案有短板，那阿里云的Fluss是怎么解决这些问题的呢？Fluss从一开始就冲着数据湖设计的，架构上就没绕弯路。
数据从消息队列、业务数据库进来后，会进Fluss集群，集群里有个LakeTieringService，能把数据实时同步到数据湖，这不是简单复制，而是叫Tiering的分层同步。同步完之后，Spark、StarRocks这些工具就能直接在数据湖上分析了。
另外它还有个UnionRead功能，能把Fluss里最新的实时数据和数据湖里几分钟前的历史数据合并，这样拿到的就是最新的完整数据视图。Fluss的表模型也很讲究，跟数据湖的表模型几乎没区别。
它的表能分区，用分区列把表拆成几块，每个分区还能再用分桶列分桶，这样读写的时候能分布式处理，速度快很多。本来想，表模型这点小事不算啥，后来发现正是因为跟数据湖对齐，后面数据同步、分析才没那么多麻烦，这步设计确实很关键。
LakeTieringService是Fluss的核心之一，现在是个Flink作业，理论上换Spark作业也能跑，因为它的逻辑不依赖Flink的特殊功能。
它工作分三步：先由TieringCoordinator从Fluss集群拿要同步的表信息，分给TieringWorker；Worker再把Fluss里Arrow格式的数据转成Parquet这种湖格式；最后TieringCommitter把转好的文件提交到数据湖，还得把数据湖的快照回传给Fluss集群，让Fluss能管这些数据。
更重要的是，这个TieringService是无状态的，想扩容特别快，要是数据多，同步不过来，直接加几个实例或者提Worker的并发就行，不用迁状态。之前见过有些同步工具一扩容就出问题，对比下来，Fluss这点确实做得好。
UnionRead功能才是真的解决了时效问题，举个例子，数据湖里存着“张三15岁、李四20岁”的历史数据，后来Fluss收到新数据“张三35岁”。要是想查最新数据，查询引擎用UnionRead一合并，得到的就是“张三35岁、李四20岁”，这样Lakehouse的时效就从分钟级提到秒级了。
那UnionRead是怎么做到的呢，其实没什么黑科技，关键是Fluss能管好数据湖的数据，TieringService把数据提交到数据湖后，Fluss会记两个东西：一个是快照，标记当前所有进数据湖的数据；另一个是bucket和offset的对应关系，知道哪个bucket里offset之前的数据都进湖了。
这样查询的时候，就能精准找到哪些数据在湖、哪些在Fluss，合并起来就不会错，Fluss在元数据管理上也省了不少事。以前用Kafka和Paimon，Kafka用SchemaRegistry，Paimon用自己的Catalog，还得用Flink作业同步Schema，查数据的时候要切Catalog，特别麻烦。
但Fluss会自动同步Schema，对外只暴露一个Catalog，查数据的时候不用切来切去，既能看到Fluss的实时数据，也能看到Paimon的历史数据。要是不想查实时数据，只想看几分钟前的数据湖数据，加个$lake修饰符就行，还能继承Paimon作为FlinkSource的高效读取能力，列裁剪、过滤条件下推这些都能用。
用Fluss的成本也低很多，以前用Kafka存实时数据，本地磁盘成本高，还得把数据同步到数据湖，等于存两份。Fluss不用，历史数据直接放数据湖，自己只存几小时的实时数据，流存储成本能降到原来的十分之一。
我朋友他们公司之前每月存储花8万，换Fluss后才花8千，省下来的钱能投到别的技术上，另外，Fluss的数据回追也方便。历史数据存在Paimon里，Paimon批量读取快，还能高效过滤、压缩数据。
要回追数据的时候，Fluss会自动从数据湖读历史数据，再切到实时流，不用手动操作，数据也不会丢或者重复。对比之前手动回追数据的经历，这简直太省心了。拿Fluss和Confluent的TableFlow比，差别也很明显。
TableFlow得在Kafka和数据湖存两份数据，成本高，还没提升数据湖的时效，Fluss只存一份数据，时效还能到秒级。而且Kafka的Topic没Schema和分区，用的时候麻烦，Fluss的表模型本来就跟数据湖对齐，支持分区和分桶，不用再调格式。
它有个QuickStart，在开源文档里就能找到，还是基于Docker的，不用折腾环境，跟着文档走，先启动LakeTieringService，配置好Flink参数就行，在FlinkUI上还能看到作业状态。然后给普通表加个properties，开启湖表功能，TieringService就能识别了。
之后插入数据，等同步完，用UnionRead就能查全量数据，想查数据湖数据就加$lake，用StarRocks查也可以，指定Paimon的仓库路径，建个Catalog就行。未来Fluss还会对接更多查询引擎，现在已经支持Flink了，以后会加StarRocks和Spark，到时候用这些引擎也能做UnionRead。
另外，除了现在支持的Paimon，还会对接Iceberg和Hudi，社区里已经在开发了，之后还会在UnionRead里支持DeletionVector，能优化主键表的读取性能，减少合并数据的开销。
罗宇侠老师的背景也很靠谱，他是阿里云的高级开发工程师，还是ApacheFlinkCommitter，之前就做Flink和Hive、数据湖的集成，现在专门搞Fluss的湖流一体研发，对这块特别熟，所以Fluss的技术实力还是有保障的。
总的来说，Fluss算是把Lakehouse实时化的痛点给捏准了，不用重构现有基建，就能解决流存储和Lakehouse割裂的问题，还能降成本、提时效、简化治理。想深入了解的朋友可以去它的GitHub（https://github.com/alibaba/fluss）看看，文档也在（https://alibaba.github.io/fluss-docs）。另外10月上海的QCon专题也别错过，能学到大模型时代DataInfra的演进方向，说不定能有新启发。
来源：冷秋月一点号
