斗鱼实时计算平台的演进

转载：http://gitbook.cn/books/57107c8976dc085d7a00cb04/bookSource/1461911087389.html

我是吴瑞诚，来自斗鱼，很高兴能有机会和大家分享斗鱼TV实时计算平台的演进。

做一个简单的自我介绍。我之前在淘宝干过三年，主要做HBase，目前在斗鱼TV做大数据开发。

斗鱼典型直播间介绍

这是斗鱼非常典型的直播间，55开，游戏打得好，牛吹得好，在斗鱼比较好，大家看到密密麻麻的字，就是弹幕，视频直播最火的场景，弹幕。很火的时候，上面会有礼物，用户给主播赠送火箭，鲨鱼骑着火箭的礼物飘过，这个火箭价值还挺高。

右下角这些图标是礼物，用户赠送给主播的礼物，鱼翅可以充值购买，鱼丸赠送，右边是土豪的贡献排行榜，贡献越多排名越高，右边是弹幕区。内容和形态就是这样，但是现在很火，有时候我们没办法预料现象级现象。

主要分享内容

第一，日志检索，日志全局检索。后面会展开，这个地方主要是以NginxPHP日志做事例。
第二，实时CEP系统，类KV的处理系统。
第三，实时流计算，流计算。 strong text

一、日志检索

这是一个现在的大数据的架构图，这个图最近才整理出来，越整就觉得体会越深，这个图里面看一下红红绿绿有一些方块，看PPT看得多的同学，可能司空见惯了，大数据架构图到最后可能都是这个样子，但是图上的每一个块都是踩过无数个坑，付出了血的教训才成为现在这样。

我加入斗鱼，当时是一个人负责整个这一大块的东西，后来就是因为网站量上来了，个人吞吐量到了上限，招了第一批人。我第一批是组内培养的，会有一些java开发，生拉硬拽凑到大数据团队，从最开始的小系统越做越大，做到现在这个架构。

最下面一层是数据源一层，Nginx、PHP日志，公司技术栈比较多，处理起来会越来越蛋疼，现在统一接入层是是Kafka，现在还没有完全接入。

上面一层就是数据清洗和格式转换包括初步的结算。

再上面一层就包括依赖MySQL实现的归档数据，最大一块是离线计算基于Hadoop，YARN。去年上线Spark，现在应用的范围还比较小，主要还是在风控和个性推荐这一块。

另外实时计算是Hbase，是之前经验比较熟悉，Hbase大家觉得有很多替代的产品，我觉得Hbase在第一层兜住海量热数据，我觉得Hbase的优势还是非常明显的。所以我这一块一直会保持Hbase在这个地方使用，在快速查询，可以相对于自助查询走的presto。

右侧实时计算主要基于Storm，今年大目标把spark作为重点引入。对于新框架的考量，小公司二次的开发能力或者定制能力弱一些，我们现在主要应用短平快的一些方式，比如，主流的有一些大公司BAT、京东、美团把坑踩完了我们再上，这样我们成本会小很多，我们会跟进spark，spark社区活跃得让人没办法忽视它，它现在活跃程度比Hadoop强一个量级。

最右边是Elastic，最开始引入的时候只是做一个搜索引擎，后来越用越觉得爽，真的是一个神器，后面会具体展开。

再就是上面的服务数据层，前端网站和服务层使用，再就是Dashboard，监控、个性推荐、用户行为分析、风控系统、搜索引擎、其它数据应用。

平台监控非常重要。

这是Lambda架构，这三层架构，P处理层，再是上面的加速层到服务层，这三层架构，应该可以覆盖绝大多数的大数据团队架构的场景。

我们最开始，只有几个PHP实例，出了问题，我就上去grep、awk，然后规模上来了，机器和应用实例突增，就用rsync和HiveUDF的方式，把日志收集起来，按照时间粒度切碎了拖过来，然后用Hive进行一些匹配，形成这么一个非常初级的系统。

到了现在，ELK，用的很爽的系统，能支持的量很大，可扩展，全文检索，很多时候包括技术团队定位问题非常方便，有这几个特性能满足基本使用。如果再能够帮他们做一些告警，包括量的告警，文本的告警，有更好，这也是我们现在在做的。

