本文讲解了携程在实时数据渠道的一些实践，依照时刻次序来阐明咱们是怎样一步一步构建起这个实时数据渠道的，现在有一些什么新的测验，未来的方向是怎样样的，期望对需求构建实时数据渠道的公司和同学有所学习。

为什么要做实时数据渠道

首要先介绍一下布景，为什么咱们要做这个数据渠道?其实了解携程的事务的话，就会知道携程的事务部分是十分多的，除了酒店和机票两大事务之外，有近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时，这个晋级就会收效。

在做完这些作业之后，咱们就开端大规模的事务接入了，其完结在基本上覆盖了携程的一切的技能团队，运用的类型也比初期要丰厚许多。

下面给咱们简略介绍一下，在携程的一些实时运用;

首要分为下面四类：

• 实时数据报表;
• 实时的事务监控;
• 依据用户实时行为的营销;
• 风控和安全的运用。

***个展现的是携程这边的网站数据监控渠道cDataPortal，携程会对每个网页拜访的性能做一些很具体的监控，然后会经过各种图表展现出来。

第二个运用是携程在AB Testing的运用，其实咱们知道AB Testing只需在经过比较长的一段时刻，才干得到成果，需求到达必定的量之后才会在核算上有显著性;那它哪里需求实时核算呢?实时核算首要在这边起到一个监控和告警的作用：当AB Testing上线之后，用户需求一系列的实时目标来调查分流的作用，来确认它装备是否正确;别的需求检查关于订单的影响，假如对订单产生了较大的影响，需求可以及时发现和中止。

第三个运用是和个性化引荐相关，引荐其实更多的是结合用户的前史偏好和实时偏好来给咱们引荐一些场景。这边实时偏好的搜集其实便是经过这个实时渠道来做的。比较类似的运用有依据用户实时的拜访行为推送一些比较感兴趣的攻略，团队游会依据用户的实时拜访，然后给用户推送一些优惠券之类的。

那些从前踩过的坑

在说完了实时数据渠道在携程的运用，让咱们简略来聊聊这个进程中咱们的一些经历。

首要是技能上的，先讲一下咱们遇到的坑吧。

咱们运用的Storm版别是0.9.4，咱们遇到了两个Storm自身的BUG，当然这两个bug是比较偶发性的，咱们可以看一下，假如遇到相应的问题的话，可以参阅一下：

storm-763：Nimbus现已将worker分配到其他的节点，可是其他worker的netty客户端不连接新的worker;

应急处理：Kill掉这个worker的进程或是重启相关的作业。

storm-643：当failed list不为空时，而且一些offset现已超出了Range规模，KafkaUtils会不断重复地去取相关的message;

别的便是在用户运用进程中的一些问题，比方说假如或许，咱们一般会引荐用户运用localOrShuffleGrouping，在运用它时，上下流的Bolt数要匹配，不然会出现下流的大多数Bolt没有收到数据的状况，别的便是用户要确保Bolt中的成员变量都要是可序列化的，不然在集群上运转时就会报错。

然后便是关于支撑和团队的经历，首要在许多接入前其告警和监控设备是有必要的，这两个体系是许多接入的条件，不然难以在遇到十分问题时及时发现或是快速定位处理。

第二便是阐明晰的阐明、指南和Q&A可以节省许多支撑的时刻。用户在开发之前，你只需供给这个文档给他看，然后有问题再来咨询。

第三便是要掌握一个接入节奏，由于咱们整个渠道的开发人员比较少，也就三个到四个同学，尽管现已全员客服了去应对各个BU的各式各样的问题，可是假如一同接入太多项目的话还会忙不过来;别的支撑还有重要的一点便是“授人以渔”，在支撑的时分给他们讲得很细吧，让他们了解Kafka和Storm的基本知识，这样的话有一些简略问题他们可以内部消化，不必一切的问题都来找你的团队支撑。

新的探究

前面讲的是咱们基本上上一年的作业，本年咱们在两个方向上做了一些新的测验：Streaming CQL和JStorm，和咱们共享下这两个方面的发展：

Streaming CQL是华为开元的一个实时流处理的SQL引擎，它的原理便是把SQL直接转化成为Storm的Topology，然后提交到Storm集群中。它的语法和规范的SQL很挨近，仅仅添加了一些窗口函数来应对实时处理的场景。

下面我经过一个简略的比方给咱们展现一个简略的比方，给咱们有个直观的感触。我的比方是

从kafka中读取数据，类型为ubt_action;

取出其间的page，type，action，category等字段然后每五秒钟依照page, type字段做一次聚合;

***把成果写到console中。

假如需求用Storm完结的话，一般你需求完结4个类和一个main办法;运用Streaming CQL的话你只需求界说输入的Stream和输出的Stream，运用一句SQL就能完结事务逻辑，十分简略和明晰。

那咱们在华为开源的根底上也做了一些作业：

• 添加Redis，Hbase，Hive(小表，加载内存)作为Data Source;
• 添加Hbase，MySQL / SQL Server，Redis作为数据输出的Sink;
• 批改MultiInsert句子解析过错，并反应到社区;
• 为where句子添加了In的功用;
• 支撑从携程的音讯行列Hermes中读取数据。

Streaming CQL***的优势便是可以使不会写Java的BI的搭档，十分便利地完结一些逻辑简略的实时报表和运用，比方下面提到的一个休假的比方基本上70行左右就完结了，本来开发和测验的时刻要一周左右，现在一天就可以完好，提高了他们的开发功率。

【事例】

休假BU需求实时地核算每个用户拜访“自在行”、“跟团游”、“半自助游”产品的占比，进一步丰厚用户画像的数据：

• 数据流：UBT的数据;
• Data Source：运用Hive中的product的维度表;
• 输出：Hbase。

本年咱们测验的第二个方向便是Jstorm，Storm的内核运用Clojure编写，这给后续深化的研讨和保护带来了必定的困难，而Jstorm是阿里开源的项目，它彻底兼容storm的编程模型，内核悉数运用Java来编写，这就便利了后续的研讨和深化地调研;阿里的Jstorm团队十分Open，也十分专业化，咱们一同协作处理了一些在运用上遇到的问题;除了内核运用Java编写这个优势之外，Jstorm比照storm在性能上也有必定的优势，此外它还供给了资源阻隔和类似于Heron之类的反压力机制，所以可以更好的处理音讯拥塞的这种状况。

咱们现在基本上现已把三分之一的storm运用现已迁到Jstorm上了，咱们运用的版别是2.1;在运用进程中有一些经历跟咱们共享一下：

***点是咱们在与kafka集成中遇到的一些问题，这些在新版别中现已批改了：

在Jstorm中，Spout的完结有两种不同的办法：Multi Thread(nextTuple，ack & fail办法在不同的进程中调用)和Single Thread，原生的Storm的Kafka Spout需求运用Single Thread的办法运转;

批改了Single Thread方式的1个问题(新版别现已批改)。

第二点是Jstorm的metrics机制和storm的机制彻底不兼容，所以相关的代码都需求重写，首要包含适配了Kafka Spout和咱们Storm的API中的Metrics和运用MetricsUploader的功用完结了数据写入Dashboard和Graphite的功用这两点，此外咱们结合了两者的API供给了一个一致的接口，能兼容两个环境，便利用户记载自界说的metrics。

以上便是我要共享的内容，在结尾处，我简略总结一下咱们的全体架构：

底层是音讯行列和实时处理体系的开源结构，也包含携程的一些监控和运维的东西，第二层便是API和服务，而最上面经过Portal的办法讲一切的功用供给给用户。

未来方向

在共享的***，我来和咱们聊聊实时数据渠道未来的发展方向，首要有两个：

持续推进渠道全体向Jstorm搬迁，当然咱们也会调研下刚刚开源的Twitter的Heron，与Jstorm做一个比照;

关于dataflow模型的调研和落地，上一年google宣布了dataflow相关的论文(强烈建议咱们读读论文或是相应的介绍文章)，它是新一代实时处理的模型，能在确保实时性的一同又能确保数据的正确性，现在开源的完结有两个：Spark 2.0中Structured Streaming和Apache的另一个开源项目BEAM，BEAM完结了Google Dataflow的API，而且在Spark和Flink上完结了相应的Executor。

下半年咱们还会做一些调研和探究性的测验，并寻觅适宜的落地场景。

作者介绍：张翼，携程大数据渠道负责人，浙江大学硕士结业，2015年头参加携程，主导了携程实时数据核算渠道的建造，以及携程大数据渠道整合和渠道技能的演进。进入互联网职业近10年，从事大数据渠道和架构的作业超越6年。