数禾科技以大数据和技术为驱动，为金融机构提供高效的智能零售金融解决方案，服务银行、信托、消费金融公司、保险、小贷公司等持牌金融机构。数禾的业务涵盖消费信贷、小微企业信贷、场景分期等多个领域，提供营销获客、风险防控、运营管理等服务。数禾科技通过自主开发的消费信贷产品，连接金融机构与普罗大众，赋能金融机构数字化转型，迎接中国消费升级的大潮。
低效的数据处理
数禾当前有三款主要产品，还呗、还享花、小店邦。每款产品都有大量的受众，每天会产生大量的应用日志。应用日志通过 SLS 收集，数据通过压缩后归档到阿里云 OSS 存储，以达到最优的存储成本。
日常有些业务场景下需要查看详细的应用日志，但由于日志收集会将不同应用的日志都聚合到一起，导致获取某个应用的日志时，需要从 OSS 解压大量的文件，并从中过滤出特定的应用，才能获取到想要查看的日志，这个过程导致数据实效性差、处理效率低效。
数禾一开始想到是否能通过自建容器的方案来解决数据处理低效的问题。自建的处理程序从 Kafka 获取数据，并负责数据的处理，K8s 集群保证任务的弹缩，配合自建的发布平台，初步能够满足设计的需求。
该方案的优势在于，对于 K8s 的使用和任务发布平台，数禾运维团队都有了不少的积累，整体实施起来难度会比较小。但对比设想的链路目标，却还有些欠缺，主要表现在：
-
任务开发成本较高：
从 Kafka 获取数据，数据的业务处理、异步压缩上传、任务的发布更新系统对接、K8s 的弹缩策略，都需要重新开发。
-
链路弹性有限：
一是 K8s 通过指标弹出资源速度需要 10+s，对于突发的日志流量，可能会出现资源弹出不及时的情况；二是 Kafka Topic 数据处理的并发度受限于 Topic Partition，当消费程序达到 Partition 数目时，消费程序没法继续扩大并发度。
-
资源利用率不够极致：
在业务低峰期，特别是夜间，有些时间段流量很小甚至无流量，但处理程序还是需要保持最小 1 个实例的运行，造成了一定的资源浪费。
-
升级维护工作依然很多：
业务处理逻辑的修改、发布平台的更新对接、K8s 平台的弹缩规则等，都需要持续的维护。
在与阿里云函数计算（后面简称 FC）团队交流后，数禾运维团队找到了突破口。阿里云函数计算在 Kafka 对接函数计算 FC 的链路已经打磨多时，对于数禾的业务需求，正可以使用到函数计算已有功能来解决，数禾的研发团队只需要专注在自身的业务处理逻辑，就能快速搭建一套高可用、易升级、轻维护投入的任务处理链路。
函数计算是事件驱动的全托管计算服务。使用函数计算，用户无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算会准备好计算资源，弹性、可靠地运行任务，并提供日志查询、性能监控和报警等功能。
通过函数计算自带的 Kafka 触发器和定时触发器，数禾运维团队架构出了一套理想的解决方案。架构图如下：
函数的处理逻辑如下：
-
数据拆分函数
通过 Kafka 触发器触发，触发器会将 Kafka 数据以 batch 的形式发送到函数计算，函数计算处理逻辑负责将数据块通过标识字段拆分，同一个应用的数据可汇总到一起，并作为独立文件保存到 NAS 目录中。
-
数据压缩函数
接收到一批新的数据时，函数计算先对数据进行压缩，再追加到 NAS 目录对应的文件中。在写入 NAS 前，函数计算会借助 Redis 处理并发锁的问题，大大减少了小文件的数量。
-
数据上传函数
通过定时触发器触发，将压缩完成的数据上传到 OSS 对应目录，然后清理本地目录。
通过将处理逻辑拆分，将涉及不同资源的操作拆分到不同函数，实现了每个函数资源利用率的最大化，降低了总体实现的费用成本。
相比通过 ECS/K8s 自建的方案，函数计算方案的优势十分明显：
数据处理全链路升级成了 Serverless 架构，数禾运维团队无需再关心底层服务器的运维工作，如服务器的启动、停止、扩展、监控等。资源使用效率也有了巨大的提升，再配合函数计算推出的梯度计价，资源开销也得到了很好地控制。
数禾运维团队在该任务的运维投入上大大节省了运维人力，几乎达到了 0 运维投入；在功能迭代上，通过函数计算控制台提供的多版本和灰度能力，快速完成了升级的灰度。
后续数禾运维团队会将更多适合 Serverless 的业务迁移到函数计算，更好地将精力专注在公司业务上，逐渐剥离运维和底层资源的维护。