这是实时日志检索的架构图，大家可以看到应用场景，当时flume用得最多，应用场景变得比较快，我们的业务调整也非常迅猛，新场景中发现flume有两个场景没办法满足，一个场景是C++场景，它的量太大，他们的日志按实例文件夹写本地；一个是，Java太耗资源，包括CPU、包括内存，后来我们觉得这一块要做一些改变。

最开始的方案，因为我们有C++的团队做服务化，他们觉得我们可以自己造轮子，这个轮子比较简单，后来我做了一圈对比，发现Logstash新版本中，有一个Beats组件，是golang实现的。

架构图中间以Elastic技术栈为主，包括中间汇聚层在不久将来会被替换掉，但是现有的一些场景，如果一直稳定的话先保持现状。因为我们在这个阶段它比较稳定。

Flume 的Memory channel在量大的时候会OOM，这个时候把溢出的量落地到disk上面，这样可以在保证效率的同时能增大Flume能承受的吞吐量，这样让flume很稳定，一直沿用到现在。

现在还是用Flume做了汇聚层，我们后续会使用Kafka做汇聚层，有很多场景，有些日志可能回头还要再消费或者说要做Pub-sub，现在模式很难实现，必须要用到Kafka。

日志数据在图的下方走了Elastic，用Kibana做的UI，Kibana 2.0以后使用上会有很多不顺畅，我这一块其实建议大家二次开发，二次开发的成本不大，比较容易上手，所有的接口都可以走API，定制起来方便，图上方是走的Hdfs出报表。

再说一下踩过的一些坑。

首先Flume的选型。我最开始看中还是因为他是Apache的产品，觉得它稳定，在很多公司PPT里面，我稍微估计一下，flume出现的概率比其它产品出现频率高很多，所以做一些压测做了对比，差不太多，就选了flume，现在要新用或者要换型需要更详细的压测。

channel这一块，最开始内存到disk到现在两个方案混搭在一起，但是占资源特别耗资源。

flume的监控，一定要先考虑监控再上新的技术栈。

在Elastic上，我们跟Solr做对比，大家可以看一下纯开源的组建跟有商业团队支撑的开源产品，社区活跃度和产品迭代不是在一个量级上，Elastic现在已经开始注重使用体验了，这一点是Solr还没有纳入考量的点。

因为Elastic除了我们最开始最传统的搜索引擎、文本搜索，现在更大的一块可以当作我们的多维自助查询，水平扩展能力非常强，因为数据结构的天热优势，就有一些场景，包括多维的及时查询这一块有非常强悍的性能。

ES插件上，我们使用了Kopf做监控，head来操作索引。

ES读写分离。ES集群拓扑越来越大，如果按照默认的拓扑来使用的话，可能量上没法满足很多场景，比如，如果读写不做分离，查询极有可能把线上写的节点直接压垮，这样就建议有一个专门的节点来负责读。

对于资源隔离，我们使用了几个小的Elastic的集群来满足各个功能。因为，Elastic是P2P的，无主。无主有一个问题，有时候没有办法很强的控制某些节点行为，这时候要做一些隔离，最见效的方式就是按照小集群直接做隔离。

避免索引过大。这一点大家如果能注意把不必要的字段建到索引能解决大部分。

最热的查询中避免用range查询。

JVM heapsize设置，我们现在一直使用32G，Hbase集群也是这样，尽管集群配置很高，Hbase的配置还是32G。

GC方面，我们使用的是CMS，在线上使用、压测表现看的话，G1稳定性和用户体验看来都会差一些。

二、实时CEP系统

最开始我们做一个指标统计，大家把数据推到我们这边来做一些统计，然后借助redis做统计并最后把结果数据保存在Redis，简单的统计场景OK了，后来业务场景复杂了，产品线多了，redis单个实例肯定不够，可扩展性和数据规模是redis暂时无法越过的门槛，所以我们又很自然用到了Hbase。

Hbase使用有两大点需要注意：

第一，rowkey的设计，Hbase中除了rowkey没有索引可供使用。

