import jieba
import gensim
from gensim import corpora
from gensim.matutils import corpus2dense

f = open("背影.txt", "r+")   #选取文档为中文的《背影》，将文档放在当前目录下
text1 = f.readlines()        #读取文件，按行读取，存入列表
read = text1
#text1 = f.read()            #直接全部读取，是一个字符串
#text1.splitlines()          #按照 /n 切分
f.close()
f = open("stop_words.txt", "r+", encoding="GBK") #读取停用词，网上随便下载即可，注意编码方式
text2 = f.read()
stop_word = text2.splitlines()
text = []
for i in range(len(read)):                       #逐行读取   
    seg_useful = []
    segs = jieba.cut(read[i])                    #结巴分词，注意结巴分词只能针对字符串，无法处理列表
    for seg in segs:
        if seg not in stop_word:                 #删除停用词
            seg_useful.append(seg)
    text.append(seg_useful)                      #收集有用的词

dictionary = corpora.Dictionary(text)            #建立字典
word_count = [dictionary.doc2bow(text[i]) for i in range(len(text))]    #建立文档-词项矩阵

dtm_matrix = corpus2dense(word_count, len(dictionary))   
dtm_matrix.T

from gensim import models
print(len(word_count))
tfidf_model = models.TfidfModel(word_count)     #建立tfidf模型
tfidf = tfidf_model[word_count]
print(tfidf)
tfidf_matrix = corpus2dense(tfidf, len(dictionary))
tfidf_matrix

model = gensim.models.Word2Vec(text, size=100, window=5, min_count=2)    #训练词向量
model.wv[u'月台']
因为库函数可能会更新，导致部分函数无法使用，所以使用时请注意时间，现在是2018/3/29

 
 
 
 
视频结构化是一种将视频内容中的重要信息进行结构化提取的技术，利用它对视频内容按照语义关系，采用时空分割、特征提取、对象识别、深度学习等处理手段，组织成可供计算机和人理解的文本信息或可视化图形信息。在实际应用中，文本信息可进一步转化为公安实战所用的情报，实现视频数据向有效情报的一次转化。
 
视频数据结构化从多个维度优化现有的安防业务，将原本许多数量庞大、响应龟速、且大多没有应用价值的监控视频进行精缩，变为更易查找、占存更小且可被深度挖掘的高密度数据。
 
结构化的视频数据可极大提升搜索和排查效率。实验结果显示，视频结构化之后，从百万级的目标库中(对应数百到一千小时的高清视频)查找某张截图上的行人嫌疑目标，数秒即可完成;千万级目标的库中查找，几分钟即可完成(如果实现云化，速度会更快)。因此在公安实战业务中，基于结构化的视频大数据检索，可以有效解决大海捞针的难题。
 
此外，结构化视频数据的存储占比可以极大的降低。经过结构化后的视频，存储人的结构化检索信息和目标数据不到视频数据量的2%; 对于车辆，不到1%;对于行为降得更多。存储容量极大地降低，可以解决视频长期占用存储空间的问题。
 
最后，视频结构化还可以盘活视频数据，成为公安系统数据挖掘基础。视频经过智能化的处理、分类后，存入相应的结构化数据仓库，如人脸照片数据库、人脸特征数据库、行为图片及特征库、车辆图像及特征库等等，而综合这些数据仓库以及关联视频片段仓库可以建立相应的检索引擎，实现对各类的数据仓库的深度信息挖掘，充分发挥大数据作用，提升视频数据的应用价值，提高视频数据的分析和预测功能。
 

 
明景视频数据结构化系统采用目标检测、对象识别、深度学习等分析手段提取视频图像中的目标对象及运动轨迹；对目标对象进行分类为人、车、人骑车、行为、事件等不同类别；进一步提取目标的高层结构化属性特征包括目标颜色特征，分类特征，速度特征等，并把目标的轨迹信息以及高层特征形成高效的索引数据进行结构化检索。
 
 

