元数据产品调研

💡 思考可以构成一座桥，让我们通向新知识。—— 普朗克

一、什么是元数据

元数据是关于数据的数据，是为了描述数据的相关信息而存在的数据。
元数据是用数据管理数据，是快速查找数据、精确定位数据、准确理解数据和有效使用数据的关键。元数据管理还须符合数据标准、较高的数据质量、数据安全、数据共享、合理顺滑管理流程。在存储、计算和人力成本合理可控、可管理的前提下，使数据价值得到最大发挥，是数据全生命周期管理重要组成部分，是提升数据价值发挥的前提，是数据治理的基石。
除此以外，在数据仓库体系中，元数据代表了一种统计数据从元数据、数据仓库到数据应用的全链路信息，记录了统计数据从产生到展示的全部过程。可以说，有了元数据，开发人员便可以方便的找到统计数据背后的计算逻辑与过程，用于指导开发工作并追踪数据问题，可以极大的提升工作的效率。

企业业务多样、产品纷繁复杂，在各类系统和应用中形成了大量的数据。有了元数据，我们就可以了解企业拥有什么数据，数据表示什么、数据来自何处、它如何在系统中流转等等，进行元数据管理、构建元数据应用，如业务术语、数据标准、数据字典、数据资产目录、数据血缘分析、数据地图等。

二、元数据的分类

元数据按照其描述对象的不同可以大致分为两大类，分别是“技术元数据”和“业务元数据”。

技术元数据

技术元数据主要是描述系统中技术领域的相关概念信息，包括数据结构、数据处理方面的特征描述，以及数据源接口、数据仓库、数据集市、存储等全面数据处理环节的信息。这类元数据主要被系统建设的技术人员使用。主要有以下几类类型，如图所示：

业务元数据

业务元数据主要用来描述记录在系统中业务的相关概念等信息，包括业务术语、信息分类、指标定义、业务规则等内容。它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。这类元数据主要的使用者是业务人员和公司决策人员，主要有以下几种类型，如图所示：

三、为什么要调研元数据产品

数据仓库的元数据，是对数据仓库所有环节（数据源、集成同步、存储、计算、数据管理、数据应用等等）沉淀下来的数据的描述性信息和过程日志信息，我们梳理数据资产、查找和使用数据、评估数据质量、了解数仓健康状况、成本治理等等都会首先从数仓元数据入手。

帮助快速理解数仓系统

数据仓库对于公司来说有着重要的价值，其开发时间冗长，中间不可避免的会产生人员流动，如果没有元数据，就只能靠文档来了解数仓系统，但是文档毕竟是人工维护的，其实时性、准确性、全面性等都得不到很好的保障，所以对于人员流动带来的熟悉成本就非常高，新来的员工无法快速了解数仓系统，也无法尽快进入到实际开发当中；此外，数据仓库做为整个部门、公司的分析数据出口，并不仅仅服务于数据开发人员，集团高管、业务人员、运营人员、数据分析师、运维人员等都可能使用到数据仓库的数据，如果有清楚的元数据来说明数仓系统，例如数仓里有哪些项目、有多少张表、这些表是如何分层的、存储的数据有多大、哪些流程占用的存储最多、占用存储的趋势、如何找到所需要的数据、数据何时产出、哪些表被使用的次数最多、跑完一个流程所用的时间变化等信息，就会让使用者快速了解数仓的全貌。

自动化监控告警

我们根据对元数据的分析，可以自动化地获取数据源元数据、数仓运行状况、ETL 运行日志、评估模型和 ETL 代码的规范度、识别源数据变更、监控存储和计算资源的负载等等，以便第一时间发现问题、触发告警、解决问题。

高效精准沟通

一方面，数据使用者不可能像数据仓库系统管理员或开发人员那样熟悉数据库技术，因此迫切需要有一个“翻译”，能够使他们清晰地理解数据仓库中数据的含意。元数据可以实现业务模型与数据模型之间的映射，因而可以把数据以使用者需要的方式“翻译”出来，从而帮助用户理解和使用数据。可以根据业务元数据，确认彼此沟通的指标、维度含义。从而在根源上避免交流的歧义，进而提高沟通效率。