第二，数据压缩，历史数据的压缩很关键。一个指标两个指标做抽样做一些归档很好做，但是怎么做到统一，而且还很简单，我们能直接拿来用，这个时候碰到open TSDB，一个时间序列存储方案。

最开始也用了InfluxDB，感觉有时候只要压力上来了之后，它可以没有征兆挂机，后来干脆就考虑到open TSDB。数据揣拽产生图形，基于OpenTSDB，能满足很大的量。

这个系统中真正性能考验的其实还是Hbase，Hbase OK，opentTSDB也就没有问题，我们会一直把这个方案做下去，基于open TSDB，我们可以很灵活做定制，它本身就是基于Hbase做了定制的特性，包括我刚刚说到对rowkey的设计。

对数据压缩，每一个指标每一个小时会有一个row，open TSDB帮我们做了。后面有定制需求我们从头开始做，这一块是比较简单的，底层Hbase性能是没有问题，越往后看，Hbase有很多地方它会做得越来越通用。因为它的性能这一块显性能没有问题，后面卡顿的问题会有明显的提升。

回到刚刚上面的图这是CEP系统，这个图上面，大家可以看一下。

从数据收集，第一个parser会走到Kafka，从spark走到Hbase，走到这一步就走到了业务系统，包括我们的监控系统，这是有一个业务流程，现在可以简单理解成某些指标大于阈值就觉得它的是一个嫌疑事件，需要告警的，简单理解就是这样，这一块马上引入规则引擎，这一块业务变化频率太快了，发布速度拖了后腿，在已经测试上了。

到后面有一些结果的存储，再有告警的推送，这个地方也是直接走到Hbase。后面有一些统计好的指标可以拿来用的，这个地方我们走到了open TSDB，这个图就没有重新再画，直接从Cloudera Blog上面借用，这个架构图和我们的系统是一模一样的。

Open TSDB，业务指标非常灵活，我们现在有一些CPU指标，打出来我们收集起来，各个指标汇集在一起，而且是秒级的力度，这个力度因为指标量大，时间粒度比较细，我们服务机器的服务数越来越大，现在还碰不到瓶颈。

关于Hbase使用。现在用Hbase的公司越来越多，2011年淘宝这一块就已经开始在线上大规模使用，Hbase这一块很稳定，从0.96之后就已经可以说到非常稳定，1.0有一些变化，1.0之后的Hbase是值得大家使用的。

rowkey设计可以写一本书，这里只做简单介绍。Hbase没有索引，所以rowkey非常关键，我们通过rowkey定位到数据，如果通过rowkey能约精确定位到数据，查询效率越高，用这个思路看看业务场景和看看使用，可以做一些相应的优化，做一些提升。

HBase不适宜的场景，包括多维度索引、需要事务、稳定性要求极高。

关注写热点，一般，按照默认的Region Split方案，上线后如果写压力比较大，都会有写热点的问题，这时需要考虑预建region。再就是写压内考虑writebuffer、WAL、autoflush，我写的要求很高，数据一致性要求很高那这事就不好办，只有做权衡，写性能上和数据一致上做权衡，下面三个参数只要你调了或者关了，可用性就会丢，有这个风险择，这是预先告诉大家。

对日志类的表化考虑关闭compact，手动触发GC。

Open TSDB表设计和原数据和数据表。这是官方图，讲得非常透，大家看一下怎么保证维的很多，数据量很大的时候，能够基于open TSDB把这么一个系统做得高效，就是通过一套rowkey，还有右图按照时间力度做row的压缩，我觉得主要这两个特性保证它的性能。

这是跟open TSDB密切相关的两个点。

三、实时流计算

这一块我们现在斗鱼用得规模比较大，和大公司比可能就有一点小巫见大巫，但是我还是想分享一下，从0到1的过程，包括第三点，从1到1.1的过程。

流计算。比如，我们上了一个专题或者我刚开始提到，英雄联盟有一个决赛，线上有量，量有多大，只能根据卡不卡，只能主观上感觉卡不卡做一个评估。后台服务器的一些数据指标比较延时，刚开始靠猜，靠感觉，感觉要上机器了，要调一些流或者压力到另外一部分机上，靠感觉。

