采集内容管理平台(小米在数据管理建设方面的理解和探索（二）)

　　采集内容管理平台(小米在数据管理建设方面的理解和探索（二）)

　　简介：本文的主题是小米的数据管理与应用实践，主要介绍小米对数据管理建设的理解和探索。数据管理的核心重点在于构建元数据平台，支撑数据管理的上层应用，包括数据地图、数据标准管理、数据成本管理、数据质量建设以及未来规划。主要围绕以下三个方向展开：①元数据平台建设；②元数据应用；③未来规划。

　　

　　图 1 元数据平台内容 01 元数据平台建设

　　小米元数据平台的建设内容主要包括数据管理架构的现状和架构的演进过程。在元数据技术平台建设过程中，在以下三个方面进行了改进，这也是平台演进的三个关键点：

　　1. 元数据

　　元数据是用于描述数据的数据。请参考图2。从抽象的角度来看，分类包括三个方面：实体、实体的属性、实体与实体之间的关系。实体主要指表元数据和作业元数据，它们来自ETL工程师实际工作中涉及的系统。如：Hive、Doras、Kudu、MQ、ES、Iceberg，即传统数据仓库的上下游。

　　例如：实体收录技术元数据和生产元数据。其中，技术元数据用于支持数据资产管理的资产地图；生产元数据，主要是作业的一些调度信息和操作信息，用于支持数据资产管理的数据质量和成本管理服务。

　　实体的属性，包括业务元数据和派生元数据。

　　业务元数据包括数据仓库分层、数据分类、索引关联、应用信息、隐私分类等内容。内容来自业务的建模规范、业务、指标体系、BI看板、数据报表、隐私分类定义。业务元数据用于支持资产价值、安全治理和资产管理的标准治理。

　　派生元数据包括元数据的存储计量和访问计量。仓储计量服务于仓储层面的成本管理；访问度量用于描述数据的使用，并从技术角度衡量资产的价值。派生元数据来自ETL工作中涉及的HDFS-Image、Doris、Kudu、MQ、ES、HDFS-Log、SQL-Log。

　　描述实体之间的关系，包括血缘元数据，用于描述元数据之间的关联关系，用于支持数据资产管理中的影响分析和资产地图服务。

　　

　　图 2 元数据分类

　　2. 元数据平台技术架构

　　小米元数据平台的技术架构如图3所示，整体架构与Apache的Atlas非常相似。

　　整体可以分为三层。最上层是数据的来源采集以及最终数据支持的应用，包括Metadata Source、Lineage Source、Log Source和Application。中间层是集成层，由Metacat、MQ和API层组成。底层是核心存储层。

　　顶层的 Metadata Source 用于检查表元数据 采集。一开始仅限于Hive表，后来实现了全局元数据的采集。主要包括ETL的整个生产环节和整个上下游环节。例如：元数据是从业务的Mysql数据库中采集的。其中，消息队列使用了小米自研的Talos，简单的实现了数据整合分发的总线。下游元数据采集由Hive、Doris、ES、Kudu等实现。

　　

　　图3 元数据平台技术架构

　　血统源实现血缘信息采集。亲属关系元数据来自各种计算引擎。通常，血缘元数据通过SQL查询入口或调度入口采集访问。由于小米业务量大，部门独立，所以入口也很多。通过常规入口采集很难增加数据采集的覆盖范围。考虑到各科室的计算引擎都维护在科室的计算平台上，可以在引擎端进行积分管理，实现血缘元数据的采集。同时在SQL审计日志中补充了SQL条目，

　　Lineage Source中的DataHub是小米内部的数据整合平台，包括离线整理整合和实时整合。DataHub集成平台也有上下游血缘关系，也进行血缘关系元数据采集。

　　在日志级别，调度日志、计量日志和运行日志。这些日志与质量构建和访问有关。应用应用包括数据平台的上层应用、数据地图、成本管理、标准化管理。

　　中间层的 Metacat 在众多原创图像的元数据中提供了统一的元数据视角。因此，通过基于Metacat的二次定制开发，实现对各种内部系统的适配。元数据的采集通过Metacat统一，包括T+1和增量变化，都通过Metacat。因此，Metacat 与 Messaging 相连，Metacat 每天向 Messaging 发送增量变化。之后，将收录血液信息的日志通过Messaging发送到数据总线，供下游层使用，并通过API为上层应用提供数据服务和支持。