另一方面，元数据中的管理元数据会记录不同用户、角色、部门的数据权限。如果有数据需要进行通知，则可以快速查询系统进行群发邮件等方式进行沟通，从而避免了造成沟通环节的缺人和多人情况发生。

快速分析变更影响

在开发中，我们经常会遇到以下问题：如果要改动某个表或 ETL任务会对哪些业务造成影响？如果要调整某个任务流的调度时间又会造成怎样的影响？如果没有元数据，那我们可能需要遍历所有的脚本和数据才能得到想要的答案，而如果有成熟的元数据管理，那我们就可以快速评估影响，判断当前更改是否合理，节省大量时间、规避不必要的风险。

进行血缘分析

向上、向下表级、字段级别的追溯数据，能清晰展现数据加工处理逻辑脉络，快速定位数据异常字段影响范围，准确圈定最小范围数据回溯，降低了理解数据和解决数据问题的成本。在元数据管理系统成型后，我们便可以通过血缘分析来对数据仓库中的数据健康、数据分布、集中度、数据热度等进行分析。

快速定位问题

依托于数据血缘，在发生问题时，可以快速排查上游依赖任务，找到问题根源、评估当前问题对下游任务的影响、快速找到对应开发人员，使排查问题的时间大幅缩减。

数据安全审计

数据安全审计是出于数据安全、隐私、或者法律政策考虑，在数仓中什么数据应该存，或者怎么存都会有一定的要求或者标准，有了元数据就可以找到不符合安全标准的数据，进行监管。例如手机号、家庭住址、用户登录密码、身份证号等敏感信息，在数仓中都不应当以明文形式出现

为未来做好准备

大数据、人工智能、数据湖、数据中台、商业智能等企业的战略级应用系统能够依赖良好的元数据管理而发挥出其应有的效果。

四、业界的元数据产品对比

Apache Atlas

开源地址：https://github.com/apache/atlas 1.5K star

Atlas最早由大数据平台三驾马车（Cloudera,Hortonworks,MapR）之一HortonWorks公司开发，用来管理Hadoop项目里面的元数据，进而设计为数据治理的框架，它为Hadoop集群提供了包括数据分类、集中策略引擎、数据血缘、安全和生命周期管理在内的元数据治理核心能力。后来开源出来给Apache社区进行孵化，得到Aetna，Merck，Target，SAS，IBM等公司的支持进行发展演进。因其支持横向海量扩展、良好的集成能力和开源的特点，国内大部分厂家选择使用Atlas或对其进行二次开发。

Atlas的优点：

大厂开源，深度集成Hadoop生态中的Hive，支持表级、字段级血缘
与HDP原生集成，支持对接Ranger实现行列级数据权限管控
强大的元数据模型，支持元数据定制及扩展
扩展性好，国内有大量平台基于Atlas定制修改为商用产品

Atlas的不足：

产品功能更聚焦于解决技术人员的问题，而非业务人员
官方没有对Spark的支持
依赖组件较多，安装部署较为复杂

Netflix Metacat

Metacat架构

Netflix公司的数据存储在Amazon S3、Druid、Elasticsearch、Redshift、Snowflake和 MySql 中。并且需要使用Spark、Presto、Pig和Hive消费、处理和生成数据集。因为数据源的多样性，为了确保数据平台能够横跨这些数据集成为一个“单一”的数据仓库，应用而生了Metacat。Metacat是一种元数据服务，方便发现、处理和管理数据。Metacat支持Hive，Teradata，Redshift，S3，Cassandra和RDS的集成。

Metacat的优点：

Metacat 的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉的方式，一方面它不存在保存两份元数据一致性的问题，另一方面，这种架构设计很轻量化，每个数据源只要实现一个连接实现类即可，扩展成本很低，我把这种设计叫做集成型设计。这种设计方式对于希望构建元数据中心的企业，是非常有借鉴意义的。

Metacat的不足：

缺少完整的文档。尽管Netflix在其博客中发布了一些关于Metacat的文章，但这些文章并不足以提供完整的文档。这可能会使新用户或开发人员难以理解Metacat的工作原理和使用方法。
依赖于Netflix的生态系统。Metacat是Netflix公司内部使用的系统，它在Netflix的生态系统中与其他工具和技术密切相关。这意味着如果其他组织想要使用Metacat，他们可能需要调整他们的技术栈以适应Netflix的生态系统。
需要专业知识。Metacat是一个复杂的系统，需要对数据管理和元数据管理有深入的了解。这可能使得初学者或非专业人士难以理解它的工作原理。
缺少某些功能。虽然Metacat具有许多有用的功能，但它可能缺少一些其他元数据管理系统具有的功能。例如，它可能缺乏与Hadoop和Spark等大数据处理框架的直接集成，也没有数据血缘的支持。