结构化数据
 
** 
 结构化数据可以使用关系型数据库来表示和存储，如MySQL、Oracle、SQL Server等，表现二维形式的数据。可以通过固有键值获取相应信息。一般特点是：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。结构化的数据的存储和排列是很有规律的，这对查询和修改等操作很有帮助。但是，显然，它的扩展性不好（比如，我希望增加一个字段）。
 
**
 
非结构化数据
 
** 
 非结构化数据,就是没有固定结构的数据，包含全部格式的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等。一般直接整体进行存储，而且一般存储为二进制的数据格式
 
**
 
半结构化数据
 
** 
 半结构化数据可以通过灵活的键值调整获取相应信息，且数据的格式不固定，如json，同一键值下存储的信息可能是数值型的，可能是文本型的，也可能是字典或者列表。 
 半结构化数据，属于同一类实体可以有不同的属性，即使他们被组合在一起，这些属性的顺序并不重要。常见的半结构数据有XML和JSON。
 
第一个XML
 
<person>
    <name>A</name>
    <age>13</age>
    <gender>female</gender>
</person>
 
第二个XML
 
<person>
    <name>B</name>
    <gender>male</gender>
</person>
 
从上面的例子中，属性的顺序是不重要的，不同的半结构化数据的属性的个数是不一定一样的。有些人说半结构化数据是以树或者图的数据结构存储的数据，从上面的例子中，标签是树的根节点，和标签是子节点。通过这样的数据格式，可以自由地表达很多有用的信息，包括自我描述信息（元数据）。所以，半结构化数据的扩展性是很好的。
 
 
 
数据清洗
 
1       基本概念
 
数据清洗从名字上也看的出就是把“脏”的“洗掉”，指发现并纠正数据文件中可识别的错误的最后一道程序，包括检查数据一致性，处理无效值和缺失值等。
 
因为数据仓库中的数据是面向某一主题的数据的集合，这些数据从多个业务系统中抽取而来而且包含历史数据，这样就避免不了有的数据是错误数据、有的数据相互之间有冲突，这些错误的或有冲突的数据显然是我们不想要的，称为“脏数据”。
 
我们要按照一定的规则把“脏数据”“洗掉”，这就是数据清洗。而数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。数据清洗是与问卷审核不同，录入后的数据清理一般是由计算机而不是人工完成。
 
2       需要清洗数据的主要类型
 
2.1     残缺数据
 
这一类数据主要是一些应该有的信息缺失，如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类数据过滤出来，按缺失的内容分别写入不同Excel文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。
 
2.2     错误数据
 
这一类错误产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。
 
2.3     重复数据
 
对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。
 
数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要用户确认。
 
3       数据清洗的内容
 
3.1     一致性检查
 
　　一致性检查(consistency check)是根据每个变量的合理取值范围和相互关系，检查数据是否合乎要求，发现超出正常范围、逻辑上不合理或者相互矛盾的数据。例如，用1-7级量表测量的变量出现了0值，体重出现了负数，都应视为超出正常值域范围。SPSS、SAS、和Excel等计算机软件都能够根据定义的取值范围，自动识别每个超出范围的变量值。具有逻辑上不一致性的答案可能以多种形式出现：例如，许多调查对象说自己开车上班，又报告没有汽车；或者调查对象报告自己是某品牌的重度购买者和使用者，但同时又在熟悉程度量表上给了很低的分值。发现不一致时，要列出问卷序号、记录序号、变量名称、错误类别等，便于进一步核对和纠正
 
3.2     无效值和缺失值的处理
 
　　由于调查、编码和录入误差，数据中可能存在一些无效值和缺失值，需要给予适当的处理。常用的处理方法有：估算，整例删除，变量删除和成对删除。
 
