分布式基础架构中的DataPipeline

Data Pipeline，就是分布式系统里的数据传输，在大型互联网后端基础架构中，已经是重要的组成部分。其实从做数据仓库开始的ETL，就可以算做是Data Pipeline了，只不过随着互联网公司大数据处理的需求更加频繁，对于Data Pipeline的要求也越来越多样化和自动化。例如早期的Sqoop，Flume等，分别都用于数据管道传输，它们也着实解决了部分需求，但是，这些软件，都只是着眼于开发一个工具完成某项任务，而没有把Data Pipeline当作一个服务来运行，可以放到数据中心操作系统中去调度。这么做有什么好处呢？在大型分布式系统中，数据的传输多样化，给运维和开发工程师都造成了很大的困扰，例如Web服务器，各类数据库，搜索引擎，Hadoop，Storm，Spark，OLAP，它们之间都需要数据的传输，诚然，以日志为中心的基础架构设计可以解决部分问题，但也存在许多情况无法一切数据存储都围绕中心日志来做，服务化Data Pipeline，可以让这个工作变得不那么Dirty，自然也是DevOps理念的继续延伸。

Linkedin是在Data Pipeline和数据日志设计上最有心得的公司，开源的一系列软件包含日志型消息队列，CPC（Change Data Capture），等等都是从实践中提炼总结出来的系统。在以Java为核心后端的公司中，Linkedin/Netflix是笔者认为最值得学习的互联网公司，就在于分别对数据处理和云上构建架构的丰富实践经验和总结。早在2013年，Linkedin就放出了Camus这样一个系统，这是很少有人去关注的一个工具，因为它解决的是到Hadoop的Data Pipeline传输过程的写入事务。没有该工具时，因为序列化的缘故，在做数据传送时常常因为网络或者其他IO方面的原因而导致传输丢失，这让Flume或者其他自写工具的开发者很挠头，因为这意味着数据不得不经常手工重做，导致低效和巨大的人力浪费，而通过把Data Pipeline作为一个Hadoop上的Job并同时记录状态，就可以很方便的进行容错处理以及自动把高吞吐量的IO并行到不同节点处理，很轻松地就解决了这个小问题。Camus系统是Linkedin在Data Pipeline向自动化上努力的第一个产品。Data Pipeline要解决的另一个麻烦事是异构数据源，Linkedin的CPC系统Databus可以看做是在这上面的努力，但它更着眼于解决数据库数据传输的实时性和一致性，跟Data Pipeline还是有差异，因为后者对于延迟有时候要求并不很高（数据传输可以是流式执行，也可以是批处理），但对于异构数据源的支持却必不可少。

日本人在这方面颇有心得，很早就推出了fluentd这样用Ruby写成的系统，fluentd看上去跟Flume很像，但更加灵活，只需要几十行代码就可以为它添加数据源和数据传输目的地的插件实现。Fluentd的作者随后去了硅谷做了日志SaaS服务的大数据公司TreasureData，在本公众号前边的“盘点美帝大数据创业公司”一文中也有提及。Fluentd负责Data Pipeline的传输，但它还是跟Flume类似的系统，在其他方面考虑并不多。在2014年日本人还做了个工作叫做Embulk，目的是在提供Fluentd类似的灵活性的基础上，引入一些高级功能，包含：批量加载，并行执行，事务控制，数据验证，错误恢复，听起来仿佛Fluentd＋Camus。

已经相当不错了，异构数据源（可任意编写输入输出插件），事务，并行执行，等等。不过，Linkedin今年VLDB上放出的Gobblin，可算得上更近一步，因为真正做到了服务化。

对于软件的使用和介绍，只需要看相关的文档即可。这里想要多提及的是，为了让Data Pipeline服务化，Gobblin都做了哪些工作。首先，Gobblin针对数据传输任务做了统一管理，在任务调度上可以跟Hadoop上的流行工作流引擎集成，例如Oozie，Azkaban，以及Mesos上的Chronos；其次，任务状态统一保存在Hadoop中，便于容错和中断恢复；最后，Gobblin通过Helix可以运行在Yarn中，因此，就彻底解决了统一资源管理的问题。

这里多提下最后一点。Helix是Linkedin针对分布式数据存储所抽象出来的公共需求而构建的系统，主要功能包含：资源管理，分区管理，容错设计，伸缩性管理，以及监控。总体上，Helix把分布式存储系统看做是一个状态机，因此暴露相关的接口方便不同的分布式存储系统进行状态迁移。例如，启动或者下线，节点增加或者减少，分区增加或者减少，以及各类异常情况等。利用Helix可以很方便的开发集群运行的程序，例如分布式数据库，在Github上有个Fullmatix项目就是一个拿Helix给MySQL做Sharding的例子。由于MySQL本身在高可用设计上的弱点(切换时容易丢数据)，因此Fullmatix只能是一个简单的玩具项目，但它的确可以展现出如何给一个不具备Sharding的存储系统增加分布式集群管理功能并且做到好的可运维性。Helix可以在Yarn和Mesos上运行，由后者给它分配资源。

在Gobblin中对Helix的使用较为简单，因为没有涉及到分区处理，主要通过Helix来控制任务平均分配在从Yarn上获得的节点上，从而确保Gobblin任务运行的负载均衡和容错。

服务化运行的另外一点是监控设计，不论是Gobblin，还是Helix，都提供JMX输出Metrics的能力，因此这方面不多谈论。尽管Gobblin已经不错了，但是相比Embulk，Gobblin没有过多考虑输出端的需求，目前只是为Hadoop服务的，因此，这并不是说Gobblin就是终点了，需要改进的地方仍然会不断涌现并得到最终解决。