当前位置:技术分享 > 技术参考 > 正文

携程基于Storm的实时大数据平台实践2016-10-10 09:51:35 | 编辑:hely | 查看: | 评论:0

本文讲解了携程在实时数据平台的一些实践,按照时间顺序来说明我们是怎么一步一步构建起这个实时数据平台的,目前有一些什么新的尝试,未来的方向是怎么样的,希望对需要构建实时数据平台的公司和同学有所借鉴。

本文讲解了携程在实时数据平台的一些实践,按照时间顺序来说明我们是怎么一步一步构建起这个实时数据平台的,目前有一些什么新的尝试,未来的方向是怎么样的,希望对需要构建实时数据平台的公司和同学有所借鉴。

为什么要做实时数据平台

首先先介绍一下背景,为什么我们要做这个数据平台?其实了解携程的业务的话,就会知道携程的业务部门是非常多的,除了酒店和机票两大业务之外,有近20个SBU和公共部门,他们的业务形态差异较大,变化也快,原来那种Batch形式的数据处理方式已经很难满足各个业务数据获取和分析的需要,他们需要更为实时地分析和处理数据。

其实在这个统一的实时平台之前,各个部门自己也做一些实时数据分析的应用,但是其中存在很多的问题:

首先是技术选型五花八门,消息队列有用ActiveMQ的,有用RabbitMQ的,也有用Kafka的,分析平台有用Storm的,有用Spark-streaming的,也有自己写程序处理的;由于业务部门技术力量参差不齐,并且他们的主要精力还是放在业务需求的实现上,所以这些实时数据应用的稳定性往往难以保证。

其次就是缺少周边设施,比如说像报警、监控这些东西。

最后就是数据和信息的共享不顺畅,如果度假要使用酒店的实时数据,两者分析处理的系统不同就会很难弄。所以在这样前提下,就需要打造一个统一的实时数据平台。

需要怎样的实时数据平台

这个统一的数据平台需要满足4个需求:

首先是稳定性,稳定性是任何平台和系统的生命线;

其次是完整的配套设施,包括测试环境,上线、监控和报警;

再次是方便信息共享,信息共享有两个层面的含义,1、是数据的共享;2、是应用场景也可以共享,比如说一个部门会受到另一个部门的一个实时分析场景的启发,在自己的业务领域内也可以做一些类似的应用;

最后服务响应的及时性,用户在开发、测试、上线及维护整个过程都会遇到各种各样的问题,都需要得到及时的帮助和支持。

如何实现

在明确了这些需求之后我们就开始构建这个平台,当然第一步面临的肯定是一个技术选型的问题。消息队列这边Kafka已经成为了一个既定的事实标准;但是在实时处理平台的选择上还是有蛮多候选的系统,如Linkedin的Samza, apache的S4,最主流的当然是Storm和Spark-streaming啦。

出于稳定和成熟度的考量,当时我们最后是选择了Storm作为实时平台。如果现在让我重新再来看的话,我觉得Spark-streaming和Storm都是可以的,因为这两个平台现在都已经比较成熟了。

 

 

架构图的话就比较简单,就是从一些业务的服务器上去收集这个日志,或者是一些业务数据,然后实时地写入Kafka里面,Storm作业从Kafka读取数据,进行计算,把计算结果吐到各个业务线依赖的外部存储中。

那我们仅仅构建这些就够了吗?当然是远远不够的,因为这样仅仅是一些运维的东西,你只是把一个系统的各个模块搭建起来。

前面提到的平台的两个最关键的需求:数据共享和平台整体的稳定性很难得到保证,我们需要做系统治理来满足这两个平台的关键需求。

首先说说数据共享的问题,我们通常认为就是数据共享的前提是指用户要清晰的知道使用数据源的那个业务含义和其中数据的Schema,用户在一个集中的地方能够非常简单地看到这些信息;我们解决的方式是使用Avro的方式定义数据的Schema,并将这些信息放在一个统一的Portal站点上;数据的生产者创建Topic,然后上传Avro格式的Schema,系统会根据Avro的Schema生成Java类,并生成相应的JAR,把JAR加入Maven仓库;对于数据的使用者来说,他只需要在项目中直接加入依赖即可。

 

 