　　估算(estimation)。最简单的办法就是用某个变量的样本均值、中位数或众数代替无效值和缺失值。这种办法简单，但没有充分考虑数据中已有的信息，误差可能较大。另一种办法就是根据调查对象对其他问题的答案，通过变量之间的相关分析或逻辑推论进行估计。例如，某一产品的拥有情况可能与家庭收入有关，可以根据调查对象的家庭收入推算拥有这一产品的可能性。
 
　　整例删除(casewise deletion)是剔除含有缺失值的样本。由于很多问卷都可能存在缺失值，这种做法的结果可能导致有效样本量大大减少，无法充分利用已经收集到的数据。因此，只适合关键变量缺失，或者含有无效值或缺失值的样本比重很小的情况
 
　　变量删除(variable deletion)。如果某一变量的无效值和缺失值很多，而且该变量对于所研究的问题不是特别重要，则可以考虑将该变量删除。这种做法减少了供分析用的变量数目，但没有改变样本量。
 
　　成对删除(pairwise deletion)是用一个特殊码(通常是9、99、999等)代表无效值和缺失值，同时保留数据集中的全部变量和样本。但是，在具体计算时只采用有完整答案的样本，因而不同的分析因涉及的变量不同，其有效样本量也会有所不同。这是一种保守的处理方法，最大限度地保留了数据集中的可用信息。
 
采用不同的处理方法可能对分析结果产生影响，尤其是当缺失值的出现并非随机且变量之间明显相关时。因此，在调查中应当尽量避免出现无效值和缺失值，保证数据的完整性。
 
4       数据清洗的实现方式与范围
 
4.1     数据清洗的实现方式
 
(一)   手工实现,通过人工检查,只要投入足够的人力物力财力,也能发现所有错误,但效率低下。在大数据量的情况下,几乎是不可能的。
 
(二)   通过专门编写的应用程序,这种方法能解决某个特定的问题,但不够灵活,特别是在清理过程需要反复进行(一般来说,数据清理一遍就达到要求的很少)时,导致程序复杂,清理过程变化时,工作量大。而且这种方法也没有充分利用目前数据库提供的强大数据处理能力 。
 
(三)   解决某类特定应用域的问题,如根据概率统计学原理查找数值异常的记录,对姓名、地址、邮政编码等进行清理,这是目前研究得较多的领域,也是应用最成功的一类。如商用系统: Trillinm Software , System Match Maketr 等。
 
(四)   与特定应用领域无关的数据清理,这一部分的研究主要集中在清理重复的记录上,如Data Cleanser， Data Blade Module ，Integrity 系统等。
 
　　这4种实现方法,由于后两种具有某种通用性,较大的实用性,引起了越来越多的注意。但是不管哪种方法,大致都由三个阶段组成: ①数据分析、定义错误类型; ②搜索、识别错误记录; ③修正错误。
 
　　第一阶段,尽管已有一些数据分析工具,但仍以人工分析为主。在错误类型分为两大类:单数据源与多数据源,并将它们又各分为结构级与记录级错误。这种分类非常适合于解决数据仓库中的数据清理问题。
 
　　第二阶段,有两种基本的思路用于识别错误:一种是发掘数据中存在的模式,然后利用这些模式清理数据;另一种是基于数据的,根据预定义的清理规则,查找不匹配的记录。后者用得更多。
 
　　第三阶段,某些特定领域能够根据发现的错误模式,编制程序或借助于外部标准源文件、数据字典一定程度上修正错误;对数值字段,有时能根据数理统计知识自动修正,但经常须编制复杂的程序或借助于人工干预完成。
 
　　绝大部分数据清理方案提供接口用于编制清理程序。它们一般来说包括很多耗时的排序、比较、匹配过程,且这些过程多次重复,用户必须等待较长时间。在一个交互式的数据清理方案。系统将错误检测与清理紧密结合起来,用户能通过直观的图形化界面一步步地指定清理操作,且能立即看到此时的清理结果, (仅仅在所见的数据上进行清理,所以速度很快) 不满意清理效果时还能撤销上一步的操作,最后将所有清理操作编译执行。并且这种方案对清理循环错误非常有效。
 
