低延迟

App异常监控，需要保证数据延迟在分钟级。既然写ES这么慢，那我们为什么还要用ES呢？

高性能

开发者需要在监控平台上分析异常。一旦发现严重问题，及时进行热修复，从而把损失降到最低。 使用Direct模式可以避免这个问题。覆写。App异常监控平台，就是将这个方法服务化。这两个产品，因为只能做到亚秒级查询，我们平时多用在数据挖掘的场景中。使用Receiver模式，在极端情况下会出现Receiver OOM问题。这样升级主要业务逻辑代码时，只要重启一下程序即可。我们主要考虑到团队之前在Spark批处理方面有较多积累，使用Spark Streaming成本较低，就选择了后者。秒级、因此，我们只做了一些小的使用改进，例如：很多异常数据在各个维度的值都是相同的，做预聚合可以提高一些场景下的查询速度。相对上面的3种方案，基于倒排索引的ES非常适合异常分析的场景，可以满足：实时、

输出问题

如果Spark Streaming计算结果只是写入HDFS，很难遇到什么性能问题。但当这样做了之后，就会发现另一个问题——程序“忘记”上次读到了哪个位置，因为存储在Checkpoint中的Offset信息也一同被清空了。

图 2 作业异常重启架构图

如图2所示，包住异常，并不意味可以忽略它，必须把异常收集到Spark Driver端，接入监控（报警）系统，人工判断问题的严重性，确定修复的优先级。

维度

为了增强平台的可扩展性，我们做了全平台联动的动态维度扩展：如果App开发人员在日志中新增了一个“城市”维度，那么他不需要联系监控平台做项目排期，立刻就可以在平台中查询“城市”维度的聚合数据。美团点评数据平台提供了Storm和Spark Streaming两种流式计算解决方案。Phoenix算是一个“全能选手”，但更适合业务模式较固定的场景；Kylin是一个很不错的OLAP产品，但它的问题是不能很好支持实时查询和明细查询，因为它需要离线预聚合。即使做了去重等优化，符号化后的数据流还是有延迟。例如：已知某设备出现了Crash，直接搜索这个设备的DeviceId就可以看到这个设备最近的异常数据。

图1 数据流向示意图

Spark Streaming

每天来自客户端和服务器的大量异常信息，会源源不断的上报到异常平台的Kafka中，因此我们面临的是一个大规模流式数据处理问题。 我们团队在使用的OLAP解决方案可以分为4种，它们各有各的优势：

• SQL on HBase方案，例如：Phoenix、移动、为了解决这个问题，我们制定了一套服务降级方案。

  升级重导

  Spark提供了2种读取Kafka的模式：“Receiver-based Approach”和“Direct Approach”。

• 时序数据库方案，例如：Druid、性能等。SEO生产环境中使用Phoenix、 因此平台需要支持多维度聚合查询，例如按模块版本机型城市等分类聚合，如图5所示。再覆写相同的HDFS文件就保证了Exactly Once（注：并不是所有业务场景都允许覆写）。为了降低崩溃率，进而提升App质量，App开发团队需要实时地监控App异常。只需要制定好数据收集、

  输入问题

  iOS App崩溃时，会生成Crash Log，但其内容是一堆十六进制的内存地址，对开发者来说就是“天书”。我们使用的就是这种Low-level模式，但在一些情况下需要我们自己维护Kafka Offset： 升级代码：开启Checkpoint后，如果想改动代码，需要清空之前的Checkpoint目录后再启动，否则改动可能不会生效。Spark、开发者需要能快速发现关键问题。每条异常信息中，包含N维数据，如果不做符号化只能拿到其中的M维。不过在监控平台中，我们是当做“数据库”来使用的。我们在生产环境中做到了95%的明细查询场景1秒内返回。 自己维护Offset的成本并不高，所以看起来Checkpoint功能很鸡肋。如果直接使用符号化后的数据流，那么全部N维数据都会延迟时间T。

  

  服务降级方案示意图

  如图4所示，我们根据写ES的实际瓶颈K，对每个周期处理的全部数据N使用水塘抽样（比例K/N），保证始终不超过瓶颈。由于我们使用了 Direct 模式，不会因为数据量暴涨而挂掉，但这样的“稳定”从用户角度看没有任何意义：短时间内，数据延迟会越来越大，暴增后新出现的异常无法及时报出来。

  如果在使用App时遇到闪退，你可能会选择卸载App、 虽然Spark Streaming有着强大的分布式计算能力，但要满足用户角度的低延迟，可不是单纯的能计算完这么简单。

  

  图 5 聚合查询页面截图

  不用做优化，ES聚合查询的性能就已经可以满足需求。OpenTSDB是我们旧版App异常监控系统使用过的方案，更适合做系统指标监控。明细、

  可扩展

  异常平台不止要监控App Crash，还要监控服务端的异常、

ES在实际使用中的表现如何呢？

明细查询

支持明显查询，算是ES的主要特色，但因为是基于倒排索引的，明细查询的结果最多只能取到10000条。 实现24/7监控服务，我们不仅要解决纯稳定性问题，还要解决延迟问题。Kylin。数据处理、 想要支持动态字段扩展，还要使用动态模板，样例如下：

{    "mappings": {        "es_type_name": {            "dynamic_templates": [                {                    "template_1": {                        "match": "*log*",                        "match_mapping_type": "string",                        "mapping": {                            "type": "string"                        }                    }                },                {                    "template_2": {                        "match": "*",                        "match_mapping_type": "string",                        "mapping": {                            "type": "string",                            "index": "not_analyzed"                        }                    }                }            ]        }    }}

资源

美团点评数据平台提供了Kafka、你可以把ES的索引，就当成HDFS文件一样来用：新建、营收下滑。

聚合查询

面对爆炸的异常信息，一味追求全是不现实，也是没必要的。 为了更好地掌控Spark Streaming服务的状态，我们还单独开发了一个作业调度（重启）工具。OpenTSDB。ES的集群，整套技术栈在资源上也是分布式可扩展的。但中型以上规模的团队，往往会因为不想把核心数据共享给第三方平台，而选择独立开发。这种情况下，需要自己用ZooKeeper维护Kafka的Offset。那如此“简单”的系统，可用性可以保证吗？

高可用

Spark Streaming + Kafka的组合，提供了“Exactly Once”保证：异常数据经过流式处理后，保证结果数据中（注：并不能保证处理过程中），每条异常最多出现一次，且最少出现一次。我们团队从2015年Q1开始，陆续在SEM、 重导数据：重导数据的场景也是，当希望从之前的某一个时间点开始重新开始计算的时候，显然也需要自己维护时间和Offset的映射关系。造轮子，首先要考虑的就是成本问题。只有经过“符号化”的Crash Log，开发者才能看懂。

图 3 双延迟乱序数据流融合示意图

如图3所示，我们将数据源分为符号化数据流、实际分析场景可以抽象描述为：“实时 秒级 明细 聚合” 数据查询。

Elasticsearch

Elasticsearch（后文简称ES），是一个开源搜索引擎。Kylin至今。未符号化数据流，可以看出两个数据流的相对延迟时间T较稳定。删除、另外，基于其他NoSQL的方案，基本大同小异，如果选择HBase，建议团队在HBase运维方面有一定积累。保证Exactly Once是实现24/7的高可用服务最困难的地方。到应用商店怒斥开发者等方式来表达不满。不同业务的数据维度是不同的，相同业务的数据维度也会不断的变化，如果每次新增业务或维度都需要修改代码，那整套系统的升级维护成本就会很高。