欢迎大家给 StreamX 点赞 star~
联通数字科技有限公司是中国联通的全资子公司，通过全面整合云、大、物、智、链、安 基础能力，构建包含云、网、平台、数据、应用、集成、运营服务在内的综合数字化产品和智慧运营体系，为政企客户数字化转型赋能；联通数科在智慧城市、智慧文旅、安全和金融等领域与阿里、腾讯、京东、奇安信等企业成立合资公司，实现资源互补、强强联合，通过设立分公司和子公司实现全国服务的战略布局，共拥有 31 家分公司、11 家全资子公司、5 家控股公司、5 家参股公司、以及 3 个研发中心。
1
联通数科实时计算能力要求
实时计算服务是联通数据中台的核心服务之一，提供了在海量实时数据下打造场景化赋能的能力，通过面向前端业务赋能、面向数据产品化赋能，助力实时场景化运营和企业的数字化转型；服务支撑了全国 31 个省分公司以及联通集团的各个子公司的实时化业务；集成了 50 多种实时数据源，日均 1.9 万亿近 600TB 的数据处理，提供了 40 多种标准实时场景，支撑了 10000+ 的订阅。
实时服务提供了三大类的场景订阅：
- 用户行为类的场景：包括位置场景，用户终端场景、用户登网场景，以及漫游、语音、产品订购等各种场景。
- 用户使用类的场景：包括 APP 使用场景、用户流量场景、账户余额场景、欠费停机场景等。
- 用户触网类的场景：包括业务的办理场景、充值缴费场景，新入户入网场景等。
对于联通数科实时计算平台来说，实时性要求很高：数据从产生就立即进入到系统，到匹配用户订阅进行数据下发一般在几秒内即可完成。考虑到某些原因最大延迟不能超过 3 分钟，所以针对实时计算平台端到端的延迟监控我们做了大量工作；用户定义的场景符合要求的数据最少要下发一次，这个是有严格要求的，不能漏发，而 Flink 很好地满足了这个需求，这也是联通数科的实时计算基于 Apache Flink 的原因；数据的准确性要求需要达到 95%，每天我们会抽取部分订阅的离线数据，按照相同的规则进行数据生成以及数据质量比对，如果差异过大就需要找到原因并保证后续下发数据的质量。
2
实时计算面临的挑战
联通数科实时计算服务的需求方是联通的 31 个省、公司以及各个子公司，随着需求源源不断的增加，Flink 的作业也越来越多，初步估算在今年年底会达到 300+，作业的运维和管理带来很大的挑战。
1. 作业上线流程长、效率低
一般的上线步骤：连接 VPN、通过 4A 登录到目标服务器、切换到部署目录，执行自动化编译部署脚本、调用启动脚本、登录 YARN 页面、搜索作业名称、点击进入 Flink 的监控页面等，整个流程很长，效率很低，如果首次上线失败，整个流程还要重复。
2. 部署的代码分支不可控、难以追溯
通常上线一个作业我们会根据某次迭代版本进行上线，如 8 月 1 日的迭代，git 分支为 release_20220801，就得让开发人员特别注意这个待上线的分支。如果一不留神选错分支，就会导致生产故障，即使上线时选对了分支，也没有对应的手段确保上线的是这个分支，一旦出现问题无法在部署层面去确保是否有问题。
3. 脚本分散、难以管理
每个 Flink 作业都有对应的脚本进行辅助运维，比如启动脚本、停止脚本、守候进程启动等脚本。我们的 Flink 任务目前有 100 多个，多达几百个脚本，非常难管理，更严重的是这些脚本难以跟 git 远程脚本代码保持一致。一旦部署脚本的机器不可用，会造成大量脚本丢失，难以在短时间内恢复，即使可以定期将脚本备份，也没有彻底解决运维中的痛点。
4. 作业配置不集中
配置分散在运维脚本中，很难统一管理，不能追溯配置变更，在面临集群迁移或更换数据源时，面临修改大量脚本带来时长且容易引发故障等难题。
5. 缺乏数据一致性保障、引发投诉
联通的需求非常复杂，实时计算的同时需要关联外部组件，如 HBase、Redis 等，在万亿级的数据量并发下给外部组件带来很大的压力，即使外部组件可以扩容但很多时候也难以满足性能要求，而且引入外部组件增加了运维的复杂度，为了去掉过多的外部组件依赖，得益于 Flink 的状态的强大，我们在生产上使用了大量的状态来满足复杂的业务需求，同时降低了整体架构的复杂度，由此也带来了新的问题：由于需求迭代速度快，作业经常停服上线，由于是脚本运维经常出现小伙伴忘记从 checkpoint 或 savepoint 进行恢复或者脚本存在问题不能得到最新的 checkpoint 路径，导致生成的数据有数据质量的问题，引起下游的投诉。基于脚本化的运维要求研发的同学具有超高的意识，即使这样也不能保证 100% 规避此类问题。
6. 缺失集中监控、资源不能一点看全
目前我们通过定时采集 YARN 上的 ApplicationMaster 的状态和 Flink 作业的状态来监控作业是否正常、有没有失败、Flink 作业是否有重启等异常情况，我们都要求实时计算作业命名要规范，但是无法保障研发人员严格遵守，导致有的作业被过滤掉，发生了故障后无法第一时间知道，也会引发用户投诉。作业占用的资源也没有一个一点看全的地方，作业的处理数据量、处理条数等关键指标统计困难。
7. 作业用途不明确、责任人不明确
在 Flink 作业太多且脚本化运维情况下，当一个 Flink 作业出现异常时不能快速定位到影响了哪块业务，即使有文档说明，但无法保证文档是最新有效的，再就是不能很直观的明确负责人是谁，结果就是需要手动在开发群里广播来找负责人，效率十分低下。
8. Flink SQL 作业缺少管控平台
Flink SQL 可以快速满足分析人员的需求，面向 SQL 的作业需求不断增长，作业也越来了越多，急需一个平台来统计管理这些作业。
以上就是我们面临的主要挑战，可以看到我们还处于火石器时代，使用最原始的方式进行作业的开发、部署、运维，效率低下的同时带来一系列的问题，急需一个完善的平台化解决方案，彻底解决我们生产中遇到的各种问题，并且可以从多个角度协同解决各类问题。
3
StreamX 在联通数科的深度实践
针对上述挑战，Flink 实时计算平台化解决方案迫在眉睫，考虑到自研平台成本高而且耗时长，不能快速解决问题。在公司层面也鼓励大家参与开源，通过调研我们发现 StreamX 是主打一站式的实时计算平台，集成了项目编译、发布、参数配置、启动、停止、监控等诸多功能于一体， 大大简化了 Flink 任务的日常操作和维护，而且足够专注，比其他开源项目更加轻量，后续的发展理念也跟我们实时计算平台的思路一致。但是联通数科的任务多，数据量大，生产环境对稳定也有着极高的要求，不敢贸然投入到生产环境使用，于是我们进行了长达半年的测试，最终我们发现 StreamX 已经具备如下能力:
1. 代码编译、一键打包
StreamX 支持将系统菜单的名称重命名，在内部使用中我们将系统菜单设置为了中文。新建一个项目 (Project) 来配置代码的 git 地址、账户密码以及分支，完成后直接点击 build 按钮即可完成代码的编译打包，此功能直接解决了我们的三个痛点:
- 去掉了生产环境中的大量的难以维护的部署脚本
- 简化了部署的流程，从而提高了部署效率
- 能够直观的看出本次部署的是哪个分支，实现了代码分支上线的可控性和直观性，避免了错误部署分支而引发的故障
2. Flink 作业管理专家
StreamX 的作业配置化能力和任务便捷操作直接解决了生产存在大量启动脚本难以管理的问题，进入无脚本环境时代，从此资源配置和数据源配置也进入了集中化管理时代，解决了大量配置分散在各个不同脚本中的难以管理的问题。一键启动提高了工作效率，降低了因为操作脚本失误带来的故障问题，同时启动后可以在 StreamX 上查看日志或者直接一键跳转到 Flink web ui 界面，大大缩短了链路。更多解决的痛点如下：
- 支持多种部署模式
StreamX 支持 Flink 所有的部署模式，下拉框可以直接选择部署模式。
- 支持并行度设置和资源配置
StreamX 对 Flink 任务常见的各种参数有很好的支持，已经把 JobManager 和 Taskmanager 常见的内存和其他相关参数集中到一个下拉框里，可以方便的设置资源参数:
- 支持动态参数和 program 参数设置
动态参数是很重要的给作业传参的方式，StreamX 简单暴力给出一个输入框，并且有提示信息，指导用户如何使用。针对用户写的程序，在运行时要支持指定运行参数是最基本的要求，当然在 StreamX 中也做了支持:
- 支持作业的编辑、发布、启停、状态查看
StreamX 把针对任务的各种操作，如: 编辑、上线、启动、停止、查看详情等都集中到一组操作按钮上了，满足了针对任务的各种操控。同时可以点击任务名直接跳转 Flink Web UI 。
3. Checkpoint、Savepoint 管理
StreamX 很好的解决了 checkpoint 和 savepoint 问题，当第一次启动作业的时候，由于没有 checkpoint，StreamX 会提示是否从 savepoint 启动，如果需要就得提供 savepoint 的路径。主要应用于在生产环境中作业跨集群迁移启动或有重大停服的情况下。
当作业启用了 checkpoint 机制，StreamX 会记录 作业触发的 checkpoint，并标识出哪个是最新的，启动作业的时候默认从最新的 checkpoint 恢复，这直接解决了我们频繁上线的状态下研发人员经常忘记从 checkpoint 恢复，导致下发数据质量问题而引起的投诉。
如果没有选择 checkpoint 将面临数据丢失，此时会出现很尴尬的事情，选择之前最新的 checkpoint 会造成数据重复，不选会面临数据不准引发的投诉，试想在上百个 Flink 作业、几十号开发人员、每周频繁上线，没有平台保障是怎么样的困难。
4. 明确任务用途、明确责任人
通过在平台上注明作业赋能的业务以及展示作业的创建人，当出现问题时就可以非常直观看到影响以及所属人，能快速定位找到责任人和评估影响，这在大量的作业下是非常有用。
5. Flink 任务一站式支持
生产环境中 Flink SQL 的作业是最多的，而且会持续增长，如果没有一个平台也就意味着需要脚本化提交，这样增加了数据分析人员的门槛，难以推广。同时在管理方面也会遇到很大挑战，如：到底有多少作业、作业的业务用途是什么、作业所属人不明确、哪些作业在运行不清晰等等。StreamX 支持 SQL 配置化、资源配置化、参数配置化、一键启停等，在使用方面解决了管理难题。
通过超过半年的调研和测试，我们对 StreamX 已经有足够的信心，目前已经大规模在生产环境投入使用，用于运行 Flink 任务的集群节点超过 500+，迁移到 StreamX 上 Flink 任务累计 100+， 数量还在持续增长中。通过观察虽然有一些小问题但总体稳定性和可用性达到了预期，目前 StreamX 社区还在持续不断的增强稳定性和增加新的功能。
在选择 StreamX 之前，我们也做了大量的调研，调研的平台或功能不完善，或与非实时计算的功能耦合较多，即平台较重，或没有生产实践可以借鉴。之所以选型 StreamX 主要是因为功能完善、轻量、专注，而且已经有多家公司的生产实践了，社区活跃，查阅相关资料也方便。借助 StreamX 的能力，解决了我们实时计算生产环境的诸多问题，整体运维效率、运维质量都有巨大提升，同时故障数量和投诉率大大减少。研发团队走出了运维泥沼，幸福指数大大提升。
4
借助开源反哺开源
初次接触 StreamX 是因为公众号的文章，随后在使用 StreamX 的过程中体验是很容易上手，不需要太多学习成本，如 DevOps 的 pipeline 隐藏了很多环节，不需要复杂的配置和流程，然后就是轻量，没有多余累赘的东西，可以说功能很像迷你裙，足够短又足够长，即功能刚好够用。
加入 StreamX
在深度使用 StreamX 的过程中，我们也发现了一些问题，如当作业过多时的翻页问题、SavePoint 的路径优先级问题，作业 owner 不直观的问题，我们也将生产运维中遇到的 bug 和新的 Feature 提交给了社区。
目前数据源和 Flink SQL 的元数据没有单独的管理模块，数据源的配置还是分散在作业中，不够集中；Flink SQL 元数据与作业耦合在一起；这两部分后续我们也会参与建设。 对社区的印象
社区还是很活跃，通过观察用户群，越来越多的用户在使用或者在体验 StreamX。贡献者有来自一线互联网公司以及代表性的传统企业，涉及的行业也较多。实时计算是大势所趋，故面向实时计算 StreamX 是一个很有潜力的项目，还有很多功能待实现，也还有更长的路要走，期待在实时计算领域走的更远，希望更多的小伙伴参与建设，我们也会继续关注。
什么是 StreamX
StreamX 的初衷是让流处理更简单，定位是流处理开发脚手架和一站式实时计算平台。目前，StreamX 为 Spark 和 Flink 提供了一套快速开发的 API，定义了最佳的编程方式，提供了一系列开箱即用的连接器，标准化了配置、开发、测试、部署、监控和运维的整个过程。此外，StreamX 很好地解决了流处理任务开发、部署和运维方面的问题，集成了项目编译、发布、启动和状态监控等工作。通过 StreamX，流处理任务可以轻松的部署在 YARN 或 Kubernetes 上，这大大降低了 Flink 和 Spark 应用的开发部署管理门槛，为 Apache Flink 和 Spark 的普及尽一臂之力。
我们正在积极运营 StreamX 社区，并期待着不断增加社区活动，目前我们已经有一大批用户在生产环境使用 StreamX，欢迎更多用户前来使用。欢迎广大开发者参与我们，携手共建。
用户案例