包括有一些上专题，比方说有一些活动，锤子或者魅族、乐视新品发布，他们的量，有时候没有能想象的大，有时候会非常大，但是我们没有办法做一些预案，所以这个时候我们就慢慢有了这个，这是我们最开始的一个迫于压力有了这样一个方案，redis实时统计的量。

用户多了，鸟就多了，各种羊毛党就越多，这一块有了一个风控，再一个个性推荐，用户多了之后，用户群体户越来越多样化，这一块就考虑个性推荐，千人千面，这一块是后来第二阶段的需求。就有了现在storm加spark Streaming的方案在跑。

这是数据流的架构，最开始只有最上面的架构，web、APP，在Nginx Lua，这是锤子2发布会捐赠的一个项目，他把世界上最快的两个系统，一个是Nginx和Lua，加在一起性能非常好强悍。基于Lua和redis，性能好，又好用又稳定，又不吃资源。

到了Kafka这一层，就有了另外的一些数据，比方用户行为数据接入进来，关系表MySQL，我们没有其它的关系存储。到了Kafka出来之后就是storm，是线上规模用得最大，我刚才说的数据产品都是基于storm，后面简单介绍一下storm踩过一些坑。

Spark吞吐量是非常好的，因为两个数据模型就决定了他们两个侧重业务场景是不一样的，后面离线计算，这个中间有一个是数据应用层，我们可以从实时计算到数据应用层，会写到中间离线层，又有另外一批数据到前面的应用层，实时数据监控和其它应用。

刚刚讲了数据收集这一块，尤其用户行为数据，包括另外有一些服务层的服务，开始堆PHP，太耗资源，我们就发现OpenResty。

再用Storm，我先把这个罗列在这个地方，Storm优化主要就是基于这两个逻辑对象图。

Storm的新版本中，已经剥离了对ZK的依赖。我们所有的调优调这几个对象的参数，比方提高并行度，我们要提高时间时效，就是基于这个图。

这个图中，数据流怎么从这个流程里面最快的流入，最快流出，这就是实时流计算的初衷或者说包括最终的解决方案，也就是一直在优化。就比方说我们在第一级Kafka或者redis出来之后进到storm，越简单越快把消息弄进来最好。弄进来之后越快把消息处理完统计完把数据推走，越快推走对压力越小，处理时效吞吐量越大。

如果我们做优化，会去分析在第一个bolt1或者bolt2，如果里面有堆积，是在哪一个逻辑里面堆积，会考虑增加并行度或简化它的逻辑，让数据流尽快从第一级到第二级到第三级，流出数据流程，我们整个优化的思路就是这样。

bolt1、2到bolt3，想跟大家分享，我们很多时候优化Storm忽略一个点，Storm依赖外部资源会成会我们的瓶颈，我们的数据没办法往外面推，没办法落地，后面一层堆积也会直接制约我们优化的一个瓶颈。

我们最后往redis写，性能强悍，你一个storm没问题，当时用一个redis做一些hush，做分散，还是解决不了，后来把redis替换掉。

这是我们在storm优化整体的思路，比较简单，主要几大块。spout数和Kafka中的话题的partition数相匹配。监控每一个执行的时效，去做监控，及时发现某一些componet要不要做优化。

我们最开始上storm就有了spark流，流利用在时空监控的场景，这是今年2016年的大方向。

这是流的简单使用有一些心得，踩过一些坑。批处理时间。换粗需要经常的使用的数据。集群task并行度，使用Kryo序列化。

这是我们踩过的巨坑，最后和大家强调一下。

第一个踩过的巨坑就是监控。

我们有很多量，现象级的，百万级的用户立马在一秒到十秒用涌入一个直播间，这个直播间放在和其它直播间放在一个server上面，立马卡顿不卡用，如果在监控这一块，可以解决很多的一些告警和预警。包括有一些业务的指标监控，监控这一块非常重要。

