满成见：猎聘网数据治理实践全流程经验分享

---

作者：满成见
本文根据满成见老师在 2018 年 5 月 11 日【第九届中国数据库技术大会】现场演讲内容整理而成。

　　讲师简介：

　　满成见，猎聘网数据仓库架构师。2016 年加入猎聘网，负责猎聘数据仓库平台架构设计与模型开发，八年数据仓库设计与数据治理项目实施经验。

　　摘要：

　　猎聘网业务规模的高速发展，线上产品与线下销售、客服业务的高度融合，猎头、企业、经理人多角色的招聘生态闭环，多元化与多组织层次的数据统计与运营分析需求...... 在这些复杂业务环境下如何做好数据治理实践的? 猎聘 DIG 数据平台中 MySql、GreenPlum、Hive 多源数据库共存，整合了结构化和半结构化的数据，为实时统计、T+N 的企业管理报表、机器学习提供更适合的基础设施，同时以数据生命周期和数据血缘的管理作为数据治理的两大核心脉络。线上、线下不同业务形态的数据，在时间、地域、组织等不同维度上，在数据产生、成长、下线、归档不同的生命阶段，设置不同的数据监测和管理策略，保证数据仓库中数据的及时性和有效性。通过制定数据标准、规范协作流程、自研监测与预警工具，保证业务数据、数仓明细数据，核心指标等各个数据加工链条节点上的数据一致性和质量可靠性。

　　正文：

　　猎聘网是一个互联网线上招聘业务网站，业务背景主要涉及三方面：内部系统、线上产品以及数据应用。线上产品部分，我们有经理人、企业 HR、猎头等服务产品，今年年初，经理人用户达到四千万，每天客户端和服务端的埋点数据增量大约在 3 亿条左右; 内部系统部分，有 ERP、CRM、EHR 等，客户池的客户量级大概在百万级。我们的数据应用分析也包含了线上和线下两方面，以及实时和 T+1 的分析，针对传统线下业务，为支持公司运营管理，需要跟踪、管控销售顾问和招聘服务顾问的工作进程以及业绩考核，线上数据分析主要包括流量分析、用户获取、转化留存、A/B 测试、产品运维等方面的分析。除了 BI 分析报表，我们猎聘大数据研究院同时担负着数据挖掘和智能决策分析等相关服务。

　　2016 年，我加入猎聘网时所面对的业务困境主要有以下几大方面：首先，大数据团队中没有划分专业的数据仓库团队; 其次，整个数据使用不规范，所有数据应用分析直接从业务表和日志数据一步加工，中间缺乏数据规整和分层处理的步骤; 然后，整个数据仓库近两千张表有 50% 以上的元数据是丢失，这就造成我们对整个数据质量缺乏把控，数据质量完全依靠分析师个人判断，数据问题由下往上发现追溯; 最后， 缺乏数据上下游节点的合作规范和沟通流程。这就是我们当时所面临的业务困境。

　　要想解决这些困境，我们首要解决的问题是数据如何治理，在这方面，我们倒是有一个不错的开端。

　　首先，我们的首席数据官 CDO 非常重视基础数据治理工作，这让整个数据治理理念很好得贯彻执行了下去。做好数据治理前提是要加强流程管控，管控加强的同时必然又会不可避免的降低流程节点之间的工作效率，如果没有公司战略决策层的支持，数据治理将很难从业务部门贯彻到数据部门。

　　其次，我们整个大数据团队的接口层设计非常完善，完整保留了 90% 以上的核心业务数据每天的拍照，这为后续 DW 核心明细层的整合打了非常好的基础。 然后，我们有自己的任务调度系统，可以记录任务之间的血缘关系。

　　数据治理的工作展开，主要考虑三个维度：模型架构、平台技术和流程规范。

　　在模型架构层面，依据传统数据仓库的理论是对数据进行分层管理，每一层进行相应的业务主题梳理，提炼出业务实体、实体之间的关系、实体的业务行为以及这些由业务行为所沉淀出的度量指标。

　　在平台技术层面，首先要有元数据管理系统，其次要有数据血缘追溯系统、数据质量监测系统等，这些平台技术可以帮助我们部分实现自动化管理。作为互联网企业，业务迭代、表以及字段的增加速度都非常快，如果没有好的平台技术支撑，消耗的人力成本会非常高。

　　在流程规范层面，不管平台技术多么先进，整个数据治理过程都不可能百分百覆盖，因此必须保证整个上下游各个岗位、各个序列里所有数据相关方遵循统一的流程规范，对数据的来源、定义、使用方式等有明确统一的原则。

　　上图为猎聘网的整个数据治理流程，首先是梳理元数据，建立数据标准，包括业务用语、业务规则、业务模型和业务指标。同时，对用户行为日志做埋点。这些标准和规范一开始就要落实到文档，最终把文档落实到标准库。元数据库包含数据编码、数据格式、数据血缘、数据访问权限以及数据存储方式。数据标准库的数据是整个数据质量治理的基石。我们在这个标准之上才会衍生规则、制定任务并做预警监控。同时，我们要管控好所有线下数据，一定要保证所有分析相关数据入到线上数据仓库，否则不知来源的数据会给最终数据的血缘追溯制造很多困扰。

