CN110569298A - 一种数据对接、可视化方法和系统 - Google Patents

Abstract

本发明公开了一种数据对接、可视化方法和系统，方法包括：服务端获取若干业务端数据，对数据进行清洗与治理；将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值；对新创建或已存在的数据字典选择标签字段，以形成数据标准；业务端选择数据字典，将本地数据与标签字段进行映射；通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。本发明与现有技术相比，解决现有技术采用通用数据进行展示，使得数据不匹配的问题；同时，本发明利用数字字典的形式，形成配套方案，可以解决现有技术需要业务端进行选择组合、使得数据处理麻烦的问题，降低了对业务端管理员的要求。

Description

一种数据对接、可视化方法和系统

技术领域

本发明涉及一种数据对接、可视化方法和系统。

背景技术

大数据(big data)是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换而言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。它的特色在于对海量数据进行分布式数据挖掘。

然而现有的业务系统(业务端)具有各式各样的数据，尤其是对于不同公司的业务系统更具有不同的数据，若仅采用行业内通用数据进行可视化展示，会大程度产生数据不匹配的问题。

公开于本发明背景技术部分的信息仅仅旨在加深对本公开的一般背景技术的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域技术人员所公知的现有技术。

发明内容

本发明的目的在于克服现有技术的不足，提供一种数据对接、可视化方法和系统。

本发明的目的是通过以下技术方案来实现的：

本发明的第一方面，提供一种数据对接、可视化方法，包括：

服务端获取若干业务端数据，对数据进行清洗与治理；

将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值；

对新创建或已存在的数据字典选择标签字段，以形成数据标准；

业务端选择数据字典，将本地数据与标签字段进行映射；

通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。

进一步地，在所述获取若干业务端数据之前还包括接口连接步骤，具体包括：

服务端检测到业务端接入预定的接口时，建立与业务端的连接，并创建服务线程，以获取并解析来自业务端的请求；

所述服务端的服务线程在解析到来自业务端的请求为源数据调取请求时，建立业务端与源数据接口的连接，并创建第一监听线程；

所述第一监听线程对源数据调取过程进行监听，判断源数据接口是否能访问成功并成功返回请求数据，同时判断源数据接口接收到的返回的数据是否为有效数据；如果有任意一项不满足，则生成预警信息并发送；

在判断源数据接口能访问成功后，创建对应于所述源数据接口的第二监听线程；

所述第二监听线程轮训式监听业务端的数据库日志记录，验证当前数据是否有效存在；如果不满足，则生成预警信息并发送。

进一步地，所述业务端连接至服务端时，将业务端类型一并发送至服务端；对于不同类型的业务端数据分别保存至不同的中间库；

所述标签字段和数据字典均分为不同中间库类别的标签字段和数据字典；所述业务端选择数据字典，具体包括：根据自身类型自动选择对应中间库类别中的数据字典。

进一步地，在所述业务端类别不与服务端中任意一个中间库匹配时，业务端自行选择中间库、或者根据业务端上传的本地标签字段匹配最高相似度的中间库、或者新建新类别的中间库。

进一步地，所述对数据进行清洗与治理，具体包括：

使用kettle工具将数据库里的json转存为hive临时表；

使用hue工具将hive临时表进行逻辑加工清洗计算输出hive结果表；

使用kettle将hive结果表进行推送。

进一步地，所述将hive临时表进行逻辑加工清洗，具体包括：

将hive临时表数据新增至hive结果表，在hive结果表新增当前时间字段，用于通过hive结果表根据时间查看历史数据；

根据逻辑处理数据，将数据处理成大数据表对应字段结构，得到最终的hive结果表。

进一步地，所述字段范围取值还经人工审核后限定。

进一步地，所述方法还包括：

当多个能匹配类型的业务端无法完全匹配数字字典的数字标签时，对对应类型的数据重新进行清洗、治理与转换，以形成新的中间库。

进一步地，所述可视化展示包括对对应数字标签的数据进行联动显示。

本发明的第二方面，提供一种数据对接和可视化系统，包括服务端和业务端；其中：

所述服务端，用于获取若干业务端数据，对数据进行清洗与治理；

所述服务端，用于将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值；

所述服务端，用于对新创建或已存在的数据字典选择标签字段，以形成数据标准；

所述业务端，用于选择数据字典，将本地数据与标签字段进行映射；

所述业务端，用于通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。

本发明的有益效果是：

