欢迎光临网站优化公司网站,专业细致,精诚服务是给客户最好得口碑

网站优化公司

专业企业平台页面优化服务方案

项目优化实战分享

作者:jcmp      发布时间:2021-05-16      浏览量:0
从百亿级日志分析到千亿级实时日志分析踩过

从百亿级日志分析到千亿级实时日志分析踩过的那些坑(完整版)

业务背景概述

简单来说 目前我们主要用来做Web专区Nginx 访问日志,和CDN边缘节点日志分析,yyms,告警系统等业务。

Web业务数目庞大,出现故障之前都是需要通过访问日志去定位问题,而海量的日志存储在数百的机器中,由于Web专区的分布式架构需要采用查看日志定位问题通常需要很长时间。

同时通过日志很难定位地域性的问题以及偶发性的问题。同时如果要知道故障发生的机器或者定位到某个URI问题基本没有可能。

通过Nginx访问日志分析我们可以做什么,统计Uv,pv,不同响应码pv,uri 相应时间 响应码 服务器应答时间,

同时也可以分省份 isp 浏览器 操作系统 统计。通过流式的实时日志分析我们可以做到分钟级别的延时。

同时通过告警通知等方式通知相关人员修复问题,

同时也可以在系统里面实时查看系统灰度结果,提供到ip+uri级别故障定位。

- Cdn边缘节点日志分析

相对Web专区请求量Cdn请求高于它一个数据量级,我们通过和厂商合作要求厂商通过提供边缘日志的方式给我们方便我们进行CDN日志分析,分析的数据类型和Web专区类似, 只是由于数据量特别大如image.yy.com。

单个域名的日志量5分钟的数据量已经到达4kw,文件大小超过20g,和 http:// image.yy.com 处在同级别的请求量的域名也有近10个,从文件下载到数据传输,到流处理计算都遇到相当大的挑战。

平台架构

项目采用的Storm流计算的架构,目前业界的流计算框架较多如Spark,Flink,JStorm,Heron,2015年刚刚开始进行日志分析的时候并没有那么多选择,

同时公司内部也有许多团队采用它搭建了分析服务,相对成熟的Storm几乎是流计算的唯一选择,直至今日Storm依然是流数据分析的最热门的应用之一,

我们使用的第一个Storm版本是0.8.1,实际Flume+Kafka+Storm+Hbase是一个非常通用的架构,不论你是一个大型的企业或者中小企业,当你需要做流计算分析的时候都可以通过它搭建。

核心在于通过Flume把前端数据采集后,传输到Kafka集群进行数据分发,Storm通过消费Kafka队列数据进行计算。

为什么选择这个架构

storm

首先,在开源所有的流式计算里面Storm是最热的,应用最广的之前提到的Spark,Flink(Heron,Jstorm都是后来出现的产品)。

它们在它们的细分领域有它的优势但是在Web专区日志分析并不是特别适合计算模型设计相对复杂,Spark处理效率高于Storm,Flink数据传输性能也数倍于Storm,

但是做Nginx日志分析它们的计算复杂度远大于通过Storm处理,同时Storm的处理延时是 最小的,完全采用java进行开发,学习成本最低。

ps: 作者写这篇博客时间是16年,那时候flink的使用还没有普及开来,真正普及开来的是阿里在flink的基础上开源了blink,才会使flink流行开来,当然是flink本身的优秀实时计算特性,

使得它可以做批处理和真正的实时流处理,即解决了spark streaming mic batch 的缺点(实际还是批处理的思想),又解决了storm只能进行流处理,框架的选择可以查看我的另外一篇文章 选型一个合适的框架-分布式任务调度框架选型。

kafka

选择Kafka 最重要的一个原因是Kafka性能卓越,Kafka的测试成绩几乎可以达到机器物理瓶颈同时对机器的Cpu和内存占用很低,Web专区的日志分析经过了3个大的版本改动,

之前为了不跨网计算我们用单台Kafka处理一个机房的全部nginx日志,2.0版本我们将集群合并通过9台Kafka集群容纳了公司全部的Nginx日志的传输,

同时在Cdn日志分析时候也承担了Cdn的日志队列服务,一般的日志分析服务3-5台Kafka已经可以满足业务的分析需求。

Kafka队列并没有像其他队列服务支持复杂的队列场景,最大区别是Kafka并不保证队列的顺序(每个分片数据保证顺序多分片之间不保证),数据重复消费(at-least-onece),

如果其他队列性能可以满足建议还是使用其他队列

