本文摘自网络，作者，侵删。
硕士毕业于西安电子科技大学，曾就职于阿里云存储部门，主要从事存储服务相关功能的设计与开发工作。于2016年加入七牛云，主要负责流式计算与离线计算服务pipeline的架构和开发工作。目前pipeline承载公司每天超过千亿、超过百TB的数据处理。
今天的分享主要围绕七牛在最近一年时间里面开发的大数据平台进行展开，目前我们的平台已经承载了公司核心业务的运营；关于我们的产品，主要会从一个场景展开进行介绍，当中包含了我们在设计过程中遇到的挑战以及解决方案。也欢迎大家基于这些问题和我们展开交流与讨论。
场景.产品
对于运维人员来说，在进行每日常规的线上运维时，日志当中的一天内访问量的波动、线上错误分布、其他业务指标这些数据对于运维人员来说并非是一个透明的过程，那么如何将这些东西做到可视化，或是将这些数据收集起来做统一的处理分析，其实是一个比较复杂和较难实现的过程。这就是所谓的运维日志分析，也是我们之前所提及的场景。关于我们产品解决场景的细节，在下面将会进一步进行分析。我们以Nginx-log为例对我们的Pandora产品进行叙述。
数据接入Pandora—logkit配置运行
任何数据分析的第一步都是数据接入。Pandora开发的数据接入工具logkit，可以帮助用户将数据打入Pandora平台内；在最开始需要下载logkit，配置并运行（图1）
图 1
logkit工具支持多种数据源，比如对Nginx-log、kafka数据进行采集，并打入我们的数据处理平台当中。下面对图 1 进行详解，首先，我们需要查看日志格式，包括日志格式的名称。在图 1 中，我们明确了日志存储的路径以及格式。最后进入配置文件，将需要进行配置的信息进行配置，并指明数据需要打入存放的路径，如果需要打到某一个消息队列中时，需要对密钥进行配置并运行它，那么此时这个数据才会采集收录到我们的平台当中。
* 日志检索
图 2
图 2 所示是一个比较直观的可视化界面，它支持拖拽，页面左侧可以看到“数据源”与“日志检索”这两项内容，配置好的 logkit 运行之后，所有数据都会打入“数据源”中。页面右侧则显示了数据源中每个字段的名称、格式等信息。
图 3
图 3 所示是“日志检索”的内容显示页面，通过“日志检索”我们可以清晰的查看一些业务逻辑，在搜索框中填入你的查询条件，就可以进行全文检索，当需要查看过去某个时刻响应超过3s的所有请求，那么通过“日志检索”页面也可以清楚的查询并显示出来。图 3 仅仅是展示了一个全文搜索的状态，在功能页面还可以查看相关数据分布的柱状图。
* 日志聚合
图 4
如图 4 所示，打入到数据源里面的数据，可以通过一段SQL以每分钟为粒度进行计算聚合。可以做聚合的内容很多，如来自某个IP的请求数量，也可以是别的一些相关操作，聚合结束之后，数据便会再次回流到我们的数据源当中。简单来说，我们通过一次计算将数据重新回流到数据源用于下一环节的分析处理，计算、回流的过程是可以不断去进行级联的，可以实现很多相对比较复杂的数据处理。
* 数据回流至平台
图 5
上面提及的数据回流至数据源是一种处理方式，用户搭建自己的一套HTTP服务，数据通过HTTP的接口回流至其自己系统内是另外一种数据处理方式。通过这种方式回流的数据，用户可以将分析结果在自己平台进行沉淀，操作页面如图 5 所示。
* 实时数据展示与监控
图 6
图 6 所示直观展现了我们的监控页面，监控服务需要开通之后再进行Grafana页面配置，页面的基本配置在我们官方文档中都有提供，用户可以直接下载导入。
图 7
图 7 展示的是对 Nginx 的日志进行分析之后的数据展示图。左上角橙色的框（visits为0）显示可总访问量，右上角绿色的柱状图则是在过去一段时间内发生的请求数以及响应时间，右下角的饼状图显示了相关用户访问的占比量。这些图的样式及位置都可以进行配置。
* 架构设计
图 8
图 8 所示展示了Pandora的业务架构。数据通过Portal/Logkit/SDK/API可以导入我们的平台，进入消息队列当中，消息队列当中的数据可以经过计算反复在计算任务和消息队列之间进行流动，当然，这些数据也可以直接导出。导出后的数据经过下游系统（日志检索/时序数据等）处理最终可以生成数据报表，以上就是数据的整个流向。
每个系统在最初设计时都会拟定设计目标以及相应的需要解决的问题。下面先讲一下我们的设计目标，首先这个系统必须支持数据快速接入、高吞吐量、低延迟；其次作为一个云服务，它必须支持海量用户并发访问以及必须支持海量消息队列；要提供实时计算与离线计算的框架满足计算需求；最终它必须是可视化的操作满足用户操作需求。在设计目标提出之后，我们要对选型进行规划，我们需要选择具备高吞吐量的存储系统，当然目前七牛的存储系统无疑是最满足需求的；其次我们需要强大灵活的大数据处理引擎；最后开发人员必须保证最终设计的产品是可以快速迭代开发的。基于这些要求，我们很轻易选择了相应的技术支撑，使用Kafka来满足我们的对海量消息队列设计的需求；使用Spark作为计算引擎；语言选型上则选用我们底蕴积淀深厚的Golang，最终，在确定这几种技术选型之后，我们便开始搭建系统。
图 9
图 9 所示，是我们Pipeline的整体架构设计，它负责pandora中数据的接入和处理。数据通过Logkit等方式导入到数据接入层，也就是apiserver。通过apiserver的数据会进入到消息队列里面，之后通过计算引擎的读取和回写操作，最终导入到下游系统中（LogDB/TSDB/HTTP/七牛云存储）我们今天着重关注绿色箭头指引的数据流方向，会提及里面相关的重点进行详解。在整个数据流流动过程中，有几个因素可能会决定这个系统的效率，比如稳定性、性能等。所以我将从用户到消息队列，经过计算任务再返回到消息队列，最终导出数据这整个过程来讲解。
* 数据接入层
图 10
图 10 所示显示的是数据接入层。数据通过apiserver导入，调度器用来管理一些用户消息队列的源数据，其中包括数据以何种形式写入到消息队列当中去。logkit这个工具之所以放在这里，不是因为数据会通过apisever流向logkit最终再流向消息队列，而是因为它可以采集各种形式的数据，在这里我们用它采集系统审计日志与监控信息。它很容易进行管理和配置。
* 容器化
图 11
在最开始设计这个系统时，扩容是一个比较困扰我们的问题。因为接入的基本是内部用户，接入速度比较快，所以一周之内需要扩容至少一到两次，这在运维上是一个比较重的负担。之后我们采用了容器的方案，因为整个数据接入层是一个无状态的组件，所以我们将它容器化，使用我们的容器云产品解决。如图 11 所示，每一个pod中，我们都将apisever与logkit布局在一起，通过监控数据，我们将每个容器包括这个集群整体的信息全部都汇总在了这个调度器当中。调度器里面承载着整个集群负载及资源总量这些信息，可以及时根据这些信息动态的实现扩容缩容。
* 数据写入优化
图 12
图 12 所示是对数据写入进行优化的过程。第一代数据写入流程，采用了串行的方式进行，数据导入之后是一行一行进行解析，全部解析之后再将数据写入到消息队列当中，但是这种方式的处理效率是非常低效的。所以我们利用go语言的特性，采用了line channel，数据源源不断进入channel，然后会在channel下游起多个parser，并行的对数据进行解析。也就是说我们利用channel将处理变成了并发的过程，最终提高了CPU的利用率，降低了用户响应的延迟率，大大优化了性能。
* 计算
图 13
如图 13 所示，我们的计算基于Spark 实现，提供了一个比较简单的SQL，对用户屏蔽了底层细节。
* 导出优化
图 14
相关阅读 >>
leetcode 1639 -通过给定词典构造目标字符串的方案数
更多相关阅读请进入《Go》频道 >>
Go语言101
一个与时俱进的Go编程知识库。