　　许多数据清理工具提供了描述性语言解决用户友好性,降低用户编程复杂度。如ARKTOS 方案提供了XADL 语言(一种基于预定义的DTD 的XML 语言) 、SADL 语言,在ATDX 提供了一套宏操作(来自于SQL 语句及外部函数) ,一种SQL2Like 命令语言,这些描述性语言都在一定程度上减轻了用户的编程难度,但各系统一般不具有互操作性,不能通用。
 
　　数据清理属于一个较新的研究领域,直接针对这方面的研究并不多,中文数据清理更少。现在的研究主要为解决两个问题:发现异常、清理重复记录。
 
5       数据清洗的方法
 
　　一般来说，数据清理是将数据库精简以除去重复记录，并使剩余部分转换成标准可接收格式的过程。数据清理标准模型是将数据输入到数据清理处理器，通过一系列步骤“ 清理”数据，然后以期望的格式输出清理过的数据（如上图所示）。数据清理从数据的准确性、完整性、一致性、惟一性、适时性、有效性几个方面来处理数据的丢失值、越界值、不一致代码、重复数据等问题。
 
　　数据清理一般针对具体应用，因而难以归纳统一的方法和步骤，但是根据数据不同可以给出相应的数据清理方法。
 
5.1     　解决不完整数据（即值缺失）的方法
 
　　大多数情况下，缺失的值必须手工填入（ 即手工清理）。当然，某些缺失值可以从本数据源或其它数据源推导出来，这就可以用平均值、最大值、最小值或更为复杂的概率估计代替缺失的值，从而达到清理的目的。
 
5.2     错误值的检测及解决方法
 
　　用统计分析的方法识别可能的错误值或异常值，如偏差分析、识别不遵守分布或回归方程的值，也可以用简单规则库（ 常识性规则、业务特定规则等）检查数据值，或使用不同属性间的约束、外部的数据来检测和清理数据。
 
5.3     .重复记录的检测及消除方法
 
　　数据库中属性值相同的记录被认为是重复记录，通过判断记录间的属性值是否相等来检测记录是否相等，相等的记录合并为一条记录（即合并/清除)。合并/清除是消重的基本方法。
 
5.4     不一致性（ 数据源内部及数据源之间）的检测及解决方法
 
　　从多数据源集成的数据可能有语义冲突，可定义完整性约束用于检测不一致性，也可通过分析数据发现联系，从而使得数据保持一致。目前开发的数据清理工具大致可分为三类。
 
　　数据迁移工具允许指定简单的转换规则，如：将字符串gender替换成sex。sex公司的PrismWarehouse是一个流行的工具，就属于这类。
 
　　数据清洗工具使用领域特有的知识（ 如，邮政地址）对数据作清洗。它们通常采用语法分析和模糊匹配技术完成对多数据源数据的清理。某些工具可以指明源的“ 相对清洁程度”。工具Integrity和Trillum属于这一类。
 
　　数据审计工具可以通过扫描数据发现规律和联系。因此，这类工具可以看作是数据挖掘工具的变形。
 
6       数据清洗的步骤
 
6.1     定义和确定错误的类型
 
6.1.1  数据分析
 
数据分析是数据清洗的前提与基础，通过详尽的数据分析来检测数据中的错误或不
 
一致情况，除了手动检查数据或者数据样本之外，还可以使用分析程序来获得关于数据属性的元数据，从而发现数据集中存在的质量问题。
 
6.1.2  定义清洗转换规则
 
根据上一步进行数据分析得到的结果来定义清洗转换规则与工作流。根据数据源的个数，数据源中不一致数据和“脏数据”多少的程度，需要执行大量的数据转换和清洗步骤。
 
要尽可能的为模式相关的数据清洗和转换指定一种查询和匹配语言，从而使转换代码的自动生成变成可能。
 
