导读
58集团作为国内领先的生活服务及分类信息平台，业务覆盖招聘、房产、汽车、二手、本地生活服务及金融等领域，各业务每天生成海量信息，对内容安全、业务违规的高效治理和处罚的需求亟需解决，本文站在中心化建设视角，阐述58集团处罚数据中心的设计与实践。
背景与目标
目前有各业务自建的治理系统和集团主风控系统两条路径来治理内容安全和业务违规问题。上游治理层系统针对用户和信息进行处理后，产生的处罚类数据由各业务自行存储和使用，虽然相对简单和快速地解决了当下面临的治理问题，但对于用户而言需要面对不同形态的处罚数据和繁杂多样的系统操作规则，同时对于下游用户申诉中心无法做到统一高效地处理户申诉诉求。
基于上述背景，处罚数据中心旨在建立集团统一的处罚平台，满足各业务方治理层处罚业务留证和回溯操作诉求，建立标准化处罚信息。
业务现状与决策
3.1 业务现状
上游治理系统多
上游治理系统多
主要包括各业务治理（招聘、房产、微聊等）的处罚和风控治理的处罚，且其中涉及多个系统，采集处罚数据需要适配各系统的接入。
海量数据接入
各业务每天生产海量的数据，需要快速、准确、高效的接入实时处罚数据和存量数据。
处罚方式多样
集团涉及业务广泛，处罚方式多样，例如加黑名单、部落帖子禁止分享、房产信息降权等，需要将所有处罚方式统一归纳、梳理，并对处罚方式进行字典管理。
处罚上下文格式不统一
涉及的多个处罚系统、风控平台都无法抽出数据模型来覆盖所有内容，需要制定标准化处罚业务数据模型来描述所有处罚信息。
处罚数据归属
在数据非标准化、集团风控治理情况下，处罚数据大多无法区分业务归属，针对这种情况下的数据归属也是解决重点。
3.2 解决方案
我们提出两种解决方案：
方案一：由上游所有业务提供标准化数据，比如上下文信息，最后将数据推送到处罚中心进行留存。
优点：处罚数据中心只做数据分类留存。
缺点：推动所有上游业务改动困难，让各业务统一使用风控平台进行治理也不现实
方案二：处罚中心作为基础平台统一处理异构数据，进行数据ETL后进行留存。
优点：不需要上游业务改动，项目成本可控。
缺点：在分类治理数据中有技术挑战。
综上，我们采用方案二由处罚中心作为集团处罚链路基础层，统一处理异构数据。同时，基于规则对海量存量异构数据进行清洗，过程中在保证业务正确性的前提下，还需要保证服务清洗效率以及服务的稳定性。
数据ETL（Extract-Transform-Load）的关键点
数据粒度
58集团作为国内知名信息分类平台之一，其信息数据增长迅速，需要根据业务场景对数据进行聚合，如何定义处罚粒度，以什么样的维度聚合来描述当前处罚信息，对后面标准化建设以及应用有重要意义，例如针对同一批次或者同一类型的处罚信息进行聚合可以更准确记录处罚现场。
数据标准化
在接收各数据源数据时，数据里缺失关键信息问题，需要借助数据里的特征，对处罚数据进行补全，再构建处罚中心标准数据。
设计方案
处罚中心整体架构，如下图所示：
数据层：58集团业务产生的治理数据、集团处理中心产生的业务数据、以及业务线下同步的数据，都会成为我们的数据源。
服务层：服务层的核心功能为对所有数据源进行数据采集数据抽取模块、对采集的数据进行规则特征匹配的数据清洗模块、以及对数据应用展示查询、反向恢复的数 据应用模块
存储层：作为集团处罚数据中心，处罚数据的增量写入与查询需求很高，使用公司自研数据库wlist、wtable，wlist为
数据ETL
5.1 数据采集
数据采集包括对线上实时数据、离线数据、业务同步数据、存量数据的采集。对于不同上游的数据接入，数据采集需要适配各系统接入差异，同时海量数据的采集在保证对数据采集渠道的扩展支持上，还要关注采集效率。
5.2 抽取框架选择
