1.机遇与挑战数据治理面临着诸多挑战，最重要的一点是落地难。首先，管理工作与业务存在一定的矛盾。二是治理难度大，组织管理难度大。三是“人”的行为难以规范。在治理过程中，要靠人来推动和落实。人员的能力各不相同，组织文化和目标也不一致。第四，缺乏适应性强的产品工具。由于治理工作范围广、环节长，涉及跨部门、跨系统的目标对接，需要一个完整的产品平台。下面结合字节的特点介绍数据治理的机遇和挑战。字节文化第一，字节有很多业务，多个业务并行发展，需要快速响应业务需求；第二，字节的OKR文化让每个人都参与到数据治理的规划和策略制定中，积极寻求实现路径，快速对接；第三，为追求高效治理，没有统一的数据治理委员会，而是各部门根据各自业务情况进行治理。业务第一字节业务规模大，以数据为驱动构建闭环的产品很多，导致数据质量对业务的影响非常大。综上所述，字节数据治理是一项挑战与机遇并存的工作。2.数据治理思路2.1新数据治理——分布式数据自一致性针对以上问题，提出分布式数据自治思想，综合考虑治理收益、业务影响、执行效率。首先，在业务影响方面，为了保证影响小，治理工作按业务单元进行。作为数据治理的范围和目标，业务部门可能是一个小团队或一个小项目。二是要积累各条业务线的治理经验，提高治理效率；通过产品辅助业务自驱动，实现常态化、战略化、自动化治理。通过工具等平台能力，降低治理门槛。并支持灵活的治理方式，如管理者视角、自上而下的规划治理、一线执行者视角，促进自下而上的治理。第三，要有很强的适应性，打造覆盖治理全环节的产品。在各种场景下，产品具备覆盖能力，多个模块可独立使用，按需组合；并根据自身特点和发展阶段，提供完备的开发能力，支持服务的自对接。2.2集中式VS分布式分布式治理相对于传统的集中式治理有很多优势。集中治理要求建立大组织、权责分工、定期抽查考核制度。建设周期长，适应性弱，组织投入大。分布式自治，业务影响小；周期短，见效快；效率高，节省人力；易于计算业务收益并降低成本。3.技术架构演进基于以上思路，平台工具如何支持数据治理？3.1解决方案——一站式首先提出一站式解决方案。将治理分为三层。第一层——视图层从资产、管理者和实施者的角度提供了数据治理的概览。第二层——程序层提出治理过程的双重路径。路径一【主动策划】策划过程中要解决的主要问题是：目标确定后如何推动实施。将治理目标拆解为治理规则，进行诊断，根据诊断结果实施治理。治理结束后，通过收入统计和改进方案进行总结。路径二【系统发现】响应流程系统发现的问题会通过高度警戒等形式通知资产负责人进行处理。通过根因分析等进行总结。第三层——工具层就是以上两层，提供完善的管理工具。覆盖质量、安全、成本、稳定、告警和唤醒等场景，通过打通基础服务打通以上两条治理路径。3.2平台搭建-治理方案-规划流程下面给大家介绍下我们两条路径在治理流程中的具体搭建流程。路径一：计划治理的目标是资产清晰、规则丰富、动线完整、回报精准。首先，需要制定目标，包括健康子目标和减少存储和计算资源的目标。根据目标，制定治理方案，包括划分治理域，在治理域内通过规则发现问题资产。计划建立后，系统会查找存储、计算等问题的明细。对以上发现的问题进行分析，通过消息提醒等方式将问题发送给责任人进行治理。系统会收集治理效果，反馈目标达成情况，并对一段时间内的治理结果进行统计统计。以上就是策划过程的主要思路。下面介绍如何实现规划过程的几个目标。3.2.1资产清晰度资产主要从治理全景和健康两个方面进行描述。一是治理全景。通过细节和统计，从各个维度描述团队或个人资产的具体情况。比如每张表占用多少存储空间，计算资源占用，任务报警率，唤醒率，数据时效和质量等。第二，衡量资产健康度。健康子系统按三个层次建立。第一层按照治理的垂直方向划分，包括：存储健康分、计算健康分、质量健康分等。第二层细化第一层维度下的问题类别。如存储，包括：无效存储、异常存储等；质量，包括：时效性、告警、元信息配置规范等。在第二层的划分下，通过标签定义具体问题，得到第三层。例如，在无效存储方面，涉及不合理的TT和流行信息（xx天未查询）等。综上所述，资产主要通过健康全景和治理全景清晰表达。通过元数据仓库，进行底层数据的构建。3.2.2规则丰富目前平台治理规则完备，涵盖存储、计算、质量、告警四个维度50余条规则。其中包括全局规则，例如：永久生命周期、近7天空输出、暴力扫描任务等；还包括一些自定义规则，比如生命周期xxxt天，过去xxx天空输出等。同时它还有一些挖掘规则，包括根据统计信息聚合后形成的规则，以及基于相似度的规则资产（包括库、表等），可以通过关联和排序发现问题。规则部分和能力建设分为以下几个部分：首先，通过底层与平台基础组件的连接，收集数据，形成数据仓库的基础层；基于基础层，对数据资产进行画像描述，进一步形成特征域，进行特征挖掘和关联分析；然后将应用数据放入数据服务中，对外提供灵活的数据查询能力。最上层是组合在线规则引擎，将数据和规则联系起来，应用到规则构建中。3.2.3动线彻底标记问题资产后，尽快完成治理，减少与业务的冲突，提高效率非常重要。基于治理平台的能力，我们在各个垂直场景建立了比较完整的治理线。总体思路是将能力分为几类：任务管理、任务开发、任务运维平台打通、支持任务关闭、调整、参数调整、链路优化等；库表规范，与元数据平台联动，实现表管理、库管理、资产转移、属性修改等；在生命周期方面，通过治理平台，与底层存储（包括hdfs、hive等组件）打通，形成闭环治理；在数据质量方面，包括sla的时效性，离线和实时数据的监控，会和具体的质量规则平台强链接，互相注册数据，签订sla，和强跳交互等。以上是动线的完整部分，可以让用户以极低的运营成本在平台上完成一站式闭环管理。3.2.4盈利准确度第四个是盈利的准确部分。我们做了治理之后，对于我们付出的成本和精力，怎么知道它是有效的还是达标的呢？如何衡量这个阶段的工作是有价值的，治理是盈利的？这就需要准确衡量平台建设的效益。目前已经搭建了基于事件中心的统一底层框架。通俗的说就是定义数据的消费模型，通过上面的一些消息通道定期收集各个平台的操作消息；同时定义了事件的SDK，兼容API的方式，灵活对接不同的上游平台。目前我们大部分的研发平台、元数据平台、质量平台等，都是通过消息订阅和消费的方式，将治理事件连接到事件中心，将事件中心的离线数据dump到数据仓库进行离线处理，以及同时，我们会将最新的事件注入到在线元数据服务中，及时完成治理收益的计算。3.2.5技术架构在规划过程的技术层面，遵循以下原则：统一数据查询、灵活组合各种规则、耦合操作、精准治理效益。整体平台后台将负责分发和转换各种治理逻辑，包括统计、设定目标、展示和揭示健康分数以及治理操作。后台平台收到消息后，会拆分具体的事件。比如在看板类查询部分，将需求统一发送给查询服务。数据查询服务将适配底层存储。通过pointcheck、list、aggregation类型的查询，根据底层选择的存储引擎的特点，分析后，选择不同的底层存储。规则引擎服务部分可以与数据查询服务对接。通过数据查询服务获取数据后，通过定义规则形成标签。这个过程可以抽象成一个服务。该服务可以作为通用能力对外提供资产标签的描述。在治理的具体实现部分，我们将其抽象为一个后台模块。具体的实现，如设置消息、设置ddl、删除等，由本模块统一下发给组件层进行操作。在组件层或其他平台进行有效操作后，事件收集服务收集事件，写回数据查询服务，形成治理收益的总结。3.3平台建设-治理方案-响应过程第二条路径是响应路径。主要做事后治理、问题总结、经验积累。在这条路上，大致分为几个部分。首先，警报和消息被用作源。包括sla断线告警、数据质量任务告警、计算任务告警等，系统会对以上信息进行汇总，展示在治理平台上。治理平台可通过消息搜索、问题属性归属、根因标注等方式定位组件和平台问题；或者召开会议，向相关责任方提出问题，推动他们做出一些有针对性的保证。经过以上进展后，我们将在系统中列出问题描述和改进方案，有针对性地界定问题，分析如何做才能达到事后治理的目的。最后，在问题解决后，促进解决方案的共享、沉淀和复用。3.3.1技术架构响应式治理的架构与计划式治理类似，区别在于消息服务部分。该部分作为基础能力，将大数据平台各个产品的消息，包括研发平台和质量平台，全部接收到一个统一的服务中，所有的消息都通过该服务发送出去。此消息服务成为所有警报消息的入口点。通过它可以实现一些升级策略，比如消息聚合、催发等。另外，类似计划治理，后台平台控制响应路径的逻辑，包括消息订阅、问题注册、总结审核模块等。其他部分与规划路径类似。3.4平台建设——开放接入说完两条路径，下面是一些实践中的解决方案。因为企业有自己的发展阶段和不同的治理目标。比如对于比较新的业务，主要关注的是SLA能力；一些成熟的业务，现在做的比较好，需要标准化。不同的企业有不同的要求。如何避免一刀切，让不同的业务使用平台进行治理，开放性很重要。开放能力意味着构建治理生态，企业可以自定义治理规则的接入，实现治理。现阶段治理分为四个象限，横坐标是元数据部分，纵坐标是规则部分。规则包括表达式和算法包。系统提供的能力主要集中在一个象限：定义的标准元数据和统一表达，直接通过规则引擎进行适配。如果业务方有第三方元数据，要访问我们定义好的规则，如图中第二象限，需要定义第三方元数据的访问。接入的第三方元数据需要遵循接入标准，通过规则引擎进行适配。如果规则部分需要升级，比如相似度计算等，不是资产的一维标注，不是可以用纯表达式描述的规则。在这种情况下，它被定义为一个算法包或一个逻辑单元。需要定义输入输出的标准，通过调用包或插件来执行逻辑。第三方元数据和算法包的组合也是一样，定义输入输出，注意包的执行效率和时间，才能满足整体接入。总的来说，要打通平台能力，让商家可以访问自己的规则和数据，需要定义一个标准的元数据格式。例如，您可以定义行是特定资产，列是特定配置文件。业务方负责处理自己的接入部分，完成配置和数据映射，通过表达式或算法包计算后定义统一的输出，即可接入系统。目前，系统支持单资产标记（pointwise）和双资产关联标记（pairwise）。3.5平台建设——智能化能力接下来是我们近期要做的事情。平台的工具端做了很多能力建设，通过智能化的方式，可以进一步降低治理成本，提高治理效率。下面介绍几个有代表性的落地。3.5.1TaskSLAsigningrecommendation在做SLAsigning的时候，task的上下游可能有成百上千的节点。如何估计何时应该生产？我们目前是通过血缘关系找到节点所在的关键路径，根据运行时间分配权重，保证节点有相对合理的SLA缓冲。推荐的签名部分已经申请了专利，并取得了一定的效果。现在我们在做第二阶段，根据运行失败的概率分布，调整上游缓冲压缩和下游缓冲松动。3.5.2动态阈值监控解决的问题是：数据量呈正态分布，但看起来异常。例如，在节假日或活动日期间，流量日志通常会突然增加或突然减少。在做质量监控时，用绝对值阈值来限定报警范围，比如参考历史7天的波动率。这样很容易在节假日或活动日造成误报，给值班人员造成不必要的干扰。动态阈值就是为了解决这个问题。主要思想是：根据数据的历史情况，可以归纳为几种分布。针对不同的分布，提供不同的预测方法，预测某一天整表的量级，然后根据数据量级设置上下阈值，超过阈值则发出告警或消息通知。在数据分布上，我们针对自己的业务划分了几种典型的分布：数据量单调递减，大部分是快照表或者全量表；日志表，长时间观察时，节假日或活动日可能会出现数据量的突然增加或减少；维度表，数据量比较稳定，当维度发生变化时，会体现出一定的问题；以及一些类似维表的波动比较小的分布。基于不同的数据分布，目前采用四种不同的预测方法：移动平均法、指数平滑法、自回归法和同时检测法。对不同波动的拟合在一定程度上得到了验证。3.5.3相似任务的识别由于业务庞大，开发人员多，任务量大，在开发任务时，不知道线上是否有相似任务，跨团队的情况比较明显，所以详解任务检测是必要的。基本思想是将目标源码和待检测源码的AST序列化，然后进行向量化，计算特征向量的余弦相似度，通过乘积揭示结果，然后用业务，经过人工确认分析后合并或下线任务。以上是我们在智能方面的一些探索。3.6平台建设-架构总结综上所述，平台整体架构分为三层：产品层，区分管理者视角和执行者视角。在具体治理上，采取双路径：在规划治理时，从目标制定、规则选择、治理实施，到收入统计、经验总结；第二条道路是响应式治理。通过订阅消息、发现问题、实施治理、登记问题、回顾总结等几个步骤进行治理。服务层提供整体的服务逻辑层，在下面拆分不同的模块，尤其是接入服务，提供开放的能力。通过拆解任务执行、事件中心等不同模块，为各种场景提供灵活的服务。数据组件层作为基础构建层，包括元数据仓库的构建和大数据组件的适配。四、未来展望未来展望主要包括三个部分。在体验打磨平台的建设阶段，已经建立了比较完善的能力，并在内部得到了有效的运用。此外，双通道建设将得到更多落实。在规划的路径上，资产将更加清晰，规则将更加丰富，动线将进一步打磨，收益的准确性将得到提升。在响应路径上，除了问题的登记、归属、总结，后期的建设将主要集中在总结、归纳和经验积累上，让经验更好地被其他业务方复用。开放能力基于分布式自治的理念，目前没有一刀切的治理策略。可以自定义自己的目标，对齐自己的SLA等。未来会支持自定义健康点，不同的业务可以自己定义健康点的组织形式和描述。第二点是自定义方案。我们将进一步打磨自定义规则的接入流程，进一步开放规则能力以支持业务调用。商家在打标后获取信息后，可以做自己的资产分析。三是要开拓业务，进一步从业务角度看问题，针对业务问题做好平台建设。增强型数据治理目前主要基于统计规则，部分挖掘规则正在建设中。后续会在智能模型构建方面做一些预测分析。
