UPYUN Open Talk：51 信用卡日志分析变迁史

首先恭喜 UPYUN 的好伙伴 51信用卡 得到B轮 5000万美圆的融资。51 信用卡管家是国内信用卡管理第一品牌。自 12 年创业开始，至 14 年开始的 “瞬时贷”上线，15年完成p2p金融信贷服务。51 信用卡的 CTO 殷鹏翔在 UPYUN Open Talk 《移动时代互联网金融的架构趋势》主题线下沙龙中，分享了 51 信用卡的日志分析演变过程。

1、 日志变迁过程
一、12 年初创期，用户数量在 50 万之内，处于原始数据积累期。日志分析主要用来关注天天新增用户、新增邮箱总数。整个系统彻底同步处理数据库，只有业务处理、业务展现两个简单的层级结构。
二、规模性增加期，用户量到达 200 万，日志慢慢开始转向为运营和产品服务。在运营层面，关注转化率（邮箱转化率，设备新增数等）；产品层面，基于点击量判断产品功能、系统流程的好坏，以及关注系统稳定性（应用层故障指标，同步报警等）。在这个阶段，数据处理的方式也由同步处理转变成异步处理。
三、高度增加期，当用户量达到 500 万时，业务耦合性高。为了不资源浪费，建立了统一的数据分析接口，将全部日志所有汇总到一个数据统计分析平台，各业务线复用数据处理平台。

2、日志变迁中技术细节

在引入日志分析前，最先的方式是 DB Select Count 的形式, 整个系统采用同步处理的方式，一台 Nginx 作前端，两台 DB，两台 Sever，简单处理数据，展现结果。

最初采用同步日志结构，全部东西都保存 Queue 里面，有一个线程扫描 Queue。当时访问量较少，用了六台机器，彻底用 JVM 内存保存瞬时数据，使用线程池保证异步数据处理。问题是并发峰值、井喷访问的时候，线程池过大就很容易致使内存溢出，线程死锁也比较严重，致使 JVM 崩溃，内存里面的数据就所有丢失了。在数据量初步增加期，能够接受，但一旦达到必定规模后就彻底没法承担。数据还有高峰低谷期的差异，须要以高峰期的资源配置保证整个系统的正常运行，所以加到了 20 个 JVM 存放数据。当日志量成倍增长的时候，明显感受到当前的架构遇到了性能瓶颈，这时咱们考虑到须要采用异步流程。

在日志收集过程当中，咱们增长了一个 MongoDB Capped Collection 模块。Capped Collection 的好处是有一个固定的结合点，好比说保存 10G、50G 的集合，先写入到 Capped Collection 中。它的性能很高，顺序插入速度很快，插入的时候每一个数据有一份 Object ID。在插入最新数据的时候，淘汰最先的数据。全部的数据都是暂存MongoDB 里面，一旦这个数据超过了 50G，前面的数据会摘掉，这样能够排除前面的异常数据。最后根据一秒伪实时，保证数据都是顺序的处理。由于 Object ID 不一样的机器收集的数据不是彻底顺序的，系统容许一秒钟的伪实时算法，可以抛弃一秒钟的数据。

如今用 Fluentd 的方式收集日志，经过 Fluentd 实时采集到 Dashbroad，放到 MongoDB 的 Capped Collection 中。第二个就是 Log4j Append，Append 主要是采集系统应用层的数据，还有一些实时数据（好比页面的点击数）。部分行为日志会将实时数据采集到 MongoDB 的 Capped Collection。接下来是 Schedule，线程定时扫描收集到得日志进行分析统计，在同一个 Schedule 里面会存三份数据，一份存到 Result 做为统计结果，一份数据存到 HDFS，主要做为离线的数据预演，还有一份保存到 SolrCloud。 SolrCloud 最先是把它做为一个搜索引擎，也是为了一些预演，在 SolrCloud 上面作了一些定制，能够作不少维度的统计。在这个系统里面，SolrCloud 主要用来实时查数据、统计数据和验证数据。