　　猎聘网的整个数据仓库架构分层见下图：

　　数据分层管理的核心是根据数据的业务特性和分析特性划分到不同的物理层次中，以到达对数据精细化管理的目的。

　　接口层的核心功能就是要保留所有历史拍照，很多时候企业产生的数据有一部分都是脏数据，但是脏数据的定义可能会有很多标准，如果对业务理解不清楚，你可能会把空值或者异常值都粗略得算为脏数据，但有时这些异常值也会代表一种业务形态，所以，我们在接口层保留了所有历史数据。为了节省接口层存储空间，我们会选择业务表不同的同步方式，比如全量拍照，或者根据业务表的时间戳进行按天增量存储，或者将增量和全量数据合并去重。根据历史增量拍照和每个日期内的增量分区，我们就可以恢复出某个业务表在历史上某天的数据状态，这对结合业务上下游环境进行精准分析非常有帮助。

　　此外，我们在接口层主要做了 MySQL 分库分表整合，数据规范方面主要做了生成唯一主键、编码转换、敏感字段过滤以及数据格式统一等工作。敏感字段过滤主要涉及经理人的联系方式、邮件地址、证件号码等敏感数据。我们不允许这些数据导入数据仓库，如果需要获取敏感信息可以找业务研发或安全部门团队开发统一接口。

　　在 DW 层，主要是根据业务，划分分析主题，提炼业务实体和关系模型，做业务关联整合，业务信息方面除了一些实体和行为指标的整理，还要进行一些冗余设计，屏蔽业务表变化对整个上游的冲击。互联网端的线上业务研发迭代速度非常快，每两周就会有一次大产品迭代，对应的业务表和业务字段都会有变更，数仓工程会在 DW 层完成对业务变更的适应调整，对下游应用分析屏蔽具体细节，保证整个数据的一致性和完整性以及指标的统一性。

　　在 DM 层，我们的主要工作是决策层核心报表与部门级集市报表，使用 Hive 保留原始加工数据，MySQL 支持 T+1 报表，Greenplum 支持 10 分钟以内的实时业务分析。

　　上图为猎聘网自主研发的大数据管理平台，包括元数据管理平台 Octopus、任务调度系统 Leo、数据质量稽核系统 Raven 以及数据同步系统 Mule。

　　按照传统数据仓库理论，我们会将元数据管理分为业务元数据和技术元数据两部分。业务元数据是指业务对象、业务关联以及业务规则，业务对象可能落实到我们的业务表或者业务字段，业务关联指业务实体之间在业务关联，业务规则要根据不同的业务部门进行提炼总结。

　　技术元数据主要分为数据生命周期、数据血缘等部分。数据生命周期就是指所有数仓数据的创建信息、变更历史以及销毁信息等工作; 数据血缘负责任务之间的依赖、表与字段之间的依赖等; 其他信息，比如数据仓库里的数据安全等级和使用热度等。

　　以下着重介绍数据生命周期管理部分。猎聘网之所以强调数据生命周期管理，是因为我们互联网的业务背景。如果不做好数据仓库的入库、上线以及停更工作，我们将很难判断整个数据仓库中各表是否可用、出了问题之后应该找谁负责等。举例来说，我们经常面临一些周年或节日活动，此时可能会集中出来一批表用于维护活动信息，待活动结束，这批表肯定面临着下线问题。这种情况下，我们要做好表的生命周期管理，保证整个数据仓库数据的实时有效可用。此外，所有数据入库必须通过前端工具完成，不允许在后台通过服务器端以人工脚本执行的方式完成，因为一旦这张表出现问题，我们将很难确认责任负责人。我们会在入库时同步创建表接口，在接口中强制填写入库表的责任人、业务注释、业务归属线、业务参照关键状态等信息。

　　如果部分表没有业务属性存在，或者不再有用时，我们需要对表进行停更操作，主要有三种方式：物理删除、归档和保留。物理删除主要用于临时表，当这些表不在被需要时，我们会进行物理删除以节省存储空间，但是这类表比较少; 归档相当于在数据仓库里对业务用户不可见，这些表的特征是暂时不具备分析价值但未来可能会再次查阅; 保留状态则时对用户可见，这部分表的特征是虽然暂时下线并停止更新数据，但其作用是无可替代的，需要保留一段时间。

　　接下来是数据血缘影响的管理。数据血缘关系主要指表与 ETL 任务、表与数据表、表与数据表的字段、表与埋点事件、表与 UDF 函数、表与指标、表与报表之间的关系。