ps: kafka 重复消费,一般是业务逻辑处理完成,offset 提交失败导致,导致下次消费的时候还是从上次提交offset位置消费,导致数据重复消费,如果业务逻辑是把结果处理完成写入mysql。

其实可以通过设置唯一健来进行处理,当重复消费时,也不会影响最终的结构,写入redis的时候,可以判断是否存在该key,如果存在也是忽略。数据重复消费无法避免,

可以在业务逻辑处理的时候把数据重复消费的影响忽略掉。

flume

Flume 在Hadoop时代Flume已经是大数据传输的标配,Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统,支持在系统中定制各类数据发送方,用于收集数据;

同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。Flume提供3种数据可靠性选项,包括End-to-end、Store on failure和Best effort。

其中End-to-end使用了磁盘日志和接受端Ack的方式,保证Flume接受到的数据会最终到达目的,但是效率是最差的。

Store on failure在目的不可用的时候,数据会保持在本地硬盘,效率会比end-to-end高,但是会出现日志丢失的情况。Best effort不做任何QoS保证,效率最高,日志记录没有保证。

hbase

Hbase Hbase是运行在Hadoop上的NoSQL数据库,它是一个分布式的和可扩展的大数据仓库,也就是说HBase能够利用HDFS的分布式处理模式,并从Hadoop的MapReduce程序模型中获益。

这意味着在一组商业硬件上存储许多具有数十亿行和上百万列的大表。除去Hadoop的优势,HBase本身就是十分强大的数据库,它能够融合key/value存储模式带来实时查询的能力,

以及通过MapReduce进行离线处理或者批处理的能力。它是开源并基于Google Big Table白皮书,HBase运行在HDFS之上,因此使它具有高度可扩展性,并支持Hadoop map-reduce程序设计模型。

HBase有两种访问方式:通过行键进行随机访问;通过map-reduce脱机或批访问。

平台与数据规模

Web专区

Web专区日志量规模日峰值在200-300亿 2000-3000w/分钟。

Kafka+zookeeper+storm+hdfs+hbase 通过混合部署一共使用了20台机器(后面为了容纳跨机房故障扩展到了双机房部署)。

下图为某天Web专区的总请求转发数截图: 涉及公司内容不上图

#### Cdn日志分析

Kafka+zookeeper+storm+hdfs+hbase 双机房混合部署 (Web专区日志 Cdn日志分析 yyms 等系统共用) 两个机房每个机房部署30台机器 一共60台。

Cdn日志分析的日志量大约是Web专区的5-10倍 每天1000-1500亿 1亿-2亿/分钟 日志大小数十T。

下图为某天Cdn请求量总数截图:涉及公司内容不上图

流计算的技术现状和架构

对比storm 与 spark streaming ,flink,heron的技术架构 ,建议去官网了解。

flink

Flink利用基于内存的数据流并将迭代处理算法深度集成到了系统的运行时中,这就使得系统能够以极快的速度来处理数据密集型和迭代任务。

当服务器内存被耗尽时,Flink也能够很好的运行,这是因为Flink包含自己的内存管理组件、序列化框架和类型推理引擎。

利用Java或者Scala语言能够编写出漂亮、类型安全和可为核心的代码,并能够在集群上运行所写程序。

开发者可以在无需额外处理就使用Java和Scala数据类型,在无需进行任何配置的情况下,Flink内置的优化器就能够以最高效的方式在各种环境中执行程序。

此外,Flink只需要三个命令就可以运行在Hadoop的新MapReduce框架Yarn上,Flink支持所有的Hadoop所有的输入/输出格式和数据类型,

这就使得开发者无需做任何修改就能够利用Flink运行历史遗留的MapReduce操作。

实践经验和我们踩过的坑

ps :这是分享这篇文章的重点,好好看下别人踩坑和填坑过程 ,其实就是之前听说的一句话,一个人的能力大小就是看这个人的填坑能力。

去年3月份开始我们从Storm0.8.1 Storm0.9.1 Storm 0.9.3 到Storm0.10.0,

在数据量从数百亿到达千亿规模,我们踩过了很多坑,以及我们是如何定位这些问题并解决这些坑的,

希望大家的流计算工程有所帮助。日志分析分析经历过大致三个大版本更新。

v1.0

分集群统计方案,由于最初设计大家担心跨网传输数据的稳定性,同时机器没有办法一次到位(buffer池正好每个机房有一台机器可以申请,查询采购需要等1-2个月左右),