Linkedin Datahub

开源地址：https://github.com/datahub-project/datahub 7.2K star

DataHub是由Linkedin开源的，为了解决多种多样数据生态系统的元数据管理问题，它提供元数据检索、数据发现、数据监测和数据监管能力，帮助解决数据管理的复杂性。

DataHub基于Apache License 2开源，采用基于推送的数据收集架构，能够持续收集变化的元数据。当前版本已经集成了大部分流行数据生态系统接入能力，包括但不限于：Kafka, Airflow, MySQL, SQL Server, Postgres, LDAP, Snowflake, Hive, BigQuery。

Datahub的优点：

名门开源，与Kafka同家庭。社区活跃，发展势头迅猛，版本更新迭代迅速。
底层架构灵活先进，为扩展集成而生，支持推送和拉取模式，详见：https://datahubproject.io/docs/architecture/architecture/
UI界面简单易用，技术人员及业务人员友好
接口丰富，功能全面

Datahub的不足：

前端界面不支持国际化，界面的构建和使用逻辑不够中国化
较多功能在建设中，例如Hive列级血缘
部分功能性能还需要优化，例如SQL Profile
中文资料不多，中文交流社群也不多
缺少对数据安全的支持：Linkedin Datahub虽然提供了基于OAuth2的身份验证和访问控制机制，但是对于数据安全方面的支持还不够完善。

WeWork Marquez

开源地址：https://github.com/MarquezProject/marquez 1.3K star Marquez的优点：

界面美观，操作细节设计比较棒
部署简单，代码简洁
依靠底层OpenLineage协议，结构较好

Marquez的不足：

主要聚焦数据资产/血缘的可视化，数据资产管理的一些功能，需要较多开发工作
社区支持不足：WeWork Marquez 是一个相对新的开源项目，社区支持相对不足，可能会影响用户的使用和开发体验
功能相对单一：WeWork Marquez 的主要功能是元数据管理，对于其他数据管理领域的需求，比如数据质量控制、数据集成等，可能并不能提供完整的解决方案
技术门槛较高：WeWork Marquez 使用的技术栈较为复杂，需要用户具备一定的技术知识和能力才能使用和定制

Lyft Amundsen

开源地址：https://github.com/amundsen-io/amundsen 3.8K star

Amundsen 是来自Lyft 开源的元数据管理、数据发现平台，功能点很全，有一个比较全的前端、后端以及数据处理框架

Amundsen的优点：

Lyft大厂开源，版本更新较多
定位清晰明确，与Datahub类似，致力于成为现代数据栈中的数据目录产品
支持对接较多的数据平台与工具

Amundsen的不足：

中规中矩的UI界面，操作便捷性不足
中文文档不多
血缘、标签、术语等功能方面不够便捷

五、选择Atlas的理由

产品名称	所属公司	开源时间	是否有UI界面	是否支持数据血缘	社区建设情况	是否对外暴露接口	支持数据源	特色
Atlas	Apache	2013.06	是	列级	社区活跃，文档多	REST API, Kafka	HBase, Hive, Sqoop, Kafka, Falcon, Storm	深度集成Hadoop生态中的Hive，支持表级、字段级血缘
Metacat	Netflix	2018.06	否	否	没有官方文档	REST, Thrift	Hive, RDS, Teradata, Redshift, S3, Cassandra	直接从所支持的数据源中获取各自的元数据，无需拉取
Datahub	Linkedin	2020.06	是	表级	中文资料不多，中文交流社群也不多	REST API	Hive, Kafka, RDBMS	UI界面简单易用，对技术及业务人员友好
Marquez	WeWork	2018.10	是	表级	没有官方文档	REST API	S3, Kafka	主要聚焦于数据资产/血缘的可视化
Amundsen	Lyft	2019.10	是	否	中文文档不多	--	Hive, Redshift, Druid, RDBMS, Presto, Snowflake, etc.	支持对接较多的数据平台与工具

