经过十多年的发展，数据治理在传统行业以及新兴互联网公司都已经产生落地实践。字节跳动也在探索一种分布式的数据治理方式， 将从以下四个部分展开分享：
● 字节的挑战与实践
● 数据治理的发展与分布式
● 分布式治理架构
● 分布式治理核心能力
首先来看一个问题： “一家公司，数据体系要怎么搭建？”
● 方案一： 整体规划，系统架构驱动
● 方案二： 问题出发，业务价值驱动
在字节跳动，我们选择的是方案二，即从业务遇到的问题出发，重视落地结果与业务过程，去解决实际的治理问题。
基于这个理念，在数据治理过程中， 字节跳动也面临以下三个挑战与机遇：
● 业务特点： 业务发展快、场景丰富、数据量大且形态各异。业务的线上服务及创新，都对数据有较强的依赖，核心业务数据延迟，质量问题将直接影响业务表现及发展。
● 组织特点： 扁平化的组织模式，分布式的组织管理。无行政手段或强组织约束，也无全局治理委员会，且数据从采集到应用全部的生产流程，没有全局规范，业务团队需要自主制定策略并落地。
● 文化特点： OKR拆解与对齐文化，业务团队有充足的目标定义与拆解权限，且任何人都可能有动机、有角色、甚至有权限去进行数据治理，导致数据治理的业务流程复杂
/ 字节数据治理演进阶段 /
字节数据治理演进阶段分为6个阶段：
1.业 务第一原则： 坚持业务第一原则，解决业务实际遇到的治理痛点
2. 优先稳定建设： 优先解决交付稳定，保障数据链路与产出稳定，减少交付延迟
3 .保障数据质量： 核心链路质量管控，配置强质量规则，自动熔断，避免全链路数据污染； 加强事前检查，从源头加强质量控制； 完善事后评估，为每一张表建立健康档案，持续改进。
4. 关注数据安全： 冗余权限识别，消除授权风险； 数据分类分级，风险定义与多策略控制，减少安全风险
5. 重视成本优化： 基于多种规则的与完备的治理元数仓，提供低门槛的治理产品能力，快速优化存储
6.提高员工幸福感： 在帮助业务完成数据治理的后，还需要考虑团队的负载压力，报警治理，降低员工起夜率；归因分析，快速排查修复故障。
在这里，再介绍字节特色的“0987”量化数据服务标准。这四个数字分别指的是：稳定性 SLA 核心指标要达到 0 个事故，需求满足率要达到 90%，数仓构建覆盖 80% 的分析需求，同时用户满意度达到 70%。
按照这个高标准来要求自己，同时这也是一种自监管的机制，能够有效的防止自嗨，脱离业务需求和价值。
/ 字节的部分场景实践 /
下面通过 两个例子 为大家介绍数据治理在字节的场景实践。
案例一：
问题： 字节跳动内部2019年到2020年间，双月内事故数量较多，对业务造成一定影响，且收敛困难，每天都有告警、起夜、对正常开发进度造成影响。
解决方案： 采用了分布式用户自治的SLA治理，通过数据分级保障目标管理，在各业务内部进行【拉齐链路-数据分级-广泛共识-系统管理】的行动闭环，系统化保障目标传递和落地。
效果： 截止2020年中，事故以每双月30%环比下降，在1年内达到稳定性问题彻底收敛。
案例二：
问题： 抖音的实时数仓治理人员的精力分散，以被动的运动式、“救火”式的工作模式为主。协同效率低，人力投入巨大，缺少可持续性。
解决方案： 覆盖质量、成本、SLA、安全等治理方向，以业务评估体系，构建治理方案进行例行诊断，对存量问题进行识别和派发，形成一套【评估->识别->规划->执行->复盘】业务内部分布式自治的治理机制。
效果： 从21年至今，治理人员的精力彻底从”运动式“治理的模式中解放出来，更多精力会集中在监督执行与规则优化中，团队起夜率降低30%。质量保障覆盖率达到100%。双月存储优化均在20+PB。
众所周知，有很多机构都分享了对 数据治理的定义 ，这里简单分享一下。
国际数据管理协会（DAMA）： 数据治理是对数据资产管理行使权力和控制的活动集合。
IBM： 数据治理是对企业中的数据可用性、相关性、 完整性和安全性的全面管理。它帮助组织管理他们的信息知识和作为决策依据。
维基百科对数据治理的定义 ： 数据治理是一个涉及全体组织的数据管理概念，通过数据治理，确保在数据的整个生命周期中拥有高数据质量的能力，也是对业务目标的支持。
数据治理的关键的重点领域包括可用性、一致性、数据完整性和数据安全性，也包括建立流程来确保整个企业实施有效数据管理。
在传统的数据治理方法论与定义中，注意到他有以下共性特点， 同时也是现在大多数公司的实践路径 ，即：
但是在实际的执行过程中，他需要以下 几个前提 和随之带来的 落地难点。
1. 需要明确组织制度
梳理业务数据部门，设立公司级别数据治理委员会/部门，各业务分设执行部门，公司内各业务宣导讨论，统一制定公司数据治理规章制度。
难点一
组织依赖重、建设周期长。需要招聘大量专业的治理专家或引入外部咨询机构，计划制定周期长；专设部门牵头，若无自顶向下的项目背景，业务协调对齐困难。
2. 需要明确权责管理
梳理公司数据资产，迁移、拆分、业务改造。确保资产归属与治理权责明确，定期梳理资产类目，维护资产元数据的有效性，确保治理边界清晰
难点二
业务影响大，目标对齐难。需完成存量的资产归属划分、改造生产开发体系，对增量定期人力打标，确保资产归属与权责边界清晰，因可能业务系统改造，会对业务发展造成影响。
3. 需要进行复盘抽查
管理组织定期检查各业务治理过程是否符合公司治理制度，定期检查各项治理结果是否落地，线下复盘与推动不符合预期的治理过程。
难点三
沟通成本高，执行推动难。如何制定适用于不同业务特点与发展阶段的团队的治理评估体系，各团队是否认可评估标准。
为了解决以上三个问题，我们有些新的思考， 通过火山引擎大数据研发治理套件DataLeap推出「分布式」的理念。
Governance一词在根源上同Government，1990年代被经济学家和政治科学家重新创造，由联合国、世界货币组织和世界银行等机构进行传播。
其核心有以下两种论述：
● 第一个论述： 标准与规范。指的是一定范围内的一致的管理，统一的政策，某一责任区指导以及合适的监管和可问责机制。这种行政力的集中化管理存在一些问题，比如决策成本高，人力投入高、落地阻力大，精力消耗大。
● 第二个论述： 过程与结果。指的是只要关注结果和产出以及业务内部实践，通过分布式协作让业务的治理结果、业务痛点和治理方式及手段在内部闭环，而不是由中台层面统一推动。
我们尝试从第二种论述，即重视过程落地和治理结果产出的出发，更快的落地产品，落地数据治理的产品解决方案。
/ 从集中式到分布式 /
基于分布式的数据自治的理念，我们来解决在 落地执行 上的两个最困难的点。
一、组织制度分布式： 尝试将组织的强管理属性转换到监督属性，治理单元与制度设计回归到业务单元。好处是，不强依赖横向中心化组织，业务治理痛点闭环在业务单元，且业务基于自身发展阶段制定治理目标，ROI论证回归业务。
二、权责验收分布式： 基于产品体系与落地解决方案，支持业务按需自驱，市场化执行，平台辅助与按需验收。好处是，无须长周期的资产类目梳理，业务系统改造，权责均由业务区分，基于业务单元与多维视角，按需验收治理结果，业务单元内对齐。
如上图展示的饼图，对于一个公司的数据资产，传统来说，可以很清晰地按照业务边界来划分清楚。
对于分布式数据治理，我们通常是由业务单元自行认领，业务单元A自行认领属于自己部分，业务单B也自行认领属于自己部分。认领就意味着，所有治理的动作包括结果，安全性、成本、质量、稳定都由认领业务单元负责。
当然，这样这样也可能存在两个问题， 不过在分布式的理念中能够得到较好解决。
第一是认领范围重合： 这种情况往往让业务在线下对齐是否需要去做改造和划分，各自拿到自身需要的治理结果，短期无须重人力投入，不追求绝对的边界划分。长期因不同治理验收需求或团队管理需求，自行进行资产归集和整理。达到动态的平衡状态。
第二是无人认领： 针对长期无人认领的资产，我们可以基于每个业务的历史的规则和能力，形成一个治理的平均线，再从平台层面推动无人认领的资产治理，由于无人认领，这样的资产推动起来相对较快。
/ 我们理解的分布式治理 /
定义：DataLeap以业务单元为数据治理闭环单元，通过完善的产品工具，将管理视角转化为监督视角，解决数据治理落地痛点;各业务团队分布式自运行，整体上达到全局最优， 从形态上，适配更多业务特性和发展阶段，从效果上，强推进重落实与结果。
DataLeap通常以业务单元作为一个数据治理闭环， 即在业务单元内部完成数据稳定性、质量、存储、计算等治理。同时每个业务单元不是孤立的，也有相互协作，比如A业务单元的数据治理经验可以沉淀为治理模板，供后续其他业务使用。
这样的分布式治理方式，有以下一些优势：
● 影响小，依赖小。 治理下放到各个业务中，各级业务乃至个人都能自驱治理，业务根据自身发展阶段灵活组合治理工具，无须对组织强依赖。
● 周期短，见效快。 业务自驱梳理核心数据及链路，跨团队对齐线上化、协议签署、过程追踪。治理周期显著缩短，很快就出成效，增强团队信心。
● 效率高，省人力。 SLA治理提高跨团队协作效率，聚焦核心数据任务集中资源保障，集中精力，报警归因减少起夜，帮助企业节省年度人力消耗。
● 算清帐，降成本。 各业务口径的存储计算资源消耗、核算成本，制定降本目标并追踪落地；业务经验规则化、策略化、自动化、自驱化持续降本增效。
为达成业务分布式治理，DataLeap对用户行为路径完全覆盖，对业务经验完全接，并提供完善的开放能力，协助业务进一步提效 。
/ 产品体系 /
以上关于分布式的理解，下面将介绍 DataLeap分布式治理的产品体系。
从DataLeap治理门户来看，包括治理全景、工作台、规划、诊断、复盘等全流程治理环节。在治理场景中，提供数据质量安全、资源优化、报警、企业复盘管理等一系列垂直场景。在底层，包含数据全生命周期流程，从数据采集、数据传输、数据存储、数据处理、数据共享到数据销毁。
/ 治理双路径 /
为了把用户所有治理经验沉淀为平台能力， DataLeap抽象了2种治理路径。
第一种是规划式路径。 这是一个比较常见的规划式路径，即从看板和报表出发，自上而下做规划。比如看板已经反映出成本增加、延时变长或者数据质量变差，团队管理者发起报告或事故，推动业务单元同事进行数据治理，最后进行复盘。
第二种是响应式路径。 比如生产者收到一个数据质量或延时的报警，随后快速定位原因并做改进计划。
为了更好把业务经验全部线上化，我们通常双路径并行使用。
1.规划式治理路径案例
首先看DataLeap通用模块资产视图，包括资产增量情况评估等，以及业务对于资产的评价，如健康分体系。我们通常根据资产情况去制定目标。如果发现问题之后，业务驱动制定目标，可能是降低存储。
同时需要去应用一些业务规则，比如团队内部认为 TTL(数据生命周期)很重要，需要帮助识别出来的同时也需要设定一个诊断周期。在团队方案确认完之后，产品会做监督，包括定义提醒，同时也推动资产owner完成总结。
2.规划式治理路径案例
例如，我们发现一些任务在深夜执行失败了，需要先做问题排查，发现问题是HDFS丢块导致。在传统情况下，解决方案是去检查API 问题，再去拉相关人员，可能2- 3 小时才能完成，最后配合监控并收归到 wiki 中。 而在DataLeap数据治理产品里，可以直接实现归因打标等能力，最后快速复盘。
/ 治理全规则 /
如果要覆盖业务的全部属性，治理平台需要形成有效且全面的规则模板。
目前，DataLeap规则模板包含两个部分：
第一是规则引擎，具体包括 业务输入、平台输入、推荐输入。
● 业务输入： 主要依据业务团队的治理经验以及行业经验。
● 平台输入： 平台会提供一些基础能力，如存储、计算、质量、报警等几个维度。截止目前已经提供了80多个规则。
● 推荐输入： 基于业务输入和平台输入，去做分析和挖掘，发现哪些规则用得多、哪些规则阈值更合理。
第二是治理数仓，具体包括 行为数据、治理操作、效果数据。
● 行为数据： 包括用户规则配置等内容是否有重复以及带元素标签的资产数据等。
● 治理操作： 包括生命周期、任务关闭、数据删除、SLA签署等。
● 效果数据： 包括操作收益、资产收益、指标收益等。
/ 不同业务快速灵活接入治理规则 /
分布式自治基础是要构建治理生态、建设开放平台，让不同业务能够快速、灵活接入。
为了让业务能快速介入，DataLeap把数据分成了四种类型： 表达式、三方元数据、标准元数据、算法包。 针对不同的业务，根据当前的经验和能力，我们会提供不同的接入方式，让业务去更好把规则和能力去接入到我们的平台。
/ 基于业务单元进行智能化提效 /
在获取不同业务的规则和能力之后 ， DataLeap通过平台完成能力沉淀， 把好的规则和能力复用给更多业务。
Case1： 任务SLA签署推荐。基于运营时间做权重分配，保证下游任务运行完成，同时也会进行关键链路分析。这个规则目前在字节内部广泛使用。
Case2： 动态阈值监控。这是基于业务在报警阈值上的实践提取的规则。
Case3： 相似任务识别。通过序列化和向量化操作，去和底层 spark 引擎做配合。在业务内部应用覆盖99%，且优化任务都千级以上，由此接入平台并推荐给其他业务。
/ 治理全景-分布式验收 /
在分布式验收中， 会区分为全员视角、团队视角和个人视角。 全员视角可以看到公司级资产，包括整体的健康分体系以及核心指标。团队视角中，主要由业务自己梳理，包括内部的评价体系。
/ 治理工作台-集中治理待办 /
上图为个人工作台功能，主要为了把SLA保障、计算任务、数据存储等治理场景展示在一个页面，方便 owner 业务全局查看治理待办事项。
/ 治理规划与诊断-权责与规划分布式 /
第一， 支持自定义治理域，灵活自治，提供多种维度，自定义组合和圈选资产范围。
第二， 支持创建治理方案，例行诊断：发起人基于业务需求，选择治理域，设计治理规则，发起存储/计算/质量等类型治理方案。例行诊断与推进实施。
第三， 支持规则管理，提供80+治理基础规则，支持自定义组合和配置规则与分享。
/ 复盘管理 /
复盘管理是一个通用模块。 业务根据自身需要去识别任务是否需要复盘，或者仅仅做问题登记。
除此之外，业务还可以用复盘管理能力做内部管理，比如查看、检索所有的事故复盘，查看每个事故发生的原因和改进计划。同时，也可了解归因分布情况，并帮助下一个值班同学快速反馈和定位问题。
/ SLA治理 /
在字节跳动内部，SLA不是平台级保障，而是源于业务团队内部。 首先是业务按需申报，可能是PM、运营或数据研发等任何角色，认为自身任务重要，填写背景、原因、等级、时间等信息之后，即可发起一个SLA。
发起之后，在团队内部进行审核，可能存在同一个团队多个高优任务的情况，这由团队内部自行调整优先级。同时，这个也是跨团队判断该任务重要性的标准。
之后是完成签署，签署也会在产品里面体现出来。每个节点时间都有实时监控，如果产生了延迟，会推动业务做复盘和登记。我们也提供基础的DAG，包括申报业务单的查看，同时也可以让大家去查看每个等级的破线情况，以及团队对业务的服务情况。
/ 数据安全 /
在数据安全层面，主要专注于清理冗余权限，完善分类分级。不同团队对冗余权限定义不同，有的90天无访问算冗余权限，有的70天，有的7天。 因此我们提供自定义能力，由业务内部发起review，完成冗余权限的识别和定义规则，识别之后复用诊断能力。
/ 资源优化 /
基于每个团队实际执行情况，提炼出一些通用的规则。 例如，某些规则可能有几十个业务在使用，近 90% 认为近 30 天无查询需要被识别出来，我们就会在平台中提供这类能力，方便新业务或者小白业务去使用。
/ 报警归因 /
在报警归因方面，我们能提供所有报警明细，方便查看是否有重复规则，是否有高频报警规则，帮助用户发现无效报警和重复规则，降低告警量和跟起夜率。除此之外，我们也提供业务内部的归因登记和分析能力。
以上是字节跳动在数据治理相关实践。
目前，字节跳动也将沉淀的数据治理经验，通过火山引擎大数据研发治理套件DataLeap对外提供服务。作为一站式数据中台套件，DataLeap汇集了字节内部多年积累的数据集成、开发、运维、治理、资产、安全等全套数据中台建设的经验，助力ToB市场客户提升数据研发治理效率、降低管理成本， 欢迎大家点击“阅读原文”来体验。
产品介绍
火山引擎大数据研发治理套件DataLeap
一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。 后台回复数字“2”了解产品。