1.0版本我们的处理方案采用Web专区七个机房每个机房计算自己的数据(每个机房一台机器处理),每个机房将计算结果传输到队列中,再通过程序对各机房的计算结果进行合并,最终数据保存在Mysql中。

由于考虑Mysql容量问题(单数据库公司最大只能1T左右,Web质量运营系统的数据7天的总量就将近1T),1.0版本支持的统计模型较少,只有比较核心的几个指标 pv uv 5xx 4xx topUri 等指标且数据统计粒度只到了小时级别,

但是1.0版本也为了后面的改进提供了丰富的经验,对每个应用组件的性能进行了多次调优。

Kafka的那些坑

Kafka 支持压缩传输,由于开发周期比较短2周左右的开发时间,很多参数没有进行调优,中间有兄弟团队在Kafka传输上遇到问题,

把网卡打爆了,原因是没有开启Kafka压缩传输,实际Kafka支持压缩传输,像日志这种数据压缩比可以到达20倍以上,

打开压缩传输带宽和硬盘使用量一下就降下来了(Kafka性能并没有出现瓶颈 问题出现在我们机器只有千兆网卡)。

ps:大日志传输,考虑网络带宽和资源消耗,一定要考虑压缩

Storm的那些坑

开发中我们使用的版本是Storm 0.8.1,生产环境我们使用的Storm 0.9.1,Storm 早期的版本非常不稳定,当数据出现热点很可能就导致数据处理异常,同时看日志并没有指出异常,

一旦程序出现问题只能进行猜测可能是哪导致的,但是基本都是数据热点问题,你发现后解决掉热点即刻正常,当时我在无锡集群分析的时候遇到数据热点问题,

看现象就是worker不断挂掉,后台只能看到各种连接netty 连接timeout,然后集群spout不再发送数据,整个集群出现僵死的情况,通常几个小时甚至几天才会出现,

后面通过分析和交流发现实际这是0.9.1在大数据分析的时候普遍会遇到的问题,当数据超过1000w-2000w/10分钟的时候 就会出现,0.9.1版本 Storm 由于版权问题替换了原来的zeromq队列。

改用netty作为原数据传递的通道,worker worker之前传输数据 和worker 与nimbus传输数据都是通过netty通道进行的,当netty通道数据处理不过来的时候,worker和nimbus之间的心跳不能及时被响应,

nimbus就认为worker不能响应了 就kill掉了worker,worker挂掉以后数据的ack机制会把挂掉的worker没有处理完成的数据进行重发,继而又导致了其他worker挂掉,继而发生了雪崩,

由于storm 0.9.1没有对netty超时进行异常处理,导致超时以后的异常并没有被捕获到,这大大的增加了我们处理问题的时间。

后面通过对数据的分层处理我们引入了域名分析维度 和uri维度分层处理 解决了数据热点问题,实际产生问题的原因是topN uri计算对计算资源要求比较多,数据在某些大域名上产生了堆积,在高峰期的时候 capacity需要到10ms左右。

V2.0

多机房分析可以保证数据不跨网传输,但是数据复杂度某些上升,同时由于一个域名通常都转发到多个机房,topN Uri,uv 等数据实际都有一定程度的失准,由于对之前的处理经验和对各应用性能的了解,

V2.0采用单集群集中式处理方案(由于传输采用压缩方式带宽使用已经可以忽略,近20倍的压缩比),具体不同点数据采用Flume进行跨网传输,同时V2.0对数据多样性有了极大程度的优化。

增加了很多新的维度,同时也将数据处理延时从小时降到了分钟级别,由于数据有了极大的丰富存储我们采用了Hbase作为存储数据库(OpenTSDB),数据写入量到了平均20w/s写入量。

Nginx的那些坑

Nginx 日志切割官方一直没有给出一个好的解决方案,最开始我们使用lograte进行日志的切分,切分完成后发送命令给nginx 释放文件句柄,但是由于Web专区上面都代理上百个域名nginx请求较多,

虽然发送给了Ngnix 释放文件句柄但实际并没有释放(文件大小一直变,导致Flume不能正常上传文件),后面通过对源码的阅读发现实际Nginx所有的命令都是异步处理的,接收到命令后并不会阻塞释放掉文件句柄,

导致新日志一直打印到了切分之前的文件里面,而不是新文件中。解决方案查明问题后安全组的同学(吴高俊)帮忙增加了一个时间变量,日志打印完全安装分钟直接打印不再使用lograte进行切分。