　　数据血缘是 ETL 的 DAG 图、任务优先级制定、销毁上游对象约束、质量稽核影响性以及打通各平台工具的脉络。以任务优先级举例来说，数据血缘关系是任务优先级设定的重要参考指标，通常，任务的优先级由任务创建人制定，但同时也需要我们根据数据血缘重新赋权优先级系数，以保证真正核心任务的优先级。为了避免错误操作，我们每天都会在固定的时间对数据血缘进行检查，确认所有 ETL 调度任务依赖的表是否存在，如果不存在，就会报错并通知相应人员做一些变更和修改。

　　在数据质量稽核部分，数据质量稽核系统会对整个数据仓库里面的库、字段、指标以及埋点数据做相应的质量稽核，并针对业务规则设定阈值，每天晚上任务调度系统工作完成之后开始启动，一旦监测到疑似错误的问题存在，邮件以及短信回发到对应的任务责任人。

　　以下是整个数据质量稽核规则与流程：

　　通过时间序列分析可以在一定程度上提醒业务责任人数据可能出现的波动性异常。拿我们招聘服务网站而言，有所谓的” 金三银四”，每年的 3/4 月会有较大的业务提升，时间序列分析可以将这些业务正常波动考虑在内。在键属性这边会对业务的表字段做一些非空、唯一性以及数据参照集合。对业务和数据的合法性，比如主从一致等进行很好的规范，所有码值业务表字段必然在 Java 代码中有枚举类与之对应，我们会在对应的表之间做映射关系，从代码里面获取最新自检值，以判断字段的注释和值是否正确。在统计属性方法中，我们会根据数值是离散值还是连续值采用不同的稽核规则，如果是离散值，我们会继续考察分布占比情况，如果中间出现某个值的占比突然降低或升高，或者主营业务数据突然降低，会判断该数据可能出现错误。如果是连续值，则主要考察极、均值、分位数等，同时也会结合数据的标准差和方差来检查数据分布是否合理。

　　指标稽核主要是业务规则和交叉校验两部分工作，业务规则主要指表责任人和使用者如何定义指标的波动范围。当然，我们也会从其他角度校验，但凡一个指标统计来源肯定不止一种方式。如果是站在报表引用和分析的角度，我们必须要有统一的途径， 但可以利用其他途径做参考校验。交叉校验就是通过不同的方式加工同一个指标，然后判断指标的相关性，如果数据的差异不在同一个量级，那么实际上这个数据是有问题的。比如新增用户数指标，我们可以通过埋点和业务表信息两种方式进行创建。当然，这种方式无法覆盖数仓中的所有表，只针对各个公司或者各个事业部关注的一些核心指标应用。

　　我们目前也正在探索通过数据质量稽核应用生成数据质量报告，并将报告抄送给我们的业务和研发人员，让更多序列的人参与进来并关注稽核结果。

　　我们需要强调数据安全。随着猎聘网的不断发展壮大，整个体量相对来说比较庞大，各项业务形态或者说管理标准都已成熟，但业务体系实际上比较复杂，尤其是涉及销售和招聘部分，我们需要严格把控整个数据安全管理过程。

　　数据安全主要涉及安全标准、数据粒度、用户行为和审批流程四个环节。在安全标准方面，又可细分为个人隐私、业务敏感、财务数据、部门隔离和等级区分几部分。所有的个人联系方式等隐私数据并不会传入数据仓库，我们会在数据入仓时进行校验，对个人隐私数据、业务敏感数据以及一些财务数据实行不入仓原则。部门隔离实际上在整个公司发展过程中，我们发现不同事业部之间的数据可能是不希望共享的，因此我们需要针对业务进行初步隔离，同时针对所有数据进行安全等级区分。我们目前主要分为两个等级权限，一是查询权限，一是下载权限。

　　在数据粒度层面，我们主要分为 schema、表级、字段级、任务级以及接口级。用户行为主要分为任务查询、表查询、明细数据下载权限以及邮件内容。审批流程层面主要分为自动解析、系统提醒和人工审核三部分。

　　总结以上，我们整个数据仓库团队和工程师一起搭建了数据治理体系，包括元数据管理、数据稽核工具与配置、数据血缘影响与分析、数据异常通知与预警、指标管理工具与配置、数据服务接口提供。但是整个数据上下游的治理必然不是数据部门自己的事情，而是要产品、研发、数据一起合作完成的。只有这样，数据才能更好的为产品赋能，产品和运营团队才可以更好得分析数据，由数据完成智能驱动业务高速发展。

　　经过两年多的不懈努力，猎聘网目前已经实现定时监控上游数据结构与质量问题，发现问题当天跟进处理，保障 90% 以上的核心报表与数据应用的稳定与可靠性; 模型分层，统一了下游引用出口，上游系统升级改造，影响截止到 DW 层，节省分析师 90% 以上的资源投入; 元数据完善 95% 以上，数仓知识体系与数据标准构建完毕，业务与数据学习使用效率极大提升。
来源：it168

---

---