6.2     搜寻并识别错误的实例
 
6.2.1  自动检测属性错误
 
检测数据集中的属性错误，需要花费大量的人力、物力和时间，而且这个过程本身很容易出错，所以需要利用高的方法自动检测数据集中的属性错误，方法主要有：基于统计的方法，聚类方法，关联规则的方法。
 
6.2.2  检测重复记录的算法
 
消除重复记录可以针对两个数据集或者一个合并后的数据集，首先需要检测出标识同一个现实实体的重复记录，即匹配过程。检测重复记录的算法主要有：基本的字段匹配算法，递归的字段匹配算法，Smith—Waterman算法，Cosine相似度函数。
 
6.3     纠正所发现的错误
 
在数据源上执行预先定义好的并且已经得到验证的清洗转换规则和工作流。当直接在源数据上进行清洗时，需要备份源数据，以防需要撤销上一次或几次的清洗操作。清洗时根据“脏数据”存在形式的不同，执行一系列的转换步骤来解决模式层和实例层的数据质量问题。为处理单数据源问题并且为其与其他数据源的合并做好准备，一般在各个数据源上应该分别进行几种类型的转换，主要包括：
 
6.3.1  从自由格式的属性字段中抽取值（属性分离）
 
自由格式的属性一般包含着很多的信息，而这些信息有时候需要细化成多个属性，从而进一步支持后面重复记录的清洗。
 
6.3.2  确认和改正
 
这一步骤处理输入和拼写错误，并尽可能地使其自动化。基于字典查询的拼写检查对于发现拼写错误是很有用的。
 
6.3.3  标准化
 
为了使记录实例匹配和合并变得更方便，应该把属性值转换成一个一致和统一的格式。
 
6.4     干净数据回流
 
当数据被清洗后，干净的数据应该替换数据源中原来的“脏数据”。这样可以提高原系统的数据质量，还可避免将来再次抽取数据后进行重复的清洗工作。
 
7       数据清洗的评价标准
 
7.1     数据的可信性
 
可信性包括精确性、完整性、一致性、有效性、唯一性等指标。
 
(1)精确性：描述数据是否与其对应的客观实体的特征相一致。
 
(2)完整性：描述数据是否存在缺失记录或缺失字段。
 
(3)一致性：描述同一实体的同一属性的值在不同的系统是否一致。
 
(4)有效性：描述数据是否满足用户定义的条件或在一定的域值范围内。
 
(5)唯一性：描述数据是否存在重复记录。
 
7.2     数据的可用性
 
数据的可用性考察指标主要包括时间性和稳定性。
 
(1)时间性：描述数据是当前数据还是历史数据。
 
(2)稳定性：描述数据是否是稳定的，是否在其有效期内。
 
7.3     数据清洗的代价
 
数据清洗的代价即成本效益，在进行数据清洗之前考虑成本效益这个因素是很必要的。因为数据清洗是一项十分繁重的工作，需要投入大量的时间、人力和物力。在进行数据清洗之前要考虑其物质和时间开销的大小，是否会超过组织的承受能力。通常情况下大数据集的数据清洗是一个系统性的工作，需要多方配合以及大量人员的参与，需要多种资源的支持。
 
企业所做出的每项决定目标都是为了给公司带来更大的经济效益，如果花费大量金钱、时间、人力和物力进行大规模的数据清洗之后，所能带来的效益远远低于所投入的，那么这样的数据清洗被认定为一次失败的数据清洗。故，在进行数据清洗之前进行成本效益的估算是非常重要的。
 
8       常见的数据清洗算法（属性清洗算法）
 
8.1     空缺值的清洗
 
对于空缺值的清洗可以采取忽略元组，人工填写空缺值，使用一个全局变量填充空缺值，使用属性的平均值、中问值、最大值、最小值或更为复杂的概率统计函数值来填充空缺值。
 
8.2     噪声数据的清洗
 