实际之前日志切割方案一直导致了一个计算周期的数据出现在3个日志文件里面导致数据处理的延时增加,通过自定义日志模块的方案完美的解决了日志切割的问题,数据延时从原来的7分钟延时降低到了3分钟左右。

ps: 小的处理方案带来大的性能提升 ,思维锻炼有多重要,就是在不经意间用到。

OpenTSDB的那些坑

我们的数据存储采用openTSDB作为存储中间件,数据的读取写入都是通过TSD进行,由于TSD本身是单线程处理读写在大数据查询的时候很容易导致查询阻塞,导致前端查询的僵死,

后面增加了对TSD的监控,避免查询僵死导致阻塞问题(后面发现实际由于我们没有对最大查询超时时间进行限制导致线程不停的处理后面设置了查询超时时间避免了大数据查询导致的僵死问题),

数据查询僵死最终原因是因为数据URI数目过多,域名进行SEO经常会吧URI进行伪静态处理,导致URI数非常多,同时我们是针对每5分钟URI 多个维度计算topN(最慢 不同相应码 topn 请求最多 流量最大 动态 静态),一个周期的uri总数多的时候都有上百个,查询一天的Uri数据 可能会出现上万的uri,如果用户在前端进行1天的数据查询就会导致数据查询慢的问题,我们通过正则表达的方式 提供用户自定义伪静态 URI聚合功能,

同时对数字 md5等特征的uri进行了默认聚合,经过聚合以后大部分域名的topn请求都下降到1w以下,同时由于对URI的聚合URI维度的数据总体覆盖率也从之前的70%提升到了95%以上。

Storm Kafka的那些坑

2.0开发完成后对pv/uv数据的自身验证,我们当时是开发了另外一个Storm程序去单独计算核心数据最后通过两份数据的对比去校验2.0开发数据的一致性,核心校验的是pv 以及uv这两个核心指标,

由于校验程序的业务比较简单很快就可以处理完成数据,由于数据之前按5分钟进行日志切割传输,实际数据大部分都是在10s内全部到达,数据进入Kafka后立即会被消费,由于校验程序简单消费速度快占用了很多系统资源,

对生产环境的kafka处理能力影响了,现象就是生产环境的Storm经常会出现连接超时的情况,产生这个问题的原因主要Storm,Kafka 都没有对消费者做限制 也没有优先级,对资源消耗没有控制,

单个业务不合理会影响到整体业务,不过后续的Storm2.0 Heron都有设计这块以后应该可以做到资源隔离和资源控制,后面通过减少spout消费线程数进行一定的优化,避免了这个问题。

V2.5

2.0版本问题主要体现在数据只传输到一个机房,单机房网络出现问题后数据将不能正确处理,作为一个全网在用的监控系统机房出现故障的时候服务不可用是不能容忍的,

v2.5主要将服务提升到了多数据中心模式,数据通过Hash 将日志传输到某个机房 传输出现中断或者发现机房A网络有问题自动切换到机房B,机房A 机房B 同时承担数据的计算,

同时两个机房的数据通过类似binlog的方式实时同步,当网络恢复后数据立即恢复,同时数据的处理全部自动化,无需人工干预。

ps: 数据中心解决跨网络传输问题

OpenTSDB的那些坑

TSD数据传输支持Http协议和telnet协议,在测试过程中发现telnet协议的写入数据速度远大于使用http协议进行写入,

所以在数据录入的时候我们使用telnet协议进行传输数据,但是由于没有对telnet连接池控制好在多线程的情况下,

出现了数据串号问题,最后发现由于连接池没有做好线程安全控制。

V3.0

3.0版本主要功能是处理CDN边缘节点日志,由于数据量较之前大了一个数据量级别,原来的计算模型已经出现了瓶颈。

Zookeeper和Kafka混部的那些坑

ps: zk和kafka部署到同个机器

目前的大数据应用都是通过Zookeeper进行数据调度,由于zookeeper本身对延时敏感,当zookeeper出现瓶颈的时候依赖它的服务都会出现问题,由于机器数有限我们zookeeper和kafka部署在相同的机器上,

zookeeper和kafka都是硬盘io特别大的服务,在进行Web专区日志分析的时候zookeeper并没有出现瓶颈,但是Cdn日志分析上线以后Zookeeper的性能明显吃紧了,

由于Storm 分析和kafka Hbase都对Zookeeper依赖,zookeeper如果出现问题整个分析服务都会出现异常,根据之前的一些经验zookeeper的写入量不要超过1k/s,读操作不要超过1w/s,

导致zookeeper性能问题的主要原因有两点kafka对硬盘io的占用(ssd也可以提高zookeeper的性能),

