CN111858534A - 一种增加日志大数据量排序方法 - Google Patents
一种增加日志大数据量排序方法 Download PDFInfo
- Publication number
- CN111858534A CN111858534A CN202010729406.9A CN202010729406A CN111858534A CN 111858534 A CN111858534 A CN 111858534A CN 202010729406 A CN202010729406 A CN 202010729406A CN 111858534 A CN111858534 A CN 111858534A
- Authority
- CN
- China
- Prior art keywords
- file
- data
- index
- current
- log
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 239000012634 fragment Substances 0.000 claims description 7
- 230000001360 synchronised effect Effects 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 3
- 238000006467 substitution reaction Methods 0.000 description 2
- 241001269238 Data Species 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
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/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- 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/25—Integrating or interfacing systems involving database management systems
- G06F16/254—Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明涉及大数据ETL领域,具体提供了一种增加日志大数据量排序方法,多线程解析Redo日志后的多批次无序数据,通过路径文件命名、落盘和抓取的方式进行排序后,以正确有序的队列向后传输至目标源中,用于完成数据的同步。与现有技术相比,本发明的可以使用多线程解析,致使同步数据量达到T级别。满足绝大部分业务的增量需求,且该处理器配置简单、开发成本低、运行稳定、操作难度低,具有良好的推广价值。
Description
技术领域
本发明涉及大数据ETL领域,具体提供一种增加日志大数据量排序方法。
背景技术
现在的社会是一个高速发展的社会,科技发达,信息流通,人们之间的交流越来越密切,生活也越来越方便,大数据就是这个高科技时代的产物。目前来看,随着信息化越来越普遍,业务中的每天增量数据已经不仅仅局限于几百KB或者几百G的数据量,更多的业务增量redo日志日增数据量达到了T级别。于是这就产生了另一个问题,解析日志的速度达不到redo日志的产生速度。
由于要保证数据的一致性,即数据DML一致,之前解析redo日志文件是以单线程运行的,即按照redo日志的生成时间逐个解析。这种解析方式无法并发导致速度无法达到日志生成速度,从而多线程对日志的解析方案就呼之欲出。但是多线程的方式速度达到了,然而各个线程解析日志文件后的数据是杂乱无章的,如何将这些数据以正确有序的方式重新排列成了本领域技术人员面临的技术难题。
发明内容
本发明是针对上述现有技术的不足,提供一种实用性强的增加日志大数据量排序方法。
本发明解决其技术问题所采用的技术方案是:
一种增加日志大数据量排序方法,多线程解析Redo日志后的多批次无序数据,通过路径文件命名、落盘和抓取的方式进行排序后,以正确有序的队列向后传输至目标源中,用于完成数据的同步。
进一步的,解析Redo日志之前先需要在FetchOracleRedoLogFile获取某一时间段的所有redo日志文件名称,按照日志生成的时间给每个日志文件名称依次加上current.index(1,2,3...)属性。
进一步的,多线程解析Redo日志时,ExecuteOracleLogMiner为解析日志文件处理器,每个线程处理一个日志文件,每10000条生成一个数据流向后传输,同时设置上FragmentNumber与NextFragmentNumber属性,当FragmentNumber与NextFragmentNumber相同时,则说明该日志文件已解析完毕。
进一步的,多批无序数据使用处理器FetchRedoBySequential进行数据的传输,先查看所述处理器中有无该数据表保存的状态,如果状态中未查询到该数据表的状态,则采取初始化状态Initial sequence(1-1)。
作为优选,所述数据表中键列为用户名和数据表,值列为所期待的序号批次数据。
进一步的,所述处理器FetchRedoBySequential为单线程执行,若传输的数据流不能识别,则采取的逻辑即将其落盘,路径为用户所配置的路径(/indata/disk_0/nifi/datas+“/用户名/数据表/current.index”),文件名为FragmentNumber+NextFragmentNumber。
进一步的,当所期待的数据流传输来后,首先将其向后传输,其次,便去磁盘中扫描是否存在下一个数据流文件;数据流传输后,获取其NextFragmentNumber属性,这时分为两种情况:
1)、当FragmentNumber与NextFragmentNumber相同时,则说明当前current.index的日志文件已排序完毕,接下来扫描/indata/disk_0/nifi/datas/user1/tableA/current.index+1路径下的以1开头的文件名。
2)当FragmentNumber与NextFragmentNumber不同时。则说明当前current.index的日志文件还未排序完毕。扫描当前/indata/disk_0/nifi/datas/user1/tableA/current.index路径下的以NextFragmentNumber开头的文件名。
如若扫描到所期待的文件,则获取该文件并向后传输并循环上述1)、2)步骤直至扫描不到所期待文件,则说明所期待文件还未传输到该处理器。此时更新该处理器user1.tableA状态为所期待的数据流对应的属性(current.index+FragmentNumber),等待着该数据流的流入。
进一步的,当从磁盘扫描文件,一个current.index路径扫描完毕后,则可以设置Delete Disk File属性为true来将这个路径删除。
进一步的,若从磁盘中取出文件出错时,抛出异常的同时,将状态更新到出错文件的前一批次状态并生成一个新的数据流回滚。
本发明的一种增加日志大数据量排序方法和现有技术相比,具有以下突出的有益效果:
本发明的一种增加日志大数据量排序方法,提供了对数据属性的解析、落盘路径和文件名称等,解决了单线程无法匹配Redo日志增量的大数据量问题。可以使用多线程解析,致使同步数据量达到T级别。满足绝大部分业务的增量需求,且该处理器配置简单、开发成本低、运行稳定、操作难度低,使数据信息排列成有效的数据信息,具有广泛的应用场景。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
附图1是一种增加日志大数据量排序方法中采集增量redo日志的流程示意图;
附图2是一种增加日志大数据量排序方法中FetchRedoBySequential配置参数的示意图;
附图3是一种增加日志大数据量排序方法中FetchRedoBySequential保存状态的示意图。
具体实施方式
为了使本技术领域的人员更好的理解本发明的方案,下面结合具体的实施方式对本发明作进一步的详细说明。显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例都属于本发明保护的范围。
下面给出一个最佳实施例:
如图1所示,本实施例中的增加日志大数据量排序方法,主要为多线程解析Redo日志后的多批次无序数据,通过路径文件命名、落盘和抓取的方式进行排序后,以正确有序的队列向后传输至目标源中,用于完成数据的同步。
通过以下步骤具体实现:
FetchOracleRedoLogFile获取某一时间段的所有redo日志文件名称,按照日志生成的时间给每个日志文件名称依次加上current.index(1,2,3...)属性。
ExecuteOracleLogMiner为解析日志文件处理器(可设置为多线程),每个线程处理一个日志文件,每10000条生成一个数据流向后传输,避免内存溢出。同时设置上FragmentNumber(当前redo文件的当前批次序号1,2,3...)与NextFragmentNumber(当前redo日志文件的下一个批次序号1,2,3...)属性,当FragmentNumber与NextFragmentNumber相同时,则说明该日志文件已解析完毕。
如图2所示,多批无序数据使用处理器FetchRedoBySequential进行数据的传输,先查看所述处理器中有无该数据表保存的状态,如果状态中未查询到该数据表的状态,则采取初始化状态Initial sequence(1-1)。
其中数据表中键列为用户名和数据表,值列为所期待的序号批次数据。
如图3所示,第5012个redo日志文件的第一批次序号。如果状态中未查询到该数据表的状态,则采取初始化状态Initial sequence(1-1)。
处理器FetchRedoBySequential为单线程执行。由于前一个处理器为多线程运行,传输进来的数据为无序的。以user1.tableA为例。开始运行时所期待的数据流为1-1,即current.index属性为1、FragmentNumber属性为1的数据流。然而通常传过来的数据流并不是自己所期待的,可能为2-2或者1-2。此时采取的逻辑即将其落盘,路径为用户所配置的路径(/indata/disk_0/nifi/datas+“/用户名/数据表/current.index”),文件名FragmentNumber+NextFragmentNumber。
如:/indata/disk_0/nifi/datas/user1/tableA/2/2-3。
当所期待的数据流1-1传输过来后,首先将其向后传输,其次便去磁盘中扫描是否存在下一个数据流文件。数据流1-1传输后,获取其NextFragmentNumber属性。这时分为两种情况:
1)当FragmentNumber与NextFragmentNumber相同时,则说明当前current.index的日志文件已排序完毕,接下来扫描/indata/disk_0/nifi/datas/user1/tableA/current.index+1路径下的以1开头的文件名。
2)当FragmentNumber与NextFragmentNumber不同时。则说明当前current.index的日志文件还未排序完毕。扫描当前/indata/disk_0/nifi/datas/user1/tableA/current.index路径下的以NextFragmentNumber开头的文件名。
如若扫描到所期待的文件,则获取该文件并向后传输并循环上述1、2步骤直至扫描不到所期待文件,则说明所期待文件还未传输到该处理器。此时更新该处理器user1.tableA状态为所期待的数据流对应的属性(current.index+FragmentNumber),等待着该数据流的流入。
当从磁盘扫描文件,一个current.index路径扫描完毕后,则可以设置DeleteDisk File属性为true来将这个路径删除。
当从磁盘中取文件出错时,抛出异常的同时。将状态更新到出错文件的前一批次状态并生成一个新的数据流回滚。例如:取current.index为2的文件名为3-4文件出错时,则状态设置为current.index为2,FragmentNumber为2,即为2-2。同时生成一个数据流,其属性current.index为2,FragmentNumber为2,NextFragmentNumber为3回滚流回自己,再次触发。
通过以上逻辑来完成对多批次无序数据进行排序传输。
上述具体的实施方式仅是本发明具体的个案,本发明的专利保护范围包括但不限于上述具体的实施方式,任何符合本发明的一种增加日志大数据量排序方法权利要求书的且任何所述技术领域普通技术人员对其做出的适当变化或者替换,皆应落入本发明的专利保护范围。
尽管已经示出和描述了本发明的实施例,对于本领域的普通技术人员而言,可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型,本发明的范围由所附权利要求及其等同物限定。
Claims (9)
1.一种增加日志大数据量排序方法,其特征在于,多线程解析Redo日志后的多批次无序数据,通过路径文件命名、落盘和抓取的方式进行排序后,以正确有序的队列向后传输至目标源中,用于完成数据的同步。
2.根据权利要求1所述的一种增加日志大数据量排序方法,其特征在于,解析Redo日志之前先需要在FetchOracleRedoLogFile获取某一时间段的所有redo日志文件名称,按照日志生成的时间给每个日志文件名称依次加上current.index(1,2,3...)属性。
3.根据权利要求2所述的一种增加日志大数据量排序方法,其特征在于,多线程解析Redo日志时,ExecuteOracleLogMiner为解析日志文件处理器,每个线程处理一个日志文件,每10000条生成一个数据流向后传输,同时设置上FragmentNumber与NextFragmentNumber属性,当FragmentNumber与NextFragmentNumber相同时,则说明该日志文件已解析完毕。
4.根据权利要求3所述的一种增加日志大数据量排序方法,其特征在于,多批无序数据使用处理器FetchRedoBySequential进行数据的传输,先查看所述处理器中有无该数据表保存的状态,如果状态中未查询到该数据表的状态,则采取初始化状态Initial sequence(1-1)。
5.根据权利要求4所述的一种增加日志大数据量排序方法,其特征在于,所述数据表中键列为用户名和数据表,值列为所期待的序号批次数据。
6.根据权利要求5所述的一种增加日志大数据量排序方法,其特征在于,所述处理器FetchRedoBySequential为单线程执行,若传输的数据流不能识别,则采取的逻辑即将其落盘,路径为用户所配置的路径(/indata/disk_0/nifi/datas+“/用户名/数据表/current.index”),文件名为FragmentNumber+NextFragmentNumber。
7.根据权利要求6所述的一种增加日志大数据量排序方法,其特征在于,当所期待的数据流传输来后,首先将其向后传输,其次,便去磁盘中扫描是否存在下一个数据流文件;数据流传输后,获取其NextFragmentNumber属性,这时分为两种情况:
1)、当FragmentNumber与NextFragmentNumber相同时,则说明当前current.index的日志文件已排序完毕,接下来扫描/indata/disk_0/nifi/datas/user1/tableA/current.index+1路径下的以1开头的文件名。
2)当FragmentNumber与NextFragmentNumber不同时。则说明当前current.index的日志文件还未排序完毕。扫描当前/indata/disk_0/nifi/datas/user1/tableA/current.index路径下的以NextFragmentNumber开头的文件名。
如若扫描到所期待的文件,则获取该文件并向后传输并循环上述1)、2)步骤直至扫描不到所期待文件,则说明所期待文件还未传输到该处理器。此时更新该处理器user1.tableA状态为所期待的数据流对应的属性(current.index+FragmentNumber),等待着该数据流的流入。
8.根据权利要求7所述的一种增加日志大数据量排序方法,其特征在于,当从磁盘扫描文件,一个current.index路径扫描完毕后,则可以设置Delete Disk File属性为true来将这个路径删除。
9.根据权利要求8所述的一种增加日志大数据量排序方法,其特征在于,若从磁盘中取出文件出错时,抛出异常的同时,将状态更新到出错文件的前一批次状态并生成一个新的数据流回滚。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010729406.9A CN111858534A (zh) | 2020-07-27 | 2020-07-27 | 一种增加日志大数据量排序方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010729406.9A CN111858534A (zh) | 2020-07-27 | 2020-07-27 | 一种增加日志大数据量排序方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111858534A true CN111858534A (zh) | 2020-10-30 |
Family
ID=72947050
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010729406.9A Pending CN111858534A (zh) | 2020-07-27 | 2020-07-27 | 一种增加日志大数据量排序方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111858534A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112732662A (zh) * | 2021-01-04 | 2021-04-30 | 浪潮云信息技术股份公司 | 一种NiFi同步数据量统计方法 |
CN113254461A (zh) * | 2021-02-07 | 2021-08-13 | 浪潮云信息技术股份公司 | 一种基于nifi的实现数据库同步的优化方法及系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103309858A (zh) * | 2012-03-06 | 2013-09-18 | 深圳市腾讯计算机系统有限公司 | 一种多线程日志管理的方法及装置 |
CN105677876A (zh) * | 2016-01-12 | 2016-06-15 | 国家电网公司 | 一种基于物理级的数据库日志挖掘方法 |
CN106354817A (zh) * | 2016-08-30 | 2017-01-25 | 苏州蓝海彤翔系统科技有限公司 | 一种日志的处理方法及装置 |
CN109582551A (zh) * | 2018-10-11 | 2019-04-05 | 平安科技(深圳)有限公司 | 日志数据解析方法、装置、计算机设备和存储介质 |
-
2020
- 2020-07-27 CN CN202010729406.9A patent/CN111858534A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103309858A (zh) * | 2012-03-06 | 2013-09-18 | 深圳市腾讯计算机系统有限公司 | 一种多线程日志管理的方法及装置 |
CN105677876A (zh) * | 2016-01-12 | 2016-06-15 | 国家电网公司 | 一种基于物理级的数据库日志挖掘方法 |
CN106354817A (zh) * | 2016-08-30 | 2017-01-25 | 苏州蓝海彤翔系统科技有限公司 | 一种日志的处理方法及装置 |
CN109582551A (zh) * | 2018-10-11 | 2019-04-05 | 平安科技(深圳)有限公司 | 日志数据解析方法、装置、计算机设备和存储介质 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112732662A (zh) * | 2021-01-04 | 2021-04-30 | 浪潮云信息技术股份公司 | 一种NiFi同步数据量统计方法 |
CN113254461A (zh) * | 2021-02-07 | 2021-08-13 | 浪潮云信息技术股份公司 | 一种基于nifi的实现数据库同步的优化方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11487735B2 (en) | Combinators | |
CN109800222B (zh) | 一种HBase二级索引自适应优化方法和系统 | |
US20130159251A1 (en) | Dedicating Disks to Reading or Writing | |
CN111125260A (zh) | 一种基于SQL Server的数据同步方法及系统 | |
CN111563095B (zh) | 一种基于HBase的数据检索装置 | |
CN114637989B (zh) | 基于分布式系统的apt攻击追溯方法、系统及存储介质 | |
CN112307037A (zh) | 一种数据同步方法和装置 | |
CN110321383A (zh) | 大数据平台数据同步方法、装置、计算机设备及存储介质 | |
CN111858534A (zh) | 一种增加日志大数据量排序方法 | |
US12057208B1 (en) | Visualizing anomalous feature vectors based on data from healthcare records systems | |
CN110245134B (zh) | 一种应用于搜索服务的增量同步方法 | |
CN114756629B (zh) | 基于sql的多源异构数据交互分析引擎及方法 | |
US11106739B2 (en) | Document structures for searching within and across messages | |
CN113094442B (zh) | 全量数据同步方法、装置、设备和介质 | |
Goasdoué et al. | CliqueSquare: efficient Hadoop-based RDF query processing | |
WO2022261249A1 (en) | Distributed task assignment, distributed alerts and supression management, and artifact life tracking storage in a cluster computing system | |
CN111143468B (zh) | 基于mpp分布式技术的多数据库数据管理方法 | |
CN110209578B (zh) | 一种信息在线测试平台 | |
US9390131B1 (en) | Executing queries subject to different consistency requirements | |
US8990169B2 (en) | Statistics collection for database tables | |
Manghi et al. | De-duplication of aggregation authority files | |
CA2418093A1 (en) | Data compiling method | |
CN115982231A (zh) | 分布式实时搜索系统及方法 | |
Nykiel et al. | Sharing across multiple MapReduce jobs | |
CN114490865A (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 |