分箱(Binning)，通过考察属性值的周围值来平滑属性的值。属性值被分布到一些等深或等宽的“箱”中，用箱中属性值的平均值或中值来替换“箱”中的属性值；计算机和人工检查相结合，计算机检测可疑数据，然后对它们进行人工判断；使用简单规则库检测和修正错误；使用不同属性间的约束检测和修正错误；使用外部数据源检测和修正错误。
 
8.3     不一致数据的清洗
 
对于有些事务，所记录的数据可能存在不一致。有些数据不一致，可以使用其他材料人工加以更正。例如，数据输入时的错误可以使用纸上的记录加以更正。知识工程工具
 
也可以用来检测违反限制的数据。例如，知道属性间的函数依赖，可以查找违反函数依赖的值。此外，数据集成也可能产生数据不一致。
 
8.4     重复数据的清洗
 
目前消除重复记录的基本思想是“排序和合并”，先将数据库中的记录排序，然后通过比较邻近记录是否相似来检测记录是否重复。
 
消除重复记录的算法主要有：优先队列算法，近邻排序算法(Sorted—Neighborhood Method)，多趟近邻排序(Multi—Pass Sorted—Neighborhood)。

0、题记
 
日志分析是ELK起家的最核心业务场景之一。
 如果你正在使用Elastic Stack并且正尝试将自定义Logstash日志映射到Elasticsearch，那么这篇文章适合您。
 Logstash写入ES之前的中间数据处理过程一般叫做：数据ETL或者数据清洗。
 本文重点介绍数据清洗环节的非结构数据转化为结构化数据的——Grok实现。
 
1、认知前提
 
老生常谈，夯实基础认知。
 ELK Stack是三个开源项目的首字母缩写：Elasticsearch，Logstash和Kibana。 它们可以共同构成一个日志管理平台。
 Elasticsearch：搜索和分析引擎。
 Logstash：服务器端数据处理管道，它同时从多个源中提取数据，对其进行转换，然后将其发送到Elasticsearch存储。
 Kibana：图表和图形来可视化数据ES中数据。
 Beats后来出现，是一个轻量级的数据传输带（data shipper）。 Beats的引入将ELK Stack转换为Elastic Stack。
 
 
2、啥是Grok？
 

 Grok是Logstash中的过滤器，用于将非结构化数据解析为结构化和可查询的数据。
 它位于正则表达式之上，并使用文本模式匹配日志文件中的行。
 下文分析你会看到，使用Grok在有效的日志管理方面大有裨益！
 
一图胜千言。
 
 如果没有Grok，当日志从Logstash发送到Elasticsearch并在Kibana中呈现时，它只会出现在消息值中。
 在这种情况下，查询有意义的信息很困难，因为所有日志数据都存储在一个key中。
 白话文——Grok的目的：
 将如上一个key对应的一长串非结构的Value，转成多个结构化的Key对应多个结构化的Value。
 
3、日志数据非结构化 VS 结构化
 
3.1 非结构化原始日志数据
 
localhost GET / v2 / applink / 5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0
 
如果仔细查看原始数据，可以看到它实际上由不同的部分组成，每个部分用空格分隔符分隔。
 对于更有经验的开发人员，您可以猜测每个部分的含义，以及来自API调用的日志消息。
 从数据分析的角度：非结构化数据不便于检索、统计、分析。
 
3.2 结构化日志数据
 
localhost == environment （基础环境信息）
GET == method （请求方式）
/v2/applink/5c2f4bb3e9fda1234edc64d == url （URL地址）
400 == response_status （响应状态码）
46ms == response_time （响应时间）
5bc6e716b5d6cb35fc9687c0 == user_id （用户Id）
 
如上切分的中间转换正是借助grok实现。非结构化数据变成结构化数据后才凸显价值，检索、统计、分析等都变得非常简单了。
 
4、Grok模式
 
4.1 内置模式
 