我们不添加机器的解决方法将zookeeper和kafka服务分开盘部署避免kafka高速读写硬盘导致zookeeper 性能下降,

同时我们将Storm 和其他服务的zookeeper分开 保证storm分析服务不影响到其他服务。应用尽量减低对zookeeper的依赖。

ps: 了解zk和kafka都是对io操作比较大的服务组件,因此要对组件部署进行隔离,同时storm程序也要和zk隔离。

Flume的那些坑

Flume 传输效率非常高,传输数据到Kafka队列一秒几十M都很正常,但是对于五分钟要传输几十G内容,单文件就到达40G以上的时候,瓶颈就开始体现了无论你是使用多点分发还是多线程,

多进程都没有办法做这个大数据的传输,Flume 传输模式是一个文件一个文件的处理方式,假如一个文件没有处理完成即使后面有小文件也会阻塞不处理等大文件传输完成后再处理,

storm处理数据的时候理想的情况数据是离散的,这个数据传输方式直接导致了storm 数据处理能力的下降,数据过于集中,

至于优化我们的完整方案是把数据先按100w行进行切割传输到不同的机器后再通过flume进行上传保证,通过按大小切割的方式,我们也可以对数据上传延时和超过处理的日志部分进行控制并告警。

目前我们集群的处理能力在3000亿每天的规模,超过量的数据可能会导致storm处理不过来(CDN经常会因为某活动,如娱乐盛典请求量会有突发是日常的3倍以上,为了保证业务正常,必须限流)。

ps: 了解flume传输模式,先把文件均分切割上传,同时对业务峰值的超量数据进行限流。

服务监控的那些事情

Ambari整体部署

Apache Ambari是一种基于Web的工具,支持Apache Hadoop集群的供应、管理和监控。Ambari目前已支持大多数Hadoop组件,包括HDFS、MapReduce、Hive、Pig、 Hbase、Zookeper、Sqoop和Hcatalog等。

我们2.0开始的集群全部都是基于Ambari进行安装监控,所有的服务基础类它都有自带监控下面我主要说一下业务监控。推荐大家使用Ambari搭建自己的集群,同时通过Ambari可以很方便的对基础服务进行监控告警,

同时Ambari也提供的很方便的自动化运维能力,缺点是服务需要接入到Ambari上,如果是版本更新没有社区快,自己接入平台有一定的开发成本,上面也可以部署Yarn Mesos 等发布数调度平台,

但是Ambari 并不是涉及发布调度控制等东西的,实际是个机器应用部署监控一体化工具。修改配置 扩缩容配置好授信的机器基本都可以做到一键搞定,同时所有的服务都可以根据指标配置告警。

Kafka

Kafka 监控主要是对数据写入和数据读取监控,录入数据的查看可以使用Kafka Manager,

但是消费数据由于Storm 是按自己规范进行的消费 各种偏移的记录方式和原生有差异,

Kafka Manager不能覆盖到,我们只有通过自己写程序记录 然后做监控告警。

Storm

Storm 监控主要是对nimbus 和各个处理节点进行监控,监控进行是否worker存活(处理性能有问题worker会经常挂掉重启),以及对数据处理延时进行监控。

OpenTSDB

Tsd 是单线程处理业务的 单一个事务阻塞后 其他事务不会响应会导致前端查询僵死的情况,对tsd的监控主要是需要对tsd 进程 cpu 100%的情况进行监控告警,单出现性能锁死过久的时候告警。

Zookeeper

zookeeper监控主要依靠taokeeper做的比较多,但是由于公司没有对zookeeper进行统一管理,自己一个服务进行taokeeper接入成本比较高,另外一种监控方案是采用脚本上报Metric进行监控告警,

我们目前是采用这种方式。zookeeper主要是要对写入量进行监控,实际应用中读取方面的问题比较少可能发生,同时zookeeper服务部署机器必须是奇数同时部署节点最好超过5个同时低于11个。

Hbase Hdfs监控

由于我们都是接入了Ambari平台 平台已经提供了比较丰富的Metric监控 同时本身也有UI可以方便的观察业务。

机器监控

机器监控我们主要依赖YYMS提供的监控服务,新版的YYMS提供了全局性监控视图,机器指标的问题很容易定位到,同时YYMS也支持配置各种告警策略。

应用优化的那些事情

由于我们的服务数据量和并发数都相对较多,实际生产环境的运行中我们也对各个应用做了很多优化点,有部署方面的也有参数调优我这边由于每个应用参数调优项非常多,我只针对几个我觉得比较重要的进行解释。