(1)在本发明一示例性实施例中，将若干业务端数据抽取清洗后形成标签字段，再将标签字段组合成用于数据字典；之后业务端选择数据字典，并进行相应的可视化展示。与现有技术相比，本发明解决现有技术采用通用数据进行展示，使得数据不匹配的问题。同时，本发明利用数字字典的形式，形成配套方案，可以解决现有技术需要业务端进行选择组合、使得数据处理麻烦的问题，降低了对业务端管理员的要求。

(2)在本发明一示例性实施例中，提供的接口预警，其核心思想是从服务端到业务端两层关卡，双向保障数据接口预警效果，无遗漏：第一层是监听服务端源数据接口，第二层是监听业务端数据库日志记录。同时，对于第二层监听的前提是第一层监听的基础，避免在服务端出现问题时仍然创建第二层监听浪费多余资源的问题。

(3)在本发明一示例性实施例中，由于业务端可能会对应不同类型，该类型可以是行业类型，也可以是服务端提出的类型分类。因此为了使得数据选择更加准确，在业务端连接至服务端时，将业务端类型一并发送至服务端；对于不同类型的业务端数据分别保存至不同的中间库；标签字段和数据字典均分为不同中间库类别的标签字段和数据字典；步骤S4中所述业务端选择数据字典，具体包括：根据自身类型自动选择对应中间库类别中的数据字典。

(4)在本发明一示例性实施例中，在所述业务端类别不与服务端中任意一个中间库匹配时，业务端自行选择中间库、或者根据业务端上传的本地标签字段匹配最高相似度的中间库、或者新建新类别的中间库。

(5)在本发明一示例性实施例中，当多个能匹配类型的业务端无法完全匹配数字字典的数字标签时，对对应类型的数据重新进行清洗、治理与转换，以形成新的中间库。

附图说明

图1为本发明方法流程图。

具体实施方式

下面结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

参见图1，图1示出了一示例性实施例中提供的一种数据对接、可视化方法，包括：

S1：服务端获取若干业务端数据，对数据进行清洗与治理。

具体实施时，可以采用ETL工具来实现，ETL是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过萃取(extract)、转置(transform)、加载(load)至目的端的过程。

而在一示例性实施例中，在该步骤S1中的所述对数据进行清洗与治理，具体包括：

S101：使用kettle工具将数据库里的json转存为hive临时表；

S102：使用hue工具将hive临时表进行逻辑加工清洗计算输出hive结果表；

S103：使用kettle将hive结果表进行推送。

其中：S101能将杂乱无章的原始数据进行拆分解析成为业务所需的数据项进行分类存储至数据仓库hive中。

而S102是通过hue工具采用数据开发，将数据仓库中STG层的原始数据进行一定的业务逻辑加工清洗、计算等最终输出到数仓DWD层中。

S103再通过kettle工具将数仓中DWD层数据进行快速、实时的推送至业务平台中进行相关大屏微件展示。

具体地，下面是大数据平台关于数仓设计详细部分：数据分层包括下面三层：

(1)STG层：STAGE，结构与源系统保持一致的增量/全量数据。云仓第一层，汇聚本地仓数据。也是ETL加工过程的缓冲区，便于源系统数据质量核查及溯源。

对于表命名规范：stg_${业务库简写标识}_${业务库原始表名}_${分区标识}。命名示例：stg_aic_base_card_df。

对于表结构设计：STG层表结构，在源业务系统表结构基础上，增加如下字段：1)入库日期字段，字段命名load_time数据类型为datetime。2)增加分区，默认字段名pt

对于数据更新：1)生命周期：全量表生命周期7天；2)每日全量数据：抽取前置库源业务系统表全量数据，填写入库日期字段，放入STG层表T-1(前一日)分区。

(2)ODS层：Operational Data Store，结构与STG保持一致的增量/全量数据。进行数据清洗和脱敏(加密)的工作。

对于表命名规范：ods_{业务库简写标识}_{业务库原始表名}[_分区标识]。命名示例：ods_aic_base_card_df。

对于表结构设计，ODS层表结构，与STG层表结构保持一致

对于数据更新：1)生命周期：全量表生命周期7天；2)每日数据处理：对STG层表T-1分区数据按脱敏策略，进行脱敏处理，放入ODS层表T-1(前一日)分区。

对于转换：针对脱敏字段，进行脱敏操作。

(3)DWD层：Data Warehouse Detail，数据仓库明细层数据。对数据按规划的数据域进行分类，整合，清洗，形成一套标准化数据模型。

对于表命名规范：dwd_{数据域}_<数据子域>[_数据描述]_[分区标识]。命名示例：dwd_ry_jbxx_zb_df。

对于表结构设计：1)结构基于ODS表结构。2)根据清洗转换规范，扩展新增字段到DWD基础表中。

