用户背景
中国联合网络通信集团有限公司，是中华人民共和国一家主要从事通信业的中央企业，也是中国第三大电信运营商，在中国内地31个省、市、自治区运营移动与固网通信业务。
业务需求
电信行业的业务系统非常复杂，所以它的数据源也是非常多的，目前实时计算平台接入了 30 多种数据源，这 30 多种数据源相对于总的数据种类来说是比较小的。即使这样，联通的数据量也达到了万亿级别，每天有 600TB 的数据增量，而且接入的数据源种类和大小还在持续增长。平台的用户来自于全国 31 个省份公司以及联通集团的各个子公司，尤其是在节假日会有大量用户去做规则的订阅。用户想要获取数据，需要在平台上进行订阅，联通会将数据源封装成标准化的场景，目前已经有 26 种标准化场景，支撑了 5000 多个规则的订阅。
对于实时计算平台来说，实时性的要求是很高的。数据从产生到进入联通的系统，大概有 5~20 秒的延迟，经过系统正常处理之后大概有 3~10 秒的延迟，联通允许的最大延迟是 5 分钟，所以必须做好实时计算平台端到端的延迟的监控。
平台建设
2020 年以前，联通是使用 Kafka + Spark Streaming 的方案来实现的，而且是采购厂商的第三方平台，遇到了很多问题和瓶颈，难以满足日常的需求。与此同时，很多企业都正在进行数字化改革，系统的自研比例也越来越高，再加上需求的驱动，自研、可灵活定制、可控的系统迫在眉睫。在这个背景下，联通从2020 年开始接触Flink，并实现了基于Flink的实时计算平台。
既往平台存在的问题如上图所示。为了解决这些问题，联通自研了基于 Flink 的实时计算平台，根据每个场景的特点进行最优的定制，最大化资源的使用效率。同时利用 Flink 内置状态存储的特性减少外部依赖，降低了程序的复杂度，提升程序的性能。通过灵活定制实现了资源的优化，相同体量的需求下大大节约了资源。此外，为了保证系统的低延迟率，还进行了端到端的监控，比如增加了数据的积压、延迟、数据断传监控等。
联通的Flink集群需要日均处理 1.5 万亿数据，近 600TB 的数据增量，对稳定性的要求比较高，因此是独立搭建的。它独享了 550 台服务器，没有和离线计算混用。
联通对场景深度定制的主要原因是数据量大，同一个场景的订阅又非常多，而且每个订阅的条件又是不一样的。从 Kafka 读取一条数据的时候，这条数据要匹配多个规则，匹配中后才会下发到规则对应的 topic 里面。所以不管有多少订阅，只从 Kafka 中读取数据一次，这样能够降低对 Kafka 的消耗。
手机打电话或者上网都会连接到基站，相同基站的数据会按一定的时长窗口和固定消息进行压缩，比如三秒钟一个窗口，或者消息达到了 1000 再进行触发，这样下游接收到的消息就会有量级的降低。然后是围栏匹配，外部系统的压力是基于基站规模的，而不是基于消息数目。再就是充分利用了 Flink 的状态，当人员进入和滞留的时候会存入状态，用 RocksDB 状态后端减少了外部依赖，简化了系统的复杂度。此外，联通还实现了亿级标签的关联不依赖外部系统，通过数据压缩、围栏匹配、进入驻留、标签关联后才开始正式匹配规则。
用户订阅场景后，订阅的规则会以 Flink CDC 的方式同步到实时计算平台，这样可以保证延迟比较低。由于人群的进入滞留会存入到状态，基于 RocksDB 的状态后端数据量比较大，联通会通过解析状态的数据进行问题排查，比如用户到底有没有在围栏之中。
此外，联通还搭建了基于 Flink 的集群治理架构，通过采集资源队列的信息，解析 NameNode 的元数据文件 Fsimage，采集计算引擎的作业等信息等，对集群做 HDFS 画像、作业画像，数据血缘、冗余计算画像、RPC 画像以及资源画像。
联通通过基于Flink进行实时计算平台建设和集群治理，有效提高了计算资源的利用率，存储文件数降低 60% 以上，RPC 负载也大幅降低，从而解决了长期以来的资源紧张问题，降低了集群扩容开支，每年会有千万级别的成本节约。
未来规划
首先，目前联通还没有一个完善的实时流管理平台，且监控比较分散，研发通用的管理和监控平台势在必行。 其次，面对日益增长的需求，深度定制化虽然节约了资源，提升了支撑的规模，但是它的开发效率并不理想。针对数据量不大的场景，联通考虑使用 Flink SQL 来搭建通用的平台，以此来提升研发效率。 最后，联通会继续探索 Flink 在数据湖中的应用。
