在大数据场景下借鉴Splunk SPL的提供通用的数据分析手段

序言

SPL是Splunk Search Language的简称，但不仅仅是一种搜索语言，是非关系数据分析的事实标准。SPL 提供 140 多种命令，可让搜索、关联、分析和可视化任何数据 — 一种可在 5 个重要领域概括的强大语言。

使用SPL语言，能够实现从数据获取、分析、可视化整个过程的描述。其中分析包括常见的统计分析、人工智能算法等。SPL以linux管道形式的表达数据分析的过程，更加简单容易理解，把数据分析拆分成步骤，每一步完成数据相应的处理，最终得到分析结果。

应用场景

• 日志搜索
• IT运维
• 业务分析
• 物联网
• 人工智能
•  ……

Splunk作为Gartner象限的领导者，其SPL设计思路具有很大的参考意义。

SPL在大数据领域

SPL的目标

SPL要做的是数据分析和可视化，在90%的应用场景中无需写代码，能够通过比SQL更简练的语句实现复杂的需求。

SPL需要支持的计算类型

• 实时处理
• 批量分析

目标人群

• 不具备编程能力的技术人员（有开发能力的自然不在话下），如运维人员、数据分析人员。
• 业务人员

大数据技术现状

大数据处理引擎分类

• 重量级的大数据引擎

spark、flink、hadoop、apex等为代表的重量级大数据平台，提供了完整的运行时环境，包括计算、调度等等。

• 轻量级的大数据引擎

kafkaStreams为代表，不提供运行时环境，只提供lib类库，嵌入到普通的应用程序中。

目前这两类方式都比较是重量级的解决方案，使用门槛高，需要开发人员写代码，打包代码的方式进行部署执行。

基于大数据引擎的数据仓库

以大数据处理引擎为基础，为了降低大数据平台的门槛，所以提出了很多支持SQL标准的大数据仓库，例如Hive大数据仓库、Kylin OLAP数据仓库、Spark Sql大数据仓库、Druid实时大数据分析引擎等等，面向不同的领域提供了很好的解决方案。

不写代码的方式的前提下，SQL能够满足很多需求，但是有些需求依然需要通过外部的配合进行处理。

存在的问题

• 复杂的分析难以编写和阅读

毫无疑问SQL非常强大，是行业标准，SQL存在的一个小问题，如果是复杂的分析，SQL语句会因为嵌套，变得特别复杂，难以编写和阅读。

• 聚焦在数据分析

SQL的核心是数据分析，数据怎么来，怎么呈现并不是SQL关心的，所以在大部分场景下，SQL解决了数据分析的一部分需求，仍然需要在前端付出大量的工作。

业务数据分析需求

面对非常多的数据来源

在业务领域中，需要分析各种各样的数据，包括结构化、非结构化，如业务数据、web访问日志、传感器数据等等。

从多种多样的数据来源收集数据，关系型DB、MQ、ElasticSearch、Hbase、Hive、文件、Excel等等。

需求场景多

业务分析、IT运维、安全分析、物联网等很多种场景，其背后的技术诉求都是类似的：简单、快速。

脑洞大开的设想

结合技术现状和业务分析的需求，我们提出一个问题，能不能在90%的场景下，用相同的方式完成数据分析的需求，并且直接通过视图的方式将结果呈现给使用者，尽量的降低开发人员的负担，更好的去服务于业务，灵活的面对业务分析需求的变化。

那么将SPL引入到大数据的领域中，需要考虑以下几个问题：

如何描述SPL

SPL语言可以被视作一种领域特定语言(DSL),实现DSL有以下几种方式：

1、 通过python 、groovy之类的语言

但是存在语言的绑定。简单的来说，可以在后台利用python、groovy能语言，但是在web浏览器中就难以使用了，要做语法提示之类的也有些麻烦。

2、 元编程

ANTLR（Another Tool for Language Recognition），一个通过语法描述来自动构造自定义语言的识别器（recognizer），编译器（parser）和解释器（translator）的框架。它被广泛的用于构建语言，工具，和框架。ANTLR 现在已经支持了多种当前流行的开发语言，包括 Java、C#、C、C++、JavaScript、Objective-C、Python 和Ruby.1 等。

现实的项目中，我们可以使用 ANTLR ，来解析一些正则表达式无法完成的复杂语法解析，可以用它生成自己的SQL语法，甚至是一门新的编程语言。

所以在此考虑使用Antlr作为SPL的语法描述工具。

例如search 命令

例如chart命令

如何执行SPL

SPL编写完毕之后，需要进行编译和执行，此时需要考虑何种运行时环境(单机、分布式集群)。

• 单机环境，例如常见的Spring Boot、J2EE应用服务器（tomcat 、jboss）等。单机的优点是简单，缺点是存在性能上限。
• 分布式环境，例如Spark、Flink等，分布式的优点是性能可以扩展，缺点是复杂，不同的平台有不同的API，SPL与每一个平台对接工作量太大。

此处必须要区分一下一种特殊情况的分布式集群，姑且称之”半分布式”。像Spark之类的集群，一个计算任务开始执行的时候，任务会被分解成子任务，由集群的Mater调度任务的执行，一个任务可能会被几十台服务器协同执行完成。半分布式，则只是多台相互独立的服务器，一个计算任务只能在其中一台上执行，并不能分解到多台服务器上协同执行，也就是说一个计算任务无法充分利用集群的计算能力，仍然存在单点计算能力的瓶颈。例如Elasticsearch的SearchHead就是一种半分布式解决方案。

 如何实现SPL

前边提到了单机的问题和多平台的复杂度问题，在此尝试提出一种解决方案：使用Apache Beam作为SPL的实现接口。参考Apache Beam简介。

使用Apache Beam的理由如下：

1、 ApacheBeam是谷歌开源的，跨大数据平台编程模型，Spark、Flink、Apex、Storm等大数据平台都提供了支持，同时也支持单机模式的运行，可以在单机模式和集群模式之前无缝切换，无需修改代码实现。

2、 Apache提供了流式计算、批处理的统一编程模型，实时计算和批处理计算使用了相通的API接口，简化了SPL实现的工作量。

SPL语法文件 https://github.com/ffly1985/spl/blob/master/spl/PLParser.g4

以上内容纯属务虚，非具体设计，细化待续！

全文完！