对于清洗转换：1)代码值扩展，对常用代码，将代码对应的名称字段扩展到表内。2)字符格式转换，进行全半角转换，字段中部份特定字符的清理，包括\n、\r、尾部\等。3)针对字段后出现空字符‘’统一转换为NULL；针对字段后出现“NULL”字符串也统一转换为NULL。4)时间标准化，扩充按datetime类型的时间字段。

并且在上述示例性实施例中，步骤S102中所述将hive临时表进行逻辑加工清洗，具体包括：

S10201：将hive临时表数据新增至hive结果表，在hive结果表新增当前时间字段，用于通过hive结果表根据时间查看历史数据；

S10202：根据逻辑处理数据，将数据处理成大数据表对应字段结构，得到最终的hive结果表。

通过数据仓库分层能很好的进行原始数据、清洗中间数据、结果数据分类建设，也就是俗称的数仓设计，原始数据作为备份数据，即使后续业务数据发现有问题或者逻辑不对时，还能进行相关数据恢复重新计算清洗等。

S2：将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值。

其中，该标签字段用于组合之后形成作为数据标准的数据字典。

而在一示例性实施例中，所述字段范围取值不仅根据获取到的取值进行限定，还经人工审核后限定。尤其是对于部分部分数据大概率分布于小范围、而该部分数据的取值范围可以存在于大范围的情况。

S3：对新创建或已存在的数据字典选择标签字段，以形成数据标准。

其中，该数字字典为在服务端进行选择，可以是管理员选择、也可以是具有一定权限的业务端在服务端上进行选择。

同一个数据字典优选包括多个标签字段。

S4：业务端选择数据字典，将本地数据与标签字段进行映射。

具体地，由于数据字典具有多个标签字段，需要业务端在本地将本地数据的类型与标签字段进行映射。

在具体实施中，映射包括两种方式：(1)自动映射，根据标签字段的名称和数据的实际情况，业务端自行进行映射；(2)手动映射，业务端管理员手动对本地数据与标签字段进行映射。也可以将两种方式进行结合。

S5：通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。

其中，该可视化工具进行显示的软件模块通过服务端进行下发至业务端，尤其是根据对应数据字典选择的数据配置相应的软件模块。

在一示例性实施例中，所述可视化展示包括对对应数字标签的数据进行联动显示。

更优地，在又一示例性实施例中，在所述获取若干业务端数据之前还包括接口连接步骤S0，具体包括：

S01：服务端检测到业务端接入预定的接口时，建立与业务端的连接，并创建服务线程，以获取并解析来自业务端的请求。

在一示例性实施例中，所述预定的接口可以是硬件接口，例如串口、USB接口，即对应的业务端可以是采集数据的实体数据设备；也可以是软件接口，例如应用程序编程API接口等等，即对应的业务端可以是具有软件数据的存储设备。

然而由于业务端的请求具有多种(其中一种即为源数据调取请求)，因此当业务端通过预定的接口接入至服务端时，所述服务端可与所述业务端建立连接；同时创建一服务线程，该服务线程用以获取并解析来自业务端的请求，尤其是识别源数据调取请求。

S02：所述服务端的服务线程在解析到来自业务端的请求为源数据调取请求时，建立业务端与源数据接口的连接，并创建第一监听线程。

在一示例性实施例中，服务线程识别到业务端请求数据调取时，不仅建立业务端与源数据接口的连接，还会创建第一监听线程，即通过第一监听线程开始对服务端这一层的进行监听。

S03：所述第一监听线程对源数据调取过程进行监听，判断源数据接口是否能访问成功并成功返回请求数据，同时判断源数据接口接收到的返回的数据是否为有效数据；如果有任意一项不满足，则生成预警信息并发送。

其中，在每次调取源数据接口时，都会进行双重验证：(1)判断源数据接口是否能访问成功并成功返回请求数据；(2)判断源数据接口接收到的返回的数据是否为有效数据；如果两者都满足则进行下一步，否则会生成预警信息并发送。

而在一示例性实施例中，所述的判断源数据接口是否能访问成功，具体包括：

通过http协议访问请求源数据接口，验证接口是否正常能调用。

而在又一示例性实施例中，判断成功返回请求数据，具体包括：

采用http协议判断接口请求状态，并根据返回的协议状态码进行验证。

而在又一示例性实施例中，所述的判断源数据接口接收到的返回的数据是否为有效数据，具体包括：

验证数据结构：接口请求成功后返回的数据结构是否满足业务需求；

验证每个数据项格式是否正确，包括字符、数字、汉字和长度在内的字符类型验证；

验证所有返回的数据项是否都是合法有效数据。