今年做了比较大的一块，就是在做统一监控平台，现在我们也是在花主要的开发资源做这一块，因为我们前端有网站端后端有C++服务端，语言异构排查起来就存在，没法定位，第一反应大家很本能甩锅，就需要统一监控平台。

第二，安全。

最开始太粗放，我们最开始做网络隔离，我们的集群是第一次做了网络上的隔离，然后后来就包括人员越来越大，因为不可能是我一个人干，也不可能做这么多业务场景，用的人越来越多，包括其它团队，业务分析师做数据分析用到线上环境，这个地方安全非常重要。

第三，一定的余量。

预估业务、提需求，上机器这么一套下来，就一两个月，小公司不要扣这部分的成本，起码预留20%的量。

探索式数据集市、推荐系统、风控系统，这是我们今年最大的三块目标。

斗鱼实时计算平台的演进相关推荐

阿里实时计算平台的演进和运维
本文整理自阿里云实时计算高级运维专家王华 (尚付) 在 Flink Forward Asia 2021 生产实践专场的演讲.主要内容包括:演进历史和运维挑战.集群运维 Flink Cluster.应用 ...
唯品会实时计算平台的演进之路
来自:DBAplus社群本文根据王新春老师在[2018 DAMS中国数据资产管理峰会]现场演讲内容整理而成. 讲师介绍王新春,唯品会高级经理.数据平台实时团队高级架构师,主要负责实时计算平台.实时 ...
SLA 99.99%以上！饿了么实时计算平台3年演进历程
来自:DBAplus社群作者介绍倪增光,饿了么BDI-大数据平台研发高级技术经理,曾先后就职于PPTV.唯品会.15年加入饿了么,组建数据架构team,整体负责离线平台.实时平台.平台工具的开发和 ...
马蜂窝实时计算平台演进之路
MES 是马蜂窝统一实时计算平台,为各条业务线提供稳定.高效的实时数据计算和查询服务.在整体设计方面,MES 借鉴了 Lambda 架构的思想.本篇文章,我们将从四个方面了解 MES: 1. 关于 L ...
58同城实时计算平台架构实践
背景 58同城作为覆盖生活全领域的服务平台,业务覆盖招聘.房产.汽车.金融.二手及本地服务等各个方面.丰富的业务线和庞大的用户数每天产生海量用户数据需要实时化的计算分析,实时计算平台定位于为集团海量数 ...
接近淘宝 80%的大数据实时计算平台，从0搭建的经验和坑
上周一,来自武汉的直播平台斗鱼TV宣布C轮融资,腾讯领投的 15 亿人民币,距其获得 B 轮1亿美元不到半年,也是大写的牛逼. 但小寻更关心他们的大数据架构,作为一个在 2 年多时间里崛起的公司,其流 ...
基于Apache Flink的爱奇艺实时计算平台建设实践
导读:随着大数据的快速发展,行业大数据服务越来越重要.同时,对大数据实时计算的要求也越来越高.今天会和大家分享下爱奇艺基于Apache Flink的实时计算平台建设实践. 今天的介绍会围绕下面三点展开 ...
bilibili Saber 实时计算平台架构与实践【Apache Flink 替换 Spark Stream的架构与实践】
摘要:本文由 bilibili 大数据实时平台负责人郑志升分享,基于对 bilibili 实时计算的痛点分析,详细介绍了 bilibili Saber 实时计算平台架构与实践.本次分享主要围绕以下四个 ...
携程实时计算平台架构与实践丨DataPipeline
文 | 潘国庆携程大数据平台实时计算平台负责人本文主要从携程大数据平台概况.架构设计及实现.在实现当中踩坑及填坑的过程.实时计算领域详细的应用场景,以及未来规划五个方面阐述携程实时计算平台架构与实 ...
滴滴是如何从零构建集中式实时计算平台的？| 技术头条
作者 | 梁李印责编 | 唐小引出品 | CSDN(ID:CSDNNews) 滴滴出行作为一家出行领域的互联网公司,其核心业务是一个实时在线服务.因此具有丰富的实时数据和实时计算场景.本文将介绍滴 ...

斗鱼实时计算平台的演进

斗鱼实时计算平台的演进相关推荐

最新文章

热门文章