Hadoop集群从180到1500，携程大数据实践之路

内容来源：2018 年 09 月 08 日，携程大数据平台技术总监张翼在“2018开源数据库论坛暨首届MariaDB中国用户者大会”进行《大数据平台在携程的实践》演讲分享。IT 大咖说做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：3501 | 9分钟阅读

获取嘉宾演讲视频及PPT，请点击： t.cn/EZtuxxP。

摘要

携程你们应该是蛮熟悉了吧，全国领先的OTA平台，旅游出行相关的均可以在上面一站式的完成，从酒店和机票的预订到火车票和汽车票，租车等，只要你能想到的和旅行相关的全部东西，在携程上均可以轻松实现。

携程大数据平台现状

平台规模

2015年我刚加入携程的时候，它的Hadoop集群规模还仅有约180台，如今已经发展到超过1500台，也就是8倍的提高。同时天天的数据增量在200T以上，调度任务数9万，运行的实例超过18万，其中80%的做业都运行在SparkSQL上。 这些调度任务转换成底层任务大概是MR Job 27万，Spark Job 9万。实时方面咱们如今支持Jstorm和Spark-streaming，整个集群规模100以上。

平台架构

上图为咱们的平台架构。底层是自动化运维和监控；中间层是一些开源的大数据基础架构，分为批量计算框架和实时框架，批量部分的底层基于hadoop，在此之上的ETO主要是用Hive和Spark，另外还有Presto和kylin；平台最上层被划分为4个系统，开发平台Zeus、查询平台ART、AI开发和管理平台，以及实时数据平台Muise。

若是单从界面上来看muise就像一个管理平台，用户能够经过它作一些提交。但其实咱们还对Sprak进行了封装，并提供本身的library。这是为了限制并发资源的使用，让用户能够控制并发资源，同时可以触发外部报警。

系统 “蜻蜓点水”

数据开发平台总览

咱们的开发平台分为5个系统，最主要的是调度系统Zeus。Datax数据传输系统用于给用户提供快捷配置的界面，用户操做完成后任务会被提交给Zeus。

主数据管理系统会展现表的信息并分析Job和Job间的依赖关系，以及经过解析SQL获取总体序列。

数据质量系统中配置了一些质量校验的规则，在调度系统运行完成以后会触发质量检验任务，若是优先级较高的质量校验任务失败就会阻断主要调度任务执行。最后是统一的权限绑定系统，这部分较为简单就很少作赘述了。

今年新进展

AI平台

虽然今年咱们在底层上也作了不少尝试，但本次主要仍是讲AI相关的基础设施上的一些工做。

上图为简化的生命周期图，从数据处理到特征工程、模型训练、模型更新这样的过程，通常是AI训练的固定流程。当模型训练好并达到所制定的指标和要求以后，接下来就是上线，这部分分为特征上线和服务上线。

咱们指望经过图中所示的3个平台来支持AI研发的整个生命周期。以特征管理平台管理全部的特征，可以支持特征工程，快速生成一些训练集和测试集，可以以更为简便的方式上线特征。

模型引擎主要用来cover服务上线过程，目标是让用户只须要开发必要的数据抽取逻辑等，其余的部分均可以经过配置的方式来造成上线服务，该模块后续计划会和咱们公司的发布系统打通。而针对AI训练部分，咱们但愿经过AI训练协做平台来帮助用户更好的完成任务。

现阶段特征平台基本上开发完成，并已上线使用，AI训练平台刚刚开发完成，尚处于部署和测试阶段，而模型引擎仍在开发过程当中。（截至演讲时间）

特征平台

特征平台的特征配置包括基础信息、数据源、计算逻辑、存储信息。咱们的特征平台想作的是经过统一的SQL方式表示特征的计算逻辑，并以key value的形式存储。对于特征提取咱们提供了对应API，用户能够经过特征ID和别名来获取相关特征。

特征提取完成后，用户会测试特征上线过程，平台为此提供了随机生成离线和实时任务的能力。离线任务主要是在Zeus的基础上增长一些传输做业。实时方面则会生成blink任务 ，由Kafka读取数据并处理后放到Spark上。

模型Engine