在 2014 年的五六月份，咱们开始行为数据的收集。在移动互联网领域，通常都会使用第三方工具来作数据统计，但统计结果不够详尽，没法很好地知足咱们的业务需求。行为日志主要就是统计产品各个方面的日志，包括各个 UI 界面上的点击数、渠道转化率，用于控制成本和产品迭代。这些东西在当时没有更全面的数据来支撑，并且咱们风控团队但愿有更多的基础数据支撑风控结果验证。

客户端的每个操做咱们都会记录到行为日志中，再经过必定的压缩规则，上传到日志服务器中。使用 Hadoop 作离线分析，经过客户端的实时记录预测下一个时间段的交易量。实时数据是经过业务网关主要是 HDBS 的方式上传到服务器上面。

2014 下半年的时候，数据量井喷致使延迟加大，增长业务线须要修改代码、扩展性差，以及 Mongo 自己分布式能力不够、单点风险大，MongoDB 方式在 15 年没法支撑现有的数据分析和处理的实时性，咱们引入了 Storm。

以前的日志系统不能进行数据分级处理，会因某一数据过大，而影响全部分析延迟。好比说因为邮件收集数据过大，瞬时贷的日志会同期日后延迟，这样的话任何一笔业务都是在计算之前的数据。这是整个实时数据分析的改进逻辑，咱们将网关数据和前端服务器的日志分开处理。如今打算在业务数据采用 Kafka，访问数据延用 MongoDB 的方式，系统日志和其他重要的业务数据走 MQ，能保证不一样的业务场景使用不一样的流处理，分级处理。

现阶段基于日志的分析，行为日志、业务服务日志、系统日志和网络日志都会通过日志分析，也会有中间统计结果。中间统计结果数据会出运营报表、访问量统计、系统监控、服务监控以及产品跟踪，中间结果 ETL、消费行为、风控和授信评分，及其余终端业务产品作数据支撑，用户数据进入金融产品。在金融产品逐步增多的过程当中，整个 ETL 过程变成最耗时、耗资源的部分。下一步在就是把 ETL 做为总体的数据分析平台，基于Hadoop HDFS，包括 map reduce 和 Storm 结合作一个分析平台。

目前各业务线都要特定的 ETL 目标，上线一个新功能，须要遍历数据库，从新编写获取元数据。这种状况下，各业务线会用到 90% 相同的数据处理结果，好比用户访问频次、用户注册地、用户帐单分析结果，便会形成资源浪费和入口不统一。所以，须要搭建一个数据平台——提供统一数据接口、统一分析、标准化 IPO 模式，实现 ETL 逻辑。
处理 ETL 目标不同，逻辑也不同，这须要不一样的处理过程，和不一样的存储框架。为实现日志分析平台化，将日志分为实时和离线两种形式，足以确保全部数据都通过实时流或离线处理。

实时流处理访问日志，用于判断服务器有无被攻击、后端服务器是否出现异常，以及地区访问量、业务收入等数据。

Hive 异步离线分析用于分析用户行为日志。行为日志存储在手机上，在面临用户低频率启动应用的状况下，系统半个小时作一次异步离线处理。在这个过程当中，最关键的是，用户的消费数据会根据 ETL目标，进行 Map Reduce 处理或其余处理，采用数据结构较丰富的 Redis 作输出。最后会将数据结果输出到 SAS 中聚合和相关性分析，获得相关性模型。这就是整个数据分析平台化的过程。

咱们下一步的目标是引入规则引擎，由于整个统计过程当中，包括计算都是一个规则，若是全部的规则都作好了，这种算法是彻底规则化的。引入引擎以后咱们应用层的开发量就比较少了，但定制量比较多，业务人员和运营人员就能够配置规则进行数据统计分析。

UPYUN Open Talk是 UPYUN 发起主办的行业技术沙龙，旨在以邀请各行各业优秀的企业技术负责人分享介绍本身工做过程当中的技术架构经验的方式，推进整个移动互联网时代的企业员工的我的技术成长，从“人”这个关键点的我的成长提高去帮助推进企业的快速成长。