　　在存储部分的底部，基本信息存储在Mysql中；T+1 快照存储在 Hive 中；和血缘关系图关系存储在 JanusGraph 中。元数据检索，包括权限检索过滤、审计检索等都放在ElasticSearch中。

　　3. 全局元数据

　　在元数据平台的演进过程中，关键的演进点之一是全球元数据。如前所述，元数据是基于 Hive 进行管理的。显然，只能看到Hive层的数据，无法知道生成的Hive表到达下游后是否最终使用。比如有一堆数据给上层应用做看板或者指标，生成一个Doris表；但是对应的看板可能不会被任何人看到，所以你可以在链接中反向这个链接。优化或治理。要实现这样的场景，就需要打通整个环节，包括看板信息、搜索等，这些都需要全局元数据的支持。这时候就需要进行域扩展。以Hive为中心看上下游，包括上游业务数据库、Messaging、下游Doris、Kudu、ES，包括传统Hive数据仓库Iceberg的内部重构，都需要采集元数据。在实现全域的过程中，同时开放统一元数据的Hive Metastore，实现统一的表数据透视和管理。见图 4。

　　

　　图4 实现全局元数据

　　4. 实时血缘关系

　　第二个关键进化点是实时血缘关系。前面提到过，小米的入口很多，血缘关系的方方面面都很难实现采集。最早的解析HDFS日志的方法存在血缘关系难以正确解析的问题。例如，在读取一个表时，可能会有很多打开操作。这些Open操作很难对应表与表的关系，会造成血缘关系不准确的问题。早期的解决方案是找出所有的读写操作，做一个笛卡尔积，但这会产生大量不存在的血缘关系。

　　这些痛点严重影响了上层的数据治理和问题解决的溯源过程。另外由于只能解析日志，知识量比较大；如果有流数据，则根本无法解析。这些与通过SQL分析可以确定血缘关系的情况完全不同。

　　因此，在新版本的进化版中，考虑了入口问题和引擎接入改造的成本。方案最终采用了实时引擎MQ埋点方案。同时每个引擎本身都要执行这个SQL，比如Hive、Flink、Spark等，包括Presto、Distcp。因为需要执行这种操作，所以需要解析执行计划本身。Spark 和 Flink 也支持这些操作。通过对血缘关系分析的内部转化（见图5），整体运行流畅。同时结合SQL Proxy Log做血缘关系整合，从而实现对血缘关系的精准分析血缘关系。

　　

　　图5 Metadata实时血缘关系

　　5. 精准测量

　　第三个关键进化点是精确测量。精确测量目前还不是完全精确的测量，但它解决了测量中的零和一的问题。在最早的录入问题中，不准确的测量使得无法判断数据的冷热程度。例如，用户可以通过各种 SQL 操作各种形式的 Hive 表。

　　尤其是难以应对研发需求。比如Spark SQL分为常驻服务和非常驻服务，都是为了解决Spark SQL作业执行的启动问题。非常驻服务，如 Hive SQL，每次都必须有一个启动过程。常驻服务可以及时响应SQL需求并直接执行，减少几分钟的启动过程，查询过程可以快速响应。还有Flink SQL、Beeline、Flink Jar、Spark Jar，包括想要覆盖这些入口的计量的Distcp。访问的确定也是解析HDFS日志。通过这些日志分析血缘关系的问题是，在Hive Jar这个级别，

　　测量部分解决了现阶段的零一问题。简单的说，就是在访问数据的时候，基本上可以保证被标记为数据访问。同时，通过HDFS日志提供的足够信息，准确的统计和排序，更正结合顶级SQL审计，可以获得对具体访问次数的准确计量。见图 6。

　　

　　图6 元数据的准确度量

　　下面基于元数据平台的建设，从以下四个方面阐述小米元数据应用的进展：

　　02数据图

　　数据地图是元数据应用的典型应用，包括数据搜索和数据地图中的血缘关系两个方面。

　　1. 数据地图-搜索

　　数据地图在业界已经是比较成熟的服务，小米的数据地图建设目前正处于追赶阶段。数据地图需要支持元数据的搜索和发现，具体包括以下三个方面：

　　① 支持表、字段、描述信息、数据仓库分层、数据分类、标签、部门等信息搜索，即实现对实体属性和关系数据的全局搜索；

