携程基于Storm的实时大数据平台实践.docxVIP

携程基于Storm的实时大数据平台实践 首先先引见一下背景，为什么我们要做这个数据平台？其实了解携程的业务的话，就会晓得携程的业务部门是格外多的，除了酒店和机票两大业务之外，有近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的数据（应用流量日志），那基本上是携程用行为的访问日志。次要应用集中在实时的数据分析和数据报表上。 在平台搭建的初期阶段，我们有一些阅历和大家共享一下： 最重要的设计和规划都需要提前做好，由于假如越晚调整的话其实付出的成本会越大的； 集