支持与多种数据源整合

目前，支持的数据源有Hive、Sqoop、Falcon、Storm、Kafka和Hbase。

支持字段级数据血缘

Atlas深度集成了Hadoop生态中的Hive，支持表级、字段级血缘，目前调研的几款产品中只有Atlas的数据血缘达到了字段级别。

对权限有很好的控制

Atlas中的元数据的准确性和安全性由Apache Ranger来保证，Ranger能够在运行时阻止那些不具备权限的数据访问请求。另外Atlas允许管理员自定义元数据的安全驱动策略来对大数据进行高效的治理，当元数据库中的元数据发生改变时，Atlas会以发送事件的方式通知Ranger。

允许元数据交换

允许从当前的组件导入已存在的元数据或模型到Atlas中，也允许导出元数据到下游系统中。

支持全文搜索

采用Solr实现索引，进一步支持全文搜索这一特性，可以快速与准确地定位相关数据及审计事件。

支持商业业务分类自定义

从各类元数据源中导入Atlas的元数据以最原始的形式存储在元数据库中，这些元数据还保留了许多技术特征。为了加强挖掘与治理大数据的能力，Atlas提供了一个商业业务分类接口，允许用户对其商业领域内的各种术语建立一个具有层次结构的术语集合，并将它们整合成能够被Atlas管理的元数据实体。商业业务分类这一应用，目前是作为Atlas管理界面的一部分而存在的，它通过REST API来与Atlas 集成。

丰富的接口支持

所有功能通过API向用户提供，也可以通过Kafka消息系统进行集成。

优秀的UI支持

通过Web服务将数据血统生命周期以可视化的方式展现给客户，它允许管理员与数据科学家发现元数据信息和添加元数据注解。在诸多主要的功能中，Atlas提供了搜索接口与类SQL语言，这些特性在Atlas的架构中扮演着十分重要的角色，它们能够被用于查询Atlas中的元数据类型和对象。

集中审计

对于每一个访问数据的应用以及交互过程，Atlas会抓取其安全访问信息；对于每一个执行的操作活动及其具体步骤，Atlas能够将这些操作信息抓取下来。

良好的可扩展性

Atlas扩展新的大数据组件时，只需要将组件的HOOK按照kafka的规范添加到系统中即可，这样Atlas就可以对这一新的组件进行管理。

社区活跃，文档丰富

Atlas从2013年就被开源出来，被全球各大公司广泛使用，所以积累了丰富的文档和使用案例，在遇到问题时，也可以方便地找到解决办法。

六、Atlas介绍

简介

在当今大数据的应用越来越广泛的情况下，数据治理一直是企业面临的巨大问题。

大部分公司只是单纯的对数据进行了处理，而数据的血缘，分类等等却很难实现，市场上也急需要一个专注于数据治理的技术框架，这时Atlas应运而生。

Atlas官网地址：https://atlas.apache.org/

Atlas是Hadoop的数据治理和元数据框架。

Atlas是一组可扩展的核心基础治理服务，使企业能够有效、便捷地满足Hadoop中的合规性要求，并允许与整个企业数据生态系统集成。

Apache Atlas为组织提供了开放的元数据管理和治理功能，以建立其数据资产的目录，对这些资产进行分类和治理，并为数据科学家，分析师和数据治理团队提供围绕这些数据资产的协作功能。

如果想要对这些数据做好管理，光用文字、文档是不够的，必须用图。Atlas也是把元数据变成图的工具。

安装部署

可参考文档：https://blog.csdn.net/weixin_49539577/article/details/129236448

底层架构

Atlas架构图如下：

Core层

Atlas核心包含以下组件：

类型(Type)系统: Atlas允许用户为他们想要管理的元数据对象定义模型。该模型由称为“类型”的定义组成。称为“实体”的“类型”实例表示受管理的实际元数据对象。Type System是一个允许用户定义和管理类型和实体的组件。开箱即用的Atlas管理的所有元数据对象（例如Hive表）都使用类型建模并表示为实体。要在Atlas中存储新类型的元数据，需要了解类型系统组件的概念。
图形引擎: Atlas在内部使用Graph模型持久保存它管理的元数据对象。这种方法提供了很大的灵活性，可以有效地处理元数据对象之间的丰富关系。图形引擎组件负责在Atlas类型系统的类型和实体之间进行转换，以及底层图形持久性模型。除了管理图形对象之外，图形引擎还为元数据对象创建适当的索引，以便可以有效地搜索它们。Atlas使用JanusGraph存储元数据对象。
采集/导出：Ingest 组件允许将元数据添加到Atlas。类似地，Export 组件暴露由 Atlas 检测到的元数据更改，以作为事件引发，消费者可以使用这些更改事件来实时响应元数据更改。

