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

爱被打了一巴掌 2021-09-17 21:00 184阅读 0赞

**平台规模**

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

**　　平台架构**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70][]

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

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

**　　系统 “走马观花”**

**　　数据开发平台总览**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 1][]

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

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

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

**　　今年新进展**

**　　AI平台**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 2][]

虽然今年我们在底层上也做了很多尝试，但本次主要还是讲AI相关的基础设施上的 些工作。

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

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

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

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

**　　特征平台**

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

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

**　　模型Engine**

![BNfuqyq.png_web][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 3][]

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

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

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

**　　[大数据][Link 2]平台建设经验分享**

**　　选型原则**

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

就拿转向SparkSQL为例。不同于其他大厂早就用到了SparkSQL，我们去年年末才开始从Hive转到SparkSQL。 方面是因为SparkSQL在2.2之后解决了很多问题，稳定性上已经达到了我们的要求;另 方面是我们自身的条件也已成熟，团队中有 两位同学已经可以深入到Spark源码上解决问题。正是基于这种条件，我们才决定启动全面Hive转Spark的过程，这也是为什么说团队能力也很重要的原因。

**　　案例 - [数据分析][Link 3]基础设施选型**

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

其次是是否要用到Hadoop，这个主要看数据量及其增长情况，量不大的时候可以直接用数据库应对，要用Hadoop的话，现在 般采取HDFS加Spark的方式，数据存储格式用Parquet、Carbondata、ORC等。

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

**　　如何“拥抱”新技术**

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

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

**　　“成长的烦恼”有什么**

平台本身的增长肯定会给底层的技术人员带来 定的压力，主要体现在3个方面。

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

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

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

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

对于开源系统的使用，我认为还是要在思想上做好长期斗争的准备。关键的是要建立“代码 ”的维护能力，比如招聘时选择对技术有浓厚兴趣，能够沉下心来的同学;在底层团队通过各种层次的分享建立学习，研究的氛围。

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

小编我整理了一些大数据资料可以领取（Hadoop，Spark，flink，hbase，es等等，更有源码级的视频讲解资料），一个大数据的交流群：[\[\*\*878761222\*\*\]][878761222].欢迎大家进群交流讨论，学习交流，共同进步。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 4][]  
  
当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。  
  
但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有有效资源还是很有必要的。

[hadoop]: http://www.thebigdata.cn/Hadoop/10722.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70]: /images/20210724/65d4d7dd615a49c88e633d90f09000ba.png
[Link 1]: http://www.thebigdata.cn/JieJueFangAn/13315.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 1]: /images/20210724/4ffd5a7c1ffb46ad817a01f258852e92.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 2]: /images/20210724/3010b2d6ef3943fda2e15feeeb11757d.png
[BNfuqyq.png_web]: https://img1.tuicool.com/BNfuqyq.png!web
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 3]: /images/20210724/deb3809c6f434065900858fac670b559.png
[Link 2]: http://www.thebigdata.cn/YeJieDongTai/7180.html
[Link 3]: http://www.thebigdata.cn/JiShuBoKe/31800.html
[878761222]: http://shang.qq.com/wpa/qunwpa?idkey=42be6ba8447390a954623d99d0fcbf5030219b7eb3734345fecbced8663803df
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70 4]: /images/20210724/532685d3161f44a0959ac7f46a2bf9bc.png