CN108351898A - 用于结构化多字段文件布局的自动化解释 - Google Patents

用于结构化多字段文件布局的自动化解释 Download PDF

Info

Publication number
CN108351898A
CN108351898A CN201680066594.3A CN201680066594A CN108351898A CN 108351898 A CN108351898 A CN 108351898A CN 201680066594 A CN201680066594 A CN 201680066594A CN 108351898 A CN108351898 A CN 108351898A
Authority
CN
China
Prior art keywords
oracle
field
file
data file
data
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.)
Granted
Application number
CN201680066594.3A
Other languages
English (en)
Other versions
CN108351898B (zh
Inventor
M·伯特纳
W·D·柯林斯
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.)
Ankhak Co
Original Assignee
Ankhak Co
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 Ankhak Co filed Critical Ankhak Co
Publication of CN108351898A publication Critical patent/CN108351898A/zh
Application granted granted Critical
Publication of CN108351898B publication Critical patent/CN108351898B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84Mapping; Conversion
    • G06F16/86Mapping to a database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00Methods or arrangements for processing data by operating upon the order or content of the data handled
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/04Inference or reasoning models

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种用于解释多字段文件的字段布局的完全自动化的系统,使用由三个子系统的交互构建的丰富的上下文框架,以提供如每个字段的位置和数据类型所定义的对结构化数据文件的上下文的整体视图。每个子系统的作用是(1)确定文件的元数据和不同数据字段的位置;(2)使用易错的oracle(即没有oracle必须能够识别每个记录的类型),以在若干等级上提供对这些字段的一套解释;以及(3)即使在数据不明确的情况下,也不需要正确解释每个记录就能准确确定每个字段的位置和特定数据类型。该系统可以在分隔和固定宽度的结构文件上运作。

Description