此外,我们封装了Storm的API,帮用户实现了反序列化的过程,示例代码如下,用户只要继承一个类,然后制定消息对应的类,系统能够自动完成消息的反序列化,你在process方法中拿到的就是已经反序列化好的对象,对用户非常方便。

 

 

其次我们来说说资源控制,这个是保证平台稳定性的基础,我们知道Storm其实在资源隔离方面做得并不是太好,所以我们需要对用户的Storm作业的并发做一些控制。我们的做法还是封装Storm的接口,将原来设定topology和executor并发的方法去掉,而把这些设置挪到Portal中。下面是示例的代码:

 

 

另外,我们前面已经提到过了,我们做了一个统一的Portal方便用户管理,用户可以查看Topic相关信息,也可以用来管理自己的Storm作业,配置,启动,Rebalance,监控等一系列功能都能够在上面完成。

在完成了这些功能之后,我们就开始初期业务的接入了,初期业务我们只接了两个数据源,这两个数据源的流量都比较大,就是一个是UBT(携程的用户行为数据),另一个是Pprobe的数据(应用流量日志),那基本上是携程用行为的访问日志。主要应用集中在实时的数据分析和数据报表上。

在平台搭建的初期阶段,我们有一些经验和大家分享一下:

最重要的设计和规划都需要提前做好,因为如果越晚调整的话其实付出的成本会越大的;
集中力量实现了核心功能;
尽早的接入业务,在核心功能完成并且稳定下来的前提下,越早接入业务越好,一个系统只有真正被使用起来,才能不断进化;
接入的业务一定要有一定的量,因为我们最开始接入就是整个携程的整个UBT,就是用户行为的这个数据,这样才能比较快的帮助整个平台稳定下来。因为你平台刚刚建设起来肯定是有各种各样的问题的,就是通过大流量的验证之后,一个是帮平台稳定下来,修复各种各样的bug,第二个是说会帮我们积累技术上和运维上的经验。

在这个之后我们就做了一系列工作来完善这个平台的“外围设施”:

首先就是把Storm的日志导入到ES里面,通过Kanban展示出来;原生的Storm日志查看起来不方便,也没有搜索的功能,数据导入ES后可以通过图标的形式展现出来,也有全文搜索的功能,排错时非常方便。

其次就是metrics相关的一些完善;除了Storm本身Build in的metrics之外我们还增加了一些通用的埋点,如从消息到达Kafka到它开始被消费所花的时间等;另外我们还是实现了自定义的MetricsConsumer,它会把所有的metrics信息实时地写到携程自己研发的看板系统Dashboard和Graphite中,在Graphite中的信息会被用作告警。

第三就是我们建立了完善的告警系统,告警基于输出到Graphite的metrics数据,用户可以配置自己的告警规则并设置告警的优先级,对于高优先级的告警,系统会使用TTS的功能自动拨打联系人的电话,低优先级的告警则是发送邮件;默认情况下,我们会帮用户添加Failed数量和消费堵塞的默认的告警。

 

 

第四,我们提供了适配携程Message Queue的通用的Spout和写入Redis,HBbase,DB的通用的Bolt,简化用户的开发工作。

最后我们在依赖管理上也想了一些方法,方便API的升级;在muise-core(我们封装的Storm API项目)的2.0版本,我们重新整理了相关的API接口,之后的版本尽量保证接口向下兼容,然后推动所有业务都升级一遍,之后我们把muise-core的jar包作为标准的Jar包之一放到每台supervisor的storm安装目录的lib文件夹下,在之后的升级中,如果是强制升级,就联系用户,逐个重启Topology,如果这次升级不需要强制推广,等到用户下次重启Topology时,这个升级就会生效。

在做完这些工作之后,我们就开始大规模的业务接入了,其实目前基本上覆盖了携程的所有的技术团队,应用的类型也比初期要丰富很多。

上一篇:Hadoop新手学习指导之hadoop核心知识学习 管理大数据存储的十大技巧下一篇:

公众平台

搜索"raincent"或扫描下面的二维码