　　②除Hive表外，在全局元数据概念上完善其他引擎，如：Talos、Doris、Kudu、Iceberg、ES、MySQL等数据引擎；

　　③ 实现支持指标、维度、看板等信息的搜索。

　　例如：搜索新零售，如图7左侧所示。按照用户喜欢的数据域分类进行标注。把大量的重量记录放在上面，搜索结果更多是一种展示产品的形式。

　　

　　图 7 数据映射-搜索结果

　　2. 数据图-血缘关系

　　通过数据地图，可以更清晰地展示数据之间的血缘关系。通过技术架构的改造，实现了整个链路的数据沿袭，从而可以展示不同系统的链路关系（如8），包括MySQL/MQ/Hive/Iceberg/Doris，等等。）。这样用户就可以很方便地从最早的数据源追踪到顶级应用程序。它极大地方便了问题的追踪，更容易评估整体数据的价值。

　　后续数据地图的构建会增加血缘关系的搜索和变化的通知。

　　

　　图 8 数据图-血缘关系

　　03 数据标准化治理

　　元数据应用的关键应用是数据标准治理，它对元数据的生态健康起着至关重要的作用。数据标准治理分为两个衡量维度：

　　数据标准治理以以上两个维度为指标，量化数据的健康完善程度。

　　

　　图 9 元数据应用-数据标准治理

　　1. 造型标准度

　　造型标准度分为以下三个方面：

　　①命名是指表的命名是否符合采集标准；

　　② 分层是指手表需要按照采集规范进行分层。例如：目前70%以上的手表没有按照采集规范分层。希望可以结合一系列整改措施，配合整体数据治理，推动用户进行分级治理或整改；

　　③ 标记是对业务部门的数据字段和标签进行标记。

　　2. 建模复杂性

　　建模完善包括以下两个方面：

　　04数据成本治理

　　元数据应用中的数据成本管理是优化数据使用成本最直接的部分。数据成本管理是元数据应用的一项关键投资。因为小米的数据量增长比较快，所以整体业务成本上升的比较多，对成本的要求也比较高。

　　

　　图 10 元数据应用-成本治理

　　1. 数据成本治理的原因

　　成本管理从业务角度出发，成本的根本原因最终回归到底层，即主机和整个网络等资源；而上层应用追求的是存储和计算资源。关于主机成本，从商务谈判层面已经做了很多努力，包括打折，单靠业务层面已经无法挖掘成本优化的潜力。

　　存储计算技术也在迎头赶上，尤其是在成本方面，例如分层存储。此外，计算层面的灵活算力也在建设中，难以快速管理成本，降低成本。

　　当业务达到极限时，技术水平也在追赶业务。这时，从元数据的角度考虑成本优化，就面临一个简单的问题。企业不知道它有多少数据。这个数据就像花了多少钱。花在哪里，应该如何优化，优化后会有什么反馈？.

　　针对这个问题，做了一个产品级分析优化的闭环，即成本分析和优化的闭环。这个闭环的关键环节，简称为：观察现状、调查问题、优化、反馈。

　　2. 数据成本管理计划

　　为了支持闭环的成本分析和优化，对数据成本管理进行了改造。改造主要包括以下四个方面：

　　① 计算一个洞是指使用的数据要与底层HDFS中存储的数据对齐，以保证数据量的统一计量。在成本管理的计算中，存储是指存储维度，存储本质上回归底层数据存储。例如，存储在 HDFS 级别的数据通过 HDFS-Image 进行最准确的测量。它将准确地描述每个文件到每个路径和存储容量。数据成本管理的首要任务是将数据与存储在底层HDFS中的数据对齐，以保证存储容量被计算在内；

　　②对于天级账单，由于数据量太大，需要及时跟踪数据成本优化。不然选数据了，这个数据优化能省多少钱，要一个月才能说清楚。反馈时间过长，难以完成闭环；

　　③根据人的归属，明确数据对应的用户。经常使用数据的人名下的表比较多，相应的成本也比较高；

　　④ 及时估算。对于任何与数据相关的操作，它应该能够及时估计和反馈数据量和成本。

　　这些优化可以节省多少钱？

　　3. 数据成本治理结果

