一种准实时效能管理方法、装置、计算机设备及存储介质与流程

1.本发明涉及计算机软件技术领域，特别涉及一种准实时效能管理方法、装置、计算机设备及存储介质。


背景技术：

2.目前业内主要的项目管理软件有：jira(是atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域)、禅道(一种开源项目管理软件，其核心管理思想基于敏捷方法scrum，内置产品管理和项目管理)、tapd(源自于腾讯的敏捷产品研发协作平台，提供贯穿敏捷开发生命周期的一站式服务)、阿里云效平台(企业级一站式研发协同平台，支持公共云、专有云和混合云多种部署形态)、华为projectman(其提供简单高效的团队协作服务,包含多项目管理、敏捷迭代、看板协作、需求管理、缺陷跟踪、文档管理、wiki在线协作、仪表盘自定制报表等功能)等。上述软件虽然含有效能管理，但不具备类似bi软件(一种大数据分析工具)的灵活报表配置能力。而如果将数据导入bi软件做效能管理，则又无法达到实时的效能管理，即只能实现离线或者半离线分析，导致用户缺乏体验。


技术实现要素：

3.本发明实施例提供了一种准实时效能管理方法、装置、计算机设备及存储介质，旨在对项目管理中的数据实现高性能、准实时的效能分析。
4.第一方面，本发明实施例提供了一种准实时效能管理方法，包括：
5.从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；
6.采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；
7.利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；
8.通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。
9.第二方面，本发明实施例一种准实时效能管理装置，包括：
10.第一读取单元，用于从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；
11.第一写入单元，用于采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；
12.第二写入单元，用于利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；
13.对接管理单元，用于通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。
14.第三方面，本发明实施例一种计算机设备，包括存储器、处理器及存储在所述存储
器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面所述的准实时效能管理方法。
15.第四方面，本发明实施例一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的准实时效能管理方法。
16.本发明实施例提供了一种准实时效能管理方法、装置、计算机设备及存储介质，该方法包括：从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。本发明实施例通过将mysql数据库中的binlog数据提取并写入至kafka同步机制中，然后结合存储数据库对数据进行存储和查询，从而实现了对项目管理中的数据进行高性能、准实时的效能分析管理。
附图说明
17.为了更清楚地说明本发明实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
18.图1为本发明实施例提供的一种准实时效能管理方法的流程示意图；
19.图2为本发明实施例提供的一种准实时效能管理方法的子流程示意图；
20.图3为本发明实施例提供的一种准实时效能管理方法的另一子流程示意图；
21.图4为本发明实施例提供的一种准实时效能管理装置的示意性框图；
22.图5为本发明实施例提供的一种准实时效能管理装置的子示意性框图；
23.图6为本发明实施例提供的一种准实时效能管理装置的另一子示意性框图。
具体实施方式
24.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
25.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
26.还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
27.还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
28.下面请参见图1，图1为本发明实施例提供的一种准实时效能管理方法的流程示意图，具体包括：步骤s101～s104。
29.s101、从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；
30.s102、采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；
31.s103、利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；
32.s104、通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。
33.本实施例中，在对数据(例如数据报表等)进行效能管理时，首先从mysql数据库中读取binlog数据，然后对其进行解析和压缩，并写入至kafka同步机制中，接着通过数据仓库技术读取kafka同步机制中的binlog数据，并进一步写入至存储数据库(例如clickhouse数据库)中，随后采用bi工具与存储数据库对接，以获取存储数据库中存储的数据，从而方便对存储数据库中的数据进行效能管理。
34.本实施例通过将mysql数据库中的binlog数据提取并写入至kafka同步机制中，然后结合存储数据库对数据进行存储和查询，从而实现了对项目管理中的数据进行高性能、准实时的效能分析。例如在具体应用场景中，本实施例所提供的准实时效能管理方法的数据延时低于10秒。
35.在一实施例中，如图2所示，所述步骤s101包括：步骤s201～s203、
36.s201、采用canal技术模拟mysql数据库主从同步的方式读取所述binlog数据；
37.s202、解析并获取所述binlog数据的全局事务，以实现事务化同步；
38.s203、通过protobuf格式对解析后的binlog数据进行压缩。
39.具体的，在所述步骤s202之前，包括：
40.对mysql数据库开启binlog和全局事务模式，并将binlog设置为行模式。
41.本实施例采用canal技术，通过伪装成mysql-slave的方式从mysql数据库中读取binlog数据，并对所述binlog数据进行解析，然后通过protobuf格式压缩解析后的binlog数据。本实施例既能通过dump的方式同步现有数据，又能通过binlog的方式同步增量数据，其中增量数据的偏移量存储的是gtid，可实现事务化的同步，在一个事务结束后(即gtid发生变化)，数据才真正开始写入。此外，在同步前，mysql数据库必须开启binlog和gtid模式，并将binlog设置为行模式。在具体应用场景中，采用go语言开发，能够无需外部依赖，可实现便捷部署。
42.本实施例所述的canal是一种通过流的方式来将mysql数据库中的binlog数据流转到目标的技术，主要用途是基于mysql数据库增量日志解析，提供增量数据订阅和消费。binlog数据是mysql数据库二进制格式的日志文件。binlog是用来记录mysql内部对数据库的改动(只记录对数据的修改操作)，主要用于数据库的主从复制以及增量恢复。
43.在一具体实施例中，所述采用canal技术模拟mysql数据库主从同步的方式读取所述binlog数据，还包括：
44.通过canal集群实时获取mysql数据库中的binlog数据；
45.利用预先存储于canal集群中的表关联策略构建目标表；
46.将所述目标表写入至数据流转服务中。
47.其中，所述的表关联策略具体为：若mysql数据库中有两张数据表在同一事务中进行了修改，则将两个数据表中新增的binlog数据在canal集群中进行关联，并组成目标表写
入数据流转服务中；若mysql数据库中有一张数据表中新增binlog数据，则通过数据流转服务获取与该binlog数据相关联的字段，并组成目标表写入数据流转服务。此外，所述的canal集群采用key-value方式，并以关联字段的数据作为key，与对应的value值进行匹配。
48.此外，在解析并获取所述binlog数据的全局事务时，利用反射技术对其进行标记，标记内容可以为：组织/团队、用户等，标记数据记录可以在后续步骤中准确识别出某些操作是由哪个团队的哪个用户所产生的。在事务执行之后获取到mysql数据库中的gtid(global transaction id:全局事务id)。由于在go语言的mysql driver中是没有办法直接获取到gtid的，所以对mysql driver的代码进行调整，使用反射技术，从mysql数据库的ok package中获取得到gtid。在事务中通过反射获取gtid，能够减少开发人员对底层的了解，只需要关心业务层即可。
49.还有，在通过protobuf格式对解析后的binlog数据进行压缩时，具体包括：
50.根据binlog数据的结构编写.proto文件；
51.使用protobuf工具生产.pb.cc文件和.pb.hh文件；该.pb.cc和.pb.hh文件定义了消息的类，消息字段就是类成员，包含了设置和获取各个成员的方法；
52.结合所述的.proto文件、.pb.cc和.pb.hh文件对所述binlog数据进行编译压缩。
53.在一实施例中，所述步骤s102包括：
54.采用lz4算法对所述binlog数据对应的二进制格式数据进行压缩，并在压缩完成后写入kafka同步机制中。
55.本实施例中，以二进制消息的方式写入kafka的同步程序。优选的，在写入的时候，使用lz4算法对二进制数据再次压缩，如此可使该格式下的binlog数据相比json格式下的binlog数据所占控件缩小60％以上。
56.本实施例采用的kafka同步机制可以起到保证binlog数据不会丢失的作用，通过将binlog数据存储到kafka的队列中，既能实现binlog解析程序和下游etl数据转换程序的解耦，又能保证即使下游发生崩溃，也能实现程序较快恢复，并从断点继续同步。另外，由于存储数据库的写入速度是受限的，在网络流量高的时候容易因写入压力过大而崩溃，因此kafka同步机制还能起到削峰的作用，从而提升了系统的稳定性。在具体实施例中，kafkakafka同步机制需要使用3副本集群的方式部署，如此可以在挂掉其中一个节点的情况下，依然保持正常工作。
57.在一具体实施例中，在采用lz4算法对所述binlog数据对应的二进制格式数据进行压缩时，包括以下步骤：
58.设置滑动窗口和扫描窗口，例如设置滑动窗口大小为6字节，扫描窗口为1字节；
59.对所述二进制格式数据进行扫描，并按照滑动窗口大小对所述二进制格式数据进行哈希运算，然后将哈希运算结果与预置哈希表对照，若预置哈希表中没有相应的哈希运算结果，则将该哈希运算结果存入至预置哈希表中；例如当滑动窗口大小为6字节时，对0-5位置做hash运算，hash表中无该值，所以存入hash表；
60.根据所述扫描窗口的大小继续下一次扫描，并计算下一次扫描中所述二进制格式数据的哈希值，同样与预置哈希表对照，并当预置哈希表中不存在相应哈希值时，将该哈希值存入至预置哈希表中；例如扫描窗口为1字节时，在下一次扫描过程中，计算1-6位置的hash值；
61.按照上述扫描过程类推，直至完成所述二进制格式数据的扫描，并确认所述预置哈希表中存在相应的哈希值，此时，对所述二进制格式数据进行压缩。进一步的，设置偏移量offset和重复长度，例如偏移量offset值置为9，重复长度为6，该值存入token值的低4位中；
62.匹配压缩项后开始尝试扩大匹配，例如当窗口扫描到10-16时，发现并没有匹配到，则将此哈希值存入预置哈希表；如果发现预置哈希表中有相应的哈希值，如果符合匹配条件(例如10-15符合1-6)则扩大匹配项，重复长度设为7，调整相应的token值。这样当滑动窗口扫描完所有的字符串之后，结束操作，完成压缩。
63.在一实施例中，如图3所示，所述步骤s103包括：步骤s301～s303。
64.s301、基于规则引擎算法对所述kafka同步机制设置规则；
65.s302、对所述规则绑定至少一个事件处理函数；
66.s303、利用所述事件处理函数从所述kafka同步机制中读取binlog数据，并同步至存储数据库中。
67.本实施例中，通过数据仓库技术(etl)从kafka同步机制中读取binlog数据，并对其进行解析和转换后，批量写入至存储数据库中。具体来说，本实施例基于规则引擎算法，可实现数据快速灵活的同步，并且用户能够根据具体业务需求灵活自定义各种规则，如此很好的满足了效能管理各种维度和数据指标的同步。所述的规则引擎算法基于正则匹配得到，例如可以对某个数据库中的某个数据表定义一个规则，同时对该规则绑定若干事件处理函数，而这些事件处理函数则会按顺序依次执行。在执行的过程中，规则引擎会直接对处理事件提供上下文，例如一个典型的上下文包括当前库、当前表、当前binlog事件、同步偏移量等信息。同时，规则引擎还提供缓存机制以加速同步，由于事件处理函数需要用到的很多数据可以直接从内存读取，而内存中不存在对应数据时则可以从数据库加载，这样大大提高了同步程序的性能和实时性。另外，本实施例所述的etl数据仓库技术可以同步的数据集包括：project(项目)、task(任务)、工时(manhour)、测试用例(testcase)等，并且具有较强的扩展性，可灵活根据业务需求扩展数据集。同样的，该程序可以使用go语言开发，无外部依赖，可实现便捷部署。
68.在一实施例中，所述步骤s104包括：
69.通过bi工具中的superset-db数据库对接存储所述存储数据库中的数据；
70.通过bi工具中的superset-api后端和superset-web前端对所述superset-db数据库中的数据进行效能管理。
71.本实施例中，所述的存储数据库(例如clickhouse数据库)用于存储和加速olap(online analytical processing的缩写，即联机分析处理)查询,本实施例基于clickhouse实现了高性能的效能管理，可以做到在1秒内对数百万条数据的聚合。进一步的，在clickhouse数据的基础上，可以搭配使用各种bi工具，由于clickhouse是通用olap数据库，因此对于不同种的bi系统，都可以做到很好的兼容，比如superset(一种运维数据可视化平台)、finebi、衡石等。在这里，采用superset与clickhouse数据库对接管理，具体的，采用superset-db数据库对接所述clickhouse数据库中的数据，superset-db是superset bi工具用到的mysql数据库，该部分可根据具体bi工具组件而变化。还通过superset-api后端和superset-web前端进行数据效能管理，superset-api是superset bi工具的后端，
superset-web是supersetbi工具的前端，二者均可根据具体bi工具组件而变化。
72.图4为本发明实施例提供的一种准实时效能管理装置400的示意性框图，该装置400包括：
73.第一读取单元401，用于从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；
74.第一写入单元402，用于采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；
75.第二写入单元403，用于利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；
76.对接管理单元404，用于通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。
77.本实施例中，在对数据(例如数据报表等)进行效能管理时，首先从mysql数据库中读取binlog数据，然后对其进行解析和压缩，并写入至kafka同步机制中，接着通过数据仓库技术读取kafka同步机制中的binlog数据，并进一步写入至存储数据库中，随后采用bi工具与存储数据库对接，以获取存储数据库中存储的数据，从而方便对存储数据库中的数据进行效能管理。
78.本实施例通过将mysql数据库中的binlog数据提取并写入至kafka同步机制中，然后结合存储数据库对数据进行存储和查询，从而实现了对项目管理中的数据进行高性能、准实时的效能分析。例如在具体应用场景中，本实施例所提供的准实时效能管理方法的数据延时低于10秒。
79.在一实施例中，如图5所示，所述第一读取单元401包括：
80.第二读取单元501，用于采用canal技术模拟mysql数据库主从同步的方式读取所述binlog数据；
81.事务同步单元502，用于解析并获取所述binlog数据的全局事务，以实现事务化同步；
82.格式压缩单元503，用于通过protobuf格式对解析后的binlog数据进行压缩。
83.在一实施例中，所述准实时效能管理装置400还包括：
84.模式设置单元，用于对mysql数据库开启binlog和全局事务模式，并将binlog设置为行模式。
85.本实施例采用canal技术，通过伪装成mysql-slave的方式从mysql数据库中读取binlog数据，并对所述binlog数据进行解析，然后通过protobuf格式压缩解析后的binlog数据。本实施例既能通过dump的方式同步现有数据，又能通过binlog的方式同步增量数据，其中增量数据的偏移量存储的是gtid，可实现事务化的同步，在一个事务结束后(即gtid发生变化)，数据才真正开始写入。此外，在同步前，mysql数据库必须开启binlog和gtid模式，并将binlog设置为行模式。在具体应用场景中，采用go语言开发，能够无需外部依赖，可实现便捷部署。
86.本实施例所述的canal是一种通过流的方式来将mysql数据库中的binlog数据流转到目标的技术，主要用途是基于mysql数据库增量日志解析，提供增量数据订阅和消费。binlog数据是mysql数据库二进制格式的日志文件。binlog是用来记录mysql内部对数据库
的改动(只记录对数据的修改操作)，主要用于数据库的主从复制以及增量恢复。
87.在一具体实施例中，所述通过canal技术模拟mysql数据库主从同步的方式，以将mysql数据库中的binlog数据流转至数据流转服务中，还包括：
88.通过canal集群实时获取mysql数据库中的binlog数据；
89.利用预先存储于canal集群中的表关联策略构建目标表；
90.将所述目标表写入至数据流转服务中。
91.其中，所述的表关联策略具体为：若mysql数据库中有两张数据表在同一事务中进行了修改，则将两个数据表中新增的binlog数据在canal集群中进行关联，并组成目标表写入数据流转服务中；若mysql数据库中有一张数据表中新增binlog数据，则通过数据流转服务获取与该binlog数据相关联的字段，并组成目标表写入数据流转服务。此外，所述的canal集群采用key-value方式，并以关联字段的数据作为key，与对应的value值进行匹配。
92.此外，在解析并获取所述binlog数据的全局事务时，利用反射技术对其进行标记，标记内容可以为：组织/团队、用户等，标记数据记录可以在后续步骤中准确识别出某些操作是由哪个团队的哪个用户所产生的。在事务执行之后获取到mysql数据库中的gtid(global transaction id:全局事务id)。由于在go语言的mysql driver中是没有办法直接获取到gtid的，所以对mysql driver的代码进行调整，使用反射技术，从mysql数据库的okpackage中获取得到gtid。在事务中通过反射获取gtid，能够减少开发人员对底层的了解，只需要关心业务层即可。
93.还有，在通过protobuf格式对解析后的binlog数据进行压缩时，具体包括：
94.根据binlog数据的结构编写.proto文件；
95.使用protobuf工具生产.pb.cc文件和.pb.hh文件；该.pb.cc和.pb.hh文件定义了消息的类，消息字段就是类成员，包含了设置和获取各个成员的方法；
96.结合所述的.proto文件、.pb.cc和.pb.hh文件对所述binlog数据进行编译压缩。
97.在一实施例中，所述第一写入单元402包括：
98.二进制压缩单元，用于采用lz4算法对所述binlog数据对应的二进制格式数据进行压缩，并在压缩完成后写入kafka同步机制中。
99.本实施例中，以二进制消息的方式写入kafka的同步程序。优选的，在写入的时候，使用lz4算法对二进制数据再次压缩，如此可使该格式下的binlog数据相比json格式下的binlog数据所占控件缩小60％以上。
100.本实施例采用的kafka同步机制可以起到保证binlog数据不会丢失的作用，通过将binlog数据存储到kafka的队列中，既能实现binlog解析程序和下游etl数据转换程序的解耦，又能保证即使下游发生崩溃，也能实现程序较快恢复，并从断点继续同步。另外，由于存储数据库的写入速度是受限的，在网络流量高的时候容易因写入压力过大而崩溃，因此kafka同步机制还能起到削峰的作用，从而提升了系统的稳定性。在具体实施例中，kafkakafka同步机制需要使用3副本集群的方式部署，如此可以在挂掉其中一个节点的情况下，依然保持正常工作。
101.在一实施例中，所述二进制压缩单元包括：
102.窗口设置单元，用于设置滑动窗口和扫描窗口；
103.例如设置滑动窗口大小为6字节，扫描窗口为1字节；
104.哈希运算单元，用于对所述二进制格式数据进行扫描，并按照滑动窗口大小对所述二进制格式数据进行哈希运算，然后将哈希运算结果与预置哈希表对照，若预置哈希表中没有相应的哈希运算结果，则将该哈希运算结果存入至预置哈希表中；
105.例如当滑动窗口大小为6字节时，对0-5位置做hash运算，hash表中无该值，所以存入hash表；
106.对照存入单元，用于根据所述扫描窗口的大小继续下一次扫描，并计算下一次扫描中所述二进制格式数据的哈希值，同样与预置哈希表对照，并当预置哈希表中不存在相应哈希值时，将该哈希值存入至预置哈希表中；
107.例如扫描窗口为1字节时，在下一次扫描过程中，计算1-6位置的hash值；
108.压缩确认单元，用于按照上述扫描过程类推，直至完成所述二进制格式数据的扫描，并确认所述预置哈希表中存在相应的哈希值，此时，对所述二进制格式数据进行压缩。
109.进一步的，设置偏移量offset和重复长度，例如偏移量offset值置为9，重复长度为6，该值存入token值的低4位中；
110.匹配压缩项后开始尝试扩大匹配，例如当窗口扫描到10-16时，发现并没有匹配到，则将此哈希值存入预置哈希表；如果发现预置哈希表中有相应的哈希值，如果符合匹配条件(例如10-15符合1-6)则扩大匹配项，重复长度设为7，调整相应的token值。这样当滑动窗口扫描完所有的字符串之后，结束操作，完成压缩。
111.在一实施例中，如图6所示，所述第二写入单元403包括：
112.规则设置单元601，用于基于规则引擎算法对所述kafka同步机制设置规则；
113.函数绑定单元602，用于对所述规则绑定至少一个事件处理函数；
114.数据同步单元603，用于利用所述事件处理函数从所述kafka同步机制中读取binlog数据，并同步至存储数据库中。
115.本实施例中，通过数据仓库技术(etl)从kafka同步机制中读取binlog数据，并对其进行解析和转换后，批量写入至存储数据库中。具体来说，本实施例基于规则引擎算法，可实现数据快速灵活的同步，并且用户能够根据具体业务需求灵活自定义各种规则，如此很好的满足了效能管理各种维度和数据指标的同步。所述的规则引擎算法基于正则匹配得到，例如可以对某个数据库中的某个数据表定义一个规则，同时对该规则绑定若干事件处理函数，而这些事件处理函数则会按顺序依次执行。在执行的过程中，规则引擎会直接对处理事件提供上下文，例如一个典型的上下文包括当前库、当前表、当前binlog事件、同步偏移量等信息。同时，规则引擎还提供缓存机制以加速同步，由于事件处理函数需要用到的很多数据可以直接从内存读取，而内存中不存在对应数据时则可以从数据库加载，这样大大提高了同步程序的性能和实时性。另外，本实施例所述的etl数据仓库技术可以同步的数据集包括：project(项目)、task(任务)、工时(manhour)、测试用例(testcase)等，并且具有较强的扩展性，可灵活根据业务需求扩展数据集。同样的，该程序可以使用go语言开发，无外部依赖，可实现便捷部署。
116.在一实施例中，所述对接管理单元404包括：
117.对接存储单元，用于通过bi工具中的superset-db数据库对接存储所述存储数据库中的数据；
118.效能管理单元，用于通过bi工具中的superset-api后端和superset-web前端对所
述superset-db数据库中的数据进行效能管理。
119.本实施例中，所述的存储数据库用于存储和加速olap(online analytical processing的缩写，即联机分析处理)查询,本实施例基于clickhouse实现了高性能的效能管理，可以做到在1秒内对数百万条数据的聚合。进一步的，在clickhouse数据的基础上，可以搭配使用各种bi工具，由于clickhouse是通用olap数据库，因此对于不同种的bi系统，都可以做到很好的兼容，比如superset(一种运维数据可视化平台)、finebi、衡石等。在这里，采用superset与存储数据库对接管理，具体的，采用superset-db数据库对接所述存储数据库中的数据，superset-db是superset bi工具用到的mysql数据库，该部分可根据具体bi工具组件而变化。还通过superset-api后端和superset-web前端进行数据效能管理，superset-api是superset bi工具的后端，superset-web是superset bi工具的前端，二者均可根据具体bi工具组件而变化。
120.本发明实施例还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
121.所述计算机可读存储介质上存储的计算机程序被执行时实现如下方法：
122.从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；
123.采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；
124.利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；
125.通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。
126.本发明实施例还提供了一种计算机设备，可以包括存储器和处理器，存储器中存有计算机程序，处理器调用存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然计算机设备还可以包括各种网络接口，电源等组件。
127.所述计算机设备的处理器调用存储器中的计算机程序时实现如下方法：
128.从mysql数据库中读取binlog数据，并对所述binlog数据进行解析和压缩；
129.采用二进制消息的方式将压缩后的所述binlog数据写入kafka同步机制中；
130.利用数据仓库技术从所述kafka同步机制中读取所述binlog数据，并写入至存储数据库中；
131.通过bi工具与所述存储数据库对接，以对所述存储数据库中的数据进行效能管理。
132.说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以对本技术进行若干改进和修饰，这些改进和修饰也落入本技术权利要求的保护范围内。
133.还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将
一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。