一、大数据开发治理平台介绍
首先和大家介绍下大数据开发治理平台。
1、数据驱动企业中均有建设
在各个企业中，对于大数据开发治理平台的认知包括数据中台工具、大数据平台工具和数据治理工具。
2、日常认知
日常的认知，包括：
（1）大数据生态组件的“拼接”。平台建设中往往会接触到很多的生态组件，例如 Hadoop、HDFS、Yarn、Spark、Hive、Flink 等等。对于平台来说，在业务发展到一定阶段之后，各个组件在大规模运转下的易用性和效能都会有所影响，所以需要大数据平台整合这些生态组件。
（2）开发代码的 IDE。企业当中数据 RD 同学是数据生产的主要开发者，他们对开发工具有提效的要求。
（3）查询 SQL 工具。也称之为 adhoc 工具。能给企业内大量的分析师、算法以及开发同学更快速进行 SQL 查询分析工作。
（4）作业调度平台。一般企业最初最早开发的平台工具，并以此为基础，将线下 Pipline 迁移到线上，围绕开发运维提效以及数据降本治理，迭代发展为大数据开发治理平台。
（5）数据管理工具。如提供数据地图便于大家找数，定位问题，做影响评估等。
3、产品平台解读
下面以全局视角，解读大数据开发治理平台。可分为两大模块、三种场景和四类用户。
（1）两大模块包括开发和治理模块。开发即日常在开发中所需的调度系统和代码IDE。治理包括数据管理以及和安全、成本、质量相关的提效和治理工具。
（2）三种场景包括数据生产场景、数据消费场景和数据治理场景。
开发模块主要是数据生产场景中将代码快速开发、上线、测试和发布审批、运维等等，同时也有一些开发过程中规范的落地。
在生产完数据之后，在数据消费场景中，数据需要提供给前台，赋能前台使用，比如：报表，数据应用产品，在线服务，交互式分析，启发式探索分析，需要提供更灵活的数据的消费形式，如：adhoc 查询分析，API 接口，湖仓一体查询加速等。
治理模块主要面向公司级数据治理场景，需要看到治理相关的具体大盘、治理项，以及针对治理项引导用户或治理团队进行治理的快速操作，打通下游的存储和计算系统。
（3）四类用户包括数据分析师、数据 RD、算法 RD 和数据运营。
分析师主要是启发式的探索工作，用到我们的平台工具找到分析所需的数仓表，在此基础之上进行 adhoc 查询分析。
这里我们将数仓开发、数据治理、业务开发 RD、后端、前端同学统称为数据 RD，在平台上基于监控、查 Bug 以及对业务的理解等都需要使用平台的计算能力查数。
算法 RD 大量工作基于平台进行数据生成以及最终效果数据的校验，以及一些常规的异动分析。
实际上在做数据内容的时候也会有大量的运营工作，由谁发起，最终如何使用工具做好，这些都是数据运营同学需要使用大数据开发治理平台完成的事情。
什么时候开始做工具建设，建数仓？
这更多是爆炸式数据增长催生的产物。在早期数据较少，业务相对简单的情况下，从整个生产方式上来看，由业务 RD 同学同时兼顾数据 RD，将这些数据快速迭代上线，让老板快速看到数据，此时是不需要有平台存在的，靠人力就能解决当前的问题。但在整个企业内部业务分化和工作分工更加精细化之后，实际上会考虑到例如大量的数据 Pipeline 如何管理、如何在大量的表和数据中精准找到想要的数据，以及大量的数据是否有价值，成本多少，需要有这样的组织去完成这些事情，这个组织催生出来提效的需求，偏横向的工作，需要有平台工具的支持。
4、大数据浪潮下的开发治理平台
进入大数据浪潮下，平台有很多特点，主要包括以下几点：
（1）大数据技术更新迭代快：如现在新兴的湖仓一体技术，从前年已经开始在整个社区当中流行，同时在各个企业当中也在逐步落地使用。对于平台的挑战在于开发同学会开始对新的生产力有所要求，需要立刻响应这些新的技术。
（2）前台业务多元化：对于快速增长的业务，唯一关注点是平台是否能够提供足够多的资源，无论是计算资源还是存储资源，以及在平台上的稳定性是否能够得到保障。而对于增长进入需要用数据驱动解决问题阶段的业务，目前的诉求主要在于数据质量问题，同时对于大量人员结构的增长，需要有组织上的管理要求，管理数据安全问题。
（3）企业组织形态复杂：有些部门是产研一体，在一个事业部当中形成闭环从而进行数据驱动工作；有些部门研发组织内部已经分化形成多个开发单元，组织形态包含横向和纵向，非常复杂，对于平台管理资产有非常大的挑战。
（4）数据指数级增长：数据指数级的挑战，对于平台产品经理的要求是在与各种业务沟通过程中需要了解大数据技术稳定性的基础知识，以及对应最佳的时间场景。
5、B 站选择的解决方案
B 站对市面上第三方方案进行了简单的调研，如果企业内部开发资源相对较少、业务迭代比较快速的情况下，没有更多的资源进行自研，可以考虑选择第三方的解决方案，B 站最终选择自研的解决方案，有几点原因如下：
（1）成本控制：不仅考虑到开发成本，更多在于和公司的大数据基础架构基建有关，因为整体规模量级较大，对于基建的要求以及基建稳固的成本控制会更加灵活一些。
（2）集成能力：因为平台不是仅有自己的功能开发，还依赖大量周边的系统，例如域账号系统、OA 组织架构系统，这些能快速集成必须是在平台自研能力的控制之下。
（3）性能要求：大数据基础架构做了很多性能层面的优化，有些优化和平台的集成能力存在相关性，需要平台做定制化的操作，如队列提交，调度上需要平台和基础架构之间完成较多的合作和联动。
基于如上考虑，B 站通过自建，完成了 “berserker” 平台。
6、业务产品架构
B 站整体产品架构主要包括业务前台，所有开发工具都最终赋能于业务前台。其中包含报表工具，埋点用户行为分析，AB 实验平台以及标签系统、用户增长看板等等。
数据治理模块包含找数、查数、数据地图和数据管理，偏内容型的平台工具，还包含归因影响分析、血缘分析等与数据治理相关的基础模块内容。数据建模模块保证整个数仓建设当中能够对外形成数据管理、组织域管理标准等元数据流入管理工具。同时在安全和资产方面将账单、资产以及安全保护伞等与安全运营工作相关的工具提供给相关负责数据治理的同学使用。
数据开发运维模块包含数据集成，有实时和离线，大量的数据从端到端落地到平台中做统一的计算，以及日志上报的传输通道。数据开发包括批处理、流计算、即席查询以及类似数据 API 接口等数据消费服务内容。由于平台整个数据链路复杂，线上每天同时运行的 Pipeline 繁多，需要有数据运维的工具支持，对任务运维，以及数据出现异常时的回刷操作，发布审计和版本管理。数据质量模块更多赋能业务侧进行质量效率侧的提升，对应提供智能基线、监控告警、DQC 功能服务。
底层服务相对基础，例如离线任务调度服务、数据传输服务、元数据服务、权限服务、审批流服务，做横向的建设。
底层引擎模块，由于整个 B 站技术生态起步阶段偏向于基础建设为主，大量引入新技术，除了传统的 Hive、HDFS，还包括 ClickHouse、Iceberg、Hudi、Flink 等日常使用的生态组件，更多和底层服务结合。
二、平台建设之痛
简单谈谈大家在平台建设过程中可能会遇到的痛点，以及 B 站在五年的平台建设当中遇到的痛点。
1、平台建设是公司级的问题
首先有如下几点认知和大家对齐：
（1）平台建设是先进数据生产力的提升：在建设过程中更多站在公司视角，从组织上和基础架构合作，推动生产力的提升。
（2）数据治理方法论的落地：公司当中对治理有要求和目标的同学，基本存在于公司级的数据治理团队，治理委员会，抑或是具体的 1-2 个 owner 同学，做治理驱动的工作，其目标主要是成本、质量、安全等。
（3）数据驱动成熟度的完善：在和很多业务对接的过程中会发现业务需求都是点和面的，最终希望将数据赋能于业务当中，但很多时候业务同学并不了解数据及时性和数据链路上的优化对于业务的影响，以及如何监管治理已经开发的工具。实际对于平台建设除了做好工具之外，还需要不断提高公司中数据驱动的成熟度。
2、数据自闭环多
具体的现象包括以下几个方面：
（1）平台不够稳定业务自建集群；
（2）任务运行在线下迭代更快：开发同学在线下使用自己的调度系统，或者设置定时任务用脚本实现，这样迭代更快，不需要平台的接入；
（3）对于平台的要求只分发数据就够：埋点正常上报，数据能够正常使用即可，正所谓平台不生产数据，只做数据的搬运工，从而导致平台建设处于非常被动的状态。
3、人少事多短期收益难
（1）业务投诉多，锅从天上来：很多时候工具本身不存在 Bug，按照正常周期迭代，但完成之后用户没有满意度的认知，仅仅只有不满的时候才会提出诉求，这样整体就会相对比较被动，老板收到投诉的时候，自己也无从解释。
（2）不敢承接推广新功能模块：对于新功能模块的需求处于“警觉”的状态，刚开始对于新事物往往会比较兴奋，但长时间由于人少导致在业务中的预期无法管理，不知道承接的意义是什么。
（3）爆炸式个性化需求永远做不完：业务提出的需求往往非常个性化，且很多时候需求本身是矛盾的。比如在开发规范方面，有一些声音认为在开发流程中应该进行阻断式流程，希望审批不能让有问题的任务上线，有些部门则认为上线之后事后可以进行处理，不需要做事前的预处理。
4、数据治理配合度低
（1）业务不考虑成本问题：站在业务立场，更多希望快速迭代保证数据质量
（2）业务迭代人力不够没精力治理：业务本身迭代老板层面的需求已经人力不足，无暇顾及这部分的工作。
（3）数据治理功能推进难：对于我们上线的功能，比较好的业务部门会提出意见，明确自己的需求，有些业务部门则根本未使用功能，当出现线上问题，老板怪罪下来，最终将原因归咎于治理功能不好用，导致治理推进不下去，和治理工作处于“瘫痪”状态。
5、如何破局
如何解决问题，总结为组织、方法论和工具三个方向：
（1）组织方面：首先治理工作包括治理平台的建设，是一体化的，所以前提必须是一个平台集中式的组织，无论是属于虚拟团队，还是实线团队。整个平台有自身负责平台工具建设的同学，业务需要有业务的代表，例如各个业务线的数据代表者，平台当中以 BP 的形式提供相同业务线的支持，因为他们所有业务目标、看数逻辑和目前业务阶段所需要求都基本类似，所以这里采取“BP 制”合作模式可以做到相同业务的归因，无论是在数据口径一致性，还是在整体细节对齐都有特别大的好处。
（2）方法论方面：作为数据驱动需要有四个方向的方法论，包含数据模型规范、数据质量治理、数据成本治理和数据安全治理。
（3）工具方面：完善对应工具的建设，包括数据集成传输、数据开发运维、数据治理工具和数据服务平台。
在这三个方向，需要做好相关的建设工作，任何一环都不可遗漏。工具的建设往往是一个非常长期的过程，是不可能一蹴而就的，每个业务不同的阶段要求不一样的情况下，还是需要一些组织形态的营运工作在其中，同时有些工具上线之后，如果没有方法论的驱动，大家也不知道如何使用，所以如果只是把一些行业内的工具做好抄好，不一定能解决问题本身。
三、数据治理驱动平台建设
接下来重点展开介绍如何使用数据治理的方法论驱动平台建设。
1、B 站平台规模
B 站目前整体集群规模至少 10000 台以上物理级节点；日均新增数据量级在 1000 亿级别以上，日均作业量，离线调度系统的 Pipeline 量级在 15 万以上，平台大约每天有 3000多的 DAU。
2、演进里程碑
从 2017 年开始逐步做平台建设，刚开始 2017-2018 年期间，主要方向是存通用赋能，各个业务方的诉求在于其在存储和计算上特别痛苦，基本上稳定性和算例无法保障，自己计算有了集群也没有办法维护，需要组织大量的人力和精力完成，数据量到了一定阶段实在是维护不动了，所以我们当时从通用的角度出发整合资源，做到集群统一，数据存储统一，同时需要平台有对应的产品和技术能力。
2019-2020 年期间，完善了对应功能之后，虽然底层系统已经形成统一，但数据稳定性问题依然存在，业务对于平台非常大的诉求变成如何保证数据质量，过程当中早期我们认为质量问题牵扯到的上下游、对应边界有时很难划分，但其实我们在逻辑思考中更多是在业务当中一旦有事故发生，我们会同业务一起讨论如何解决问题，最多的事故往往只会涉及基建方面出现存储系统，调度系统或者是计算资源有问题从而导致的数据质量问题。这块我们当时开发了较多的产品功能和提供了对应的技术服务，对生产力也有所提升。
到了 2021-2022 年期间，业务已经在很多工具使用当中没有太大层面的问题，只是日常的修补和迭代，此时更多在公司级别会有对应的要求，在于我们需要做好成本的治理驱动，此时催生出的对应产品包括数据治理工具、数据治理榜单、做一些组织形式的划分，按照工作空间，还包括资产管理、以及通过账单管理清算清楚成本。
3、存通用赋能
涉及的主要模块包括数据传输和数据集成。解决的问题本质上是治理数据及时性的问题，在推进这部分功能过程当中业务有时是无法理解功能的必要性，有时在功能上无法避免真正做到无感知，需要业务做一些配合工作，比如传输全部是百亿级别数据，做天维度的全量传输，是对存储资源的浪费，我们和业务的沟通方式更多的在于我们是有更先进的生产力，我们的数据湖技术可以实现增量集成，通过 binlog 做数据更新集成，省去大量的计算工作，对数据任务的及时性有提升。
大量的业务无法实现传输计算的及时性和稳定性，这块是业务比较大的痛点，而平台是有这块领域的能力，在业务当中能够以这样的能力吸引业务配合我们完成工作，例如我们在和业务沟通过程中更多情况往往是如果业务自己去做，比较简单，但需要考虑的问题是如果 Pipeline 到十万、二十万甚至千亿级别的时候，如果有一个数据出现问题，其他数据怎么去修护，我们可以提供对应的能力，在数据传输过程中，我们会有管道隔离、数据传输结构化的优化等等，这些优势业务自己是无法操作的。
围绕数据集成功能我们会做各个场景核心链路功能，不断迭代，无论是集成还是开发方面。
4、数据集成能力
在数据集成能力方面，我们长期推进的功能，也在公司内部得到了较好的评价：
（1）支持大量业务数据库接入：将业务的 MySQL、SQL Server、Oracle 的数据快速接入到 Hive；
（2）流式数据汇聚：日志更多以实时传输方式为主，将客户端、服务端和数据库变更日志数据汇总进行分析；
（3）Hive 数据出仓：数据最终只能从数仓出仓到各个不同的存储板块当中，提供给业务线上服务的使用，支持从 Hive 数据以类似 bulkload 的方式到 MySQL，ClickHouse，TiDB，Kafka，Redis，MongoDB，ES 等不同组件；
（4）与作业调度，元数据系统集成：业务在日常很难解决数据传输结束后能够立刻将作业计算调度起来，业务一般实现的方式只能打时间差，这样会导致很多时候任务是空跑的状态，数据还没有 ready 好，任务就已经开始运行，但在平台中是不会存在这样的问题。
整体演进过程主要是从全量到增量，从批处理到流处理，实现了将数据，从早期的 Flume+DataX，到中间态通过 Flink+Kafka+Waterdrop，目前核心通过Flink+CDC+Kafka，最终能够给到的业务承诺是数仓整体 ODS 层数据就绪时间，即保证在 0:30 分所有数据都会整合到平台当中，作业就开始跑起来，意味着整个数据后续跑任务时间能够节省出来。平台通过增量和流式处理能够做到提升，整体功能的推进也会更加有效果，业务也会愿意将核心数据迁移到平台当中。
5、开发运维能力
开发前，数据需要从端到端落地到系统当中，通过 adhoc 功能对数据进行探查；开发中开发任务 SQL 和 UDF 代码，代码的自动完成，表推荐，调试编译测试诊断拦截，配置调度周期与依赖推荐，将所需要依赖的下游任务给到，通过配置，从而不会产生空跑，配置任务告警，创建修改表。
运维模块最核心的功能在于事后如何回刷数据，更快的发现问题。
6、任务调度系统
整体调度系统大家更多关注的要求在于功能，即有灵活的依赖触发机制。
我们通过调研开源的系统例如 airflow，实际上业务的调度时机是较为丰富的，比如第一种时间触发，需要定时定点某个时间起来；第二种依赖触发，上游 ready 之后必须马上触发，第三种混合触发任务，例如小时和天之间的依赖，天和天之间的依赖以及依赖自己上游上次跑成功的时间。
7、依赖策略支持
（1）时间调度：用于时间调度的一种是数据同步任务，批量抽取业务数据库，在凌晨 0点 15 分开始；一种是虚拟节点任务，需要在 0 点 15 分同时启动多个数据同步任务以及关联的 ETL JOB 任务；
（2）依赖上游：同周期依赖，最常见于两个天任务之间依赖，小周期依赖大周期，小时依赖天，日依赖周，以及大周期依赖小周期，以及月任务跑完成之后，有些当天的报表需要将月维度数据补充进去等场景；
（3）自依赖：最典型的是新增留存的统计场景，基于昨天或者是历史上所有任务完成之后，才能完成今天的任务，需要和昨天的数据做交集。这时候需要用到自依赖属于，依赖自身上一周期调度完成后才能执行。
8、质量治理驱动-SLA
在完善生产力提升之后，这时公司以及有治理意识的业务关注更多的是治理工作。这时候需要思考业务最关注的是什么，实际上在任何阶段业务关注的都是数据质量问题。当时 B 站在做工具的过程中更多考虑在有限的人力之下优先将质量治理工作做好。
首先谈谈质量的 SLA，数据及时性的 SLA 是大家所关注的，拆解分成为两种时间，第一是 MTTD，即事故平均检测时间，越早发现事故越好，第二种是 MTTR，即事故平均修复时间，事故修复的越快越好。同时有一些术语需要和业务共同定义，例如破线，一般来说数据最终产出是有一个固定时间的，叫做数据预期产出时间，如果实际产出时间晚于预期产出时间，则视为破线，破线不达标的情况下，则开始计算故障时间，通常情况下，天例行任务数据及时性 SLA 一般在 95%，换句话说故障时间只能占一年的 5%。
9、质量治理驱动-智能基线
在和自身上以及公司各个部门聊清楚基线及时性目标之后，接下来需要去解决如何更快发现问题的能力。
（1）监控报警痛点：调度系统当中有成千上万甚至十万任务时，我们有很多种方法，第一种方法是给每个任务配置告警。
（2）配置难度：不可能为所有的任务配置告警，首先配置量非常大，而且规则较为复杂，每次配置需要知道任务什么时候开始和结束，执行时间多长，从而造成为每个任务配置监控规则极为繁琐。
（3）报警时间：每个任务所需报警的时间都不同，配置错误的话会造成大量的误报。
（4）监控数量：监控任务除了难配置之外，一旦下游出现问题，上游所有节点都会报警，造成大家由于告警太多从而无法处理真正有问题的事情。
（5）在做基线时只需要关注最终产出数据的任务，在最小任务当中配置一条基线，基线必须配置在任务的叶子节点当中；配置完成之后，通过叶子节点，自动识别关联路径；当关键链路上有节点出现各种异常，出现延迟后，系统将通过历史执行时间进行预测，计算所有节点执行时间结束之后，是否能够达到预期时间，这样无论中间任务有所改变，对于基线的影响都可以做出较为准确的判断，一旦基线报警，势必只会是最后一个或者是中间的任务有所影响，再对应通知到基线相关人员，而不是整个链路当中的所有人，从而能够更快发现问题，运维成本也会相对减少。
（6）具体配置内容相对于告警配置减少很多，只需要配置好基线名称、责任人、保障任务、基线类型（包含天和小时）、预计完成时间（系统自动计算）、承诺完成时间、预警时间、告警方式和告警接收人。
功能上线之初，获得了很多 RD 同学的青睐，解决了大量运维成本带来的问题。
10、质量治理驱动-DQC
数据准确性的监控，本质上等同于一个监控系统。
在数据表上，配置一些具体的字段级、行级数据波动的监测，对应的阈值。如果数据发生错误，例如上游任务出现空跑，对于下游产生影响，此时会触发红色预警，阻塞下游。
功能本身难点在于规则配置，业界其实有很多参考，同时业务也能够提出很多规则相关配置，字段级观察波动，离散型观察分布，系统只需要支持配置阈值即可。推进过程当中业务经常会提出数据质量问题是由于 DQC 工具的不完善造成的，配置告警的误告太多，规则相对较少，无法解决当前问题，希望规则推荐阈值，提高配置效率。但工具层面只能提高效率，不能根治数据质量问题。质量问题本身是一个链路很长且很大的问题，且并不是靠工具本身就能解决，更多在于数据质量运营治理：
（1）分级治理 P0 全部覆盖：和业务共同梳理，通过反问业务如果 Pipeline 出现问题，哪些是涉及资损和舆情层面。
（2）对于未处理告警优化，定期优化阈值。
（3）指标监控阈值：通过对比业界标准，给到业务最佳实践，例如推荐 CTR 一般为 5%。
（4）源监控阈值：业界标准，计算过去统计周期内的异常率，重复率，离散值个数，离散值条数分布等值，一方面根据业务形态自己控制，另一方面属于行业内部必然会出现的问题，例如设备 ID 获取率通常为 10%。
通过相关的方法论和组织形态推动 DQC 工具的迭代。
11、质量治理驱动-回刷工具
另外大家反响较好的是回刷工具。有时候事故是非常巨大的，像根任务，传输任务出现问题导致传错了数据，遇到最多的情况是日志数据有问题，此时需要将对下游影响巨大的根任务进行修复。系统当中需要提供的工具在于根据 P0 基线做优先调度执行，一般出现事故时候首先在工具当中将出现故障任务的下游拉取出来，之后进行过滤，因为有些任务不一定是能够重跑的，其不具备幂等性，如果重跑会造成较大的问题，对线上数据造成污染，甚至有些数据已经交付出去，此时再重跑，被客户看到数据发生了变化反而会造成较多的舆情问题，对于这些情况的任务是需要过滤掉的。批量停止，黑名单，链路选择，批量执行等功能，调度系统会根据 P0 基线链路选择优先执行，并且站在数据开发的角度如果作为数据产出的 owner，下游存在大量数据依赖方，通过一键拉群或者通知 owner 等功能打开内部 im 工具做出较大的通知，从而提升效率。
衡量指标一方面是用户的反馈，另一方面是对应的 MTTR 时间，每次事故产品同学都会记录对应的故障时间以及修复时间，能够看到明显优化的过程。
12、成本治理驱动
顺应公司降本增效的要求，我们需要做较多的成本治理驱动。主要从三个方向着手，如今处于降本增效的环境下，作为公司级别的部门，更多为老板考虑的是如何省钱，首先需要明确资产归属，如果连资产都不知道属于谁，都统一归属平台，是没有办法做出优化或者是找到需要优化的人。第二是完善用量账单，因为老板、业务方对于任务量级、存储大小是无感知的，更多时候需要算钱。最后通过治理标准拉出成本优化大头。
13、成本治理驱动-工作空间
在资产归属方面，公司当中变更频繁，部门业务存在整合与拆分，一个部门会因为业务调整，拆分为多个部门，组织形式多元化，资产资源难以区分处理，从而导致整体资产不好交接，以及在整体拆分之后资产应该交接给谁。管理粒度粗，一些部门巨大，职能线多，人数太多，数据管理员难以指定，导致资产管理效率低下。资源隔离难：容易形成数据烟囱，数据重复计算、重复存储，因为我们的部门是一个资源管理单元，会和队列、库以及资源存储的 quota 绑定，容易造成跨业务资源容易争抢，无法说清楚具体每个业务应该使用多少资源，依赖复杂。
于是我们加入了工作空间 workspace，在开发治理平台当中，让所有的资产例如任务、表、报表、数据源等等归属到空间之上，工作空间再归属到分管的部门，再决定每个空间应该执行哪些对应的队列、库和存储，增加了空间之后，可以对其做很多的治理操作，整个治理单元更加纵向化，更好的做组织上的沟通。
14、成本治理驱动-用量账单
这里比较难做的事情在于如何将最终的成本换算成钱给老板看，首先在平台上更多通过采购服务器，按照采购价格拆分成单价，以及通过采集 SDK 获取用量，而最终的账单=单价*用量。整个数据生产当中使用到的资源包括 CPU、内存和磁盘，单价如何拆分？
服务器有对应的采购价格，将整体采购价格分摊到每个月，折算出折旧成本，可以和相关采购和财务部门确认，大概可以估算出一个服务器在当月对应多少钱，将一次性采购的钱拆分成多个时间段的钱，在多个时间段当中按照服务器的 CPU、内存和磁盘的占比，计算出具体 CPU、内存和磁盘对应多少钱，这就是所谓的成本比例。同时再根据水位线，由于每个服务器不可能所有的资源都给用户使用，会有公摊的部分，比如调度系统当中处于等待状态的任务是需要占用公共内存的，磁盘也不能全部用满，否则整个集群就会挂掉，所以整体磁盘的水位线一般设定为 75%，CPU 利用率能够达到 80%-90% 之间。水位线数值一般是基础架构同学给出的，是一个较为科学的数值，平台会将水位线成本分摊到各个业务线当中，这样我们能够通过对应的公式：
服务器拆分成时间的总价，各个使用量单元的占比*水位线即可获得对应的单价。
通过采集的工作将每个执行任务，存储的表都对应采集到，同时把他们当前使用的 CPU、内存和磁盘用量计算出来，这样最终将所有任务和资产对应的用量乘以单价得到最终的账单。
通过上述计算方式给业务和老板最直观的感受，到底我们用的东西对应消费了多少数值的人民币。随之产生的是各部门级别的资产大盘，以及用户维度的消费资产数据。
15、数据治理驱动-治理标准
完成上述工作之后，我们可以进行数据治理相关全局性的工作。因为从质量成本出发业务侧和老板侧都有了较大的认知，方法论上没有较大的问题，此时各个部门如何全局去看，做出建设，需要我们平台推出治理标准。我们的标准是同数据治理团队共同定制的，包括模型建设、数据规范、数据质量、任务优化和资源使用五个维度，各自的评判标准主要围绕数据一致性、数据的及时性和准确性、任务是否存在浪费资源、任务优化成本如何以及运行资源使用的合理性、水位线是否符合要求。
16、数据治理驱动-治理指标与功能
基于数据治理标准，列出了较多的细项。包括错层依赖比率；以及模型信息完整率，涉及数据是否能提供给他人使用。ODS 模型建设率，不可以总是将 ODS 层数据提供出去。数据质量方面主要关注基线运营，通过观察基线 SLA 达标率，没有达标破线的情况，视为数据质量不好，存在对应的扣分机制。另一方面是准确性的保障，观测 DQC 在 P0 基线层面的覆盖率，P0 基线表都需要被监控到，以及 DQC 达标率，DQC 是否达标以及对应告警是否有较好的处理。任务优化方面，涉及到钱，可以计算出对应哪些任务花费的钱较多，运行时间太长的任务一般都是存在问题的。资源使用方面，存储当中由于先后基础架构的引进，存在很多问题，例如生命周期没有配置，没有使用压缩格式的配置和迁移，ODS 层重复的清洗和建设，数据同步的重复等等。
标准当中进行不断地迭代和演进，最终目标是为了把治理项整合出来，有了治理项和钱，我们可以进行两个方面的 Todo。一方面在公司做总体预算的时候，由于归属已经明确，可以将各个部门浪费资源和对应治理的情况拉取出来，首先客观的去看它的预算是否科学合理，是否符合自然增长规律和新项目的要求，如果符合，我们会将治理项的浪费算上去，相当于必须基于治理能够完成的情况下做采购，必须给出一个对应的治理目标，否则预算是会被打回的；另一方面更多是采用 top-down 的当时，和老板做汇报的时候，更多的将成本浪费的部分汇报上去，因为有些业务本身虽然的确存在浪费，从规则层面是属于浪费的情况，例如重复建设，但其占用的数据量级本身并不大，且业务本身处于一个快速发展的阶段，对于整个业务迭代速度其实是可以接受“先污染后治理”的，我们就可以有一个比较好的尺子和方向去推进治理工作。
对应产生出来评分、榜单、具体的治理项内容，换算成钱推送给各个部门做相对应的治理工作，有了标准之后，对应的工作变得更加容易推进，因为业务和老板是能够感受到钱的变化，产生压力的。
四、产品策略思考
最后总结一下，在整体平台建设过程中沉淀的一些产品策略思考。
（1）业务合作：需要思考 BU 当前阶段的痛点，整体治理平台或者是工具建设能够做的事情很多，但实际在公司内部真正落地时候，如果只是和业务方空谈当前的痛点，规范，收益以及完整的让人兴奋的产品架构，业务是不太感冒的。和业务的合作不是告诉对方行业如何做，我们应该如何做，而是了解业务当前的痛点，业务无非关注的就是数据及时性和数据质量问题，如果这些问题能够匹配的话，当前治理工作就能够得到较好的推进。
（2）新技术：大家经常会被新技术所误导，一些开发，基础架构或者是业务同学拼命想要使用，业界反响很不错为什么不用呢？例如数据湖技术，是做增量计算和查询加速的，但是我们忽略了几个点，第一数据湖在整个传输链路上做了较大的变更，实际上可能会造成数据的丢失，增量主要还是以日志传输方式为主；第二和全量的同步中会存在数据的差异性；第三最严重的点在于数据回刷方式极为复杂，毕竟还是实时链路，有时需要批或者流式回刷。这些是产品经理考虑之外的，产品经理能做的地方在于面向的场景和功能上保持敬畏之心，通过反问技术或业务如果遇到对应的问题，对方希望通过什么功能层面解决，不是先做新技术的覆盖，而是先考虑新技术覆盖当中最小化需要什么，从而需要对 Demo 链路进行调研决策，这是 pm 需要关注的内容，最终不至于因为上线了新技术导致一方面推不动，另一方面上线之后发现存在很多潜在的问题，内部研发和业务同学意见很大的困局。
（3）组织形态：很多时候平台建设往往是工具+业务，存在通用业务的，理应上由平台做统一出口，更加能够保证数据一致性，所以当有了这些业务，就会拥有自己的 Pipeline、开发同学，和对应的业务要求，形成了自身闭环，有了业务就会离业务更近，这样就方便后续做更多的尝试，包括 Demo 的尝试。
（4）优先级：如果需求太多，尽量按照质量>成本>安全三块内容做出优先级评估，这只是一个参考，有些公司老板更注重安全。安全方面更多以做好事后的工作为主，大量的数据需要先流转起来，把业务先生产起来，然后将小批量数据做一些安全，对我们的工具要求反而不是特别高，更多是愿意做安全工作和对应的监控。但是质量和成本永远是业务方和老板会优先考虑的问题。
（5）意识形态：一定要运营数据而不是只做工具，如果只是照搬行业内的工具去做，甚至抄一遍，不一定能够达到目标，很多时候我们开发的工具是承载了数据的。我们需要理解数据、任务是什么样的，有什么特征，业务在使用数据当中遇到的痛点，再完善工具是一个较为正向的流程和解决方法。
五、问答环节
Q1：如何做平台的工具推广以及使用率，因为做平台更多希望让平台能够被用起来，以及我们在平台的工具建设初期，最早要做哪些开发以及对应的优先级是如何规划的？
A1：对于开发规划模块，实际上在开发初期当中，还是根据业务方本身的发展阶段，质量还是业务最关注的，先深入到业务本身看业务遇到了哪些质量问题，比如是性能上存在问题，还是 Pipeline 太多监控无法管理，还是不知道如何管理，还是不知道如何进行修复等问题，在整个链路当中，每个点都可以做相应的了解，并且找到一个能够给到业务最大收益的地方。如果是业务希望事前完成，出现最多的故障属于 SQL 写错、变更存在问题，我们优先做出 SQL 拦截，SQL scan 相关模块，制定基础规则，规则本身其实并不难，但对应收益会特别明显，且在很多业务部门当中会产生共性的问题，这时可以做一些推广工作。在此过程当中同时需要和研发不断沟通成本的问题，有些需求迭代成本特别快速，例如数据湖技术本身是一个非常长期的过程，投入产出并非一蹴而就的，但有些功能对应的实现成本则非常低，对于产品经理而言在推进需求优先级本身需要考虑这几方面的因素最终决定做哪些事情。
Q2： 关于开源相关的，如果想要做一个像样的治理平台或者大数据平台，有没有开源的组件进行参考或者推荐，这样能够直接进行快速使用它搭建自己的平台？
A2：传输模块的组件业界比较多，例如 Flume（日志传输）、Flink（日志传输的计算引擎和传输引擎）
传输过程当中会使用到 Kafka 队列对传输的数据进行削峰填谷和分发，分发侧基本也是以 Flink 为主。
离线数据传输主要是在数据库传输当中，有些数据对于数据准确性和一致性要求是非常高的，此时对于数据库传输的要求是不能出现丢失或者重复的，目前在实时传输中很难解决 SLA 在 100% 的问题，还是需要采用到 DataX 的开源组件以及 Waterdrop 组件做批量数据的传输，Waterdrop 是基于整个 flink-batch、Spark 计算引擎做的。
作业调度模块业界较多的组件是 airflow、易观开源项目 DolphinScheduler 等比较好的设计，大家可以直接进行使用或者是二次开发。
Olap 模块更多使用的是 ClickHouse、Iceberg，Iceberg 主要是做数据湖查询加速的，一定程度上能够解决数据出仓、数据查询性能秒级查询的问题，ClickHouse 更加针对的是亚秒级数据查询，在数据湖加速场景，集成加速、传输加速以及 upsert 加速场景，更多使用 Hudi。
Q3： 对于开放平台多租户的资源管理问题，这块如何进行设计，尤其是对于计算密集型和资源共享型用户如何合理的分配资源？
A3：首先可以对大数据资源调度做一些了解，一般是如何进行隔离的，隔离实际上是按照队列进行隔离，如果认定一个业务单元或者是生产单元属于是需要被隔离的类型，比如对于一张报表，它是给老板看的，我们对其的要求是一定要做到较好的隔离，首先在平台上需要对其做出标识，标识这个任务属于高优任务，标识完成之后内部对应两种方式做调度优化，一种是调度系统在任务执行的排队过程当中会优先在执行节点当中执行，因为调度系统属于中心节点分发的过程，分发到了执行节点，就要看对应任务的优先级，这时有了优先级之后就会把任务单独提高到执行节点当中进行插队执行，另一方面执行时候会有一些计算任务，计算任务在集群当中按照队列做的，我们可以要求或者告诉用户，通过衔接用户和基础架构之间，在平台上支持新建一个队列，在对应任务当中设置提交队列，提交到单独的隔离队列当中，其中的 CPU 和内存都是物理隔离的，实际上这个任务就可以完成没有影响的执行。
从全界管理的角度，我们一般会将整个队列在一个部门或者工作空间当中做出分配，每个部门或者工作空间拥有一个单独的队列，在队列当中分成 P0、P1、P2 三块的级别或者 label。P0 任务是提供给业务方做类似给老板看的任务，或者是有资损和舆情情况任务的执行，所有调度优先级最高，且能抢占 P1 和 P2 任务的资源；P1 主要用于一般任务、非 P0 任务的执行，P1 可以抢占 P2 任务资源，但无法抢占 P0 任务的资源；P2 资源主要提供给业务在平台做一些日常 adhoc 查询，以及常规补数据的查询，这样基本上将场景、最终资源以及抢占方式做了对应的设定，并且在平台上有相应的调度算法以及任务提交队列的绑定，实现对应的隔离方式。
