导语 | 本文推选自腾讯云开发者社区 -【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与宽泛开发者打造的分享交换窗口。栏目邀约腾讯技术人分享原创的技术积淀，与宽泛开发者互启迪共成长。本文作者是腾讯高级开发工程师杨波。
本文次要总结集体在数据安全分类落地过程遇到问题的教训，心愿本文能对此方面感兴趣的开发者们提供一些教训和帮忙。
背景
随着《数据安全法》、《个人信息保护法》等相继出台，数据安全回升到国家平安层面和国家策略层面，数据分类分级曾经成为了企业数据安全治理的必选题。然而数据分类分级的实现在行业内有很多痛点，次要体现在如下几点：
- 规定制订简单：数据进行分类有多种维度，不同维度各有价值。在不同行业及畛域，甚至具体到每个企业和部门，针对不同级别数据也各有定义。维度、级别的不清晰会导致后续基于分类分级的很多合规管控存在问题。
- 协调沟通老本高：企业规模一直宏大，组织架构也随之变得复杂臃肿。数据的扫描上报关联到多个部门和事业群，甚至子公司。这波及到多人之间的协调沟通，还需思考网络隔离，拜访权限和审批等诸多问题。
- 数据容量大：互联网时代到来，企业信息化建设始终高速倒退中，业务零碎也越来越简单。随之产生的海量数据，给企业带来微小的价值。相应一旦海量数据透露，也会给企业造成重大的结果。如何实时，高效，全面笼罩海量数据分类分级，这对技术架构是一种考验。
- 存储组件多：互联网尤其是云计算时代，企业为了应答大流量高并发业务场景，诞生关系型，非关系型，对象存储等多种存储组件。这既有开源实现，也有企业外部自研。不同的实现，有着不同的传输协定和数据结构。要笼罩多种存储组件数据分类分级，须要大量的工作量。
然而查阅公司内外很多材料，往往只着重解说数据分类分级概念与规范。目前并未有可借鉴，可落地的分类分级技术实现参考。因而本文重点不在于探讨数据分类分级的规范制订，而是从技术层面来讲述一种通用能力形象封装，海量数据辨认，跨部门和平台数据接入的分类分级架构实现。将数据分类分级技术进行赋能，防止反复造轮子。并以此为根底来从理论角度满足数据安全合规工作的落地和推展。
注：数据分类分级介绍参考数据安全治理：数据分类分级指南。
数据安全业务流程
（一）业务层面
从业务层面看，以数据分类分级作为数据安全的基石，来对数据进行平安管控，比方数据加密，数据脱敏，数据水印，权限治理，平安审计等。可见数据分类分级对数据安全的重要性。
（二）技术层面
从技术层面看，将数据扫描上报，通过数据辨认引擎进行辨认。然而在理论落地过程中，却发现很多问题。比方存储组件品种多，上报数据流量大，以及时效性，准确率，覆盖率等等问题。
整体架构
通过一直对数据分类分级业务剖析，设计如上数据分类分级架构。架构外围由五大块组成：
- 多种存储组件数据扫描上报工具。
- 数据辨认服务集群，对立接管上报数据，并进行数据辨认。
- 辨认规定引擎，对立保护辨认规定的治理，在线热更新等性能。
- 数据中台，依靠分类分级后果，进行数据安全管控。
- 依靠公司的根底框架能力，保障引擎服务的高可用，比方监控，告警，日志，弹性扩缩容等。
其中重点要解决前三点。
海量数据实时辨认
企业规模一直宏大，海量用户，必然产生海量数据。如何满足高性能，时效性同时，又能达到高正确率和覆盖率要求，对于零碎架构是一个微小考验。
（一）数据存储
PCG 目前笼罩近二十种存储组件类型和平台，三千万张表，以 mdb，cdb，tredis，苍穹为例：
存储选型
从表格可见，仅 mdb 已超过五百万张 MySQL 表，而 cdb 甚至超过一千万张 MySQL 表。而一张 MySQL 表即对应要保留一条分类分级辨认后果。MySQL 单表数据倡议在五百万左右，超过这个数据量倡议通过分库或分表处理，这在电商我的项目一些场景是可行，比方交易订单数据。但这也会带来经典的分布式事务等问题。
因而须要抉择一种满足大容量，高并发，高可用和事务 acid 的数据库。
大数据 hadoop
hadoop 作为经典大数据存储架构，可存储 pb 级别以上数据，但时效性不高，通常用作 T + 1 离线工作 olap 场景。且 hadoop 对事务 acid 反对无限，无奈满 oltp 场景。
tidb
tidb 是一款分布式海量容量云原生 newsql。tidb 底层应用 raft 算法，实现数据分布式存储和保证数据一致性。同时兼容 MySQL 协定，反对事务。因而 tidb 满足要求，然而公司目前没有专门团队保护 tidb。
云原生 tdsql-c
tdsql- c 是 TEG 自研的一款的数据库。tdsql- c 对 MySQL 架构做了改良，将计算和存储拆散，从而实现存储和计算资源的疾速扩容。因而 tdsql- c 反对 MySQL 协定和事务，同时具备高性能等个性。且公司目前有专门团队保护 tdsql-c。
存储比照
从表格可见 tidb 和 tdsql- c 满足需要，但 tdsql- c 有公司外部专人保护。因而抉择 tdsql- c 来存储数据分类分级辨认后果。
（二）数据接入
服务端须要对接多种存储组件平台的数据上报，不必平台对资源，性能，时效性有不同要求。因而实现 http，trpc，kafka 多种接入形式，以满足不同场景。
kafka 传输大数据
kafka 能够实现生产端失败重试，且能够对流量进行削峰，举荐应用 kafka 进行数据上报。
为了保障辨认后果正确，对关系型数据库单表取 200 条数据上传。大数据存在一些宽表或者大字段，导致上传的数据超过 1M，这超过了 kafka 默认配置。除了限度上传数据包大小以外，也须要对 kafka 配置进行优化。
kafka producer
max.request.size=1048576（1M）
batch.size=262144（0.25M）
linger.ms=0
request.timeout.ms=30000
因为音讯数据包比拟大，因而不心愿音讯常驻 producer 内存，造成 producer 内存压力，因而让音讯尽可能疾速发送到 broker 端。
kafka consumer
fetch.max.bytes=1048576（1M）
fetch.max.wait.ms=1000
max.partition.fetch.bytes=262144（0.25M）
max.poll.records=5
topic partion>=20
retention.ms=2
因为音讯数据包比拟大，且 consumer 生产音讯须要几百秒提早，缩小批量拉取音讯数量同时进步拉取音讯等待时间，防止 consumer 频繁去 broker 端拉取音讯，导致 consumer cpu 被打爆。\
优化成果
数据辨认
在解决数据上报，数据存储，数据接入当前，便是数据辨认。这是整个数据分类分级架构最外围也是最简单局部。对数据辨认过程次要分为数据映射，规定治理，权重计算，数据校验四大块。
数据映射
服务端对单表取 200 条数据进行辨认，按每张表 20 个字段，每个字段需进行 20 种正则辨认。每天假如跑 1 千万张表，一共大略要跑 8 千亿次正则计算。如此微小的计算量，在流量冲击下，立马将服务端的 cpu 飙升到 100%，从而导致服务不可用！！！
绝对于 io 密集型，cpu 密集型无奈简略应用常见的缓存，异步等形式去加重服务端压力。因而须要思考点如下：
- 通过云上 k8s 弹性扩缩容，将流量扩散到多个容器节点，升高单节点负载压力。
- 单节点利用多核并行，将计算压力分担到多个 cpu 核处理器上。并且应用信号量限流，防止 cpu 始终处于 100%。
- 正则表达式优化。藏在正则表达式里的陷阱，竟让 CPU 飙升到 100%！
多核并行
多核并行借鉴 MapReduce 编程模型，实质是一种“分而治之”的思维。
优化成果
规定治理
数据的分类分级，需更精细化的规定治理，能力对后续数据安全做到更正当的管控。规定包含不限于正则，nlp，机器学习，算法，全文匹配，含糊匹配，黑名单等。对应每种具体分类分级定义，又包含多个规定的组合应用。通过理论的经营和梳理当前，目前有近四百种分类分级定义和八百种辨认规定。
因而需思考正当的形式，将规定治理和辨认逻辑解耦，以便后续的保护和降级。同时需思考规定热更新和敞开，做到对线上服务无感知。
权重计算
数据分类分级，在不同行业和业务有不同的维度和定义。且源数据因为开发和运维人员定义不清晰，导致最终辨认后果存在含糊的边界。在理论经营过程中，常会因为辨认后果不精确，被业务方反馈。
假如有字段叫 xid，有可能是 qqid，也可能是 wechatid，而 qdid 和 wechatid 对应不同的分类分级，这会影响后续的合规流程。在理论场景，xid 有可能同时被 qqid 和 wechatid 辨认规定命中，那么该取哪个呢？
因而引入权重的概念，权重不在于将辨认后果做简略的 0 和 1 取舍，而是通过多个组合规定辨认后，计算出一个权重值，并对多个辨认后果的权重值进行排序，取权重最大的辨认后果作为以后字段的分类分级。
数据校验
数据安全合规管控，最重要一项是数据加密。为了不便经营后续进行合规追溯，须要在服务端对以后上报数据是否加密进行校验，并将校验后果保留下来。
数据是否加密需综合判断库表状态等信息，其中包含数据是否加密，表是否删除，库是否删除，实例是否下线等。状态的转换，通过以下决策树示意：
跨部门和平台接入
在重点解决数据上报和数据辨认等难点当前，数据分类分级框架已能够满足大部分业务场景。因而也心愿框架能服务更多的部门需要，缩小大量繁琐反复的工作量。
因为数据分类分级后果属于敏感数据，对于跨部门和平台接入，需思考将数据依据不同部门和平台进行物理隔离存储。
总结
数据分类分级很简单，这种复杂性有业务层面，也有架构层面。本文重点在于述说架构层面的问题。这些问题有些能够提前规划设计，比方存储选型、通用扫描能力等。也有些须要在落地过程中继续优化，比方海量数据辨认，除了对服务自身性能优化，也要对资源老本综合思考。
架构没有好坏之分，只有适合一说。本文所讲述是基于集体在落地过程遇到问题的经验总结。因而重复斟酌，认真梳理写下本文，也是对自己工作的一个阶段总结。同时也心愿框架能失去更多人认可，并达到数据分类分级能力复用，为公司数据安全合规工作尽到一点小小奉献。
如果你是腾讯技术内容创作者，腾讯云开发者社区诚邀您退出【腾讯云原创分享打算】，支付礼品，助力职级降职。