　　通过提供成本分析和优化的闭环能力，成本管理在短期内取得了不错的效果，总共优化了40%的数据。如图11所示，可以清楚地描述成本管理的效果：

　　上面的曲线代表公司过去一年线下数据的增长趋势；下方分叉线左侧黑色部分代表治理前的历史成本曲线；右边的红线代表历史成本曲线，用最小二乘法模拟未来正常业务增长下的成本曲线；蓝色水平线代表假设业务没有增长的成本控制线；底部橙色代表成本控制后的实际成本曲线；

　　橙色线和红色线之间的差距是成本治理的价值。

　　

　　图 11 元数据应用-成本治理

　　05数据质量建设1.数据质量建设内容

　　首先，在数据质量的建设上，采用了一些行业内成熟的质量管理方法。如图 12 所示。

　　小米的数据质量建设强调以下两个方面：

　　合格的数据产品具有以下特点：

　　

　　图 12 元数据应用-质量构建

　　2. 品质建设的技术框架

　　数据质量建设的技术架构不是采用开源的技术架构，而是一种内部的开发方式。架构*敏*感*词*如图13所示。

　　

　　图 13 质量建设元数据应用技术架构

　　①事件触发

　　在图12中，最左边是执行DAG（有向无环图）并生成DAG对应的表后的调度系统。专用用户将配置事件触发条件并触发表格内容的质量检查，以确定输出表格是否符合质量要求。执行的事件触发配置将检验事件放置在MQ中，质量系统从消费的角度实现实时事件触发。即内容质检任务直接挂载到调度系统DAG上，数据输出后，通过事件触发，实现对输出数据的自动质检。

　　② 时间触发

　　在图12中，架构的最上层是RestServer，它是一个可扩展的*敏*感*词*，用于接收上述质量规则的配置，或者查询和查询结果。通过DB级别的触发，实现时间触发。例如，业务不是通过 DAG 由事件触发，而是可以通过设置的时间点触发。

　　③ 可扩展的无状态工作者

　　触发器连接到下层的 Worker 来实现服务的执行。Worker 是一个无状态的、可扩展的执行机器。通过Worker可以支持多数据源，比如检查HDFS。通过Presto、Spark SQL和Doris，实现了对表的检查。

　　06未来规划

　　根据元数据平台和元数据应用的需求，未来规划包括三个方面：

　　1.生产保障联动资源调度

　　产保联动资源调度是打通产保从基线、运行、调度、到纱线的全链路。包括基线管理、生产执行、监控预警等。

　　计算资源治理仍在开发中。如图 14 所示。

　　

　　图 14 未来数据管理和应用规划

　　2.元数据建设的长期路线

　　元数据建设的长期路线是数据管理。需要回答两个问题：

　　综合元数据平台和元数据应用经验，要回答上述问题，需要统筹考虑数据管理、数据模型规范、资源使用与度量、数据安全与防范、数据价值与挖掘等方面的建设。

　　

　　图 15 未来规划-长期路线

　　3. 商业赋能

　　业务赋能是如何让业务愿意访问数据到中台。根据以往做消息中间件的经验，我们需要从业务关注的痛点入手。例如：对于任何业务，是否能够及时产生涉及质量水平的重要数据；生产后的数据质量是否可信？有问题吗？

　　基于以往的经验，业务赋能需要从数据治理层面综合考虑，通过质量、效率、成本三个维度，确保业务在质量、效率、成本三个维度的痛点能够得到解决。有效解决：

　　① 在质量层面，可以通过基线管理、数据质量检查、内容检查等方式实现输出的实时监控，包括确保数据输出的整体环节；

　　② 在效率方面，可以通过标准建模、查询优化、更快的数据输出和数据地图的优化来加快业务搜索。包括元数据血缘关系的构建，要加快业务中问题的追溯，即提高业务的效率；

　　③在成本层面，帮助业务实现成本分析和优化的闭环，可以为成本优化提供一些工具或手。

　　当能够提供这样一个完整的解决方案让业务感觉良好时，业务愿意尝试。这三个方面必须有效落实，才能解决业务将遇到的风险。

　　以上经验已经得到印证：最早，小米拥有数量特别多的MQ。通过与各个部门的沟通，规划自己的MQ对接业务，最终所有的MQ都统一了。其中Talos成为小米数据总线的实现标准。

　　

　　图 16 未来规划-业务赋能