Storm

所有的计算逻辑基本都是由Storm进行承担,正对Storm的优化主要是对参数的调优,例如连接数心跳时间,超时时间,缓存大小,批量处理大小等参数调优,垃圾回收器建议使用G1,

中间我觉得比较重点的是一个节点里面的worker数的调优,我这边有几个建议worker数目不能最好是cpu数除以3,同时一个worker的内存大小不要超过3G,在worker的并发度方面控制在8-12个并发比较合适,

Storm本身支持可靠计算通过元数据ack机制实现,但是ack功能对系统的性能损耗也是比较大的,在一些对数据一致性要求不严格同时有数据处理量特别大的场景建议把ack关闭,关闭后可以性能可以提高30%以上,

同时当业务出现洪峰的时候不会导致雪崩,如果采用ack方式 数据处理不过来或者worker挂掉正在处理的或者没被处理的数据都会重发 数据ack 实际也会对zookeeper有较大的负载,

我在Web质量运行稳定后将这个参数设置成关闭了,数据的补算我通过数据重发的方式进行补算(数据结构设计本身就支持数据补算和数据延迟到达)。

ps: 数据采集要有历史数据补采的功能

Kafka

Kafka 主要是要注意本身kafka 对硬盘io读取很大,最好不要和一些对磁盘io性能要求高的服务部署在同一个物理盘上如zookeeper,这样会对其他服务照成比较大的影响,

参数优化点主要是kafka 分区和样本数设置,建议对数据要求高的副本数设置成3,如果对性能要求高的设置成2,如果kafka节点部署较多副本数设置3 节点较多的情况实际这个对性能影响并不是很明显,

topic 分片数设置建议是机器的硬盘数*3,其他的优化参数如读并发数和写并发数等基本参数根据文档自己优化,

kafka本身使用内存和cpu不多对机器的性能要求不高,读写都是顺序的所以选用ssd应该也不会太大的性能提升。

zookeeper

Zookeeper 主要问题是写入性能一般而且并不能通过扩展机器的方式提高写入性能,读性能可以通过扩展机器扩展,所以如果遇到zookeeper性能问题,一般的处理方式就是单独部署zookeeper服务,

还有采用性能更加好的硬盘如ssd(采用ssd性能提高明显),部署需要注意的是zookeeper数据盘最好不要和读写较多的服务部署在一起,

同时zookeeper也支持通过一些牺牲一致性(极端情况)的方式提高性能,不建议修改。

hbase

Hbase 我们主要是对region split的分片大小进行优化以及对数据配置压缩,由于我们数据压缩比较高,同时数据采用单条记录存储多条记录的方式,

实际Hbase服务虽然写入量多但是对硬盘的依赖不高,根据我们对region大小进行优化设置成1g,Hbase 在使用的过程中有很多需要考虑的点 主要要考虑的是读热点或者写热点问题,

如果出现读热点或者写热点问题一般都是导致整个服务的不可用,读热点会导致数据查询不能快速响应,写热点会导致数据写入慢,

所以Hbase 这块主要是对rowkey的优化,另外一个监控系统Metrics 遇到比较多的写入和读取热点问题。

OpenTSDB

OpenTSDB 优化 我们主要是对metric 和tag的长度由3个字节增加到4个字节(需要修改源码),由于我们的Metrics数超过了千万,3个字节最大只能有1k6w,同时OpenTSDB本身会对历史数据进行聚合,聚合时间时间点发生在整点(容易导致瞬时负载高),我们对整点聚合频率进行了优化(需要修改源码),

再就是我们对tsd进行了读写分离,读写对tsd的稳定性要求不一样,读实际需要的更多要求快速响应,写更加注重的是稳定性,同时tsd本身会有数据缓存,通过读写分离很好在稳定性和性能方面做好平衡,用于读的tsd 我们更加注重查询性能和返回延时方面,写的进程我们更加注重是服务的稳定性同时由于需要缓存更多的数据我们需要给它配置更加多的内存。读方面我们则可以为请求延时进行控制设置超时时间避免tsd请求堵塞等。可用性我们采用接入Web专区的方式实现负载均衡和服务故障切换,同时接入后也可以对服务可用性进行监控,接入Web内部专区可以保证服务的安全不被外界访问,建议大家把内部服务也通过内部Web专区进行接入,同时Web上下线完全可以完全自助的上线自己的业务,一个服务接入1分钟左右就可以搞定非常方便。