使用 File Data Visualizer 将 CSV 和日志数据导入 Elasticsearch
我们在 Elastic Stack 6.5 中推出了一项新功能：File Data Visualizer。通过这项新功能，用户能够上传包含以分隔符隔开的文本（例如 CSV）、NDJSON 文本或者半结构化文本（例如日志文件）的文件，然后新的 Elastic Machine Learning find_file_structure 端点将会分析文件并返回包含数据相关结果的报告。这些结果包括建议使用的采集管道和映射，通过这些管道和映射便可从 UI 中将文件导入 Elasticsearch。
这一功能的目的是帮助那些希望使用 Kibana 或者 Machine Learning 探索自己数据的用户，让他们无需学习数据采集流程的复杂知识，便能轻松将少量数据导入 Elasticsearch。
这里有一个近期发生的很好的例子，那就是并没有开发背景的一位 Elastic 营销团队的成员撰写的这篇博文。通过使用 File Data Visualizer，他能够轻松将地震数据导入 Elasticsearch，进而帮助他使用 Kibana 中的 geo_point 可视化来探索和分析地震地点。
示例：将 CSV 文件导入 Elasticsearch
要想演示这一功能，最好的方法就是通过一个示例逐步呈现。在下面的示例中，我们将会使用来自 CSV 文件中的数据，这个 CSV 文件中包括某一航班预订网站的虚构数据。我们在下面仅列出了这个文件的前五行，让您大概知道数据的样子：
time,airline,responsetime 2014-06-23 00:00:00Z,AAL,132.2046 2014-06-23 00:00:00Z,JZA,990.4628 2014-06-23 00:00:00Z,JBU,877.5927 2014-06-23 00:00:00Z,KLM,1355.4812
在 File Data Visualizer 中配置“CSV 导入”
File Data Visualizer 位于 Kibana 中的下列位置：Machine Learning > Data Visualizer。用户会看到下面的界面，在此界面上，用户便可以选择或者拖放文件。对于 6.5 版本，我们将文件大小的上限设置为 100MB。
选择 CSV 文件之后，此页面会将文件中的前 1000 行发送给 find_file_structure 端点，然后此端点便会进行分析并返回结果。 通过查看 UI 中的 Summary（汇总）部分，我们可以看到该端点已正确检测到数据格式为包含分隔符，并且分隔符为英文逗号。
它还检测到有一个标题行，并且已将这些字段名称添加为每列数据的标签。第一列对应到一个已知的日期格式，并且已经高亮显示为 Time（时间）字段。
Summary（汇总）部分下方便是字段部分，对于曾使用过最初 Data Visualizer 功能的用户而言，他们应该已经熟悉这一部分。
我们可以看到，已经正确识别出了这三个字段的类型，并且还针对每个字段列出了一些高层次统计数据。 针对每个字段列出了出现次数最多的前 10 个值。对于已被正确识别为数字型字段的 responsetime，还列出了 min（最小值）、median（中位数）和 max（最大值）这三个值。
对于拥有标题行的的 CSV 文件，此功能的运行效果很好，但如果数据顶部没有标题行的话，又会如何呢？
在这种情况下，find_file_structure 端点将会使用临时字段名。我们也可以演示一下这种情况，从示例文件中删除第一行，然后再次上传即可。现在，这些字段被赋予了通用名称：column1、column2 和 column3。
用户很可能会拥有一些相关领域的知识，并希望将这些字段重新命名为涵义更加明晰的名称；点击 Override settings（覆盖设置）按钮便可进行重命名。
在重命名这些字段的同时，用户还能够编辑其他设置，例如 Data format（数据格式）、Delimiter（分隔符）和 Quote character（引用字符）。可以将这一部分看做为用户提供了一种方法，让他们能够更正 find_file_structure 端点就数据做出的合理猜测。您可能会有多个日期字段，而此端点仅选择了第一个。或者，即使文件包括标题行，您仍然希望完全更改字段名称。
对这些设置感到满意之后，我们便可以点击位于页面左下角的 Import（导入）按钮。
将 CSV 数据导入 Elasticsearch
然后我们会来到 Import（导入）页面，在此页面上，我们便可以将数据导入 Elasticsearch。请注意：此功能不可用于重复性的生产流程，仅可用于最初的数据探索过程。主要原因固然是缺少自动化选项，但还有另外一个原因，即此功能目前尚处在实验阶段。
有两种导入模式可供选择。Simple（简单），使用此种模式的话，用户只需要提供新的唯一性索引名称，并选择是否需要同时创建索引模式。
还有 Advanced（高级），使用这一模式，用户可在更细层面上管理创建索引时所用的设置。
- Index settings（索引设置）- 默认情况下，无需针对索引创建和导入过程进行额外设置，但是这里仍然提供了对索引设置进行自定义的选项。
- Mappings（映射）-
find_file_structure会根据识别出的字段和类型提供一个映射对象。如需了解可用映射列表，请查看我们的 Elasticsearch 映射文档。 - Ingest pipeline（采集管道）-
find_file_structure会提供一个默认采集管道对象。采集数据时便会用到这个采集管道，而且此采集管道还可用于上传任何其他数据。
在 6.5 中，为了降低损坏索引的几率，我们仅允许创建新索引，而不允许向既有索引中添加数据。
单击导入按钮即会开始导入过程。这一过程包括多个步骤，已在下面编号列出：
- 处理文件 - 将数据转换为 NDJSON 文档，从而可以使用批量 API 进行采集
- 创建索引 - 使用设置和映射对象创建索引
- 创建采集管道 - 使用采集管道对象创建采集管道
- 上传数据 - 将数据加载到新的 Elasticsearch 索引中
- 创建索引模式 - 创建 Kibana 索引模式（如果用户选择的话）
导入完成之后，用户便会看到一个汇总，其中列明了索引的名称、索引模式、所创将的采集管道、所采集的文档的数量，
以及用于探索新导入数据的大量 Kibana 链接。还会为白金级和试用期订阅用户提供一个链接，让他们能够基于数据快速创建一个 Machine Learning 作业。
示例：将日志文件和其他半结构化文本导入 Elasticsearch
现在我们已经讲完了 CSV 数据，NDJSON 数据就更简单了，导入时仅需要进行极少处理即可，但是半结构化文本又怎样呢？我们看一下 CSV 数据的分析过程与典型日志文件数据（亦称半结构化文本）的分析过程有哪些不同。
下面是路由器生成的某个日志文件的三行数据。
<190>38377:GOW45-AR002:Apr 18 08:44:02.434 GMT: %JHG_MS-6-ROUTE_EVENT_INFO:Route changed Prefix 10.156.26.0/23, BR 10.123.11.255, i/f Ki0/0/0.849, Reason None, OOP Reason Timer Expired <190>38378:GOW45-AR002:Apr 18 08:44:07.538 GMT: %JHG_MS-6-ROUTE_EVENT_INFO:Route changed Prefix 10.156.72.0/23, BR 10.123.11.255, i/f Ki0/0/0.849, Reason None, OOP Reason Timer Expired <190>38379:GOW45-AR002:Apr 18 08:44:08.818 GMT: %JHG_MS-6-ROUTE_EVENT_INFO:Route changed Prefix 10.156.55.0/24, BR 10.123.11.255, i/f Ki0/0/0.849, Reason None, OOP Reason Timer Expired
使用 find_file_structure 端点分析时，其正确识别出了格式为半结构化文本，并且创建了一个 grok 模式来从每行数据中提取字段和字段类型。在这些字段中，它还识别出了哪个为时间字段以及此字段的格式。
与带有标题行的 CSV 文件或者 NDJSON 文件不同，此端点无法获知这些字段的正确名称，所以其会根据字段类型给它们赋予通用名称。
然而，通过 Override settings（覆盖设置）菜单可以对这一 grok 模型进行编辑，所以我们能够更正字段名称以及类型。
然后，这些更正后的字段名称便会显示在 File（文件）统计数据部分。请注意，它们是按照字母顺序排列的，所以我们稍微调整了一下顺序。
导入时，会将这些新的字段名称添加至映射对象中，并且会将 grok 模式添加到采集管道中的处理器列表中。
总结
希望这篇文章勾起了您尝试 6.5 中 File Data Visualizer 功能的浓厚兴趣。这在 6.5 中仍然是一项实验功能，所以可能并不能正确匹配每种文件格式，但是欢迎大家尝试并向我们反馈您的使用情况。您的反馈能够帮助我们尽快推出这一功能的正式版本。