Integration层

在Atlas中，用户可以使用以下的两种方式管理元数据：

API: Atlas的所有功能都通过REST API向最终用户暴露，该API允许创建，更新和删除类型和实体。它也是查询和发现Atlas管理的类型和实体的主要机制。
Messaging: 除了API之外，用户还可以选择使用基于Kafka的消息传递接口与Atlas集成。这对于将元数据对象传递到Atlas以及使用Atlas使用可以构建应用程序的元数据更改事件都很有用。如果希望使用与Atlas更松散耦合的集成来实现更好的可伸缩性，可靠性等，则消息传递接口特别有用.Atlas使用Apache Kafka作为通知服务器，用于钩子和元数据通知事件的下游消费者之间的通信。事件由钩子和Atlas写入不同的Kafka主题。

Metadata sources层

Atlas支持开箱即用的多种元数据源集成。未来还将增加更多集成。目前，Atlas支持从以下来源提取和管理元数据：

HBase
Hive
Sqoop
Storm
Kafka

集成意味着两件事：Atlas定义的元数据模型用于表示这些组件的对象。Atlas提供了从这些组件中摄取元数据对象的组件（在某些情况下实时或以批处理模式）。

Applications层

Atlas管理的元数据被各种应用程序使用，以满足许多治理需求。

Atlas Admin UI: 该组件是一个基于Web的应用程序，允许数据管理员和科学家发现和注释元数据。这里最重要的是搜索界面和类似SQL的查询语言，可用于查询Atlas管理的元数据类型和对象。Admin UI使用Atlas的REST API来构建其功能。
Ranger Tag Based Policies:Apache Ranger是Hadoop生态系统的高级安全管理解决方案，可与各种Hadoop组件进行广泛集成。通过与Atlas集成，Ranger允许安全管理员定义元数据驱动的安全策略以实现有效的治理。Ranger是Atlas通知元数据更改事件的使用者。

前台界面展示：

登录界面

Atlas的页面功能非常的丰富，可以进行元数据的管理及数据血缘的展示。

主界面

Search界面（全局搜索）

基本搜索

基本搜索允许您使用实体的类型名称，关联的分类/标记进行查询，并且支持对实体属性以及分类/标记属性进行过滤。

可以使用 AND/OR 条件对多个属性进行基于属性的过滤。

支持的过滤运算符

LT（符号：<, lt）适用于数字、日期属性
GT（符号：>、gt）适用于数字、日期属性
LTE（符号：<=, lte）适用于数字、日期属性
GTE（符号：>=，gte）适用于数字、日期属性
EQ（符号：eq、=）适用于数字、日期、字符串属性
NEQ（符号：neq、!=）适用于数字、日期、字符串属性
LIKE（符号：like、LIKE）与字符串属性一起使用
STARTS_WITH（符号：startsWith、STARTSWITH）与字符串属性一起使用
ENDS_WITH（符号：endsWith、ENDSWITH）与字符串属性一起使用
CONTAINS (symbols: contains, CONTAINS) 使用 String 属性

高级搜索

Atlas 中的高级搜索也称为基于 DSL 的搜索。

领域特定搜索 (DSL) 是一种结构简单的语言，该语法模拟了关系数据库流行的结构化查询语言 (SQL)。

具体语法请参考Github上的Atlas DSL Grammer （Antlr G4格式）。

例：要检索名称可以是 time_dim 或 customer_dim 的 Table 类型的实体：

from Table where name = 'time_dim' or name = 'customer_dim'

Classification界面（分类管理）

分类传播使与实体相关联的分类能够自动与该实体的其他相关实体相关联。这在处理数据集从其他数据集派生数据的场景时非常有用。

为实体添加分类

将分类“PII”添加到“hdfs_path”实体后，该分类将传播到沿袭路径中的所有受影响实体，包括“员工”表、视图“us_employees”和“uk_employees” - 如下所示。