Logstash提供了超过100种内置模式，用于解析非结构化数据。
 对于常见的系统日志，如apache，linux，haproxy，aws等，内置模式是刚需+标配。
 但是，当您拥有自定义日志时会发生什么？ 必须构建自己的自定义Grok模式。
 
4.2 自定义模式
 
构建自己的自定义Grok模式需要反复试验。 推荐使用Grok Debugger和Grok Patterns做验证。
 Grok Debugger地址：https://grokdebug.herokuapp.com/ ，注意：需要梯子。
 Grok Patterns地址：https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patterns
 
请注意，Grok模式的语法是：％{SYNTAX：SEMANTIC}
 实践一把：
 步骤1：进入Grok Debugger中的Discover选项卡。
 期望这个工具可以自动生成Grok模式，但它没有太大帮助，因为它只发现了如下两个匹配。
 
 
步骤2：借助Elastic的github上的语法在Grok Debugger上构建模式。
 
 
步骤3：Grok Debugger实操验证。
 
 如上截图：
 输入待匹配的源非结构化数据：
 
localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0
 
输入匹配模式：
 
%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}
 
输出结构化数据解析后匹配结果：
 
{
  "environment": [
    [
      "localhost"
    ]
  ],
  "method": [
    [
      "GET"
    ]
  ],
  "url": [
    [
      "/v2/applink/5c2f4bb3e9fda1234edc64d"
    ]
  ],
  "response_status": [
    [
      "400"
    ]
  ],
  "BASE10NUM": [
    [
      "400"
    ]
  ],
  "response_time": [
    [
      "46ms"
    ]
  ],
  "user_id": [
    [
      "5bc6e716b5d6cb35fc9687c0"
    ]
  ]
}
 
在使用不同的语法后，终于能够以期望的方式构建日志数据。
 
5、grok集成到Logstash filter环节验证
 
步骤1：切换路径。
 在安装ELK Stack的服务器上，切换到Logstash配置。
 
sudo vi /etc/logstash/conf.d/logstash.conf
 
步骤2：拷贝核心Grok配置， 更新Logstash.conf。
 将验证后的grok部分贴过来。
 注意：核心三段论结构。
 1、输入：日志路径；
 2、中间处理ETL：grok解析
 3、输出：ES。
 
input { 
  file {
    path => "/your_logs/*.log"
  }
}
filter{
  grok {
    match => { "message" => "%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}"}
  }
}
output {
  elasticsearch {
    hosts => [ "localhost:9200" ]
  }
}
 
步骤3：重启。
 保存更改后，重新启动Logstash并检查其状态以确保它仍然有效。
 
sudo service logstash restart
sudo service logstash status
 
6、Kibana可视化验证
 
最后，为了确保更改生效，请务必刷新Kibana中Logstash写入的Elasticsearch索引！
 
 结论如下图所示：使用Grok，您的日志数据是结构化的！
 
 Grok能够自动将日志数据映射到Elasticsearch。 这样可以更轻松地管理日志并快速实现查询、统计、分析操作。
 
7、小结
 
这是一篇翻译文章。当近期在尝试写类似解析文章的时候，发现国外已经有讲解的非常透彻的文章。
 因此，在原文基础上做了实践验证和通俗化的解读，希望对你有帮助。
 划重点：Grok Debugger和Grok Patterns工具的使用，会事半功倍，极大提高开发效率，避免不必要的“黑暗中摸索”。
 思考：如果内置的grok pattern和自定义的pattern都不能满足已有复杂日志的匹配？我们该如何处理呢？
 欢迎留言，写下你的思考。相信深度的思考，能提升你的技术认知！
 
原文地址：https://hackernoon.com/structuring-unstructured-data-with-grok-bcdbb240fcd1
 推荐阅读：https://www.elastic.co/cn/blog/do-you-grok-grok
 

 铭毅天下——Elasticsearch基础、进阶、实战第一公众号