S04：在判断源数据接口能访问成功后，创建对应于所述源数据接口的第二监听线程。

也就是说，当源数据接口能够访问后，创建第二监听线程，即通过第二监听线程开始对业务端这一层的进行监听。

并且该第二监听线程的创建前提是基于源数据接口访问成功，避免在服务端出现问题时仍然创建第二监听线程浪费多余资源的问题。

S05：所述第二监听线程轮训式监听业务端的数据库日志记录，验证当前数据是否有效存在；如果不满足，则生成预警信息并发送。

而在一示例性实施例中，所述验证当前数据是否有效存在，具体包括：

在业务端的数据库中以轮询式搜索日志记录的数据表中是否有新数据产生，具体采用任务调度器轮询式使用Tsql脚本语句搜索。

在一示例性实施例中，所述源数据接口由服务端的任务调度模块进行调度分配，所述预警消息发送至任务调度模块；所述预警信息包括数据错误情况和源数据接口ID。

即源数据接口具有多个，需要通过统一机制(即任务调度模块)实现调度分配，当生成了预警消息时该任务调度模块会根据实际情况对源数据接口进行调整，在一示例性实施例中，对于同一个源数据接口：(1)若在一段时间内，仅出现了一次(或者预设次数)的预警消息，则无需对该源数据接口进行处理；(2)而当在一段时间多次接收到同一源数据接口ID的预警信息时，此时则证明该源数据接口出现明显问题，此时该任务调度模块需要对该接口进行调整：具体地，调整方式为将对应源数据接口挂起，自动断开业务端与服务端的连接，并分配新的源数据接口与业务端连接；之后，将挂起的源数据接口释放。

即通过重新分配接口的方式实现预警后的后处理。

然而，如果产生预警信息、源数据接口被挂起时，数据有可能在整个数据包的中端发送即被中止，因此需要一解决方式解决该问题，具体地：

在一示例性实施例中，所述数据错误情况包括数据错误类型和对应源数据的数据包名称；将所述数据包名称发送至业务端，以使所述业务端将未发送完成的数据包进行发送。

其中，数据错误类型即包括上述的三次判断(服务端两次、业务端的数据库日志记录一次)，而通过数据包名称则可实现数据的继续发送。另外，由于为了避免错误判断继续发送的数据点，因此通过重新发送数据包即可解决该问题。

而为了避免重新发送数据包导致部分数据重复获取(导致大数据获取错误)，因此在一示例性实施例中，服务端对重分配接口的业务端的所有数据进行组合处理；其中，对于具有相同数据包名称的数据，自动丢弃数据大小不是最大的对应数据包名称的数据。

在一示例性实施例中，所述预警信息还发送至显示装置，以使管理员获取各源数据接口的故障情况并进行相应处理。

其中，该显示装置可以为管理员的移动终端、固定终端等，可以通过邮件/短信/APP的方式实现。当管理员接收到包括源数据接口ID和数据错误情况在内的预警信息时，管理员即实时把控各源数据接口的故障情况，以便快速处理。

为了避免出现问题源数据接口在未恢复前即开始使用，因此，在一示例性实施例中，采用下述方式进行解决：

经挂起并释放后的源数据接口相较于未经挂起处理的源数据接口，在预设时间内具有低优先级；在预设时间后或者经管理员处理后恢复优先级。

其中，对于管理员处理后的源数据接口，立即恢复优先级，即认为该源数据接口已经恢复正常；而对于管理员未处理的源数据接口，仅在预设时间后自动恢复优先级，避免源数据接口在被挂起与释放后再次马上被调用再次出现问题的问题。

另外，由于业务端可能会对应不同类型，该类型可以是行业类型，也可以是服务端提出的类型分类。因此为了使得数据选择更加准确，在一示例性实施例中：

在步骤S0或者S1中，所述业务端连接至服务端时，将业务端类型一并发送至服务端；对于不同类型的业务端数据分别保存至不同的中间库；

而在步骤S2和步骤S3中所述标签字段和数据字典均分为不同中间库类别的标签字段和数据字典；步骤S4中所述业务端选择数据字典，具体包括：根据自身类型自动选择对应中间库类别中的数据字典。

同时，在一示例性实施例中，在所述业务端类别不与服务端中任意一个中间库匹配时，业务端自行选择中间库、或者根据业务端上传的本地标签字段匹配最高相似度的中间库、或者新建新类别的中间库。

在具体实施中，业务端可以选择一个相近类别的进行最接近匹配，或者根据本地的字段与服务端字段进行匹配，或者具有权限的业务端自行创建新类别的中间库。

另外，在又一示例性实施例中，所述方法还包括：