第一期的模型Engine会提供模型服务的SOA框架，其中包含自动转换的Input Convertor、Out Convertor。

模型服务的数据通常分为两种，经过服务直接输入的数据或者放在Aerospike上的特征。用户要完成的是前面的transformer，作的更多的是根据输入的配置从Aerospike上获取特征，而后拼接在一块儿，再通过处理获得结果。后面的transformer基本上和训练的东西同样，只要经过配置的方式加载进来就能够了。

整个SOA框架由模型引擎管理系统负责管理，最后和咱们的发布系统Tars集成发布到模型服务集群中。

大数据平台建设经验分享

选型原则

技术选型主要受需求成本、技术趋势、团队能力这3点所约束。前两点相信你们都有考虑到，不过我要强调的是团队能力也很是重要，它并不是一种静态的要求，而是动态的过程，须要领导者培养团队各方面能力以适应不断出现的新技术。

就拿转向SparkSQL为例。不一样于其余大厂早就用到了SparkSQL，咱们去年年底才开始从Hive转到SparkSQL。一方面是由于SparkSQL在2.2以后解决了不少问题，稳定性上已经达到了咱们的要求；另外一方面是咱们自身的条件也已成熟，团队中有一两位同窗已经能够深刻到Spark源码上解决问题。正是基于这种条件，咱们才决定启动全面Hive转Spark的过程，这也是为何说团队能力也很重要的缘由。

案例 - 数据分析基础设施选型

对于数据分析基础设施选型咱们首先面临的问题是，选择自建仍是使用云服务，就我我的来看对于小规模没有特殊需求的数据分析，云服务是不错的选择。

其次是是否要用到Hadoop，这个主要看数据量及其增加状况，量不大的时候能够直接用数据库应对，要用Hadoop的话，如今通常采起HDFS加Spark的方式，数据存储格式用Parquet、Carbondata、ORC等。

另外还要考虑是否须要实时分析数据，目前这方面都是用的Spark-Streaming或者Flink。最后若是对数据交互查询的速度要求不高，用Spark就够了，不然推荐使用Presto、kylin、ClickHouse。

如何“拥抱”新技术

有效和有限的分散——是美国历史上最成功的基金经理彼得林奇的投资原则之一。它的作法是以90%的资金重仓预先看好的股票，剩下的10%分散到多支股票上，并观察他们的趋势，而后将后续趋势较好的股票升级到重仓池中。

技术的投入其实也适用于这个原则。团队中大部分的资源应该先放在主要使用的技术上，对底层的系统来讲要可以作到“代码级”维护。少部分的资源能够放在多种新技术或是平台的“预备”/ POC上，若是靠谱，能够开始用在低优先级的系统或项目上，最后也许会变成主要使用的技术。

“成长的烦恼”有什么

平台自己的增加确定会给底层的技术人员带来必定的压力，主要体如今3个方面。

第一是在运维方面，系统规模的不断扩大，会使得运维系统愈加复杂，而且种类也不断增多。

第二是开源系统的问题，开源是把“双刃剑”，它能帮你快速构建起相应的系统，但随着系统规模的增大，问题也会不断暴露出来。

第三是服务和支持方面，用户不断增加的“物质文化需求”与“短小精悍”团队之间的矛盾，临时的支持与问题排查工做也会变多。

解决运维问题最重要是在于自动化，而自动化的关键的有2个，一是要保证测试环境和线上配置一致，二是覆盖范围尽量全，特别是客户端部分也要涉及到。监控方面比较简单，主要是监控重要指标并创建自动恢复的机制。

对于开源系统的使用，我认为仍是要在思想上作好长期斗争的准备。最关键的是要创建“代码级”的维护能力，好比招聘时选择对技术有浓厚兴趣，可以沉下心来的同窗；在底层团队经过各类层次的分享创建学习，研究的氛围。

服务和支持问题的应对策略能够分为几点，包括从使用者的角度去设计产品，关注产品的易用性；控制推广的节奏；完善文档以及常见问题FAQ；加强BU数据开发的工程技术能力；短时间的全员客服等。

（文中相关数据，以演讲当时为准，可能和实际状况有所差别）

以上为今天的分享内容，谢谢你们！