作者：Kuhu Shukla / 翻译：刘天栋 / 校对：EE
本期编辑：Sylvia Shu & EE
原文链接：https://s.apache.org/A72H
在一个寒冷的早晨，当我坐在办公桌前，喝着咖啡, 在 Apache Tez 项目里寻找前一天项目中新的 JIRAs 时, 我感到很开心。最新的社区发布投票已经完成，我们急需的 bug 修复程序和在我们上千个强大集群内部测试的新版本看起来不错。今天，我从另一个不同的 Apache 项目流程中寻找新的堆栈跟踪, 发觉很难错过我每天都会看到的，来自全球各地的人贡献的优秀代码。一位贡献者在 JIRA 留下了一个评论, 然后去接他参加足球训练的孩子, 而另一个贡献者早上醒来后发现, 她在在过去两个月所作的 bug 修复的努力, 终于获得了一个肯定的支持 (译者注：Apache 邮件列表中, 针对特定议题, 参与者可以用 +1 表示坚定支持, 0 表示没意见, 而 -1 则表示反对 - 并提出反对理由及/或替代方案)。
Yahoo - 和 AOL (美国在线), HuffPost (赫芬顿邮报), Tumblr, Engadget, 及众多其他品牌, 在去年携手建立了 Verizon 子公司 Oath - 早在我上高中之前就一直站在采用和贡献开源的前沿。虽然我没有事件发展的历史轨迹可以分享, 但是我还真有个故事，一个关于我如何发现自己亲身参与了将 Yahoo 所有的 Apache MapReduce 迁移到一个新的基于 DAG 的执行引擎，Apache Tez，的史诗般旅程的故事。
Oath 网格基础设施完全由 Apache 技术驱动, 例如通过 HDFS 进行存储, 通过 YARN 进行资源管理，使用 Tez 的作业执行框架, 以及 Hive, Hue, Pig, Sqoop, Spark, Storm 等用户界面引擎。我们的网格解决方案专门针对 Oath 的关键业务数据管道需求, 而这些多态技术解决方案在 Apache 社区进行托管、开发和维护 。
2015年, 我在 Yahoo 工作的第三天，收到了一个介绍 Apache Tez 的 YouTube 链接。我仔细地看了一遍, 努力地跟上思路，还从这个视频里认出了一些我之前读过的 Yarn ACM 论文里提到过的几个名字。我开始加大对 YARN 和 HDFS 的研究学习, 这二项 Apache 的基础技术项目直到今天还在吸引着 Oath 对它们的发展做着重大贡献。在最初几周, 我花了一些时间挑选我最喜欢的 (必要的) 邮件列表来订阅，并开始着手建立一个伪 (虚拟) 分布式 Hadoop 集群。我继续以新手的身份做贡献，以找到立足点, 在补丁中对空白字符的使用也越发小心。有一件事是确定的--Tez 对 Yahoo 具有重大意义。Yahoo 逐渐将大部分工作移到 Tez 上, 而到将近 80-90% 的工作运行在 Tez 的时候，身经百战的我才能真正地称自己为 Hadoop 社区的贡献者。但是, 就像徒步攀登大峡谷, 最后关键的 20% 才是最痛苦的地方。成为这一挑战的解决方案的一部分是一个美好的前景, 值得庆幸的是，为Tez 做贡献成为了我下一个季度的目标。
在紧接着的冲刺 (Sprint) 计划会议结束之后, 我接到了我的第一个主要的 Tez 任务 -- 进度报告。Tez 的进度报告原来是不存在的 - 我想 "只是需要打一个 API 补丁就可以了吧"。但是这和找出这个生态系统中几乎所有的漏洞一样的困难。该如何定义 Tez 项目进度？不同类型的输出在进度图中有何不同？问题很多。
然而, 我很快就得到答案了。Tez 社区积极地响应新手的求助, 寻找答案并提出重要的问题。我开始参加 Tez 社区的双周电话会议, 并询问现有的贡献者和提交者以修正我的进程。突然间, 这个团队变大了, 目标也变得更加轮廓分明。这对像我这样来自网络行业的人来说是全新的体验, 网络行业中的代码中最开放的部分是 RFC (Remote Function Call - 远程功能调用), 而实现细节通常是隐藏的。这些会议为我们的编码想法和实验提供了一个干净的空间。我们分享了一些想法，共享的程度包含了我们应该选择什么样的数据结构和未来的 Tez 用户将获得什么。此外，也包含了一般的项目状态更新和广泛的知识转移。
Oath 公司广泛地使用 Apache Pig 和 Apache Hive, 大多数的紧急需求和请求都来自 Pig 和 Hive 的开发者和用户。每个请求最终会进入一个社区 JIRA 上的问题列表。当我们开始在 Oath 公司范围内运行 Tez 的时候, 围绕性能和资源利用的新功能的想法和漏洞都被逐一具体化。每年, 大多数 Oath 公司的 Hadoop 团队都会前往 Hadoop 峰会, 在那里我们会遇到 Apache 社区的伙伴们, 我们会站着好几个小时，讨论最先进的技术和项目的下一步规划。有一次这样的讨论为我定下了未来一年半的目标。
我们需要一种创新的方式来随机排序 (shuffle) 数据。像 MapReduce 和 Tez 这样的框架在其处理生命周期中有一个随机排序 (shuffle) 阶段, 其中上游生产者的数据可供下游消费者使用。尽管 Apache Tez 在设计的时候，有一个功能集是与 Pig 和 Hive 中的优化需求相对应的, 但在项目启动时, 随机排序处理服务（Shuffle Handler Service）从 MapReduce 中得到了改进。
由于我们的集群中有数以千计的作业在 Tez 中利用这些特性, 随机排序处理服务（Shuffle Handler Service）就变成了一个明显的性能瓶颈。因此, 当我们与社区的朋友聊 Tez 的经验时, 我们决定为 Tez 实现一个新的随机排序 (shuffle) 处理程序。现在，所有的讨论要点都是通过 JIRA TEZ-3334 这把大伞来进行追踪的, 任务清单也很长。当我开始阅读我所选择的一些 JIRAs 时，我意识到这些是我可以贡献和审查的全新的代码。也许我可以给大家一个更好的说法, 但说实话, 这里面有太多的乐趣了。所有的白板都满了, 整个团队热烈讨论该如何定义这个 API。我们花费了无数的时间调试网络迟缓的问题、获取数据、从我们的测试运行中查看堆栈跟踪信息 (stack traces) 和网络协议分析器 Wireshark 捕获的信息。
六个月后, 我们的沙盒 (分离) 群集里就拥有了这个功能。无论是纯粹的沮丧，绝对的兴奋还是欢庆的时刻, 我们不停地用这个不断演变的功能去解决大大小小问题，同时继续处理与审核这个项目的贡献者们不断发来的评论。
只要你对你的代码抱有强烈的归属感，那么你在软件社区中将处处受到重视。然而，我绝对不会说 "这是我一个人做的", 事实上, 应该是说 "我们做到了"。就是这种强烈的共享所有权的意识和流畅的团队结构, 使 Apache 的开源体验真正让贡献者得到回报。这只是一个例子。许多在 Tez 做的工作为 Hive 和 Pig 社区所利用, 跨 Apache 产品社区的互动使得这项工作变得更加有趣和富有挑战性。透过 Tez 的这个新功能，我们对问题进行筛选和修复，使得我们百分之百完成了迁移工作，我们还将 Tez 随机排序处理服务发布到我们的研究集群中。我们已经在超过3.8万个节点上运行了总共有500亿项任务, 以及大约1亿次 Tez DAGs (注)。
2018年, 当我继续探索 Hadoop 3.0 作为我们未来的版本时，我希望如果在 Apache 社区以外的人正在阅读这篇博客, 它会赋予他们灵感和激起他们为他们选择的项目作出贡献的兴趣。我从一个 Apache 贡献者新手成长为一个 Apache 提交者新手的过程，打个比方，就像是作为一个天文学发烧友, 我透过我的望远镜看向星空 - 那里有无尽的可能性，可以挑战自我，成就卓越。
*以上所有图片均从谷歌图片库中下载*
关于作者
Kuhu Shukla 是 Oath 公司的软件工程师, 她在北卡罗来纳州立大学获得计算机科学硕士学位。在伊利诺伊州的 Champaign 市，她和 有很多有天份的 Apache 项目委员会成员和提交者在基于 Apache Tez, Yarn 和 HDFS 的大数据平台的团队携手工作。作为 Apache Tez 提交者, 她还持续地为 Yarn 和 HDFS 贡献, 并在 2017 Dataworks Hadoop 峰会上针对 "Tez 随机排序 (shuffle) 处理服务: 在 Apache Hadoop 上大规模随机排序 (shuffle)" 发表演说。在此之前, 她曾在 Juniper 网络工作，致力于路由器和交换机的配置 API。她喜欢参加开源会议和“女性参与技术”的活动。在闲暇时, 她喜欢唱印度古典乐曲和爵士乐, 大笑, 观赏鲸鱼, 徒步旅行和通过她的 Dobsonian 望远镜观星。
备注
1. DAG (Directed Acyclic Graph - 有向无环图)
2. Tez：Hortonworks 开发的 DAG 计算框架，是从 MapReduce 计算框架演化而来的通用 DAG 计算框架，核心思想是将 Map 和 Reduce 两个操作进一步拆分，即 Map 被拆分成 Input 、Processor 、Sort 、Merge 和 Output， Reduce 被拆分成 Input 、Shuffle 、Sort 、Merge 、Processor 和 Output 等，这样，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的 DAG 作业，可以用来替换 Hive / Pig 等。