更新与实体关联的分类

与实体关联的分类的任何更新也将在分类传播到的所有实体中看到。

简单的说，此功能可以监控数据到底流向了哪里。

Glossary界面（词汇管理）

词汇表，也称术语表，为业务用户提供适当的词汇表，它允许术语（词）相互关联并分类，以便在不同的上下文中理解它们。然后可以将这些术语映射到数据库、表、列等资产。这有助于抽象与存储库相关的技术术语，并允许用户发现/使用他们更熟悉的词汇表中的数据。

通过单击词汇表 UI 中的术语名称，可以查看术语的各种详细信息。详细信息页面下的每个选项卡提供该术语的不同详细信息。

当切换开关在类别上时，面板将列出所有词汇表以及类别层次结构。这是此视图下可能的交互的列表。

如果一个术语具有分类，则该实体已被分配继承相同的分类。

通过术语表的功能，让数据资产与业务系统建立了联系。

Classification和Glossary的区别

Atlas的classification是指对内容进行分类，以便读者可以根据主题、类别或其他特定条件来查找信息。Apache Atlas的classification可以根据具体需求进行自定义，但一般来说，以下一些分类可以比较合适：

数据类型：可以根据数据类型进行分类，如文本、图像、视频等。
安全级别：可以根据数据的安全级别进行分类，如公开、内部、机密等。
业务领域：可以根据数据所属的业务领域进行分类，如销售、市场、人力资源等。
数据来源：可以根据数据的来源进行分类，如外部数据、内部数据等。
数据格式：可以根据数据的格式进行分类，如CSV、JSON、XML等。
数据质量：可以根据数据的质量进行分类，如高质量、中等质量、低质量等。
数据生命周期阶段：可以根据数据所处的生命周期阶段进行分类，如采集、清洗、分析、应用等。
数据所有者：可以根据数据的所有者进行分类，如部门、个人等。

而glossary是指为了帮助读者理解专业术语而制作的词汇表。它包括对特定术语的定义、解释或翻译，以及与该术语相关的其他信息。比如以下就是一些电商行业的一些术语：

PV： pv的全称是Page View，译为页面浏览量或点击量，通常是衡量一个网站的指标。
UV： uv的全称是Unique Visitor，译为独立访问用户数，访问网站的一台电脑客户端为一个访客
GMV： gmv的全称是Gross Merchandise Volume，即商品交易总额，是成交总额(一定时间段内)的意思。多用于电商行业
DAU： dau的全称是Daily Active User，译为日活跃用户数量，常用于反映网站、APP应用、互联网应用或网络游戏的运营情况
MAU： mau的全称是Monthly Active Users，译为月活跃用户人数
CVR： cvr的全称是Conversion Rate，译为转化率，是指在一个统计周期内，完成转化行为的次数占推广信息总点击次数的比率
CTR： ctr全称为Click Through Rate，译为点击率或点曝比，互联网广告常用的术语，指网络广告（图片广告/文字广告/关键词广告/排名广告/视频广告等）的点击到达率
QPS： qps全称是Queries Per Second，译为每秒查询数，每秒能够响应的查询次数

用户也可以将术语关联到具体的atlas实体上。

因此，Atlas的classification和glossary是两个不同的概念，其目的和内容也不同。

Apache Atlas中的Business Metadata和Glossary的区别:

Business Metadata是描述业务数据的元数据，描述数据的业务含义、数据所有者、敏感度级别等信息。而Glossary则是一个术语表，定义了一组业务术语及其含义，帮助用户理解数据的业务含义。 2. Business Metadata是与实际数据相关的元数据，通常是根据数据模型或架构来定义的。而Glossary则是独立于实际数据的元数据，通常是由业务用户定义的。 3. Business Metadata可以直接应用于数据资产，帮助用户理解数据的业务含义和价值。而Glossary通常用于构建业务词汇表，提供一致的术语定义和理解。 4. Business Metadata可以帮助用户发现数据质量问题，理解数据的来源和使用方式。而Glossary则可以帮助用户识别数据资产中使用的术语和定义，确保数据在整个企业中的一致性。

说明：本文部分图片及文字摘自【大数据流动】等其他资料，如有侵权，请联系我，我会第一时间处理，感谢