用于结构化多字段文件布局的自动化解释
技术领域
本发明涉及一种用于识别数据文件中每个字段(即,布局)的特定数据类型的自动化方法,该数据文件可以表示为表格,其中每行表示单个记录并且每列表示特定属性/名称字段,例如通常用于业务数据服务和其他商业目的。
背景技术
在本背景部分中提到的参考文献不认为是关于本发明的现有技术。
今天的业务必须消耗大量的数据,其中包括例如现有的客户数据、库存数据、新客户和产品的预期数据以及作出关键业务决策所需的其他相关业务数据。这些数据可能由多个文件表示,其中一些文件可能包含数百万条记录,每个记录包含数百个字段。通常,这些文件来源于客户或数据汇总公司,不包含布局或字段格式信息。固定宽度文件(即每个记录的每个字段具有相同数量的字符位置/字节的那些文件)通常没有布局。这些数据文件需要一些预处理步骤,以为布局提供高度准确的描述。手动执行此步骤容易出错并且代价高昂。
包含数据(例如用于业务数据服务的数据)的文件通常组织为一系列记录,每个记录包含多个字段。每个字段都与特定的属性相关联。例如,在包含包括消费者数据的记录的文件中,每个记录可以属于单个消费者,并且包括在每个记录中的字段可以包括例如名字、姓氏、街道地址、城市、州、邮政编码、电话号码、人口统计数据(例如年龄、性别和收入)以及之前的购买活动。通常,数据可以表示为表格,表格的每行表示记录,每列表示字段。当要摄取(即处理)这种类型的文件时,例如为了用附加数据优化文件,执行数据“卫生”(删除重复数据和标准化)、数据分析或其他商业活动,必须准确识别每个文件记录中每个字段中的数据类型。这是由于整个行业没有这种文件记录的标准格式。传统上,识别每个记录字段中的数据类型(即,每列中的数据类型)的这一步骤已经被手动执行。定期处理这类数据的人只需查看计算机屏幕上显示的每列数据,并根据他们所看到的内容为列(字段)分配标签。取决于人的准确性,这种方法很容易出错,非常耗时且成本高昂。这些错误源于大量待识别字段的手动排序(因为如上所述,记录可能包含数百个字段),以及在许多情况下,每个字段的识别仅基于一个或极少数记录。对于人类来说,查看可能包含数百万个单独记录(行)的文件中的所有记录是不实际的。
此外,如果文件中提供了“布局”(例如,标题行),则人类审阅者强烈倾向于依赖该信息,而不在文件内对数据本身进行验证。在许多情况下,提供的布局可能不准确或不完整。例如,如果数据布局来自文件的早期版本或包含不正确的信息,则可能发生这种情况。即使在存在正确布局的情况下,对于每个字段数据类型也没有标准化的命名约定,因此必须分析布局描述本身以确定其含义。
在没有提供布局的情况下,无法仅通过仅查看该特定字段中的信息就准确地识别某些字段。例如,包含“y”和“n”字符的字段可能表示问题的“是”或“否”答案,但没有额外的上下文,就不可能确定问题是什么,并且因此答案意味着什么。
随着业务继续消耗更多表格数据并且每个记录中的记录数量和字段数量不断增长,每个重要字段的数据类型的人工识别和验证总体数据占用不断增加。各种具体问题可能导致此过程效率低下。这样的数据文件通常是分隔的,其中相邻的字段值例如是通过共同的分隔符字符分开的。下表提供了使用逗号分隔符的此类文件的简单示例。
1,John,Doe,123 Main St.,Little Rock,AR,72207
2,Mary,Smith,456 1st Street,Phoenix,AZ,85001
3,Fred,Jones,2006 Lovers Ln.,Dallas,Tx,75201
4,Martin,VanBuren,1902 Cleveland St.,Kinderhook,NY,12106
表1
然而,许多文件仍然使用固定宽度的布局,其中每个字段具有固定的字符宽度并且用单个固定字符填充。表2是使用空白字符作为填充的这种固定宽度文件的示例。
表2
对于分隔文件,分隔符的准确识别可能很困难,因为传统的分隔符实际上也可能以意想不到的位置频率出现在正统字段值内置。另外,即使提供了文件布局,它也可能不准确,或者使用不常用或不能理解的业务特定字段名称。在这些情况下,字段分隔符和布局识别必须由实际的数据内容来确定。
对于固定宽度的文件,如果提供布局,给定的布局信息可以以几种不同的表示形式出现。所有表示意在表示每个字段的名称以及其在记录中的宽度和位置。每个字段的位置信息可以作为字段宽度的序列出现,其中每个字段的起始和结束位置必须从这些值或作为起始位置来计算。在后一种情况下,存在两种变体,其中前导位置由数字1表示的索引表示和其中前导位置由数字0表示的偏移表示。表示的类型必须从布局推断出。在没有布局的情况下,字段位置的识别也必须由实际数据确定,并且对于每个记录中的数据具有显着差异的大文件,这样的确定可能是困难且耗时的。
一旦识别了字段位置,就必须识别每个字段的数据类型,以便通过常用的传统分析技术可以提取和验证后续的适当信息。但是,每个字段的准确位置和数据类型识别对于这些自动分析技术来说至关重要,从而正确提取数据。
如上所述,用于精确的字段位置和数据类型识别的现有技术的状况是使用纯粹手动处理中的一种,或者在一些情况下使用自动化系统来增补手动操作。这些自动化系统识别一小部分字段数据类型,例如姓名、地址和众所周知的识别字符串(例如货币值、电话号码和日期)。但是,这些自动化系统为这些数据类型中的每一种嵌入了死板且非常有限的预期格式。由于数据文件是从各种来源和上下文引起并创建的,因此这些数据类型中的很多可以以多种方式出现。例如,对于日期2016年10月5日,在数据文件中发现一些有效格式,包括“10/05/2016”、“20161005”、“100516”和“2016OCT05”。同样,尽管这样的日期通常出现在单个字段中,但它们也可以分成分开的字段。例如,年份可以与月份/日期信息分开,或者所有三个组成部分可以以不同的字段以多个可能的顺序呈现。类似地,名称和地址中的每一个可以用单个字段或多个字段来表示,并且这些字段在它们的组成部分方面的顺序在数据文件中是不统一的(即,名字/姓氏和姓氏/名字连续字段是常见的)。此外,还有许多可以表示多种数据类型的单词和字符串。词语“华盛顿”可以很容易地代表人名字的组成部分、企业名称、街道名称、州或城市的组成部分。最后,不能保证字段的相同数据表示将用在文件的所有记录中。
在现有技术中存在的半自动化方法中,每个方法都试图一次确定单个记录的字段类型,并且最终决定基于针对每个所应用的算法的准确度和/或概率的预定分级系统。然而,重要的是要注意,由于字符串(名称)的使用以及字母数字字符串(日期、地址表示等)的不同表示,这些方法是不可靠的。因此,这些方法容易产生上述记录到记录差异的不明确性。因此,为了显着提高这种自动化系统的能力和准确性,并且为了提高吞吐量并减少用于确定文件布局的系统的计算周期,本发明人已经认识到,这种解释范围的限制必须扩展到更丰富,更上下文关联的解释范围,其可以根据认知更深的框架做出正确的决定。
发明内容
本发明解决了减少由识别文件布局的手动或半自动化方法导致的错误和低效率的需要,并且在大量业务数据字段的处理中特别有价值。本发明利用在计算方面而言丰富的上下文和自定义过程,以非常高的准确度跨这些多个视角识别和验证每个字段的数据类型。这是通过几乎没有人工输入的自动化和不使用任何提供的文件布局来实现的。本发明改进了数据文件的摄取,用于例如但不限于数据库管理、销售、会计、直销和其他维护活动。
本发明利用了使用来自每个记录中的其他字段的上下文的方法,以便确定特定字段内的数据的含义。在某些实施方式中,本发明可以识别某些类型的字段的主要字符模式,以及确定这些字段是否仅包含少量不同值(即枚举),例如“y”或“n”意味着“是”或“否”。布局的确定完全通过使用文件的数据本身来完成,该文件本身使用多个角度(perspective)进行迭代解释,以最大限度地利用上下文来确定布局。这些角度包括从单个记录内以及覆盖大量记录组的实际数据解释数据字段类型的排序。此外,每个字段的潜在数据类型的识别以及它们与相邻和邻近数据字段的潜在数据类型的关系用于解释具有多种可能解释的字段的确切数据类型。分析的记录数量可根据所需的计算时间和准确度之间的期望折衷来定制。
在某些实施方式中,本发明通过组合三个高度相关的子系统来创建丰富的上下文框架,这些子系统从多个角度查看数据文件的内容的上下文。第一子系统侧重于识别分隔文件和固定宽度文件的字段位置,以及识别文件中使用的字符集和不同类型的分隔符的预处理步骤。第二子系统由“oracle”的多语境层组成(如本文所进一步解释的),它们相互作用以确定字段组的可能解释。这些不同层次的oracle的相互作用和随后的解释将信息从非常细微的层次(一次一个字段)合并为上下文丰富的层次(依次或本地定位的潜在相关的字段集)。第三子系统消耗整个输入文件的重要的部分,并使用前两个子系统的结果来计算并输出数据文件的最终解释,其随后将用于读入和解释实际数据本身,以用于特定于业务用例的应用程序。
本发明的一个实施方式允许用户预设要使用多少文件来确定最终布局信息。如上所述,一次使用单个记录通常会产生较差且不一致的结果。在确定布局时使用的行数越多,结果的精确度越高,但这种精确度的提高将伴随着子系统运行时间的成本。正如人们所预料的那样,在使用10,000行20字段文件和使用10,000,000行100字段文件之间会有明显的时间差异。但是在任何一种情况下,使用如本文所述的全自动化系统所节省的时间远大于现有技术的技术水平,后者可能需要多个工时到工作日。此外,因为在做出这种决定时无法手动审查数千、数十万甚至数百万个字段,可以看出,任何使用人工审查的方法在可审查字段的数量方面都受到内在限制,以确定字段类型。在本发明的一个实施方式中,指定要在字段分析中使用的默认固定行数,其可以是例如10,000行。但是,用户可以根据文件的特定上下文和大小、进程的预期运行时间以及结果的期望准确性以轻松更改该值。
Oracle子系统基于多层次的oracle集合,每个集合指示数据中的给定字段是否具有一致的数据类型形式。本文使用的术语“oracle”是在计算机系统上运行的软件程序,其对用户而言显示为用于作出高阶决策的“黑匣子”。单一的oracle有特定的上下文框架来响应输入数据组。对于本发明,每个潜在的字段数据类型将具有相关的oracle。例如,如果数据包含“名字”数据,那么将会有名字oracle。oracle会对所有正在评估的记录从固定字段中摄取并随后响应一组值。该响应将包含输入值是否似乎具有所分配的数据类型的真值以及小组相关的上下文信息。随后使用这些信息来确定最终的字段数据类型将不取决于实际oracle的内部构造,更确切地说仅取决于其输出。因此,没有任何隐藏的假设,即oracle的响应总是正确的。例如,在10,000个记录的测试集中,如果其中有大量的记录看起来是已知名字的实例,那么“名字”oracle会对该字段做出积极响应。因此,这些oracle不是对单行数据起作用,而是对文件中适当的记录组上的单个字段或连续字段组起作用。在这种情况下,并非给定字段中的每个记录值都必须解释为指定的数据类型,而是相当大比例的值认为是这样。因此,oracle的响应的准确性主要不依赖于为指定字段中的每个记录的值确定类型的能力。类似地,如前所述,存在用于人名、企业名称、街道名称、城市和州的大量“名称”。因此,给定的字段可以得到多个oracle的积极响应。来自多种类型的oracle的这种模糊程度实际上是本发明精确识别字段数据类型的能力的主要优势。在某些实施方式中,本发明实际上利用了在文件中的各种记录的字段中发现的数据的不可避免的不明确性和不可靠性,以通过考虑所有列的所有合理解释,并且然后选择一组认知最一致和完整的解释,由此以可防御的方式识别字段类型。
为了使本发明的oracle子系统能够对文件中的字段组做出准确的整体判定,在某些实施方式中,就数据类型而言,存在三个等级的oracle,其给出不同级别的字段类型的解释粒度。第一级oracle由那些可以识别原始数据模式的oracle构成,例如空格、数字串、字母串和字母数字串。这些oracle有助于识别固定宽度文件的字段位置,并定义数据类型高度专门化的字段的字符结构,例如库存件号和其他专有识别符。本发明的第二级oracle由识别大多数数据文件共有的字段类型构成。这些包括名字、姓氏、姓名后缀、街道名称、单元指示符(公寓、级别、楼层)和城市名称的名字和地址组成部分oracle以及常用数字字段(例如电话号码、日期、邮政编码和社会保障号)。业务数据文件通常还包含个体的自主密钥,因此可能会有不同的散列字符串(例如MD5、SHA 1和SHA 256)的oracle。最后,个人或地点的其他识别符(例如电子邮件地址、纬度和经度以及IP地址)可能会有相应的oracle。
在某些实施方式中,本发明的第三级oracle由用于解释连续字段组的整体含义的“元”-oracle构成。这些oracle在可以跨越多个字段的基础数据类型的位置中很有用,例如个人的全名和完整的邮寄地址。如前所述,这些数据可以出现在单个字段中或作为一系列相邻字段出现。无论使用什么字段格式,这些元-oracle都承担识别此类情况的职责。特别是,对这些oracle的输入是对已识别的字段的oracle前两个等级的输出。如前所述,每个字段都可以得到多个oracle的积极响应。因此,如上所述,这些元-oracle搜索与多字段数据类型一致的连续字段的数据类型模式。
在某些实施方式中,这些oracle也具有记录它们找到的不同数据值的频率的能力。这对于识别列举的字段(如性别)很有用,其中只使用一小组值或代码来表示数据。类似地,这些oracle还会在字段中保持记录数量的计数,这些记录的确凿证据也是关联的数据类型。这些计数对于似乎包含相同类型信息的无歧义字段是非常有用的。不同上下文级别的oracle以及特定于字段的信息的相互作用为序列字段的内容提供了极其丰富且消除歧义的视角,这种视角是单个oracle级别视角在多种数据文件中无法提供的。
在某些实施方式中,字段位置子系统负责分隔文件和固定宽度文件。对于分隔文件,系统会从最常用的分隔符组中查找潜在分隔符,这些分隔符包括大部分标点符号以及特殊空格字符。每个分隔符的频率和位置都是为一组记录建立的,并且每行的每个可能的分隔符计数的一致性和差异在该组中的所有记录中被测量。如果单个分隔符似乎在所有记录中都匹配,则可以调用oracle子系统来验证所得字段的子集可以被确定并且似乎是根据上下文有意义的(例如,在名字字段和姓氏字段之间似乎没有邮政编码)。如果存在多个潜在分隔符,则可以使用oracle子系统基于由每个分隔符构造的字段的第一遍解释来区分最佳潜在分隔符。由于某些字段可能会将潜在分隔符作为其数据类型的有效字符包含在内,因此协议不需要完全匹配每行。但是在这些情况下,oracle子系统可能会检查字段类型以获得必要的解释一致性。例如,由于剩余记录的一致结构,在一些记录中的额外逗号仍然实现了被分析字段的正确解析。
在某些实施方式中,固定宽度文件中字段的识别需要各种不同的角度。特别地,可以采用从文件中的实际数据生成的几种类型的图像的图像处理边缘检测技术。使用的一个图像是二进制图像,通过将文件的每个(行、列)字符映射为1(白色)(如果该字符是非空格字符),否则映射到图像中的(行、列)位置为0(黑色),所述二进制图像将数据文件的行和列映射到图像的行和列。至少一些字段的边缘可以由其相邻列中白色部分最大的那些列来识别。这种技术适用于大多数数据值包含空白填充的列。第二个图像以类似的方式创建,但使用第一级的oracle通过使用不同的颜色区分不同类型的非空格字符。在本发明的一个实施方式中,给每个空格字符、字母字符、数字字符和标点字符分配不同的颜色,并且这些颜色的分布用于识别上述方法未找到的列以及给定字段内的不同字符模式。与其他类型的字段相比,最后的观察允许清楚地识别完整的地址字段。最后,在现有识别字段上使用oracle子系统来确定是否有任何事实上是具有上述方法未找到的可识别数据类型的相邻字段的连接。
在某些实施方式中,第三子系统由识别和验证文件布局的实际进程组成,并在其处理中以多种方式使用前两个子系统。该子系统负责指导文件布局的确定。该子系统开始于摄取要用于分析的记录子集并确定用于创建文件的字符编码(例如ASCII或UTF8)和记录分隔符。一旦找到文件的适当元数据,子系统就会确定文件是分隔文件还是固定宽度文件。如前所述,如果在文件中找到可能的字符分隔符,则可以在确定所选择的分隔符时识别产生的字段数据类型的子集。该进程交织前两个子系统以最终识别分隔符(如果存在这样的分隔符)。如果没有识别到分隔符,则该子系统创建两个字符类型的图像,并执行后续的图像处理算法以找到现在识别到的固定宽度文件上的字段位置的第一遍确定。再次,该子系统可以调用oracle子系统来帮助最终确定字段位置。
在某些实施方式中,一旦识别了字段位置,就会调用oracle子系统来创建视角,说明单个字段和相继字段子集的不同可能的解释。然后对这些解释进行评估和过滤,以最终识别数据文件的最终布局。然后将该布局导出,以供随后的下游过程消费,在一个实施例中,后续下游过程消费完整文件的数据。
没有一个系统是完全准确的,因此当然可以在所得布局包含错误的情况下进行更正。发明人执行的测试已经显示,本发明的某些实施方式针对用于分隔文件和固定宽度文件的不同业务文件布局的大量抽样的准确度超过97%,处理时间减少到几秒钟。该准确度值比手动或混合系统报告的准确度值要大。所识别的错误主要发生在非常稀疏数量的字段中,由于现有数据值的模式不一致而极难或不可能由人类识别,因此无法预期现有技术方法对此问题有更好的结果。
结合如下所述的附图考虑以下对优选实施例和所附权利要求的详细描述,将更好地理解本发明的这些和其他特征、目的和优点:
附图说明
图1是本发明实施方式的文件布局推理系统的高级架构图。
图2A是本发明实施方式的基本oracle的操作图。
图2B是本发明实施方式的常规oracle的操作图。
图2C是本发明实施方式的文件布局推理系统的oracle子系统内的三个等级的oracle之间的相互关系的高级概述。
图2D提供了本发明实施方式的文件布局推理系统的三种类型的oracle的例子。
图3A是本发明实施方式的文件布局推理系统的字段位置子系统的分隔列分析部分的详细架构图。
图3B是本发明实施方式的文件布局推理系统的字段位置子系统的固定长度列分析部分的详细架构图。
图3C是本发明实施方式的字符位置的示例直方图。
图3D是本发明实施方式的示例性字符映射。
图4是本发明实施方式的文件布局推理系统的最终字段数据类型识别子系统的进程的详细架构图。
图5是本发明实施方式的硬件系统的示意图。
具体实施方式
在进一步详细描述本发明之前,应该理解的是,本发明不限于所描述的特定实施例和实施方式,并且用于描述特定实施例和实施方式的术语仅出于描述那些特定实施方式和实施方式的目的,并且不旨在限制,因为本发明的范围将仅由权利要求限制。
参考图1,现在可以描述本发明实施方式的文件布局推理系统的总体架构设计。给定输入文件记录10的适当样本,补充信息处理12包括确定在文件编码中使用的字符集以及文件是否看起来包含描述字段布局的前导行。
初步分析14主要侧重于记录分隔符的确定。这可以通过使用特定于可用于本发明的特定实施方式的一种或多种编程语言的一条或多条“读取线”功能来完成。对于每个这种可用的“readline”功能,该函数被调用若干次,并比较所得字符行。如果每行以相同的一个或两个字符结尾,并且行的长度没有显着差异,则分隔的记录设置为该公共结尾后缀。另一方面,如果没有这样的方法可用或者它们不符合上述标准,可以检查一组通用的“行尾”字符分隔符,以查看哪一个将文件分隔成多行。这些字符包括“换行”(LF)和“回车”(CR)字符。这些字符以及两个字符组合(如LF+CR或CR+LF)用于将文件分解为行段。根据将文件分解为一组合理的行,再次评估每个分割。选择以最佳结果分割的字符作为记录分隔符。
一旦确定记录分隔符,就确定附加的通用记录属性,例如每个记录的字符长度。这些属性为文件是否显示为可变宽度字段或固定宽度文件的分隔文件提供了强大的初始提示。如果绝大多数记录的字符长度相等,则文件具有固定宽度格式的可能性很大。在那种情况下,可以切换后续字段类型分析的顺序(即首先进行固定宽度分析)以提高处理效率并减少完成任务所需的处理周期。
一旦完成这个初步分析14,采用字段定位子系统。该子系统的定界分析部分20确定是否存在数量和所得字段类型一致的潜在字段分隔符,这将很快详细描述。如果存在这样的分隔符,则识别它并且文件准备好用于识别字段类型。如果不存在识别到的分隔符,则执行固定宽度分析22。该分析通过上述图像处理技术识别字段位置,并且在这种情况下文件再次准备好用于随后的字段类型识别进程。
字段类型识别18然后为每个识别到的字段位置收集每个非元oracle的结果。然后根据不同类型的字段的数量以及每个字段及其相邻字段的潜在字段类型的上下文来解释这些结果,如以下章节中所述。使用不同类型字段的元oracle和预期排序来确定最终解释(即,在街道名称之前不预期邮政编码)。最后,oracle子系统16包括用于字段位置分析的确认证据以及用于识别字段类型的最终决定的基础。如前所述,这个oracle子系统结构在最终决策中实现了高精度,而不需要对每个记录的字段类型进行清晰的解释。
图2A显示了每个基本oracle的总体架构设计和流程,以及图2B显示了oracle子系统中每个常规oracle的总体架构设计和流程。每种可能被识别的数据类型都有相应的oracle,它的工作是回答“指定的字段是否可能是你的数据类型?”这个问题。这是通过将来自指定字段的样本记录的实际值作为单个数据集传递给oracle来实现的。
每个oracle都是通过设置将用于识别oracle分配类型的值的框架来构造的。如图2A所示的基本oracle只在从记录集90的字段值中查找特定类型字符(例如空格、字母、数字和字母数字(基本数据类型))的存在。这是通过直接使用实现计算机编程语言特定的字符识别功能(“isNumeric”、“isAlpha”等)或由实现计算机编程语言的内置正则表达式库支持的非常简单的正则表达式来实现的。该处理在步骤92中执行。由于数据文件中的某些字段可能包含非常少量的意外字符,例如句点、撇号和连字符,因此oracle可以检查出现了多少这种意外字符。如果只有极少数这种情况,则删除字符并再次检查值,以查看修改的值字符串是否具有预期的模式。如果是这样,认为该值是匹配的,但只有在这样小的修改之后。例如,对于“数字”oracle,输入字符串“1234.536”未识别为数字值。但是,字符串中只有一个句点,在删除该字符后,生成的字符串“1234536”识别为“数字”,并进行了很小的修改。
一旦为oracle的数据类型模式检查了每个值,就会计算出附加信息。特别是,计算被识别为具有oracle的数据类型的不同值的分布,即传递给oracle的字段中的非空值的总数以及在它们被识别为具有oracle的数据类型之前需要稍作修改的值的数量。在步骤96将这些值聚合在一起,以用于字段是否为oracle的数据类型的最终决定。
识别到的不同值的分布将在稍后用于确定该字段是否实际上是枚举。例如,如果“单个字符”的基本oracle返回肯定响应,并且不同值的分布是5000个‘M’、3500个‘F’和4000个空白,对于所有字段类型的最终决定所作的努力将知道该列是枚举,并且根据该特定字段附近的字段类型,可以决定该字段代表性别值。正如后面将要提到的,区分基本类型字段是枚举的这种能力对于文件字段类型的最终决定的准确性通常是关键的。
一旦这个数据在步骤94被计算并在步骤96被聚合,oracle就在步骤98做出它的决定。如果全体非空白值的大部分识别为不需要修改的数据类型,那么oracle会将该字段识别为具有oracle的数据类型,该数据类型在步骤100处输出。如果需要修改,那么oracle会检查是否只有经过小的修改才能识别相当小的一部分值,并得出相同的结论。在所有其他情况下,oracle不会要求肯定的数据类型识别。最后,如果oracle不将该字段识别为具有其数据类型,则在步骤100处返回否定响应。另一方面,如果oracle确实以这种方式识别字段,则在步骤100处返回收所集数据的肯定响应和报告。
图2B指出了oracle子系统中每个常规oracle的整体架构设计和流程。常规oracle识别最多只有少数几个共同表示的常见和频繁出现的字段类型。这些字段类型包括电话号码、日期、名称、标准无用信息、个人标识符和地址/位置信息。然而,与基本oracle不同,这些常规oracle必须使用除正则表达式或特异于语言类型的功能之外的其他技术来识别它们的具体数据类型。例如,识别名称数据类型(例如名字、姓氏、街道名称、企业名称、城市和州)的oracle使用每种类型的有效实例的字典。如前所述,没有oracle必须在每个记录的字段中识别它的类型,因此这些字典不需要全面覆盖预期的名称,而只需要包含强大的统计范围。此外,在这种情况下,一些名称字段可以支持正则表达式增强,以查找展示指示特定类型的常见字符模式的字符串。例如,以“ville”,“ham”,“ford”或“ton”结尾的字符串,以“新”,“小”或罗盘方向开始或者包含诸如“下落”之类的景观实体的字符串具有高概率作为城市。
以类似的方式,主要数字数据(如有效的电话号码、日期和邮政编码)必须遵循特定的模式。除了字符类型的模式之外,这些数据类型的常规oracle必须检查这些模式。例如,直到最近社会保障号才被要求遵循基于地理和数字模式的特定规则。这些规则在2011年被放弃,但绝大多数人的社会保障号都遵循这些模式。由于oracle只需要识别足够数量的这些类型的值,以便正确识别这样的字段的数据类型,社会保障oracle只需要检查2011年以前的规则是否有效和准确。因此,在步骤102,将每个值拆分成组成部分并且检查组成部分的oracle数据类型模式,然后在步骤94处理进行到为每个值收集的字段间位置信息,如同基本oracle一样。
包含这些信息的数据文件的共同期望是每个这样的字段将使用单个表示。然而,情况并非总是如此,因此这些oracle考虑了对于所有记录的每个字段值的指定类型的各种各样的可能表示。例如,日期oracle必须对日期为2016年1月7日的以下潜在表示敏感:01/07/2016、01/07/16、07JAN2016、01072016、010716、1716以及其他类似的变体。这两个验证检查必须在步骤102同时进行,因为每个验证检查都直接依赖于另一个。所以如果一个潜在表示导致无效日期,那么oracle必须尝试识别另一个潜在日期形式。处理进行到聚合与每个值搜集的信息,并使用与该oracle相匹配的数据类型模式。如果没有发现导致有效日期解释的表示,则日期oracle将在步骤106中认为该值不具有其数据类型。在任一情况下,在步骤100返回真值和收集的信息,和基本oracle一样。
在例如同一个字段中的个人的名字和姓氏或地址号码和街道名称出现在同一字段中的情况下,即使在该字段中还有其他数据,常规oracle也必须识别字段是否像是包含其类型的数据。在这些情况下,oracle可以在这些字段中记录它们的数据类型实例的位置。例如,如果字段包含两个或更多名称组成部分(例如“JOHN SMITH”)的许多实例,则“名字”oracle将需要通过用空格分隔全部数据字符串,即“JOHN”和“SMITH”,来分析检索到的每个名称组成部分。该oracle会记录名字组成部分是“名字”,但第二个组成部分不是“名字”。类似地,“姓氏”组成部分会报告适当的相反信息。在字段数据类型的最终决策中,分析值的字符串表示中每个组成部分的能力至关重要。因此,常规oracle的第一步是在步骤102将每个值分割成其空格分隔的组成部分。然后,oracle像之前的基本oracle一样工作,确定每个组成部分是否为oracle的类型。如果字段值中只有一个组成部分,它的执行方式与上述基本oracle相同。另一方面,如果存在多于一个组成部分,则至少一个组成部分必须识别为oracle的数据类型,以便oracle在步骤100传递其收集的信息。如果字段值中至少有一个组成部分识别为oracle的数据类型,则会收集与基本oracle中相同类型的信息。但是,必须添加额外的上下文信息才能正确解释值的字符串中的信息类型。该信息由在步骤104中确定的值的字符串中的组成部分的数量以及它们中的哪些已被识别为oracle的数据类型构成。因此,在输入地址字符串“123 Washington Ave”的情况下,“街道号码”oracle会报告字符串具有附加信息,即街道号码出现在三个组成部分的第一个中。相应的信息将通过“街道名称”oracle以及“街道后缀”oracle进行报告。需要重点注意的是,由于这些字符串可能包含大量的不明确性,“姓氏”oracle会报告与“街道名称”oracle相同的信息。在这种情况下,实际的oracle本身(它自己的数据类型)在后续处理发生时区分解释。
在步骤104,oracle的处理的下一个阶段类似于基本oracle的相关步骤,即识别的字符串(至少一个识别的组成部分),并且收集的信息被汇总用于决策。决策步骤再次与基本oracle的信息非常相似,但是有一个很小但非常重要的区别。特别是,不仅必须肯定识别足够的值,而且还必须有强大的主导模式,以确定哪些实际组成部分实际上是肯定识别的。例如,考虑有关地址的上述情况。如果所有值都包含两个或三个组成部分,如果大量已识别的案例对最后一个组成部分有肯定的响应,则“街道后缀”oracle只会确定该字段包含此类数据类型。类似地,如果最后一个组成部分(可能是没有街道号码的街道地址的第一个组成部分)是主要识别组成部分,则“街道名称”(可能还有“姓氏”)oracle将返回肯定识别。再次,对于基本oracle,常规oracle会返回它的决定和相关信息。如预期的那样,在步骤106,对于完整文件的数据类型布局的最终决策而言,这些oracle针对肯定识别字段报告的附加信息是关键的。
在相对于不同的字段解释而言含糊不清的情况下,基本oracle 30和常规oracle32彼此相互作用。例如,数字基本oracle 30和日期常规oracle 32可以以肯定的方式响应相同的字段。这表明此潜在日期字段的表示仅为数字(即01312016),而非使用标点符号(01/31/2016)。找到多个主要数字类型的列可能并不少见。事实上,基本oracle 30已经识别了表示的主要特征,因此可以做出更好的决策,因为将这些字段定位到其他字段类型有助于解释数字字段。在这种情况下,正确的解释只是数字字段的解释,因为它包含业务特定的信息,这些信息通常看起来是有效的日期。
如图2C所示,第三(或元)等级的oracle 34试图取得先前等级结果的输出,并确定相邻的字段是否构成更复杂的数据类型,例如全名或完整地址。它考虑具有形成这些较大数据类型的可能解释的连续字段序列的结果。这可以通过表3中给出的示例数据来解释。
Oracles GEORGE WASHINGTON CARVER
名字
中间名
姓氏
城市
表3
例如,考虑在上面显示的连续字段中出现的名称“GEORGE WASHINGTON CARVER”。第一个字段收到来自名字oracle和中间名oracle的肯定响应;下一个第二个字段收到来自名字、中间名和姓氏以及城市名称oracle的肯定响应;而第三个字段则收到来自姓氏oracle的肯定响应。在这种情况下,三个字段的顺序解释是名字、中间名和姓氏。名称元-oracle 34将会为这个连续字段序列筛选所有识别数据类型的组合,以试图找到匹配全名表示的模式(在这种情况下,名字、中间名、姓氏组合)。因此,对于这种情况,全名元-oracle将返回肯定的识别。
图2D提供了表40中的一组基本oracle 30、常规oracle 32和元oracle 34的简化示例。所呈现的基本oracle 30是在某些业务数据文件中最常见的oracle。有时候这些oracle必须扩展到包含特定标点符号的模式。常规oracle 32允许识别名称和地址组成部分、若干特定标识符、标准匿名无用信息值、IP地址、地理位置、社交处理、电话号码和性别。此列表可以通过车辆识别号码、一般库存代码和若干二进制枚举(是/否、真/假、有效/无效)等其他值进行扩充。在大多数业务数据文件中发现的两个识别的元-oracle 34,即全名和完整地址是最常见的。
图3A更详细地示出来自图1的分隔列分析20。该进程首先确定输入数据文件10是否具有(可变长度)分隔字段,并且如果是,则确定文件的特定字段分隔符。第一步是在步骤50中计算出现在文件的样本记录中的非数字和非字母字符的频率。通常最常出现的这种字符是文件的分隔符,但不能保证。一旦计算了该初始频率分布,在步骤52中使用每个适当的分隔符候选计算所得字段的数量,并且在步骤54中通过字段数量和记录数量总结这些列计数。在步骤56将具有相对较低汇总计数的分隔符过滤掉。此时,所有样本记录中保留的唯一分隔符是一致的。为了确定最终分隔符,在这些分隔符的相关字段集上调用来自图2C的oracle子系统的基本和常规oracle 30/32,并且在步骤58收集结果。分隔符按照oracle子系统识别的字段数量和总记录覆盖率进行排序,并且在步骤60中选择最终分隔符。
图3B更详细地示出来自图1的固定宽度列分析22。由该图表示的固定宽度列分析尝试计算字段的固定宽度位置,以防文件中未识别字段分隔符。第一步是在步骤70识别由于列的填充空格而明显的字段边界。如图3B所示,在该步骤中为样本记录计算空格直方图,如图3C所示。这是通过对每个样本记录中的每个字符位置计算非空白字符在该位置的次数来完成的。图中的直方图是条形图,其中每个位置的灰色条的高度表示此计数。由于这种类型的文件以相同的方式一致地填充每个字段,显示从大计数到小计数或反之亦然的剧烈变化的位置表示字段边界。图3C的空间直方图用水平轴上的圆显示了这些类型的边界。
一旦识别出这些边界,就在步骤72为采样记录计算字符映射。该映射通过指示基本字符类型的颜色或阴影像素对每个字符进行编码。图3D提供了示例。对于本图中给定的字符类型,白色表示空格,黑色表示字母字符,深灰色表示数字字符,浅灰色表示标点符号。该图像具有很强的表现力,因为它通过颜色的规律性和模式清楚地描述了具有不同数据类型的字段。对于图示的示例,很明显,第一个字段是名字,第二个是中间名,第三个是姓氏。下一个字段是一个完整的街道地址字段,其中包含地址编号、街道名称和二级单元指示符(公寓编号)。地址“123 Main St.”是适合这种模式的地址的示例。下一个字段显示为城市,随后的小字符字段为州的缩写。邮政编码毫无疑问接下来会出现,但是其他字段的解释需要额外的上下文。右侧的一列显示的另一种模式是电话号码,可以确定它的电话号码,因为它由七个数字字符组成。由于并非所有的列边界都可以基于空间直方图来识别,这对于相邻的数字列类型来说特别困难,所以根据字符是空格、字母、数字还是标点符号类型字符,可以对每个字符位置进行每个字符类型的计数。
字符映射的表达性不仅在识别字段位置方面发挥核心作用,而且还可以基于许多字段的常见使用顺序,用作许多数据类型的可视指示。在步骤74用这两个映射标识字段(列)位置,并且在步骤76再次调用oracle子系统(使用基本oracle 30和常规oracle 32)以帮助验证列位置。但是,有时某些字段中的样本记录的条目很少。因此,如果所得分析中存在充分的歧义,则可以使用更大的样本重新评估文件的字段位置和类型。
如上参考图1所述,一旦字段的位置已被识别,负责文件的字段和数据类型的最终识别的第三子系统继续将文件中的每个字段的数据类型识别为列类型标识18。作为第一步,调用oracle子系统16(来自图1),并且每个基本oracle 30和常规oracle 32借助先前提到的识别技术分析和返回每个识别字段的响应,这些分别在步骤80和82中执行。如前所述,不同的oracle可以为相同字段返回肯定响应,并且这经常发生,因为在个人、商业、街道和城市名称中使用了大量常见单词。针对每个字段,从每个字段的这些oracle(先前提到的值频率分布、相同字段中的实例数量、其数据值符合oracle的识别标准的记录数量以及位置信息)中收集响应和支持数据,为后续分析做准备。每个字段记录这两组结果,用于即将到来的分析。
一旦收集了上述数据,就在步骤84中使用元-oracle 34来确定是否存在构成单个大数据类型的相邻字段,例如全名或完整地址。这些大数据类型中的每一种都具有基本的构造模式。例如,全名数据类型由一些相邻的字母“名称”数据类型形成。可能只有一个字段放置了全名,通常最多可以有五个连续的字段来保存全名(名称标题/前缀、名字、中间名、姓氏和姓名后缀)。完整地址字段也可以由一个或多个连续字段组成,具有字母、数字和字母数字字段类型的混合。因此,每个元-oracle 34不需要考虑每个可能的字段序列,而是首先寻找包含多个值的单个字段,其序列在其大数据类型内是一致的。然后,oracle可以识别数据类型组合形成oracle的大数据类型(例如,数字字段和街道名称字段)的子模式的连续字段对。一旦找到这样的候选项,元-oracle 34搜索相邻的字段以查看候选字段和新字段的报告数据类型的组合是否与oracle的数据类型一致,并且如果是,则将这些新字段添加到候选集。这个进程一直持续到没有以一致的方式添加新字段,或者已经找到了一整组形成数据类型的字段。这个进程在整个不包含在任何候选集中的一组字段中继续。在两个候选项之间潜在的字段重叠的情况下,如果较早的组不是oracle的数据类型的完整实例,则可以从较早的一组字段中移除重叠字段,并将其添加到当前的勘探(prospecting)字段中。正如前面举例说明的那样,字段通常有多个肯定的响应,可能会产生一定程度的不确定性。因此,元-oracle 34必须查看潜在的字段序列并确定这些多个响应是否可以拼凑在一起以形成有效的元类型。在所有候选集已识别之后,形成相关数据类型的完整实例的那些将由元-oracle识别。
一旦识别出任何这样的元类型,就在步骤18中确定剩余的字段类型。该确定基于为顺序解释有效的最大数量的字段选择数据类型。所选字段类型的排序的有效性基于数据类型的高度一致和通用的关系模式。所使用的关系模式包括:假设一系列个人的名称字段不包含任何形式的数字数据类型的字段。此外,还包括在与例如是城市名称或街道名称等其他标准地址数据类型不相邻的字段中找不到地址组成部分(如州缩写和邮政编码)的规则。另一个假设是,绝大多数文件中通常不会有两个以上的日期字段,并且如果有两个这样的字段,它们通常是相邻的或在彼此的很少几个字段内。为了说明,在表4中提供示例数据。
名字
姓氏
字母
数字
电话
企业名称
表4
在表4的示例中,由于数字的第二个字段,全名元-oracle 34不会将四个字段分组为全名。最后两个字段确实形成全名数据类型的变体(全名元-oracle 34将如此识别)。第一个字段不会被识别为名字字段,因为在这种数据文件中隔离名字是不常见的。由于第二个字段可能是电话号码,第一个字段也是预期的企业名称,因此按照这些类型来识别这两个字段中的每一个,遵循业务数据文件布局的常见做法。另一方面,如果第一个字段未识别为潜在企业名称,而另一个字段已识别为电话号码,则第二个字段将识别为数字字段。一种类型的字母或数字字段对于几种高度不同的字段类型具有强模式并不罕见(所有数字日期和识别代码都是常见实例)。因此,重要的是,同时具有基本和常规oracle来解释这些字段,以便正确选择适当的特定或通用数据类型。
一旦以这种方式处理了所有的字段,并且在给定基本类型的情况下似乎有太多的字段,则可以进行字段的第二次传递,意在进行小的调整以减少这种基本类型的字段的数量同时保持顺序模式的一致性。这是通过重新考虑具有多种潜在候选数据类型的字段并提供有力证据来完成的。如果其中任何一个与具有分配的基本数据类型的字段相邻,则将替换每个这样的有力候选,以查看是否可以将基本数据类型字段调整为常规数据类型,同时保持所得字段的解释的一致性。
图5表示如本领域中当前执行的手动系统与本发明的具体实施方式之间确定数据文件布局的时间的比较。这些被表示的时间是从样本记录的最初分析到最终列数据类型的最终确定和输出。本发明的该实例在用4个CPU和16GB的RAM运行RedHatEnterpriseServer6.7的单个Linux x86_64处理器机器上实现。所有子系统的实现代码都是用Python 3.4.2编写的。已安装Web服务的Flask微框架实例(BSD许可证-http://flask.pocoo.org/),生成的REST API允许任何位置的任何用户访问该系统。每个文件的数据都通过POST命令从用户传递到系统。最终结果通过API通过JSON结构返回给用户。
最大的时间复杂性在于一旦基本和常规oracle报告了它们对每列的发现后,列数据类型的最终分析。随着列数的增加,潜在列解释组合的数量呈指数增长。对于少量的总列数,例如5列或更少,识别布局的时间少于2秒。对于具有100到200列的文件,布局在1到2分钟之间的时间内确定。
此实例的一个特定批处理包含63个不同的数据文件,其中包含分隔和固定宽度布局以及各种数量的列。总共有1000多列。完整处理这些文件的时间为25分钟,包括数据下载到服务的时间。
除非另有说明,否则本文使用的所有技术和科学术语具有与本发明所属领域的普通技术人员通常理解的相同的含义。本文描述了有限数量的示例性方法和材料,尽管在本发明的实践或测试中也可以使用与本文所述的那些相似或等同的任何方法和材料。对于本领域技术人员而言显而易见的是,在不脱离本文的发明构思的情况下可以做出更多的修改。
本文中使用的所有术语应以与上下文一致的最宽泛的可能方式来解释。当本文使用分组时,该组中的所有个体成员以及该组可能的所有组合和子组合都打算被分别包括在内。当本文规定范围时,该范围旨在包括该范围内的所有子范围和单个点。本文引用的所有参考文献均以与本说明书的公开内容不存在不一致的程度通过引用并入本文。
已经参考了某些优选和替代实施例描述了本发明,这些实施例仅仅是示例性的,并不限制如所附权利要求中所阐述的本发明的全部范围。

Claims (26)

1.一种用于从包括多个记录的数据文件推断文件布局的方法,每个记录包括多个字段,所述方法步骤包括:
a.在推理引擎中接收数据文件;
b.对数据文件执行初步分析,其中初步分析包括确定数据文件是字段分隔文件还是固定宽度字段文件的步骤;
c.如果确定数据文件是字段分隔文件,则对数据文件执行分隔分析;
d.如果确定数据文件是固定宽度字段文件,则对数据文件执行固定宽度分析;
e.将列类型标识应用于数据文件,其中将列类型标识应用于字段文件的步骤包括以下步骤:将至少一个基本oracle、至少一个常规oracle和至少一个元oracle应用于数据文件;以及
f.输出数据文件的最终列类型信息。
2.根据权利要求1所述的方法,其中所述至少一个基本oracle包括阿尔法oracle、字母数字oracle、空白oracle、数字oracle或数值oracle中的一个或多个。
3.根据权利要求2所述的方法,其中所述至少一个基本oracle包括阿尔法oracle、字母数字oracle、空白oracle、数字oracle和数值oracle中的每一个。
4.根据权利要求2所述的方法,其中所述至少一个常规oracle包括地址链接oracle、消费者链接oracle、文档标识符oracle、企业名称oracle、城市oracle、国家oracle、国家oracle、日期oracle、域oracle、电子邮件oracle、名字oracle或性别oracle中的一个或多个。
5.根据权利要求4所述的方法,其中所述至少一个常规oracle包括地址链接oracle、消费者链接oracle、文档标识符oracle、企业名称oracle、城市oracle、国家oracle、国家oracle、日期oracle、域oracle、电子邮件oracle、名字oracle和性别oracle中的每一个。
6.根据权利要求2所述的方法,其中所述至少一个元oracle包括完整地址oracle或全名oracle中的一个或多个。
7.根据权利要求6所述的方法,其中所述至少一个元oracle包括完整地址oracle和全名oracle中的每一个。
8.根据权利要求1所述的方法,其中对文件执行分隔分析的步骤包括以下步骤:
a.计算非数字非字母字符的初始频率表;
b.使用来自一组可能的分隔符的试验分隔符对数据文件中每一行的列数进行计数;
c.通过字段和行的数量总结列计数;
d.筛选出低总结计数;
e.使用一个或多个基本oracle或字段oracle来排列字段计数;以及
f.输出最终的分隔决定。
9.根据权利要求1所述的方法,其中对文件执行固定宽度分析的步骤包括以下步骤:
a.在数据文件上创建空间直方图;
b.在数据文件上创建字符映射;
c.使用一个或多个空间直方图和字符映射将列提取映射到数据文件上;以及
d.输出最终的固定宽度决定。
10.根据权利要求1所述的方法,其中将列类型标识应用于数据文件的步骤包括以下步骤:
a.使用至少一个基本oracle,对数据文件中的有效值进行计数;
b.使用至少一个常规oracle,对数据文件中的有效值进行计数;
c.在使用至少一个基本oracle和至少一个常规oracle的数据文件中计数有效值的步骤之后,使用至少一个元oracle来计算初始列类型;
d.如果还有任意剩余的未知列类型,则应用一个或多个常规oracle或基本oracle信息;
e.输出最终类型确定。
11.根据权利要求1所述的方法,其中将列类型标识应用于数据文件的步骤包括分析数据文件中至少一万条记录中的每个字段的内容。
12.根据权利要求1所述的方法,其中将列类型标识应用于所述数据文件的步骤包括分析所述数据文件中的至少十万个记录中的每个字段的内容。
13.根据权利要求1所述的方法,其中将列类型标识应用于数据文件的步骤包括分析数据文件中至少一百万条记录中的每个字段的内容。
14.根据权利要求1所述的方法,其中将至少一个基本oracle、至少一个常规oracle和至少一个元oracle应用于数据文件的步骤包括以下步骤:使用不同的oracle对数据文件中每个字段的预期数据类型做出多个潜在的易错决定,并且进一步包括以下步骤:结合多个可能易错的决策的结果来就数据文件中每个字段的预期数据类型作出最佳选择。
15.一种用于从包括多个记录的数据文件推断文件布局的系统,所述多个记录各自包括多个字段,所述系统包括:
a.多个基本oracle,其中每个基本oracle可操作以确定在多个字段中的至少一个中存在特定类型的字符或多个字符;
b.多个常规oracle,其中每个常规oracle可操作以识别在多个字段中的至少一个中最多具有少数共同表示的共同和频繁出现的字段类型;
c.多个元oracle,其中每个元oracle可操作,以使用相邻字段中的任一个或两个字段以及在多个记录中的每一个中的字段相对于彼此的位置来识别多个字段中的至少一个字段中的复杂数据类型;以及
d.oracle分析子系统,其可操作以将基本oracle、常规oracle和元oracle应用于数据文件中的多个记录的至少一个子集,以确定数据文件的文件布局。
16.根据权利要求15所述的系统,其中多个基本oracle中的至少一个包括字母oracle、数字oracle、字母数字oracle、数字oracle或空白oracle。
17.根据权利要求16所述的系统,其中多个常规oracle中的至少一个包括地址链接oracle、消费者链接oracle、文档标识符oracle、企业名称oracle、城市oracle、国家oracle、日期oracle、域oracle、电子邮件oracle、名字oracle、姓氏oracle或性别oracle。
18.根据权利要求17所述的系统,其中多个元oracle中的至少一个包括完整地址oracle或全名oracle。
19.根据权利要求18所述的系统,其中oracle分析子系统进一步可操作以接收来自基本oracle、常规oracle和元oracle的多个可能易错的重叠决定,以及基于来自基本oracle、常规oracle和元oracle的重叠决定,从多个可能的解释中为字段类型和字段位置中的至少一个选择最佳选择。
20.根据权利要求19所述的系统,其中对于多个字段中的至少一个字段,基本oracle可操作以返回真实发现,并且常规oracle可操作以返回对于相同字段的真实发现,以及其中oracle分析子系统可操作来在基本oracle发现之上选择常规oracle,由此来确定字段类型。
21.一种用于从包括多个记录的数据文件推断文件布局的方法,每个记录包括多个字段,所述方法步骤包括:
a.使用数据文件中记录的至少一个子集,确定多个字段中的至少一个字段中特定类型的字符或多个字符的任何存在;
b.使用数据文件中记录的至少一个子集,识别在多个字段中的至少一个字段中最多具有少数共同表示的任何共同或频繁出现的字段类型;
c.使用数据文件中记录的至少一个子集,使用相邻字段中的任一个或两个以及字段相对于彼此的位置来识别多个字段中的至少一个字段中的任何复杂数据类型;以及
d.应用步骤(a)-(c)的结果来确定数据文件的文件布局。
22.根据权利要求21所述的方法,进一步包括确定数据文件是字段分隔文件还是固定宽度字段文件的步骤。
23.根据权利要求22所述的方法,进一步包括以下步骤:如果确定数据文件为字段分隔文件,则对数据文件执行分隔分析,或者如果确定数据文件为固定宽度字段文件,则对数据文件执行固定宽度分析。
24.根据权利要求23所述的方法,其中对文件执行分隔分析的步骤包括以下步骤:
a.计算非数字非字母字符的初始频率表;
b.使用来自一组可能的分隔符的试验分隔符对数据文件中每一行的列数进行计数;
c.通过字段和行的数量总结列计数;
d.筛选出低总结计数;
e.排列字段计数。
25.根据权利要求24所述的方法,其中对文件执行固定宽度分析的步骤包括以下步骤:
a.在数据文件上创建空间直方图或字符映射中的一者或两者;以及
b.使用空间直方图或字符映射中的一者或两者将列提取映射到数据文件上。
26.根据权利要求25所述的方法,其中应用权利要求25中的步骤(a)-(c)的结果来确定数据文件的文件布局的步骤包括以下步骤:
a.对于数据文件中每个字段的预期数据类型做出多个潜在的易错决定;以及
b.结合多个可能易错的决策的结果来就数据文件中每个字段的预期数据类型作出最佳选择。
CN201680066594.3A 2015-10-30 2016-10-28 用于结构化多字段文件布局的自动化解释 Active CN108351898B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562248619P 2015-10-30 2015-10-30
US62/248,619 2015-10-30
PCT/US2016/059378 WO2017075392A1 (en) 2015-10-30 2016-10-28 Automated interpretation for the layout of structured multi-field files

Publications (2)

Publication Number Publication Date
CN108351898A true CN108351898A (zh) 2018-07-31
CN108351898B CN108351898B (zh) 2021-10-08

Family

ID=58631927

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201680066594.3A Active CN108351898B (zh) 2015-10-30 2016-10-28 用于结构化多字段文件布局的自动化解释

Country Status (6)

Country Link
US (1) US10838919B2 (zh)
EP (1) EP3369013A4 (zh)
JP (1) JP6893209B2 (zh)
CN (1) CN108351898B (zh)
HK (1) HK1251055A1 (zh)
WO (1) WO2017075392A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110569329A (zh) * 2019-10-28 2019-12-13 深圳市商汤科技有限公司 数据处理方法及装置、电子设备和存储介质
CN110851520A (zh) * 2019-11-19 2020-02-28 中国银行股份有限公司 数据加载方法及系统
CN111414330A (zh) * 2019-01-04 2020-07-14 阿里巴巴集团控股有限公司 数据编辑方法及系统、数据处理设备、存储介质
CN113806401A (zh) * 2020-06-12 2021-12-17 甲骨文国际公司 数据流处理
CN117827991A (zh) * 2024-03-06 2024-04-05 南湖实验室 一种半结构化数据中个人标识信息识别方法与系统

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10055732B1 (en) 2013-03-29 2018-08-21 Wells Fargo Bank, N.A. User and entity authentication through an information storage and communication system
US10037561B1 (en) 2013-03-29 2018-07-31 Wells Fargo Bank, N.A. Systems and methods for managing lists using an information storage and communication system
US10530646B1 (en) 2013-03-29 2020-01-07 Wells Fargo Bank, N.A. Systems and methods for providing user preferences for a connected device
US10387928B1 (en) 2013-03-29 2019-08-20 Wells Fargo Bank, N.A. Systems and methods for transferring a gift using an information storage and communication system
US10204119B1 (en) * 2017-07-20 2019-02-12 Palantir Technologies, Inc. Inferring a dataset schema from input files
US10942959B1 (en) 2018-02-06 2021-03-09 Wells Fargo Bank, N.A. Authenticated form completion using data from a networked data repository
CN111159497B (zh) * 2019-12-31 2023-09-22 奇安信科技集团股份有限公司 正则表达式的生成方法及基于正则表达式的数据提取方法
CN111382128A (zh) * 2020-03-20 2020-07-07 中国邮政储蓄银行股份有限公司 一种文件的拆分方法、装置及计算机系统
US11410186B2 (en) * 2020-05-14 2022-08-09 Sap Se Automated support for interpretation of terms
US11461301B2 (en) * 2020-09-13 2022-10-04 International Business Machines Corporation Database index optimization
CN113095064A (zh) * 2021-03-18 2021-07-09 杭州数梦工场科技有限公司 代码字段识别方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778359A (en) * 1996-04-18 1998-07-07 Davox Corporation System and method for determining and verifying a file record format based upon file characteristics
US20090300054A1 (en) * 2008-05-29 2009-12-03 Kathleen Fisher System for inferring data structures
US20110055252A1 (en) * 2003-03-28 2011-03-03 Dun & Bradstreet, Inc. System and method for data cleansing
US20140172886A1 (en) * 2010-07-23 2014-06-19 Oracle International Corporation System and method for conversion of jms message data into database transactions for application to multiple heterogeneous databases

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01205260A (ja) 1988-02-12 1989-08-17 Toshiba Corp 文書整形装置
ES2083178T3 (es) 1991-04-24 1996-04-01 Michael Sussman Amplificador digital de documentos.
US6094684A (en) * 1997-04-02 2000-07-25 Alpha Microsystems, Inc. Method and apparatus for data communication
US6981028B1 (en) 2000-04-28 2005-12-27 Obongo, Inc. Method and system of implementing recorded data for automating internet interactions
US7225199B1 (en) * 2000-06-26 2007-05-29 Silver Creek Systems, Inc. Normalizing and classifying locale-specific information
US7111075B2 (en) * 2000-12-18 2006-09-19 Microsoft Corporation Method and system for processing data records having multiple formats
US6493858B2 (en) * 2001-03-23 2002-12-10 The Board Of Trustees Of The Leland Stanford Jr. University Method and system for displaying VLSI layout data
US7185017B1 (en) * 2002-04-10 2007-02-27 Compuware Corporation System and method for selectively processing data sub-segments using a data mask
US7305129B2 (en) 2003-01-29 2007-12-04 Microsoft Corporation Methods and apparatus for populating electronic forms from scanned documents
US7305612B2 (en) 2003-03-31 2007-12-04 Siemens Corporate Research, Inc. Systems and methods for automatic form segmentation for raster-based passive electronic documents
US20060242180A1 (en) 2003-07-23 2006-10-26 Graf James A Extracting data from semi-structured text documents
CN102982065B (zh) * 2003-09-15 2016-09-21 起元科技有限公司 数据处理方法、数据处理装置及计算机可读存储介质
US7599952B2 (en) * 2004-09-09 2009-10-06 Microsoft Corporation System and method for parsing unstructured data into structured data
US8176054B2 (en) * 2007-07-12 2012-05-08 Ricoh Co. Ltd Retrieving electronic documents by converting them to synthetic text
US8135814B2 (en) * 2005-06-29 2012-03-13 At&T Intellectual Property I, L.P. Network capacity management system
US7849048B2 (en) * 2005-07-05 2010-12-07 Clarabridge, Inc. System and method of making unstructured data available to structured data analysis tools
US8078551B2 (en) 2005-08-31 2011-12-13 Intuview Ltd. Decision-support expert system and methods for real-time exploitation of documents in non-english languages
US7792814B2 (en) * 2005-09-30 2010-09-07 Sap, Ag Apparatus and method for parsing unstructured data
US8468244B2 (en) 2007-01-05 2013-06-18 Digital Doors, Inc. Digital information infrastructure and method for security designated data and with granular data stores
US7930322B2 (en) * 2008-05-27 2011-04-19 Microsoft Corporation Text based schema discovery and information extraction
US8489388B2 (en) * 2008-11-10 2013-07-16 Apple Inc. Data detection
US8250026B2 (en) * 2009-03-06 2012-08-21 Peoplechart Corporation Combining medical information captured in structured and unstructured data formats for use or display in a user application, interface, or view
WO2011060257A1 (en) * 2009-11-13 2011-05-19 Ab Initio Technology Llc Managing record format information
US8341096B2 (en) 2009-11-27 2012-12-25 At&T Intellectual Property I, Lp System, method and computer program product for incremental learning of system log formats
US8526743B1 (en) * 2010-11-01 2013-09-03 Raf Technology, Inc. Defined data patterns for object handling
US8619090B2 (en) * 2011-09-23 2013-12-31 The Mathworks, Inc. Text import tool for a technical computing environment
EP2570974B1 (en) * 2011-09-13 2018-11-28 ExB Asset Management GmbH Automatic crowd sourcing for machine learning in information extraction
JP5838871B2 (ja) * 2012-03-14 2016-01-06 富士通株式会社 データ解析装置、データ分割装置、データ解析方法、データ分割方法、データ解析プログラム、及びデータ分割プログラム
US10146845B2 (en) * 2012-10-23 2018-12-04 Ip Reservoir, Llc Method and apparatus for accelerated format translation of data in a delimited data format
US9244903B2 (en) * 2013-04-15 2016-01-26 Vmware, Inc. Efficient data pattern matching
US10157353B2 (en) * 2013-09-12 2018-12-18 Acxiom Corporation Name variant extraction from individual handle identifiers
US9846567B2 (en) * 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US9483477B2 (en) * 2015-01-19 2016-11-01 Sas Institute Inc. Automated data intake system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778359A (en) * 1996-04-18 1998-07-07 Davox Corporation System and method for determining and verifying a file record format based upon file characteristics
US20110055252A1 (en) * 2003-03-28 2011-03-03 Dun & Bradstreet, Inc. System and method for data cleansing
US20090300054A1 (en) * 2008-05-29 2009-12-03 Kathleen Fisher System for inferring data structures
US20140172886A1 (en) * 2010-07-23 2014-06-19 Oracle International Corporation System and method for conversion of jms message data into database transactions for application to multiple heterogeneous databases

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111414330A (zh) * 2019-01-04 2020-07-14 阿里巴巴集团控股有限公司 数据编辑方法及系统、数据处理设备、存储介质
CN111414330B (zh) * 2019-01-04 2024-03-22 阿里巴巴集团控股有限公司 数据编辑方法及系统、数据处理设备、存储介质
CN110569329A (zh) * 2019-10-28 2019-12-13 深圳市商汤科技有限公司 数据处理方法及装置、电子设备和存储介质
CN110569329B (zh) * 2019-10-28 2022-08-02 深圳市商汤科技有限公司 数据处理方法及装置、电子设备和存储介质
CN110851520A (zh) * 2019-11-19 2020-02-28 中国银行股份有限公司 数据加载方法及系统
CN113806401A (zh) * 2020-06-12 2021-12-17 甲骨文国际公司 数据流处理
CN117827991A (zh) * 2024-03-06 2024-04-05 南湖实验室 一种半结构化数据中个人标识信息识别方法与系统
CN117827991B (zh) * 2024-03-06 2024-05-31 南湖实验室 一种半结构化数据中个人标识信息识别方法与系统

Also Published As

Publication number Publication date
US10838919B2 (en) 2020-11-17
EP3369013A4 (en) 2019-04-10
US20180314711A1 (en) 2018-11-01
JP6893209B2 (ja) 2021-06-23
CN108351898B (zh) 2021-10-08
EP3369013A1 (en) 2018-09-05
WO2017075392A1 (en) 2017-05-04
JP2019502979A (ja) 2019-01-31
HK1251055A1 (zh) 2019-01-18

Similar Documents

Publication Publication Date Title
CN108351898A (zh) 用于结构化多字段文件布局的自动化解释
AU2020250205B2 (en) Characterizing data sources in a data storage system
CN112639845B (zh) 确定个人信息查找结果可信度的机器学习系统和方法
CN110383319B (zh) 大规模异构数据摄取和用户解析
Gu et al. Record linkage: Current practice and future directions
US20040122841A1 (en) Method and system for evaluating intellectual property
CN112182246B (zh) 通过大数据分析建立企业画像的方法、系统、介质及应用
US20210366055A1 (en) Systems and methods for generating accurate transaction data and manipulation
JPWO2006115260A1 (ja) 情報解析報告書自動作成装置、情報解析報告書自動作成プログラムおよび情報解析報告書自動作成方法
Fu et al. Automatic record linkage of individuals and households in historical census data
Pit-Claudel et al. Outlier detection in heterogeneous datasets using automatic tuple expansion
CN116384889A (zh) 基于自然语言处理技术的情报大数据智能分析方法
Aria et al. Package ‘bibliometrix’
CN113486983A (zh) 一种用于反欺诈处理的大数据办公信息分析方法及系统
Bicevskis et al. Data quality evaluation: a comparative analysis of company registers' open data in four European countries.
EP1251435A2 (en) Knowledge database and method for constructing and merging knowledge database
WO2014084141A1 (ja) 文書管理システムおよび文書管理方法並びに文書管理プログラム
CN106126523A (zh) 一种假币犯罪信息分析系统及分析方法
CN116340387A (zh) 一种用于数据表的个人信息披露情况统计分析方法及系统
Jabeen et al. Divided we stand out! Forging Cohorts fOr Numeric Outlier Detection in large scale knowledge graphs (CONOD)
Awad et al. An interactive tool for extracting low-quality spreadsheet tables and converting into relational database
Han et al. A neotropical Miocene pollen database employing image‐based search and semantic modeling
Hood et al. Indexing terms in the LISA database on CD-ROM
Kempf et al. KIETA: Key-insight extraction from scientific tables
Wei et al. A feature extracting and matching system based on magic-number and AC-algorithm

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
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1251055

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant