CN112579585A - 一种数据处理系统、方法及装置 - Google Patents

一种数据处理系统、方法及装置 Download PDF

Info

Publication number
CN112579585A
CN112579585A CN202011531071.6A CN202011531071A CN112579585A CN 112579585 A CN112579585 A CN 112579585A CN 202011531071 A CN202011531071 A CN 202011531071A CN 112579585 A CN112579585 A CN 112579585A
Authority
CN
China
Prior art keywords
data
messages
message
data processing
cluster
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011531071.6A
Other languages
English (en)
Inventor
邹小军
戚铭铭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
JD Digital Technology Holdings Co Ltd
Original Assignee
JD Digital Technology Holdings Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by JD Digital Technology Holdings Co Ltd filed Critical JD Digital Technology Holdings Co Ltd
Priority to CN202011531071.6A priority Critical patent/CN112579585A/zh
Publication of CN112579585A publication Critical patent/CN112579585A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24578—Query processing with adaptation to user needs using ranking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/285—Clustering or classification
    • G06F16/287—Visualization; Browsing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Computational Linguistics (AREA)
  • Accounting & Taxation (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供一种数据处理系统、方法及装置，应用于数据处理技术领域。系统包括：贴源层、消息集群和模型层。其中，贴源层，用于临时存储与业务相关的源数据；消息集群，用于存储和处理多条消息，消息为对源数据处理得到的；模型层，用于根据多条消息训练数据处理模型，以及利用数据处理模型输出用于反映业务对应的可视化界面数据。这样，当数据实时变化时，将数据输入训练好的数据处理模型，得到数据处理和分析结果，实现海量数据的实时分析。

Description

一种数据处理系统、方法及装置
技术领域
本申请涉及数据处理技术领域，尤其涉及一种数据处理系统、方法及装置。
背景技术
随着我国经济不断增长，居民的生活也发生了翻天覆地的变化，随着货币收入的增加，个人经济与股份制经济都得到了快速的增长，“理财”也因此走进了广大居民的生活。民众为了使自己的钱财能够更好地保值，因此寻找新的投资项目，各大资产管理公司的理财投资业务蓬勃发展。
目前，基于投资项目的数据很多，且数据类型非常丰富。人们需要自行下载和存储投资项目相关的数据，并人为进行分析。
但基于投资项目的多类型海量数据的下载和存储较为不便利，进行数据分析的效率很低。
发明内容
本申请实施例提供一种数据处理系统、方法及装置，实现多类型海量数据的存储和实时分析。
第一方面，本申请实施例提供一种数据处理系统，所述数据处理系统包括贴源层、消息集群和模型层：
其中，所述贴源层，用于临时存储与业务相关的源数据；
所述消息集群，用于存储和处理多条消息，所述消息为对所述源数据处理得到的；
所述模型层，用于根据所述多条消息训练数据处理模型，以及利用所述数据处理模型输出用于反映所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述消息集群包括生产者、集群服务器、消费者和分布式应用程序协调服务；
所述生产者，用于对所述源数据进行数据清洗和算子处理得到所述多条消息；
所述集群服务器，用于在所述集群服务器的分片中存储所述多条消息；
所述消费者，用于消费所述集群服务器中存储的所述消息，以及将消费所述消息得到的数据输入至所述模型层；
所述ZooKeeper，用于协调管理所述消费者和所述集群服务器。
在一种可能的实施方式中，所述消费者，具体用于：
指定所述多条消息中的目标消息的偏移值和最大尺寸；
根据所述偏移值确定所述目标消息所在的目标分片；
根据所述最大尺寸确定所述目标消息在目标分片的位置；
根据所述目标消息的相对位置，读取所述目标消息对应的数据并输入至所述模型层。
在一种可能的实施方式中，所述消息集群中，将更新频率大于或等于阈值的消息设置在缓存数据库中，将更新频率小于所述阈值的消息设置在关系型数据库管理数据库中。
在一种可能的实施方式中，所述模型层，具体用于在所述消息集群中获取目标消息相关的数据，以及根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述模型层，具体用于，将所述目标消息相关的数据输入所述数据处理模型，得到用于更新所述业务的可视化界面数据。
在一种可能的实施方式中，所述贴源层纵向分为实时数据更新、T+1数据更新以及不定时数据更新。
在一种可能的实施方式中，所述消息集群包括Kafka集群；所述数据处理模型包括：多元线性回归模型和/或多因子模型。
第二方面，本申请实施例提供一种数据处理方法，应用于应用于如上第一方面以及第一方面的可能的实施方式中的所述的系统，所述方法包括：
获取与业务相关的源数据；
处理所述源数据，得到多条消息；
利用所述多条消息输出所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述处理所述源数据，得到多条消息，包括：
对所述源数据进行数据清洗和算子处理得到所述多条消息。
在一种可能的实施方式中，利用所述多条消息输出所述业务对应的可视化界面数据，包括：
在所述消息集群中获取目标消息相关的数据，以及根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据，包括：
将所述目标消息相关的数据输入所述数据处理模型，得到用于更新所述业务的可视化界面数据。
第三方面，本申请实施例提供一种数据处理装置，包括：
获取模块，用于获取与业务相关的源数据；
处理模块，用于处理所述源数据，得到多条消息；
输出模块，用于利用所述多条消息输出所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述处理处理模块具体用于对所述源数据进行数据清洗和算子处理得到所述多条消息。
在一种可能的实施方式中，所述输出模块具体用于在所述消息集群中获取目标消息相关的数据，以及根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述输出模块具体用于将所述目标消息相关的数据输入所述数据处理模型，得到用于更新所述业务的可视化界面数据。
第四方面，本申请实施例提供一种电子设备，包括：存储器，用于存储程序指令；处理器，用于调用并执行存储器中的程序指令，执行第二方面或第二方面任意可能的实现方式中的任一方法。
第五方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有指令，当指令被执行时，以实现第二方面或第二方面任意可能的实现方式中的任一方法。
本申请实施例提供一种数据处理系统、方法及装置，将贴源层中存储的源数据经处理后保存至消息集群，通过消费消息集群中的消息来获取数据用于模型层训练数据处理模型，得到训练结果。这样，当数据实时变化时，将数据输入训练好的数据处理模型，得到数据处理和分析结果，实现海量数据的实时分析。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
图1为本申请实施例提供的一种数据处理系统的系统架构图；
图2为本申请实施例提供的一种消息集群的结构示意图；
图3为本申请实施例提供的一种topic的示意图；
图4为本申请实施例提供的一种partition的示意图；
图5为本申请实施例提供的消费者消费消息的示意图；
图6为本申请实施例提供的一种远程字典服务redis的结构示意图；
图7为本申请实施例提供的一种数据处理方法的流程示意图；
图8为本申请实施例提供的一种数据处理装置的结构示意图；
图9为本申请实施例提供的一种电子设备的结构示意图。
通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
在进行项目投资前期，对投资项目进行数据分析是一个重要步骤。但基于投资项目的数据很多，且数据类型非常丰富。人们需要自行下载和存储投资项目相关的数据，并人为进行分析。
但基于投资项目的多类型海量数据的下载和存储较为不便利，进行数据分析的效率很低。
基于上述问题，本申请实施例提供一种数据处理系统，将贴源层中存储的源数据经处理后保存至消息集群，通过消费消息集群中的消息来获取数据用于模型层训练数据处理模型，得到训练结果。这样，当数据实时变化时，将数据输入训练好的数据处理模型，得到数据处理和分析结果，实现海量数据的实时分析。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图1为本申请实施例提供的一种数据处理系统，如图1所示，该数据处理系统100包括贴源层101、消息集群102和模型层103。
其中，贴源层101，用于临时存储与业务相关的源数据。
本申请实施例中，贴源层101为操作型数据存储(operational data store，ODS)数据库，用于存放源数据，该源数据可以是未经处理的数据。其中，数据处理系统支持丰富的数据源，数据源的格式可以包括：hive、jdbc、parquet、csv、json、orc、文本(text)和/或表格(excel)等。
可能的理解方式中，贴源层101中临时存储的与业务相关的源数据可以包括某行业相关的数据，或某专题业务相关的数据等。例如，源数据可以包括：A股数据、A股预测数据、B股数据、股转系统数据、债券数据、基金数据、私募基金数据、资管产品数据、期货数据、银行理财数据和宏观经济数据等。
可能的理解方式中，在移动互联网时代，由于上网用户剧增和海量的网络设备，导致海量数据的产生，该海量数据可以包括：行为日志数据、业务数据或者网络爬虫数据等，企业需要对海量数据进行存储和分析。但传统的关系型数据库由于本身技术限制，无法承担海量数据的存储和分析，因此本申请实施例提供的数据处理系统中使用贴源层101来用于临时存储与业务相关的源数据。
可以理解为，数据处理系统具有非常复杂的数据来源，且这些数据可以存放在不同的地理位置、不同的数据库或不同的应用之中，直接从该数据处理系统抽取数据来进行数据计算和分析效率低。因此，贴源层101用于临时存放从系统直接抽取出来的数据，这些数据从数据结构和数据之间的逻辑关系上都与系统中的数据基本保持一致，因此，将与业务相关的源数据临时存储在贴源层101中后，可以直接基于贴源层数据进行分析，可以提高计算和分析的效率。
可能的实现方式中，贴源层纵向分为实时数据更新、T+1数据更新以及不定时数据更新。其中，T+1数据更新可以理解为将以天为粒度的所有数据进行更新。例如，今天之前是一个T单位的数据，新加一天为(T+1)单位的数据。
消息集群102，用于存储和处理多条消息。
可能的理解方式中，消息集群102中的消息可以理解为数据，消息可以由字节数组组成。
本申请实施例中，消息集群102可以Kafka集群。示例性的，图2为Kafka集群的结构示意图。如图2所示，Kafka集群包括：生产者(Producer)201、集群服务器(Broker)202和消费者(Consumer)203和分布式应用程序协调服务Zookeeper 204。
其中，Producer 201用于生产消息，消息可以存储至Broker 202中，Consumer 203用于消费Broker 202中的消息来获取数据。
可以理解为，本申请实施例中，Producer 201生产的消息可以是将贴源层101中的源数据进行处理后得到的数据。消费者(Consumer)通过消费消息集群102中的消息获取数据，输入至模型层103。这样，可以将消息的生产和消费，与消息的存储进行解耦，并且Producer生产了消息，可以存放在Broker中，然后Producer继续生产消息，Consumer消费与否并不影响Producer的生产，这样Producer和Consumer没有直接关联，可以根据系统的实际运行情况来增减Producer和Consumer。
可能的实现方式中，将贴源层101中存储的源数据进行数据清洗后加工整合映射到指定的数据类型，得到类型数据。其中，指定的数据类型可以包括：NullType、IntegerType、DecimalType、DoubleType、TimeStampType、BooleanType、FloatType、StringType和/或DateType等类型。Producer 201生产的消息为将类型数据通过算子处理之后得到的数据，Producer 201生产消息后发送至Broker202。其中，算子包括join、collect、agg、map、union、first、filer、groupBy、orderBy、sum、count和/或where等。
可能的实现方式中，使用配置化和插拔开关支持的引擎，或者分布式任务调度、监听Binlog生成消息或消息队列消费等智能方式从贴源层101中抽取数据，Producer 201生产的消息为使用前述方法从贴源层101抽取的数据，Producer 201生产消息后发送至Broker202。
示例性的，对贴源层101中存储的源数据进行数据清洗可以是将重复和多余的数据筛选清除，和/或，将缺失的数据补充完整，和/或，将错误的数据纠正或者删除，最后得到可以进一步加工和使用的数据。
下面就生产者(Producer)201、服务器(Broker)202和消费者(Consumer)203和Zookeeper 204进行详细的介绍。
Producer 201的数量可以是一个或多个，具体可以由用户来设置。例如，如图2所示，Producer(生产者)201的数量为2个，分别为Producer(生产者)2011和Producer(生产者)2012。
在Kafka文件存储中，同一个topic(分组)下有多个不同partition(队列)，每个partition为一个目录。其中，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partition数量减1。
以图2中Broker(集群服务器)2021中topic(分组)1为例，topic1(分组)下有三个不同的partition，分别为partition(队列)0、partition(队列)1和partition(队列)2，图3为topic(分组)1的结构示意图，如图3所示，Partition是队列结构，每个Partition中的消息都是有序的，Producer生产的消息被不断追加到Partition的尾部，其中的每一个消息都被赋予了一个唯一的偏移(offset)值。
以图3中的partition(队列)0为例，如图3所示，在生产者未生产消息之前，partition(队列)0中最后一个消息的偏移(offset)值为11。在生产者生产消息之后，生产的消息是按照顺序加到partition(队列)0的尾部，因此生产者最新生产的消息的偏移(offset)值为12。消费者可以根据消息对应的offset值确定要消费的消息。
每个partition(目录)相当于一个巨型文件，如图4所示，若partition1的内存为100GB，可以被平均分配到多个大小相等的segment(段)数据文件中，其中，每个segmentfile的大小可以为500MB。但每个segment file消息数量不一定相等，这样通过将消息平均分配到segment file中，可以快速删除无用文件，有效提高磁盘利用率。
Producer发信息到某个topic，消息会被随机均匀或者根据指定的回调函数的分布到多个partition上，Broker收到消息后在对应的partition的最后一个segment上添加该消息，Producer会将消息暂时缓存(buffer)起来，这样使得磁盘检索的开支较小，同时可以减少磁盘写入的次数。当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被冲洗(flush)到磁盘，只有flush到磁盘上的消息consumer才能消费。当segment上的消息条数达到配置值后不再往该segment上添加消息，broker会创建新的segment。
可能的实现方式中，每条消息是由消息的长度与消息的内容组成的，并且每条消息都有一个offset来唯一的标记。Offset的值为8个字节的数据，该Offset代表该条消息在当前partition中所处的起始位置。Segment文件的命名为最小的offset+.kafka，比如“00000000000.kafka“，通过segment文件名就可以获取到快速定位到需要开始的消费的segment。
为了提升基于网络性能，Kafka支持将消息缓存(buffer)起来，当消息的数量达到一定的阈值时，批量发送给Borker。
每个partition在内存中对应一个index，记录每个segment中的第一条消息偏移。segment file由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件。每个segment中存储很多条消息，消息的id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。
segment文件命名规则为partition全局的第一个segment从0开始，后续每个segment文件名为上一个全局partition的最大offset(可以理解为，偏移消息数)。Offset的数值最大为64位long大小，19位数字字符长度，如果没有Offset用0填充。
Broker 202为存储消息的集群服务器，如图2所示，Kafka集群中可以有多个Broker，例如Broker2021、Broker2022和Broker2023，Broker的数量可以根据用户的需求来进行设置。其中，Broker的数量越多，Kafka集群的吞吐率越高。
可能的实现方式中，集群服务器可以为linux Server CentsOS7。
Kafka集群允许用户为每个topic设置副本数量，副本数量决定了对应用于存放Producer生产的消息的Broker的数量。如果设置的副本数量设置为3，那么一份消息就会被存放在3台不同的Broker上，那么就允许有2个Broker存储失败。
可能的实现方式中，为每个topic设置副本数量至少为2，这样就可以保证增减Broker或者重启Broker时不会影响到消息的消费。如果对数据持久化有更高的要求，可以把副本数量设置为大于或等于3的整数。
Consumer 203用于以消费者组(Consumer group)的方式工作，Consumer group由一个或者多个消费者组成，共同消费一个topic。每个partition在同一时间只能由Consumer group中的一个Consumer读取，但是多个Consumer group可以同时消费这个partition。
示例性的，如图2所示，Consumer 203包括Consumer group1和Consumer group2。其中，Consumer group1包括Consumer 2031、Consumer 2032和Consumer 2033，Consumergroup2包括Consumer 2034和Consumer 2035。
以topic1为例，如图5所示，若topic1包含4个partition，第一个partiton序号从0开始，序号最大值为partition数量减1，则topic1包含的4个partition分别为partition0、partition1、partition2和partition3。Consumer group1包括Consumer 2031、Consumer2032和Consumer 2033，Consumer 2031消费topic1中的partition1和partition2，Consumer 2031单独消费partition0，Consumer 2033单独消费partition3。则Consumer2031可以叫做partition0的拥有者，Consumer2033也可以叫做partition3的拥有者。
Zookeeper 204用于管理Broker202，所有的Kafka Broker节点分别在Zookeeper上注册一个临时节点，但只有一个Broker会注册成功，成功在Zookeeper上注册临时节点的Broker称为Broker Controller，其他的未注册成功的broker称为Broker follower。Broker Controller可以监听其他的Broker follower的所有信息。
示例性的，如图2所示，在该Kafka集群中有三个Broker，分别为Broker2021、Broker 2022和Broker 2023。Broker 2021、Broker 2022和Broker 2023分别在Zookeeper上注册一个临时节点，若Broker 2021注册成功，则Broker2021称为Broker Controller，其他的未注册成功的Broker 2022和Broker 2023称为Broker follower。Broker 2021可以监听Broker 2022和Broker 2023的所有信息。
模型层103，用于根据多条消息训练数据处理模型，以及利用数据处理模型输出用于反映业务对应的可视化界面数据。
可能的实现方式中，在消息集群中获取目标消息相关的数据，将目标消息相关的数据输入数据处理模型，得到用于更新业务的可视化界面数据，并更新业务对应的可视化界面数据。
其中，数据处理模型可以为多元线性回归模型或多因子模型等。
可能的理解方式中，模型层103为消息集群102的消费者(Consumer)，通过消费消息获取数据用于训练模型。当数据处理模型训练完成后，可以通过消费消息获取数据，并将数据输入该数据处理模型得到处理结果。根据数据处理结果，对数据按时间进行最大值、最小值、均值和/或标准差等统计分析，得到用于反映业务对应的可视化界面数据。
可能的实现方式中，Consumer消费者消费消息时，需要指定offset和最大的chunk尺寸。根据offset可以找到此消息所在segment文件，然后根据segment的最小offset取差值，得到该消息在file中的相对位置，根据消息的位置，可以直接读取即可输出该消息。
可能的实现方式中，可以批量获取多条消息。其中，批量获取的消息量的大小可以通过配置文件来设定。
可能的实现方式中，系统可以使用sendfile函数来消费消息。例如，系统调用sendfile函数通过直接存储器访问(Direct Memory Access，DMA)把硬盘数据拷贝到kernel buffer，然后数据被kernel直接拷贝到另外一个与socket相关的kernel buffer。这里没有用户态和核心态之间的切换，在内核中直接完成了从一个buffer到另一个buffer的拷贝；DMA把数据从kernel buffer直接拷贝给协议栈，没有切换，也不需要数据从用户态和核心态，因为数据就在kernel里。这样，可以将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次复制和交换。sendfile函数在两个文件描述符之间传递数据(完全在内核中操作)，从而避免了内核缓冲区和用户缓冲区之间的数据拷贝，效率很高，被称为零拷贝。
本申请实施例中，将贴源层中存储的源数据经处理后保存至消息集群，通过消费消息集群中的消息来获取数据用于模型层训练数据处理模型，得到训练结果。这样，当数据实时变化时，将数据输入训练好的数据处理模型，得到数据处理和分析结果，实现海量数据的实时分析。
在图1对应的实施例的基础上，一种可能的实现方式中，将更新频率大于或等于阈值的消息设置在缓存数据库中，将更新频率小于阈值的消息设置在关系型数据库管理数据库中。
本申请实施例中，缓存数据库可以为远程字典服务(remote dictionary server，Redis)，关系型数据库可以为MySQL。
本申请实施例中，更新频率的阈值可以根据用户需求来设定。
可能的理解方式中，更新频率大于或等于阈值的消息可以为实时性要求高和实时动态变化的数据，例如股市资金流入流出top20数据等。因此该数据需要实时进行消费，并将消费后得到的数据输入模型层进行处理。但Kafka集群中，消息的生产和消费是独立的，当Producer生产了消息之后，Consumer不一定能立即进行消费，这样可能会出现对实时性要求高和实时动态变化的数据的分析不及时，导致得到的分析结果不准确的问题。
因此，本申请实施例中，将更新频率大于或等于阈值的消息设置在远程字典服务Redis中，如图6所示，Redis由生产者(Producer)601、通道602和消费者(Consumer)603组成。其中，Producer601用于生产消息发送至通道602，通道602在接收消息之后将消息推送至消费者603，消费者603只能接收提前订阅的通道所发送的消息。由于Redis是使用内存来存储数据，Producer601生产消息后立即被Consumer603消费，这样，可以实现对实时性要求高和实时动态变化的数据的及时处理。
可能的理解方式中，更新频率小于阈值的消息可以为实时性要求不高、出现频率不太高且数据量较小的数据。此类数据因数据量小，且实时性要求不高，因此可以将该类数据设置在MySQL中，当数据更新时，可以直接从MySQL中查询数据，输入模型层中进行分析和处理。其中，MySQL可以支持丰富多元的列类型，包含整数、FLOAT、DOUBLE、CHAR、VARCHAR、TEXT、BLOB、DATE、TIME、DATETIME、TIMESTAMP、YEAR和/或ENUM等类型。
本申请实施例中，可以将更新频率大于或等于阈值的消息设置在缓存数据库中，将更新频率小于阈值的消息设置在关系型数据库中，这样可以根据数据的类型进行处理和分析。
图7是本申请实施例提供的一种数据处理方法的流程示意图，该方法适用于上述图1对应的数据处理系统。如图7所示，该方法可以包括以下步骤：
S701：获取与业务相关的源数据。
本申请实施例中，与业务相关的源数据可以包括某行业相关的数据，或某专题业务相关的数据等。例如，源数据可以包括：A股数据、A股预测数据、B股数据、股转系统数据、债券数据、基金数据、私募基金数据、资管产品数据、期货数据、银行理财数据和宏观经济数据等。
S702：处理源数据，得到多条消息。
可能的实现方式中，对源数据进行数据清洗和算子处理得到多条消息。
示例性的，对源数据进行数据清洗可以是将重复和多余的数据筛选清除，和/或，将缺失的数据补充完整，和/或，将错误的数据纠正或者删除，最后得到可以进一步加工和使用的数据。
将对源数据进行数据清洗后的数据加工整合映射到指定的数据类型，得到类型数据。其中，指定的数据类型可以包括：NullType、IntegerType、DecimalType、DoubleType、TimeStampType、BooleanType、FloatType、StringType和/或DateType等类型。将类型数据通过算子处理之后得到多条消息。其中，算子包括join、collect、agg、map、union、first、filer、groupBy、orderBy、sum、count和/或where等。
S703：利用多条消息输出业务对应的可视化界面数据。
可能的实现方式中，在消息集群中获取目标消息相关的数据，将目标消息相关的数据输入数据处理模型，得到用于更新业务的可视化界面数据。根据目标消息相关的数据，更新业务对应的可视化界面数据。
本申请实施例中，通过处理与业务相关的源数据得到多条消息，利用多条消息输出业务对应的可视化界面数据，实现对数据的分析和处理。
根据本公开实施例的另一个方面，本公开实施例还提供了一种数据处理装置，如图8所示，所述数据处理装置包括：获取模块801、处理模块802和输出模块803。
获取模块801，用于获取与业务相关的源数据；
处理模块802，用于处理源数据，得到多条消息；
输出模块803，用于利用多条消息输出所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述处理处理模块具体用于对所述源数据进行数据清洗和算子处理得到所述多条消息。
在一种可能的实施方式中，所述输出模块具体用于在所述消息集群中获取目标消息相关的数据，以及根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据。
在一种可能的实施方式中，所述输出模块具体用于将所述目标消息相关的数据输入所述数据处理模型，得到用于更新所述业务的可视化界面数据。
本申请实施例提供的装置，可用于执行图7所示实施例中的方法，其实现原理和技术效果类似，在此不再赘述。
根据本公开实施例的另一个方面，本公开实施例还提供了一种电子设备，图9为本申请实施例提供的电子设备的硬件结构示意图。如图9所示，本实施例提供的建表语句生成设备90包括：至少一个处理器901和存储器902。该建表语句生成设备90还包括通信部件903。其中，处理器901、存储器902以及通信部件903通过总线904连接。
在具体实现过程中，至少一个处理器901执行所述存储器802存储的计算机执行指令，使得至少一个处理器901执行如上的建表语句生成方法。
处理器901的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。
在上述的图9所示的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器。
总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上的建表语句生成方法。
上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。
一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。
读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本公开的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本公开实施例方案的目的。
另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
还应理解，在本公开各实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。
以上，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以权利要求的保护范围为准。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本公开实施例方案的目的。
另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
还应理解，在本公开各实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。
以上，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以权利要求的保护范围为准。

Claims (15)

1.一种数据管理系统，其特征在于，所述数据处理系统包括贴源层、消息集群和模型层：
其中，所述贴源层，用于临时存储与业务相关的源数据；
所述消息集群，用于存储和处理多条消息，所述消息为对所述源数据处理得到的；
所述模型层，用于根据所述多条消息训练数据处理模型，以及利用所述数据处理模型输出用于反映所述业务对应的可视化界面数据。
2.根据权利要求1所述的系统，其特征在于，所述消息集群包括生产者、集群服务器、消费者和分布式应用程序协调服务；
所述生产者，用于对所述源数据进行数据清洗和算子处理得到所述多条消息；
所述集群服务器，用于在所述集群服务器的分片中存储所述多条消息；
所述消费者，用于消费所述集群服务器中存储的所述消息，以及将消费所述消息得到的数据输入至所述模型层；
所述分布式应用程序协调服务，用于协调管理所述消费者和所述集群服务器。
3.根据权利要求2所述的系统，其特征在于，所述消费者，具体用于：
指定所述多条消息中的目标消息的偏移值和最大尺寸；
根据所述偏移值确定所述目标消息所在的目标分片；
根据所述最大尺寸确定所述目标消息在目标分片的位置；
根据所述目标消息的相对位置，读取所述目标消息对应的数据并输入至所述模型层。
4.根据权利要求1所述的系统，其特征在于，所述消息集群中，将更新频率大于或等于阈值的消息设置在缓存数据库中，将更新频率小于所述阈值的消息设置在关系型数据库管理数据库中。
5.根据权利要求1-4任一项所述的系统，其特征在于，所述模型层，具体用于在所述消息集群中获取目标消息相关的数据，以及根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据。
6.根据权利要求5所述的系统，其特征在于，所述模型层，具体用于，将所述目标消息相关的数据输入所述数据处理模型，得到用于更新所述业务的可视化界面数据。
7.根据权利要求1-4任一项所述的系统，其特征在于，所述贴源层纵向分为实时数据更新、T+1数据更新以及不定时数据更新。
8.根据权利要求1所述的系统，其特征在于，所述消息集群包括Kafka集群；所述数据处理模型包括：多元线性回归模型和/或多因子模型。
9.一种数据处理方法，其特征在于，应用于如权利要求1-8任一项所述的系统，所述方法包括：
获取与业务相关的源数据；
处理所述源数据，得到多条消息；
利用所述多条消息输出所述业务对应的可视化界面数据。
10.根据权利要求9所述的方法，其特征在于，所述处理所述源数据，得到多条消息，包括：
对所述源数据进行数据清洗和算子处理得到所述多条消息。
11.根据权利要求9或10所述的方法，其特征在于，利用所述多条消息输出所述业务对应的可视化界面数据，包括：
在所述消息集群中获取目标消息相关的数据，以及根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据。
12.根据权利要求11所述的方法，其特征在于，所述根据所述目标消息相关的数据，更新所述业务对应的可视化界面数据，包括：
将所述目标消息相关的数据输入所述数据处理模型，得到用于更新所述业务的可视化界面数据。
13.一种数据处理装置，其特征在于，包括：
获取模块，用于获取与业务相关的源数据；
处理模块，用于处理所述源数据，得到多条消息；
输出模块，用于利用所述多条消息输出所述业务对应的可视化界面数据。
14.一种电子设备，其特征在于，包括：
存储器，用于存储程序指令；
处理器，用于调用并执行所述存储器中的程序指令，执行如权利要求1-12中任一项所述的方法。
15.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时，实现如权利要求1-12任一项所述的方法。
CN202011531071.6A 2020-12-22 2020-12-22 一种数据处理系统、方法及装置 Pending CN112579585A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011531071.6A CN112579585A (zh) 2020-12-22 2020-12-22 一种数据处理系统、方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011531071.6A CN112579585A (zh) 2020-12-22 2020-12-22 一种数据处理系统、方法及装置

Publications (1)

Publication Number Publication Date
CN112579585A true CN112579585A (zh) 2021-03-30

Family

ID=75138852

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011531071.6A Pending CN112579585A (zh) 2020-12-22 2020-12-22 一种数据处理系统、方法及装置

Country Status (1)

Country Link
CN (1) CN112579585A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116303652A (zh) * 2023-05-17 2023-06-23 北京微吼时代科技有限公司 一种基于数据库binlog的事件分发方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107968840A (zh) * 2017-12-15 2018-04-27 华北电力大学（保定） 一种大规模电力设备监测报警数据实时处理方法及系统
CN110188149A (zh) * 2019-06-04 2019-08-30 宁波银行股份有限公司 一种数据仓库系统
CN111563102A (zh) * 2020-04-10 2020-08-21 中国联合网络通信集团有限公司 缓存更新方法、服务器、系统及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107968840A (zh) * 2017-12-15 2018-04-27 华北电力大学（保定） 一种大规模电力设备监测报警数据实时处理方法及系统
CN110188149A (zh) * 2019-06-04 2019-08-30 宁波银行股份有限公司 一种数据仓库系统
CN111563102A (zh) * 2020-04-10 2020-08-21 中国联合网络通信集团有限公司 缓存更新方法、服务器、系统及存储介质

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
无: "一文看懂kafka机制", pages 1 - 11, Retrieved from the Internet <URL:https://developer.aliyun.com/article/608566> *
李小庆等: "构建面向大数据的银行数据挖掘平台", 金融科技时代, pages 16 - 21 *
程旺: "企业数据治理与SAP MDG实现", 30 November 2020, 机械工业出版社, pages: 277 - 278 *
郭秋萍等: "企业数据挖掘理论与实践", 30 April 2005, 黄河水利出版社, pages: 50 - 52 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116303652A (zh) * 2023-05-17 2023-06-23 北京微吼时代科技有限公司 一种基于数据库binlog的事件分发方法及系统

Similar Documents

Publication Publication Date Title
TWI735545B (zh) 一種模型的訓練方法和裝置
CN111209352B (zh) 一种数据处理方法、装置、电子设备及存储介质
DE102016013248A1 (de) Bezugsblockansammlung in einer Bezugsmenge zur Deduplizierung beim Speichermanagement
CN111339073A (zh) 实时数据处理方法、装置、电子设备及可读存储介质
WO2021051782A1 (zh) 区块链的共识方法、装置及设备
CN105900093A (zh) 一种KeyValue数据库的数据表的更新方法与表数据更新装置
CN111258978A (zh) 一种数据存储的方法
CN112328592A (zh) 数据存储方法、电子设备及计算机可读存储介质
US11886225B2 (en) Message processing method and apparatus in distributed system
CN116450890A (zh) 图数据处理方法、装置、系统、电子设备及存储介质
CN113256355B (zh) 一种积分权益实时确定方法、装置、介质、设备和系统
CN112579585A (zh) 一种数据处理系统、方法及装置
CN112241474B (zh) 信息处理方法、装置和存储介质
CN113051102A (zh) 文件备份方法、装置、系统、存储介质和计算机设备
CN110737432A (zh) 一种基于词根表的脚本辅助设计方法及装置
CN116821133A (zh) 一种数据处理方法和装置
CN113360889B (zh) 权限管理方法和装置、服务器、计算机可读存储介质
CN112464049B (zh) 号码详单下载方法、装置和设备
CN108595488B (zh) 数据迁移方法和装置
He et al. Research on Global BloomFilter-Based Data Routing Strategy of Deduplication in Cloud Environment
CN110598072A (zh) 一种特征数据聚合方法及装置
CN115455031B (zh) 一种Doris的数据查询方法、装置、存储介质及设备
CN111079391B (zh) 一种报表的生成方法及装置
CN113553376A (zh) 基于分布式架构的财险产品发布与检索方法、装置及系统
CN117370338A (zh) 一种宽表数据的存储方法、装置及终端

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information
CB02 Change of applicant information

Address after: Room 221, 2 / F, block C, 18 Kechuang 11th Street, Daxing District, Beijing, 100176

Applicant after: Jingdong Technology Holding Co.,Ltd.

Address before: Room 221, 2 / F, block C, 18 Kechuang 11th Street, Beijing Economic and Technological Development Zone, 100176

Applicant before: Jingdong Digital Technology Holding Co., Ltd