Flink 流批一体在字节跳动的探索与实践
背景 字节跳动旗下拥有今日头条、抖音等多款产品，每天服务着数亿用户，由此产生的数据量和计算量也是很大的： EB 级别海量的存储空间 每天平均 70PB 数据的增量 每秒钟百万次数的实时推荐请求 超过 400 万核的流式计算资源、500 万核的批式计算资源 这对我们的整个架构，包括计算架构和存储架构都带来了巨大的挑战。 业务困境 如上图所示，左边是一个非常典型，业界应用也很多的数据链路图。这个数据链路是一个典型的 Lamda 架构，整个数据链路分为批式计算链路和流式计算链路。 在字节跳动内部，通常需要批式计算和流式计算两条链路共同服务于下游的应用。 在批式计算链路中，我们主要应用 Spark 引擎，通过 Spark 引擎在批式存储中拿到数据，经过 ETL 的计算后，存入下游的存储，从而服务下游的应用。 流式计算链路，也是我们整个实时推荐、实时信息流的核心链路。我们会通过消息中心件把实时数据进行缓存存入，然后运用 Flink 实时计算引擎进行处理，处理后经过消息中间件的缓存传输存入下游的存储，来服务下层的应用。 整个计算架构分成两条链路，带来了两个比较严重的问题： 计算不同源 维护成本高。...
