欢乐逛大数据平台的架构设计
随着业务发展，伴随着大量日志检索及指标数据的需求，大数据的使用越来越重要，人们也愈发关注数据的合理使用。在七牛架构师实践日（厦门站）上，欢乐逛基础架构组负责人廖峻阳结合实践经验为大家带来欢乐逛通过合理搭配使用部分开源组件及通过部分自研组件，完整搭建集成数据接收/数据流转处理/数据输出/监控报警等功能的日志及数据处理系统的技术分享， 以下是对他演讲内容的整理。欢乐逛在一年多以前开始整体搭建大数据相关的平台的架构设计，这当中也遇到无数的坑，主要是一些开源组件的坑，因为开源造成的坑，就导致必须要重头来。如图 1 可能大家对 Spark 等这些相关有过一些接触或者搭建，相信现场大部分人对这套整体化搭建有一样的感受，会很苦恼。遇到搭建的时候，语言体系化很多，另外也有其他一些相关的节点，导致运维很麻烦。今天先抛弃 Spark 这些大数据相关的节点，关注一下欢乐逛从 0 到 1 搭建这套系统当中碰到的问题，分别是：[*]logdb 与 logService
[*]tsdb 选择与使用
[*]logdb <—> tsdb pipeline 架构
http://5b0988e595225.cdn.sohucs.com/images/20170824/3ee26656df1a4c598b81df59c585b76a.jpeg图 1｜ logdb 与 logServicehttp://5b0988e595225.cdn.sohucs.com/images/20170824/e0d93245d2fb42adb017229f9ca488eb.jpeg图 2如图 2 是两年前的时候出一套最基础的 ELK 架构，其实是非常简单的一套架构，如果是 appss会直接做一个 redisqueue，就会将日志直接打到队列里面，然后开始按天分片，再往 es cluster 打，因为索引非常多，会出现一些问题。第一个是发现 redis 直接暴露给应用(短链接应用无谓tcp消耗)。第二 redis 是单点的东西，内存是完全不可控，如果出现异常情况，就会暴涨。第三点 logstash/Es 消费 lag 为引发连环灾难。第四，接入点过于分散(客户端/前端日志接入不易)，比如客户端或者前端日志接入不容易，变得非常的复杂，就很麻烦。第五，索引统一按天分片导致索引 shard 数过多。如果shard 达到上万级以上的话，同步非常慢。而且发现很多时候存日志并不是一定按天存的，因为有一些日志可能有一个月，有的日志留一天，这些日志的存储方式应该会变得不同。http://5b0988e595225.cdn.sohucs.com/images/20170824/2c10682782d4432993c9e6333f7c8967.jpeg图 3因此如图 3 做了架构调整。在队列层加了 logcenter proxy，然后修改filebeat 源码，端点的日志可以直接打 proxy ，因为 proxy 是无状态的，所以可以无限扩容。第二点就是异步化，同时加 disk queue。如果这样的好处是队列挂掉，日志可以同步写如 disk queue 就不会导致日志丢失，还可以对回放做限速，就不会导致队列日志过多，内存暴涨。第三就算完全抛弃队列，同样将 disk queue 直接打入 es cluster。那为什么要增加 proxy？
[*]我们需要收拢接入点，所有的日志点全部以类似的协议或者类似的格式往一http/udp 打
[*]依赖 disk queue 作为队列灾备
[*]数据规整字段补齐，过滤清洗
[*]预设值索引分片规则（容量估计），去动态设置索引的规则及比如按天，按周、月
[*]可扩展性（多存储引擎），这样可以在 proxy 这一层做处理，而不做任何改变
｜tsdb 选择：influxDb&Prometheushttp://5b0988e595225.cdn.sohucs.com/images/20170824/d880f5af58e045babf4ea8d440c9576d.jpeg图 4tsdb 的选择，有了日志之后查问题更方便，很多时候就需要出指标，这样就需要实际数据库，有两种选择。一种是 influxdb，一种是 prometheus，做一下对比。influxdb 是以推的形式来用，而 prometheus 采取是拉模型。第二点是第一种是采取类 sql 的查询语句，学习成本比较低。但是 prometheus 是自定义 query dsl，这样学习成本比较高。第三是 leveldb 存储。第四，就是 influxdb 存储每一条 doc，统计自由度高点，但是 prometheus 是提供四种数据类型，拓展性比较低。influxdb 为社区版本没有分布式支持而 prometheus 是拉模型分析式需求相对较低。Influxdb 为是基础监控，教委复杂的时序统计。开始的时候我们实际上两套都有用，同时的话，也有做一些接入，做一些数据统计相关的需求。那如何接入？http://5b0988e595225.cdn.sohucs.com/images/20170824/1f2a248b34d24f3a85ecf58c9c5772bb.jpeg图 5一：我们同样将数据流写入 disk queue ，不断的回放数据。在回放过程中，会根据app/metric做balancer 写入不同influxdb节点, 同时我们也提供一个 proxy，因此可以最大可能屏蔽掉多节点的问题。然而当接入量越来越大，第一会发现 grafana+influxdb 只能做实时统计。第二无法一条 sql 完成统计需求。第三是离线计算任务如何处理，当需要每月处理统计报表的时候，是需要离线计算来处理。第四是需要一个统一的监控报警规则，无论是 influxdb 还是 promethues，都是需要统一处理。第五数据源导入导出（如 logdb->tsdb, mysql->tsdb, tsdb->mysql），都有可能做一层计算之后再把数据导入。｜TICK架构最早的时候也是去观察一下开源当中有没有完整的架构，比如 TICK 架构，
[*]influxdb 长时计算 CPU/memory 消耗就偏大
[*]kapacitor 的 tick 为脚本学习成本较高，编辑任务不方便
[*]kapacitor 只基于 influxdb 体系输入源/输出源无法拓展
[*]社区版本 kapacitor 没有分布式支持
因为不符合预期所要的，于是我们开始推倒重来，需要几个功能有：
[*]Pipeline 本身支持一些离线任务计算
[*]Pipeline 是需要多数据源支持，比如 es 或者 influxdb 或者 mysql
[*]需要 web 管理分布式支持，并且有分布式支持，需要在任务量比较大的时候做调度
[*]需要有多数据源做统一监控报警支持。同时可能会有一些 udf 计算，就是自定义计算或者多数据源聚合运算。因此在这样的需求下，做自己的 Pipeline 架构
http://5b0988e595225.cdn.sohucs.com/images/20170824/d27fe17ae8274aca8c9413fe9f7052ad.jpeg图 6如图 6 是 Pipeline 架构体系，我们定义成本身不是数据源，也不是存储，它只是作为一个数据的流转换，因此从统一的 sql layer 层以 sql 形式往不同的引擎取数据。读取完数据之后会通过 Pipeline 会打入一个过滤节点，一个是 sql 计算，第二是 filter dsl，比如说某个字段加上某个字段大于什么或者等于什么或者增加某个字段的处理。然后是 udf 自定义，在量大的时候或者做更为复杂的自定义计算的时候，spark 是非常好用，所以会接入到 spark 当中。经过过滤节点后会将数据往做导出，同时也可以导出到一个 monitor 节点，这样可以自定义的报警支持，还能够做一些自定义的预测计算，能够自动的去添加一些规则。在这样的情况下，基本上实现一些事情。例如 tsdb 在某天某月计算的时候可以通过 sql 语句直接导出计算完再存 入tsdb。另外因为在做监控的时候会发现 influxdb 取数据非常痛苦（量大时耗时长），因此同时也会做预计算，比如预过滤，或者通过 udf 自定义来做。这些结束之后，应该说暂时满足一些欢乐逛的需求。但在结束之后，还应该做的一些事情：
[*]优化 Pipeline 分布式调度，因为本身我们 Pipeline 是基于一个 http 协议的格式，所以甚至可以完全不做通知，就可以分在不同的节点上，同时也在优化，把 Pipeline 进行分布式调度，调度到合理的位置上。
[*]基于 spark 实现多数据源聚合运算，比如说交集、差集和 filter。
[*]基于 mesos 的整体资源调度，让机器资源尽可能完整利用。
[*]监控预警规则多样化，预警智能化。尽管把预警规则做的自由度很高，比如说可以实现 dsl或者一些数学运算，运行完之后计算出某个值，但是这些值会对于指标值的域值都需要人工定义的，我们希望做的是能够做到智能化，比如预测一下数据未来的趋势，做一些数据本身的预值的波动判定或者一些处理，这样能够解放一些开发人员或者运营人员的时间。
页:
[1]