当多个能匹配类型的业务端无法完全匹配数字字典的数字标签时，对对应类型的数据重新进行清洗、治理与转换，以形成新的中间库。

产生该种问题(即多个能匹配类型的业务端无法完全匹配数字字典的数字标签)，主要包括两个原因：(1)选择数据治理与清洗的数据存在问题；(2)该类型的业务端数据在发展过程中出现了需要处理的新的数据。无论是上述两种原因的哪一种，都可以采用该示例性实施例方式的解决。

基于上述任意一个实施例中的发明构思，本示例性实施例提供一种数据对接和可视化系统，包括服务端和业务端；其中：

所述服务端，用于获取若干业务端数据，对数据进行清洗与治理；

所述服务端，用于将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值；

所述服务端，用于对新创建或已存在的数据字典选择标签字段，以形成数据标准；

所述业务端，用于选择数据字典，将本地数据与标签字段进行映射；

所述业务端，用于通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。

本领域的技术人员应明白，本申请的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种数据对接、可视化方法，其特征在于：包括：

服务端获取若干业务端数据，对数据进行清洗与治理；

将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值；

对新创建或已存在的数据字典选择标签字段，以形成数据标准；

业务端选择数据字典，将本地数据与标签字段进行映射；

通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。

2.根据权利要求1所述的一种数据对接、可视化方法，其特征在于：在所述获取若干业务端数据之前还包括接口连接步骤，具体包括：

服务端检测到业务端接入预定的接口时，建立与业务端的连接，并创建服务线程，以获取并解析来自业务端的请求；

所述服务端的服务线程在解析到来自业务端的请求为源数据调取请求时，建立业务端与源数据接口的连接，并创建第一监听线程；

所述第一监听线程对源数据调取过程进行监听，判断源数据接口是否能访问成功并成功返回请求数据，同时判断源数据接口接收到的返回的数据是否为有效数据；如果有任意一项不满足，则生成预警信息并发送；

在判断源数据接口能访问成功后，创建对应于所述源数据接口的第二监听线程；

所述第二监听线程轮训式监听业务端的数据库日志记录，验证当前数据是否有效存在；如果不满足，则生成预警信息并发送。

3.根据权利要求1或2所述的一种数据对接、可视化方法，其特征在于：所述业务端连接至服务端时，将业务端类型一并发送至服务端；对于不同类型的业务端数据分别保存至不同的中间库；

所述标签字段和数据字典均分为不同中间库类别的标签字段和数据字典；所述业务端选择数据字典，具体包括：根据自身类型自动选择对应中间库类别中的数据字典。

4.根据权利要求3所述的一种数据对接、可视化方法，其特征在于：在所述业务端类别不与服务端中任意一个中间库匹配时，业务端自行选择中间库、或者根据业务端上传的本地标签字段匹配最高相似度的中间库、或者新建新类别的中间库。

5.根据权利要求1所述的一种数据对接、可视化方法，其特征在于：所述对数据进行清洗与治理，具体包括：

使用kettle工具将数据库里的json转存为hive临时表；

使用hue工具将hive临时表进行逻辑加工清洗计算输出hive结果表；

使用kettle将hive结果表进行推送。

6.根据权利要求5所述的一种数据对接、可视化方法，其特征在于：所述将hive临时表进行逻辑加工清洗，具体包括：

将hive临时表数据新增至hive结果表，在hive结果表新增当前时间字段，用于通过hive结果表根据时间查看历史数据；

根据逻辑处理数据，将数据处理成大数据表对应字段结构，得到最终的hive结果表。

7.根据权利要求1所述的一种数据对接、可视化方法，其特征在于：所述字段范围取值还经人工审核后限定。

8.根据权利要求3所述的一种数据对接、可视化方法，其特征在于：所述方法还包括：

当多个能匹配类型的业务端无法完全匹配数字字典的数字标签时，对对应类型的数据重新进行清洗、治理与转换，以形成新的中间库。

9.根据权利要求1所述的一种数据对接、可视化方法，其特征在于：所述可视化展示包括对对应数字标签的数据进行联动显示。

10.一种数据对接和可视化系统，包括服务端和业务端，其特征在于：其中，

所述服务端，用于获取若干业务端数据，对数据进行清洗与治理；

所述服务端，用于将数据转换为标签字段，并根据获取到的数据的实际取值限定对应标签字段的字段范围取值；

所述服务端，用于对新创建或已存在的数据字典选择标签字段，以形成数据标准；

所述业务端，用于选择数据字典，将本地数据与标签字段进行映射；

所述业务端，用于通过可视化工具将本地数据以对应标签字段组的数据标准进行可视化展示。