数据平台管理之道｜如何提高管理效率
作者|单超
编辑|林颖
供稿|eBay ADI Team
本文共9232字，预计阅读时间18分钟
更多干货请关注“eBay技术荟”公众号
导读
最近读到一本很热门的技术书籍——《Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems》（作者为Martin Kleppmann），全书共分为三个部分，其中开篇第一节就提纲挈领地介绍了搭建一个可靠的、可扩展的和可管理的数据系统的基本需求。读完之后，让我有种相见恨晚的感觉，也顺势有了总结过去一段时间我们团队的一些好项目和产品经验的想法。
本文的内容主要集中在高效的管理解决方案，总共分为6个部分，分别从标准化、可观测性、易操作性、可升级性、容量管理以及服务化和产品化来分享我们在开源大数据平台关于可管理性问题改进的一些思考和案例，希望能够一起学习交流。前 言
数据平台可以有很多种分类方式，比较主流的是根据业务场景分为:
1）在线系统
有丰富的Online Transaction Processing（OLTP）数据库, 有高性能的SAN存储系统。
2）离线系统
传统的Online Analytical Processing（OLAP）数据仓库，有各种非常流行的大数据组件，如Hadoop、Spark等。
近几年，许多新生的分布式数据平台软件（如Apache Pulsar、Doris等项目）已经比前辈产品有了长足的进步，这是因为这些新生软件在设计之初就已经集成了很多可管理性的需求，可以大幅降低管理难度。但是大部分公司的实际情况还是重度依赖于上一代的产品（如Hadoop、ElasticSearch、 Kafka），而且这些产品的体量往往都已经发展到了相当大的规模。所以个人认为，在完全被下一代产品替代之前，还有很长的路要走。
下文我将通过一些工作中遇到的实际的问题来介绍我们eBay的团队是如何提高已有的大数据平台的管理效率，也希望这些分享能够给大家一些启发。
（为了便于理解，下文会对问题进行简化/假设，敬请谅解。另外，由于篇幅问题，文中提到的一些技术/问题会在后续的系列文中进行详细描述，欢迎大家多多关注！）
1 标准化
标准化管理并不是一个新的话题。当一个平台管理的规模到达一定程度之后，必然会出现标准化管理的需求。在07年我刚加入eBay的Oracle DBA团队的时候，当时对于几百个Oracle数据库的管理流程已经能通过自动化程序来实现了。那时，还没有Puppet/Salt等软件，管理员需要通过比较朴素的自动化脚本，比如定期Rsync的方式，将需要标准化的管理配置、管理脚本、元数据等定期地推送到目标机器。而且，当时的场景和管理方式也非常简单，比如会有专门的系统管理员负责SAN/Solaris等系统的标准化安装，会有专门的Oracle管理员负责Oracle软件的标准化安装。每一个责任人各司其职，都对于自身管理的系统有着深厚的管理经验，也有很强的意愿去保证标准化。
但是随着近期的DevOps理念推行之后，许多平台的管理权被下放到了研发人员，在OpenStack/物理机时代, 许多时候研发人员并没有很强的意愿投入到运维上面。举个例子，当研发人员有权限申请虚拟机、拥有Root权限并且能发布自己应用的时候，是否能够保证所有的系统配置都是公司统一标准？对于核心的业务系统，许多公司会推行线上业务发布系统来隔离研发的权限。这对于80%的应用程序来说是可行的；但是对剩余的20%，我们称之为Generic（通用）应用，就会慢慢变成“三不管”的平台。
很明显的一个例子就是大数据平台，当时我们的平台经过几年的演化，问题越来越严重。因为：
1）大数据没有运行在虚拟机上，所以从OS安装、系统优化、硬件监控等问题都下放给了大数据团队，而这个团队大部分人都是Java开发工程师，因为对运维管理工作的不熟悉不擅长，会导致对一些标准化要求的忽视。
2）因为特殊的网络隔离需求，平台被要求放在一个独立的区域，这就需要特殊的流程来开通防火墙，以实现和线上区域的打通。
3）大数据服务器硬件和软件变更频繁，团队需管理着几十个集群、几万台机器，疲于奔命。
幸好我们有足够聪明的工程师团队，我们从6-7年前开始搭建一套生命周期管理系统。从第一代的Hadoop Robot到第二代的Delos, 虽中间走了些许弯路，终于用5年的时间成功地将所有的问题得以解决。目前这套系统现在已经非常成熟了，可以解决我们在管理层面近乎所有的需求，比如日常变更、月度升级等。在这里，我们以Delos的配置模块为例，来分析我们是如何来达到配置标准化的（由于Delos这个产品随着日常各种需求已经发展得非常繁复，因此本文对其不会做其他展开描述）。
● Delos配置管理系统
Delos配置模块简化版的需求是：支持全局性地管理不同集群的不同组件的配置，支持自动配置发布和修复，并且允许多版本配置的存在，来满足定制化配置测试、灰度发布等场景。
经过分解后，核心需求有如下4点：
1）基础模块基于Agent的配置发布，需要支持十万服务器的规模；
2）灵活的分层配置设置（如下图1-1所示）
用过Hadoop的同学会知道Hadoop经常是多个组建共存于一个实例中，比如DataNode与NodeManager或Hbase RegionServer会共存，那么配置管理就一定要考虑到分层的支持，也就是会有更细粒度的配置变更需求，而不是简单的一个模块一套配置全局替换；
图1-1
(点击可查看大图)
3）服务内存中、本地磁盘上和数据库中的三个层级的配置可视化（如下图1-2所示）；
图1-2
(点击可查看大图)
4）配置不同步的自动告警和修复
有了可视化和后台数据之后，相关自动化可以很快接入。
通过这个系统的引入，我们降低了配置管理的难度，大大减少了因为配置不统一而导致的线上问题的数量。
在eBay，我们有一个方法论叫WISB(what it should be)/WIRI(what it really is), 这个理念在K8s出现之前就已经在我们公司被广泛地接受。类似控制面的实现现在已经非常成熟，感兴趣的同学可以参考https://kubernetes.io/docs/concepts/architecture/controller/, 了解K8s如何通过定义期望的状态（监控当前状态）和一个控制器（来自动触发流程），可以达到完全自动化最终一致性的目标。
近几年随着K8s的盛行，标准化的治理工作也相应变得越来越容易，绝大部分工作可以交由K8s来实现，也更方便于平台的管理。有了这样一套标准化管理的系统，大部分时刻都可以实现无人值守，因为你只要定义好目标状态和策略，可以实现诸如一台机器3块坏盘以内自动下掉坏盘的目的，而无需人为干预。
2 可观测性
关于可观测性，这里首先要推荐阅读PingCAP黄东旭的两篇文章——《我眼中的分布式系统的可观测性》和《如何做出让人爱不释手的基础软件》。
他在文中提到了四个象限，如下图2-1所示。下图的右侧代表传统意义的监控系统，对于已知的Metrics进行收集，以辅助完成对当发生已知/未知问题时的故障分析。而左侧是对一些不确定的事件的观测，比如对于一些可能发生的问题的预处理。
图2-1
(点击可查看大图)
我觉得最复杂的问题往往也是出现在左下角的象限中，即发生了一个新的未知问题，因为往往在分析这类问题时，我们会发现：没有足够的数据支持。
可观测性在我们平台的落地目前也只处于初期阶段，未来还会有非常广阔的空间。比如，某个Spark线程在某个历史时刻不响应的原因追溯；通过何种方式来启用更多的监控；如何对分布式线程做追踪；如果在问题出现的时候自动打开Debug，如何有全局性的视角去观察几万个应用分布式运行在几万台节点的状态等等。
我们目前的观测性主要做到的还是在上图的右侧，可以将许多已知Metrics/日志（包括系统的、应用的）都统一存储到后端系统，比如Prometheus/CH/ES等，而基于这些观测到的信息可以给出系统性的优化建议，或者直接触发自动化流程来修复问题。此类系统的搭建，已经能够大大提高人效，可以解决绝大部分系统遇到的问题。
在这方面，我想分享比较有趣的两点观察。
1）云平台化
在往K8s的迁移过程中，平台也在不断地演进。对于Hadoop，目前我们虽然运行在K8s云平台，但是并不是完全的云原生。比如，我们运行Yarn的应用,需要有Setuid的权限来代理提交不同用户的任务, 如果Pod没有SYS_CAP_PTRACE的权限, Netstat命令就无法读取这些用户的PID。又比如，我们有大量硬件故障监控的总结，如磁盘故障的修复，在迁移到云平台之后需要贡献给云平台部门来执行检查，而我们可以通过集成Etcd里的监控信息来触发我们的自动化流程。还比如，对于Elasticsearch, 我们通过Local Dynamic的方式来定义Local PVC以申请存储，当出现SSD变慢时，我们需要快速定位到宿主机对应的磁盘来快速报障。
2）许多开源系统对于观测性普遍不重视
大部分系统只能够做到核心Metrics的统计收集，而对于运行在系统内部的工作负载监控比较薄弱。比如Hadoop系统，对于上面运行的大量MR/Spark任务, 只有一套收集系统来将核心的任务状态固化下来，但是很难使用。所以业内会有类似Dr Elephant的系统来做二次的收集和分析，对此我们的一些经验可详见2019年初分享过的一篇技术博客——干货 | eBay Hadoop/Spark自助分析系统实践（点击阅读）。而大部分系统对于一些核心组件的监控也一样不完整，在我们2021年分享的文章“Hadoop平台进阶之路 | HDFS NameNode性能优化实践（点击阅读）”中我们也介绍过我们对于NN锁的优化，这个过程中发现缺失了大量的核心监控，这也是需要自行添加的。还有ElasticSearch系统，这个分布式系统对于运行在内部的查询、变更等缺少一个高效的视图，去辅助管理员分析、优化和解决问题。在这些方面我们也参考了许多传统数据库的先进做法，最终选择通过主动打点的方式，将许多内部缺失的信息补充进来，进而便于基于这些有效信息做自动诊断和优化。
如前文所提，我觉得我们在可观测性这个领域还有非常多的机会去提高，我们也希望会有更多的机会回馈给社区，将我们的一些所知所学贡献给更多的同行。
3 易操作性
易操作性是许多开源大数据平台的一个缺口。这是由于开源大数据平台从产品角度来设计的高级别的操作命令比较少，所以需要使用这些平台的团队自行做很多额外的增强工作。
举一个传统数据库MySQL的例子，大部分管理过MySQL的工程师，都会用到一个叫“pt-online-schema-change”的第三方工具来实现在线DDL, 通过一个叫MHA的工具来做主从的切换。这些应该是数据库提供的基础功能，但是由于数据库不同的发展阶段，迟迟不能够在核心系统中支持。对于此，Oracle工程师就不用担心了，这方面的工作基本上都可以托管给数据库系统本身，也不会担心有额外的数据一致性问题。
在大数据领域中，易操作的问题会更加严重，一些操作（如升级会涉及到大量的OSS依赖组件）的复杂度是指数级别的升高。而看似简单的命令（如Elasticsearch的Reindex、HDFS的Datanode Decommission、Namenode的重启）, 都并不是一个可以简单提交而不去密切监控的命令。为了能够安全并且高效地执行变更，我们当时提了一个指标，希望能够将所有的日常变更都接入到Delos系统。
正是得益于这样的系统，我们在平均每周可以执行5-10次有计划的变革, 并且可以开放给公司的其他系统来进行API集成。比如硬件部门如果需要操作某些机器，可以不通知我们而自动下发节点下线的指令，而且不会影响到任何运行中的任务。下面我们将通过我们系统的一些截图来展示我们是如何进行操作的：
1）部分主节点的操作命令（总共有50+种操作，如图3-1）：
图3-1
(点击可查看大图)
2）部分从节点的操作命令(总共有30+种操作，如图3-2)：
图3-2
(点击可查看大图)
3）批量选择机架进行操作（如图3-3）：
图3-3
(点击可查看大图)
上面执行的每一个命令都是由我们预先定义好的工作流来完成的，任何一个操作都会有完整的检查流程、通知机制、重试机制等，尽可能的实现无人干预。比如下图3-4是一个经常被执行的修复机器硬盘故障的工作流的截图：
图3-4
(点击可查看大图)
4 可升级性
前文提到了标准化，实际上要达到标准化的一个必要条件就是能够支持快速升级。随着软件使用规模的增大，升级需要的投入却不能随之线性增大，否则会进入到一个恶性循环而导致越来越难以进行单一大规模系统的升级。对于每一次升级，兼容性测试的覆盖度、升级前业务的透明切换、升级后的自动校验、异常的自动回滚都是必须要考虑的几个步骤。
下面我分享我们工作中遇到的几个典型的可升级性的问题。
1）操作系统的升级2016-2017年，我们为了推进标准化，当时定了几个指标，其中之一就是操作系统版本的统一。这就要求整个系统可以支持流水线式的自动系统安装且不能影响数据和计算。为了这个目的，我们搭建了前文提到的Delos系统，将所有的系统从Centos6升级到了Centos7。过程中所有和PDMR（Provision / Deployment / Monitoring / Remediation）相关的缺口都得到了解决。整个项目前前后后花了2年多，清理了大量的历史包袱，达成了第一阶段的标准化。
到了2021年，我们又提出了新的要求，因为公司具备了支付公司的属性，我们期望每隔一个月对所有机器统一打上安全补丁并重启操作系统。对于Deployment/无状态的应用，这个目标还相对容易实现。但是对于有状态的数据存储系统，我们陆续发现了很多的不足，如升级导致的数据节点短时间掉线问题。我们肯定不期望每次重启都要带来大量数据的搬迁。那么数据搬迁的超时时间阈值该如何定义，才能满足尽可能少地重新同步数据，并且不会带来数据丢失？如何能够快速地最大并发地重启DN节点，并且不带来性能的损耗和任何数据丢失的可能性？
2）计算引擎的升级2017-2018年，随着社区Spark 2.3的稳定推出，我们也希望快速将Spark版本从2.1升级到2.3。难点在于：在数据仓库场景中，计算引擎的升级是一个炸弹，因为开源系统版本升级可能会带来性能的变化，导致平时正常运行的任务因为执行计划的变化无法成功完成。更为严重的是升级带来的行为变化可能会直接导致数据问题，比如突然出现空值而没有告警，数据精度改变导致最终GMV计算异常。也就是这些难点，第一次升级2.3我们采取了一种比较保守的做法，让用户自行做引擎版本的切换和数据的校验，可想而知这个过程是多么的漫长而痛苦，我们花了近2年的时间才梳理完所有的任务并且完成了一轮的升级。到了2021年我们又开始要计划新的3.x版本的升级，计算引擎可升级性的缺陷依然存在，而我们和用户都不期望再来一轮繁重的测试和版本升级。
3）数据跨命名空间搬迁我们最近在推进一个改造——将用户从ViewFs升级到RBF，进而支持透明的数据跨命名空间搬迁。其中遇到的一个问题就是用户访问路由层需要设置新的访问路径，这样在使用过程中用户就需要同步修改其文件路径。为了做到用户透明，客户端的期望行为一定是希望自动地使用到Router而不需要修改业务代码。
最终我们是做了大量的工作来最终达成每月操作系统升级、快速安全升级Spark版本以及无缝迁移到RBF的目标，这里就不做详细展开，感兴趣的同学可以关注我们后续的系列文章，敬请期待！
5 容量管理
我们平台的服务模式是PaaS，即提供计算和存储的能力给到用户。而这些能力的背后就是靠实打实的硬件来支撑的。当规模达到千或者万这个规模的时候，降本增效会是一个不得不考虑的挑战，而这里面如何合理地规划和管理容量是作为平台管理的一个重要模块。
我们大部分服务都提供Multi-Tenant和Dedicated模式。前者的容量分配，实际上就是一个虚拟的数值，并不代表着会真正将服务区独占。我们内部比较典型的就是HDFS/Yarn的资源分配，用户被分配到的是一个存储的Quota或者一个队列, 这些都是逻辑上的资源。后者的容量，在云环境时，就是分配到具体的Pod资源，并且会交付给用户独占使用。比较典型的就是：我们内部私有化数据库/ES的资源分配（用户拿到的资源包括了真实的后台硬件，并且是可见的）。
当然对于这两种资源的管理方式也会略有不同，下面我介绍我们在实际情况下如何区别设计和管理的。
虽然我们对于每个用户的文件大小和数目的Quota都做了上限设置，但是在不断的使用中还是需要根据数据的真实使用情况来指导用户去维护数据的生命周期。比如，用户申请了100TB的存储空间，我们并不是等到空间真实快用满了，才提醒用户采取措施，而是在整个使用过程中希望可以持续地和客户沟通，让他们合理地使用资源、降低成本。
对于上述目的，第一阶段我们简单做了一个离线的数据报表，可以将HDFS内部的文件和目录可以按照不同的维度做可视化的展示，如下图5-1所示。基于这些数据，管理员或者用户可以更方便地进行梳理。另外，这份数据可以提供足够多的信息，达到管理员/用户对数据的需求。
图5-1
(点击可查看大图)
但是这种简单粗暴的做法只对头部用户管用，大量的长尾虽然也占用了大量的资源，但是仍得不到关注。所以第二阶段我们开发了一些新的功能，比如支持用户自定义地进行保留时间的配置、小文件合并的配置等等；或者基于规则去启动自动化的流程，通过系统来提醒用户去主动管理存储。当发现存储出现异常增长时，则需要自动分析增加的主要贡献因子，进而提供给用户，以便于提前解决。
在我们的环境中，当用户需要使用到ES资源时，我们提供了一套非常便利的自主化服务，来帮助用户自动生成新的集群。大部分时候，用户对于所需要的节点数量并不了解，因此我们还提供了一套公式——通过用户输入的业务场景（如峰值的每秒查询(QPS)、每秒写入索引(TPS)、Index保留周期等）自动计算一个合理的集群大小。
在项目初期，这个方案看似非常有效，但是随着集群越来越多，我们发现这样依然存在如下问题：
1）用户提交的项目预期流量和实际流量存在偏差。大部分时候用户会过多地估算资源；
2）用户的上线是一个渐进式过程，流量也是逐步增加的。而在集群申请时，会按照最大流量去分配；
3）使用过程中，当出现业务变化（如新增了一些业务场景导致流量增加）时，系统并不能很好地扩容。
这时候就出现了两个极端：①实际的资源使用率远远低于申请值；②在峰值时会因为资源不足而变慢。
为了解决这个问题，我们内部开发了一套自动的集群扩缩容系统，下图5-2为这个系统一个简单的功能展示，更多技术细节我们后续系列文章会展开介绍。
图5-2
(点击可查看大图)
通过上图，我们可以看到三条线——红、绿、蓝。红线为预测线，我们会基于历史数据做集群节点数的推荐，这里会有一些定制化的公式和算法；绿线表示用户的申请计划，可以让系统提前根据计划准备好容量；蓝线表示真实的节点数目。
通过这种方式，我们可以放心地让用户申请集群，一些有经验的用户会自己定制一些未来的节点规划，比如每个季度会随着新业务的引入去增加容量；默认用户也可以完全托管给我们的系统，系统会自动基于系统指标进行扩容和缩容。
6 服务化和产品化
本章节，希望将我们关于服务化和产品化的一些案例介绍给大家。在eBay，不论你是Devops模式，还是SRE模式，从根本上都是在代替用户去管理他们的资源。
一方面是因为根深蒂固的历史原因，导致团队的组织架构的变更都是缓慢的。我相信过去许多做Devops转型的公司都会有很深刻的体会，这样的变革需要从多个方面（如流程、系统和决心）同步推进。
另外一方面是受限于人手，过去几年大数据平台在稳定性上有着相当大的问题。这就产生了一个疑问：在解决了稳定性问题之后，还会有多少资源投入到产品化的开发呢？
我们团队也同样会面临这样的问题，那么我们是怎么做的呢？下面举几个例子。
这个系统的初衷是为了解决多集群之间的数据拷贝。日常我们会有很多的数据同步需求，需要跨机房、跨集群地将大量的数据互相同步。这就产生了以下问题（没有这个系统之前会有很明显的问题）：
1）每个客户都可以随意提交Distcp命令到集群，然后指定自己的参数（如下图6-1所示），这就导致这里的配置都是由用户控制，如果有任何变化或者迁移，很难统一修改。
图6-1
(点击可查看大图)
2）分布式的任务散落在各个角落，很难集中监控和管理（如对任务的并发控制、优先级控制等等）。
3）Distcp本身逻辑比较简单，当你有定制化的需求（如根据大小和文件数做细粒度的优化）的时候，或者甚至要自己控制子任务调度的时候，会有无从下手的困境。
后来，我们基于基础的Distcp设计了一套Optimus系统（下图6-2所示为系统架构）。
图6-2
(点击可查看大图)
Optimus系统将上面提到的问题都在这个系统里面做了解决，解决方法如下：
1）Cloudnative部署的微服务，支持基础的API的功能，可以方便和业务系统对接；
2）对于不同优先级的任务，可以支持不同调度策略、任务拆分策略、并发控制等；
3）中心化资源，可以限制总体带宽使用，避免跨机房带宽问题；
4）可视化的任务监控，对所有任务状态清晰可见。
Hadoop的用户都会比较熟悉Kerberos, 因为这是目前唯一的Hadoop社区支持的认证方案。当你需要授信地访问任何大数据服务时，你会使用到一个管理员办法的密钥存储文件——Keytab。我们做自助产品的时候，自然会考虑将这个功能开放给用户，以便于用户可以很方便地通过界面来管理自己的Keytab文件。而考虑到安全的需求，每隔三个月，我们就会提前通知用户：“账户密码过期需要重新下载密钥文件”。
这样的产品被大规模使用之后，我们发现它依然存在如下明显的问题：
1）Keytab下载需要用户操作，第一阶段是手工页面下载，后期也提供了API下载功能。但是这还是一个会造成系统影响的变更。
2）更大的问题在于：Keytab文件本身就是一个用户Principal和密码串。当你修改了服务器端密码之后，如果用户还在使用错误的版本，会不断重试错误密码导致账户被锁。在一些分布式平台用户的场景（如AI）下会尤为严重，导致他们无法有一个一致性的处理方案。
第二阶段我们就在尝试解决这个问题，思路也比较直接（如下图6-3所示）。我们将密钥的管理职权放在了我们的服务方，也就是用户不需要关心Keytab文件的存在。我们可以定期地将ticketCache分发给用户（默认10小时过期），所以只要用户10小时之内再下载一次即可。这样可以解决上述提到的两个问题。我们也提供了SDK/Agent两种方式供用户使用，这样基本上保证了用户的自身业务代码无需做任何修改。
图6-3
(点击可查看大图)
做到服务化之后，其实平台是承接了更多的一些功能，但是在重后端的同时，带来的就是轻前端的好处，对用户也更加友好。
我们还有很多类似的产品，比如ES的诊断产品、ES索引管理系统、ETL的一些核心子系统（如调度任务生成、数据库认证管理和依赖服务）等。我们在做产品化的同时，对底层服务都要求要独立，这样不同团队的产品都可以使用。慢慢就会发现，平台管理系统从开始的微服务化，也越来越接近业务研发。这样有很多好处，其中我比较推崇的一方面好处是：数据开发、产品研发和机器学习开发的基础能力要求可以尽可能地统一。如此，大家都可以通过相似的流程和系统，用最适合自己的语言来达到同样高效的开发目的。
总 结
通过上文的描述，我介绍了我们在eBay解决这些开源大数据组件的可管理性问题的一些实践。其中很多功能是集成在云平台上的，或者由云厂商提供类似的功能。随着云原生的发展，很多公司也在致力于将数据平台的各个模块云原生化，这样可以大大受益于K8s提供的各种便利性的可管理性解决方案，我们在这个过程中也在不断地学习、权衡利弊。个人认为用不了太久，行业内大数据平台的研发管理也会变得和应用发布管理一样的简单高效，而这方面人效的提升必然会带来更多的引擎和存储本身的投入和发展。
在此感谢大家的阅读，文中许多未能展开的技术细节我们会在后续文章中一一介绍，欢迎大家多多关注，敬请期待！
参考资料
[1]Martin Kleppmann.Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems[M].O'Reilly Medi,2017.
[2]https://kubernetes.io/docs/concepts/architecture/controller/
[3]https://pingcap.com/zh/blog/observability-of-distributed-system
[4]https://pingcap.com/zh/blog/how-to-develop-an-infrasoft-observability-and-interactivity
[5]https://mp.weixin.qq.com/s/nitBi7cvQZCnCv0RMFZnNw
[6]https://mp.weixin.qq.com/s/hxNObPA1SsnI2wt0oAZ2qw
往期推荐
比用户更懂用户|新一代用户行为追踪和数据洞见
eBay支付核心账务系统之直冲云霄
Hadoop平台进阶之路 | HDFS NN性能优化实践
干货 | eBay Hadoop/Spark自助分析系统实践
点击阅读原文，一键投递
eBay大量优质职位虚席以待
我们的身边，还缺一个你