日均TB级数据，支付统一日志框架

支付中心作为公共部门，主要负责的业务包括交易、实名绑卡、账户、收单等，由于涉及到交易相关的资金流转以及用户实名认证，部分用户操作环节的中间数据应内控/审计要求需要长时间保存。当前研发应用多，日志量大、格式各异，对于日志的存储和使用产生较大的挑战，故支付数据与研发团队群策群力，共同开发了一套统一日志框架。

 

二、总体架构图

 

 

核心模块包括：日志生产、日志采集、日志解析，其中调用流程如下：

 

1）研发应用/服务接入基于log4j2扩展的统一日志组件，将日志抛送至kafka。

2）周期性启动消费kafka topic的camus job将日志写入hdfs。

3）T+1启动MR job读取camus写入的hdfs内容并load到hive表。

 

三、日志生产-统一日志组件

 

 

支付研发基于log4j2自定义了多个Appender，将应用日志以服务调用形式抛送至kafka，并被log_process_service 服务统一处理并提交至常用基础日志框架如：CLOG、CAT、ES，各应用无需关心公司日志框架，统一由日志平台处理。

 

其优点：

 

• 不同日志框架对应着不同的Appender，方便进行日志框架接入的扩展。

• 采用AOP编程，对于接入的业务侵入性小，接入简单。

• 定义了丰富的java注解，便于日志配置化输出，其中可打印日志包括但不限于：类名、方法名、方法入参、返回值、异常等，支持敏感字段脱敏。

 

存在的问题：

 

• 日志格式不规范：研发应用数百个，研发人员较多，日志格式差异大，给数据分析和使用带来巨大挑战。

• 存储时长短：当前公司在线CLOG存储系统只能查询最近几天数据、ES保存稍长一段时间数据且不支持批量查询，基础离线CLOG hive表由于数据量巨大，仅能做到T+2，无法满足T+1的报表需求。

 

故支付数据团队在研发团队统一日志组件的基础上，结合数据分析和数据存储生命周期开发了统一日志框架。

 

 

3.1 统一日志-埋点设计

 

支付研发团队负责数百个服务或应用，支持的业务包括：路由、鉴权、免密、卡服务、订单、钱包实名、电子支付等，不同的业务又可拆分app、h5、online、offline等项目，整合这些数据是个极大的挑战。如果各系统研发埋点任意指定，会给BI数据分析带来极大的困难，数据分析准确性难以得到保障，故支付数据基于业务特点定义了一套统一日志埋点规范。

 

字段定义主要是基于日常分析需求，致力于简化数据的使用，故总体原则为json形式，当前原始日志有两部分组成：tag/message，其中tag数据结构为Map，关键数据一般是通过tag内的数据进行检索，明细数据通过message进行检索，tag与message的组成格式为