本篇主要从技术层面针对Splunk Enterprise中关于数据处理的概念、过程与部件进行了概要性总结。
1.数据管理基本概念
索引(index)：Splunk用于存储事件的数据仓库；
索引服务实例(indexer)：管理Splunk索引的(软件部署)实例，同时也可能肩负数据导入处理与执行检索的工作；
索引服务集群(indexer cluster)：关于Splunk服务实例的复制集形态集群。
1.1 索引
从表面上看，“索引”就是一系列的文件。这些文件分为两大类：
存储原始数据(原始数据已被压缩)的文件(rawdata files)
指向原始数据的索引文件(tsidx files)与一些保存元数据信息的文件
Splunk使用这些文件管理了所有的相关数据，不依赖任何第三方的数据库环境。此类文件被组织到一系列按照时间分代管理的目录中，这些目录被称作buckets。
1.1.1 分代数据管理
Splunk的索引服务实例会按照默认的时间分代策略来管理buckets。随着buckets年龄增长(从创建到当前)，会经历如下阶段：
hot
warm
cold
frozen
thawed
每个bucket都会从上到下地经历上述各个时间代。
当数据刚被索引时，会进入到一个hot bucket。hot bucket内的数据既可读(检索)亦可写(索引变更)。一个Splunk索引内可包含数个(不会太多)处于hot阶段的bucket。
当hot bucket满足一定的条件时，比如数据量增长到一定大小，就会转为warm阶段。此时新的hot
bucket将会被创建，以继续接收新数据到来。转换为warm阶段的bucket是只可读而不可写的。在一个Splunk索引里可能包含许多个warm
bucket。
接着，当达到一定条件后，比如warm bucket的数量达到设定数目后，warm bucket将会被按照时间老幼顺序陆续转为cold阶段。cold阶段的数据也是可读不可写的。在一个Splunk索引里可能包含许多个cold bucket。
从cold再往后的阶段就是frozen了。frozen阶段的数据默认是进行删除处理的，同样也可以通过配置，将frozen阶段的数据做归档处理。frozen阶段的数据是既不可读亦不可写的。对此更进一步地解释是cold阶段的数据已经不再索引之中了。
cold阶段被归档的数据可以被恢复(thawed)。将cold阶段的归档数据再重新加入到索引之中，即为thawed数据。
正如前文所述，Splunk通过不同的目录来管理数据，各时间代的bucket对应了不同的文件目录路径，这些均可通过配置文件来进行设定；同样可以配置的参数还有诸如各时间代大数据容量、bucket数量、转换检查周期等。
1.2 概念关系图
本章节所涉概念简要关系示意图如下：
总结来看，基于事件数据固有的时间序性，Splunk对其所管理数据进行了垂直于时间轴的划分；并且，这种划分在逻辑上与物理上是对应的。如此做法的优势在于：
通过不同的数据分代策略配置，能够更灵活地适应不同的计算环境条件；
清晰明确的数据物理结构，能够更方便的应对数据管理：迁移、备份、安全防护等。
2.数据传输处理
进入到Splunk的数据在终的持久化工作尘埃落定之前，都会经过相当繁杂的处理工作。如前文所述，索引服务实例(indexer)除了负责管理数据索引，同时也可能肩负 “数据导入处理” 与执行检索的工作。那么所谓的 “数据导入处理” 都包括哪些内容呢？
从更高的逻辑视角来看，Splunk采用了“管道-过滤器”架构风格来处理数据，处于管道起点的数据就是从原始数据源产出的数据，而处于管道终点的数据就是可以被检索并且封装了各种数据属性与对象的事件数据；相应地，数据在管道中的处理过程可以粗粒度地划分为多个处理阶段：
输入
解析
索引
检索
下图粗略展示了上述四大阶段的衔接过程：
2.1 输入
在这个阶段里，Splunk的主要工作是从相应的数据源接收数据流。此时Splunk并不认识，也不会去识别数据流的内容，只是将数据流划分为大小为64k的数据块，并且为每个数据块注明一些作用于整个数据流的元信息，包括host、source、与source
type；还有splunk内部使用的一些元信息比如数据流的字符编码、存储数据的目标索引等。
总之在这个阶段里，Splunk压根不识别事件，只是处理一些作用于整个数据流的特定的全局属性。
2.2 解析
在这个阶段里，Splunk将检查、分析并转换数据。这个过程又被称作“事件处理”(event processing)。Splunk将数据流分解为一个个独立事件的过程如下：
将数据流分行，即分解独立事件
从事件中识别、解析并为其设置时间戳
将数据流的全局属性赋予单个事件上
依据Splunk的正则转换规则转换事件数据和一些元数据
2.3 索引
在这个阶段里，Splunk的本质工作是将解析好的事件数据持久化到索引中。包括压缩后的原始数据与相应的索引数据。该阶段同样包括“事件处理”(event processing)工作，比如对事件进行分词。
从一种较高的逻辑层面上讲，“解析” 与 “索引”其实可以被连在一起来看待。但在更为实际的场景中，其实有必要把他们区别对待。具体原因下文中会有更详细的解释。
2.4 检索
简单说就是基于索引进行数据检索啦。此处暂不细表。
2.5 事件处理详解
“Event Processing”在Splunk中是一种专用叫法，这里引用官方的说明如下：
Event processing covers everything that happens to your
data between the time you define an input and the time the data appears
in the Splunk index.
可以看到，“事件处理”发生在“解析”与“索引”两个阶段里。示意性描述如下图所示：
上图中的“Parsing”、“Merging”、“Typing” 都属于所谓的“解析”阶段，“indexing”则为“索引” 阶段。
其中在“解析”阶段的工作包括如下方面：
配置字符编码
依据分行规则识别行终结符进行分行
识别时间戳信息，如果缺少时间戳信息则创建时间戳
过滤处理敏感信息，比如信用卡号码等
执行默认的字段抽取
注：“Parsing Pipeline”分解数据流至单行事件；“Merging Pipeline”合并多行事件，并且抽取时间戳；“Typing Pipeline”进行正则处理，提取字段。
在“索引”阶段的工作包括如下方面：
对事件进行分词
创建索引数据结构
将原始数据(压缩后)与索引数据写入硬盘
可以看到，“索引”阶段是一个I/O敏感的处理过程。
2.6 数据转发
在上个小节的“事件处理”示意图中，后的“Index Pipeline”里，数据除了被“indexer”存入“index”中外，还有两个方向：“tcp out”与“syslog out”。这又是怎么回事呢？
这得从Splunk中的转发器(forwarder)概念谈起。
Splunk Forwarder就是一个轻型的Splunk实例，使用它可以将接收到的数据转发给另一个Splunk实例，甚至也可以转发给非Splunk实例的外部系统。典型的应用结构如下图所示：
利用转发器的能力，基于不同的网络拓扑，可以应对各种需求场景，比如：数据路由、负载均衡。
2.6.1 转发器分类
普通转发器(Universal forwarder)：面向数据流，仅具备数据接收和转发能力。它不会解析数据，不能够基于事件内容完成诸如路由、过滤之类的功能，更不能够索引事件数据。
全功能转发器(Heavy forwarder)：几乎具备了一般Splunk实例的大部分能力，被阉割掉的功能包括：Splunk
Web、分布式检索等。区别于普通转发器的是，它可以解析数据，从而可以做一些面向事件的工作，比如基于事件的source、source
type来进行路由或者基于事件内容过滤事件等。另外，一个重要的功能是它可以在本地对事件进行索引。
“普通转发器”是区别于Splunk Enterprise产品的另外一个单独的软件；“全功能转发器”则是对Splunk Enterprise产品的部署实例加以特殊配置后的结果。
2.6.2 转发过程中的数据
在转发的过程中，可以依据数据形态分为以下三种类型：
Raw：数据被以原始的TCP网络包形态转发，尚未被转换为Splunk专有的通信格式。
Unparsed：通用转发器对原始数据做简单处理之后的数据形态。通用转发器并不检查流的内容，只是为整个流标记诸如source、source type、host之类的元信息。并且，通用转发器会将数据切分成体积为64k的数据块。
Parsed：全功能转发器将数据处理为事件后的数据形态。在这个形态基础上，转发器就可以做一些基于事件内容的工作了，比如事件路由。
相对于Raw数据，Unparsed与Parsed数据都是被加工后的数据(Cooked Data)。缺省的配置下，普通转发器转出Unparsed数据，全动能转发器转发Parsed数据。Raw数据通常用于转发到外部系统。
正是由于这种可伸缩的数据传输与处理体系，所以前文2.3小节中提到：‘“解析” 与 “索引”其实可以被连在一起来看待。但在更为实际的场景中，其实有必要把他们区别对待。’*
3.数据知识
在数据进入到Splunk的管辖之后，接下来就可以进行数据检索了吧？且慢！
在这里简单讨论下Splunk产品定位。无论存储还是检索，对于Splunk都只能算作支撑性质的功能，其定位既不是数据库也不是搜索引擎。它所瞄准的方向在于“数据分析”——从大量无结构数据中寻找有价值的信息。这里可引用“知识”术语来描述所谓的“有价值的信息”。“知识发现”(Knowledge Discovery)才是Splunk类产品的终极价值。
那么本小节以下内容将围绕“Splunk Knowledge”概念作以简单介绍。
利用Splunk分析数据时，用户并不会直接去审阅事件文本，而是关注像时间戳、关键字段、事件类型等被抽取、归纳、总结后的信息，这些来源于原始数据却又具备更高层意义的信息被称作“数据知识”(Splunk knowledge)。
这些数据知识也正是Splunk的关键价值。有的数据知识是在数据被索引(前)时提取的，但是更多的是在检索时被Splunk自动提取或者用户自助设定的。Splunk独具特色的一点是，它并不需要提前规划数据知识的提取，而是可按需从原始数据中动态地抽取。这一方面确实带来了足够的灵活性，但另一方面也牺牲了一部分的运行时性能。
数据知识在Splunk中体现为知识对象(Knowledge Object)。比如：事件类型(event type)、标签(tag)、字段抽取(field exaction)，以及被保存的检索定义(search)。
3.1 数据知识分类
Splunk中的数据知识被分为五大类别：
数据解释型(Data interpretation)
主要是指“字段”(field)以及“字段抽取规则”(field exaction)；
字段在Splunk知识对象中是“一等公民”；
包括由Splunk按照默认策略自动提取的，也包括由用户设定抽取规则所抽取的结果。
数据分类型(Data classification)
主要是指“事件类型”(event type)与“事务”(transaction)；
对具备相似性质(事件类型)或者有概念关联(事务)的事件进行分组。
数据扩充型(Data enrichment)
主要是指“lookups”与“workflow actions”；
从外数据源扩展事件数据。
数据规范化(Data normalization)
主要是指“标签”(tags)与“别名”(aliases)。
数据模型(Data models)
服务于可视化数据报表生成工作。
关于数据知识对象更详细的讨论暂不展开。这里需要强调的是，之所以说“字段”是“知识对象”中的“一等公民”，是因为其它的绝大部分的知识对象都是以字段为基础的。比如：事件类型对应于一个检索定义，而检索基本都是基于字段的；再比如“数据扩充”，无论是lookups还是workflow
actions都是针对字段的操作；而“标签”标记的也是具备某些字段值的事件特征；等等……
4.数据检索
4.1 字段与检索
正如前文所述，“字段”作为Splunk中的“一等公民”，在Splunk重要的检索功能里同样如此。通常的检索定义里都会包含如下形式的字眼：
someKey=someValue
没错，“字段”就是这样可供事件检索使用的“键值对”。不难理解，相较于仅使用关键字的检索，字段值检索更为。那么问题来了：事件数据中的字段都是如何得来的呢？
4.2 字段抽取
“字段”是从事件数据中被抽取出来的。首先需要说明的是，这种抽取是基于正则定义的字符规则来进行的；其次，这种抽取执行于两个时机：
事件数据被索引时(Index-time)
事件数据被检索后(Search-time)
正如前文中提到过的，在数据被索引时会进行一些缺省的字段提取工作，之所以叫做缺省的(默认)字段，是因为所有的事件数据都会具有这些字段。其中典型的、重要的、标识了事件数据的三个缺省字段是：“host”、“source”与“source
type”。当然，用户也可以自定义一些抽取规则，增加更多的索引字段，关于此点后文会再详细讨论。一般来讲，索引时提取的字段都是少数特定的几个。更多的字段是在事件被检索之后进行提取的。对此，Splunk依据抽取时机与处理手法做以下分类：
Indexed fields，包括Default fields;
Search fields，也可以称作Non-indexed fields。
从以上的分类命名中，可以看出，只有在索引前抽取的字段是被真正保存到索引中的。检索后抽取的字段其实都是从检索结果集中动态提取的。
从另外一个方面来讲，如果检索中包含字段条件，且该字段并非检索前抽取的，那么检索执行的过程中会先通过索引得到一个基本的结果集，然后再通过文本规则匹配的方式来终筛选出符合字段条件的结果。
4.3 检索模式
在使用检索功能时，在检索面板上有一个设置检索模式的选择器控件。如下图所示：
其中可选的模式有以下三种：
Fast mode
Verbose mode
Smart mode
这里之所以提到该处，是因为“检索模式”会确定检索时的字段抽取将如何进行。更准确地说，检索模式会决定Splunk的“字段发现”(field discovery)机制是否启用。
“字段发现”指的是Splunk在检索时，针对事件数据抽取key=value键值对的处理过程。当“字段发现”机制启用的状态下，Splunk将完成下述工作：
抽取前50个(检索结果里的所有事件中)匹配key=value模式的键值对；
抽取所有的在检索里指明的键值对，比如检索命令里包含的account=Tom；
执行用户自定义的字段抽取模式，这些模式可能是通过以下方式定义的：
Field Extractor
Extracted Fields page
配置文件
像rex这样的检索命令
“Fast Mode”检索模式下，“字段发现”机制是关闭的。这时仅能够体现出索引字段以及在检索定义中涉及的字段(“字段发现”机制中的第二条功能还是起作用的)。
在“Verbose Mode”检索模式下，“字段发现”机制是开启的。
这三种检索模式的区分不仅仅在于处理字段抽取方面的差异。因为影响检索性能的因素不止于这一个方面。另一个对检索性能有重大影响的方面就是关于事件数据统计方面的工作。在“Verbose
Mode”下，会针对所有被发现的字段进行数据统计工作，而在“Fast
Mode”模式下，仅仅会对明确指定要抽取的字段进行数据统计，并且如果指明了报表指令，将不再为生成事件列表与时间轴耗费时间，而是直接跳转到报表结果页面。
所以为了适应不同检索的检索目标，获得效率大化，Splunk提供了“Smart
Mode”检索模式。在该模式下，如果被执行的检索定义中不包含关于报表的指令，那么将会依照“Verbose
Mode”模式行事，否则将会依照“Fast
Mode”模式行事。(这里隐含了对用户的假设：即如果用户使用了报表指令，那么用户应该仅会关心该报表结果，而不再需要时间轴与所有的事件列表)
4.4 索引字段 Vs. 非索引字段
既然“事件”中的“字段”既可以被索引存储，也可以在检索时动态提取，那么对于用户来说，二者应如何取舍呢？对此，Splunk给予的建议是：尽量使用检索时动态提取的字段，即非索引字段。
理由如下：
增加索引字段将会加大索引创建方面的压力，影响事件索引创建效率
增加索引字段将增加索引体积，进而影响索引的检索性能
索引字段不具备灵活性，一旦变更将重建整个数据集的索引
对此，笔者想补充的是：检索时的字段提取同样会对检索交互的响应延迟带来负面影响。Splunk的推荐实践，或许是受其产品技术特点影响下的取舍结果。
其实，Splunk在执行检索任务时并不是简单地从索引中获取目标数据。其索引的功能只是为检索任务提供了一个初始结果集，而后在此结果集基础之上Splunk又做了大量的字符模式匹配的工作，大致包括以下子过程：
事件分词
事件类型(event type)匹配
提取字段，包括缺省提取逻辑和用户自定义的字段提取
处理字段别名
处理标签(tag)规则
从lookups补充字段信息
……
上述过程并非是一个顺序的执行过程，相反，Splunk尽可能地采用了并行处理方式，以尽快反馈用户期待的结果，毕竟是一款面向交互式操作的产品。尽管如此，在试用体验中，仍然感觉到了些许疑虑，包括系统资源占用与操作延迟方面。
4.5 检索定义
作为在事件管理领域积累多年的大厂，Splunk总结了用户利用事件数据进行分析的两大需求方向：
数据调查：在事件记录中寻找导致问题的根本原因。
数据汇总：将事件数据汇总于表格或者可视化图表之中。
相应地，Splunk将自身的数据检索也分为了两大类：
原始事件检索(Raw Event Search)
报表汇总检索(Transforming Search)
并且，为了更好地适应用户(市场)需求，Splunk设计了一套面向Ad-hoc查询称为SPL(Splunk Processing Language)的表达式语言。SPL由一系列的命令以及类“Linux Pipe”的管道机制组成。
由于接下来的内容将偏离于"数据处理"主题，故对于数据检索与SPL方面更进一步的说明本处就暂且不表啦。
End
