Chris Fregly的PANCAKE STACK研讨会及数据流水线

Chris Fregly的高级Apache Spark PANCAKE STACK 研讨会 、 高级Spark和TensorFlow聚会 、 视频 和 演讲 等包括了范围极广的数据科学和工程实践内容，对于正在评估或采取基于Spark的端到端的推荐引擎以及数据流水线的人来说会很有帮助。

这次研讨会对于正在寻求如何构建Spark数据流水线的解决方案的数据科学家和工程师就是一场及时雨。

源码都已经打包在了一个 Docker 镜像中，所以与会者可以直接安装起来就开始体验了，这样极大地节省了大家在研讨会上操作和搭平台的时间。

这个集成式的沙盘环境成为了这次跨越全世界若干个国家的中心焦点，在Github上也可以下载。

研讨会与会者和反馈、以及对研讨会材料的持续改进，就是Fregly的初创公司 Pipeline.IO 的基础。

公司的核心理念要要把他称之为“ Apache Spark 机器学习流水线最后一公里”的东西产品化，也就是那些包括了高度测量和自动化的方式进行模型改进、测试和部署等方面，以便数据科学家可以快速验证他们的模型，从而减少发现最优模型的整体时间。

InfoQ就PANCAKE STACK研讨会采访了Chris Fregly，并讨论了他在平台代码以及高级Spark研讨会上涉及到的一些关于数据流水线工程方面的趋势。

InfoQ：您是怎么想起来组织这次PANCAKE STACK研讨会的呢？这个名字是什么意思？你的动机是什么？

Fregly：PANCAKE STACK是SMACK Stack的下一代产品，后者是在2015年我和一些同事合作开发的，他们来自于Mesosphere('M'esos)、Typesafe(现在的 Lightbend ，'A'kka)、Datastax('C'assandra)和Confluent('K'afka)等。那时候我还在Databricks上班，于是我为Apache Spark和基础参考APP提供了一些内容，我们基于我的实验 代码库 用那些内容做了各种演示，最终代码库成了我现在的新公司 PipelineIO 的基础。PANCAKE STACK这个名字的隐含含义源于一个笑话，是今年早期在科罗拉多州博尔德的一个酒吧中我和一些BEA系统组旧同事们闹出来的。有时候喝多了会是一件很有趣的事。另外，域名 pancake-stack.com 还没人用，于是我就注册下来了。研讨会则非常灵活。除了我们不断增加的各种新演示和数据集之外，我们还试着根据每次会议听众的水平来调节内容。有时候我们的内容会超出这些缩写单词所定义的会议主题之外，有时候我们会花上整整半天只讲一个单词，比如'T'ensorFlow。有时候我会邀请一些演讲嘉宾，有时候我会自己讲完全程。这全都取决于听众们的背景、新版本的发布声明、当前趋势、城市、演讲者是否有空、甚至会场安排等等。至于动机，这样的研讨会是非常及时，也是非常贴近大家需求的，因为大家要用到的技术都非常前沿，人们希望能在一整个集成环境中学习和试用它。幸运的是，与会者都非常有耐心，当演示出故障时也特别体贴。当然，最后我们都做成了。

InfoQ：Spark特别擅长哪些，特别不擅长哪些？你在研讨会中又是怎么为大家演示这些的呢？

Fregly：Apache Spark让普通人也可以尝试做大数据处理、机器学习和高级分析，这非常令人赞叹。至于我个人，Spark则是唤醒了我大脑中沉睡了多年的灵感。我对统计学、概率论等数据方面的话题都非常感兴趣。我也在PANCAKE STACK的研讨会上做了许多关于机器学习和近似流的演示。Spark的成功还有一些其它因素，比如容易获得例子、培训视频、演示、会议等等。更早的，Berkeley AMPLab还创建过AMPCamp，即一系列的研讨会，突出各种不同的Spark库，包括Spark SQL、ML、GraphX和流等。由Spark的创建者创立的Databricks还在持续着这个传统，最近发布了他们的Databricks Notebook产品的 社区版 ，包含了许多Apache Spark的培训视频和参考资料。这样不仅仅是增加了他们产品的注册度，也从整体上对Spark社区做出了贡献。

InfoQ：您最近在一次研讨会上曾提到Spark Streaming有一些不足，可能无法满足所有的场景。您能就这一点展开说说吗？

Fregly：从本质上来说，Spark Streaming是一个小型批处理系统，与 Apache Storm 、 Apache Flink 和其它基于事件（记录）的流处理系统不同。当数据流入Spark Streaming时，会把一批收到的数据作为一个job提交给Spark引擎。这与批处理任务类似，当然数据量少得多。分歧点在于小型批处理系统的吞吐量会比Storm之类的基于事件的处理系统高很多，相应的代价是对于单个事件来说，它在系统中的处理就没那么及时。我属于非常喜欢把控制权交给开发者的那类人，我就赞成Spark Streaming让开发者自己做这个权衡：吞吐量与处理延迟，在框架上我们既支持小型批处理，也支持按记录处理。根据大家的物理学常识，把原子组合在一起总是更容易（把事件组成小批量），把原子切割开则更难（把小批量拆分成单个的事件）。小型批处理也限制了Apache Flink之类的基于事件的流处理系统所提供的复杂事件处理（Complex Event Processing，CEP）功能。我也发现从Spark Streaming的发送保证和状态管理中很难定位问题。每次我觉得我搞对了时，就会出现一些边界用例，颠覆我的想法。事实上这个并不是Spark Streaming的错，因为在这整个端到端的流处理过程中，还涉及到许多其他的如Apache Kafka（事件源）和Apache Cassandra（事件接收者）之类的系统，每一个都有自己的事务和回放特性。

最后一个缺点是没有一致性支持。很不幸，很多关于Spark Streaming的问题都在Spark邮件组中处于未回复状态。和上面说的一样，这也是由于实际环境中与Spark Streaming相衔接的端到端的系统中会涉及许多不同的事件源和事件接收者。

至于好的一面，Databricks公司里Spark SQL的创建者 Michael Armbrust 最近已经在Databricks公司的Spark Streaming项目中承担了更多的领导责任，因为在出现了新的“Spark SQL on Streaming”之后，Spark SQL和Spark Streaming已经走得越来越近。在Apache Spark用户与开发邮件组中我已经明显看到有很多关于Spark Streaming的问题都得到了答复。这样，在接下来的几个Spark 2.x版本中，Spark Streaming就非常有可能胜出。我也非常高兴最近他们还讨论了“Spark ML on Streaming”的工作。我最近为一个PipelineIO的用户用Spark Streaming产品化了一个增量的“ 流上指标特征抽取 ”合作式过滤推荐算法。这个事件比较复杂，只用Apache Spark是做不成的。基于Amazon的著名的 Dynamo Paper ，我们用到了Apache Cassandra、Redis和Dynomite（我的老东家Netflix的一个开源项目）。

Redis+Dynomite的组合可以提供容错和可扩展的缓存层，这样就可以为推荐系统实现预测和服务层了。Netflix的Redis和Memcached集群是跨三个亚马逊大区同步数据的，每个大区内有三个可用的数据中心，所以对于用户推荐列表数据来说是有9份副本的。有了这种全球性的、高可用的、内存中的缓存复制技术之后，对终端用户的服务推荐就不再需要消耗磁盘IO了。这是一个极大的性能飞跃。不幸的是，作为数据处理和机器学习模型训练的事实标准，Apache Spark却无法完成机器模型服务的“最后一公里”任务，事实上也不该由它完成。我在各种讲座、集会和研讨会上都常常强调：Apache Spark是一个基于批处理的系统（包括Spark Streaming的小型批量）。Spark的处理不应该放在用户的请求-响应的处理路径上，特别是对于机器学习模型服务这种需要个位数的响应延迟的业务。

很不幸，Spark Streaming给了大家错觉，以为Apache Spark可以胜任对用户请求-响应的处理。在和客户沟通的过程中我常常听到这样的误解。由于它底层是这样的小型批处理机制，所以即使是最简单的请求处理，Spark Streaming也会产生令人无法忍受的高延迟响应。要想实现用户请求-响应的低延迟处理，比较好的方案就是换Redis或Memcached来做缓存层，用MySQL、Apache Cassandra甚至 Elasticsearch 等做数据库。值得一提的是，Elasticsearch不仅仅只是一个搜索引擎。它更多的被用作一个NoSQL数据库、一个分析引擎，最近还常常被用作图数据库。

InfoQ：能讲讲你们Pipeline.io的项目，以及它们与PANCAKE研讨会的内容有什么不同吗？您主要提到了产品化，以及在电脑上单击一下鼠标就可以完成容器化了的任务和服务的部署。这样做解决了什么问题？

Fregly：创建PipelineIO的想法，要追溯到几年前我还在Netflix工作的时候了，那时候我们不得不构建一套定制的机器学习预测服务层。那时候它并不是一套可用于生产的、容错的、低延迟的开源系统，可以为Netflix这样规模的系统提供实时预测和推荐服务，现在按我的想法也还是不行。在后来Databricks和IBM Spark技术中心为许多机器学习和人工智能客户服务时这个想法也得到了进一步的验证。这些流水线在训练阶段就终止了。把一个模型推向生产的最后一公里任务完成得非常粗糙，难于维护，更别说什么性能上的优势了。但把PipelineIO用于Apache Spark机器学习、TensorFlow、Caffe和Theano人工智能模型等时就完全不用费什么力。我们从最早设计这套系统的架构开始，就已经准备好了可以轻松地扩展到任何支持Kubernetes和Docker的自建系统或云环境上，用作机器学习或人工智能流水线。那时候，我们参考了AWS、谷歌平台和Azure的流水线和演示。还有很多别的功能，比如A/B流和多臂老虎机（Multi-armed Bandit Model）测试，以及用 Spinnaker.io 、 Kubernetes 和Docker等业界标准、实践验证过的开源项目进行持续模型部署等。在Netflix的“ 自由与责任 ”模式下，流水线中的每一步都处于笔记本电脑或命令行连接的NoOps环境中，处于数据科学家和数据工程师的直接控制与监控下。根据我们的第一手的经验，我们非常相信这样的工作环境是合理的。

InfoQ：根据您的经验，在全面生产化一条基于Spark的流水线之前，在经过原型测试之后，人们该考虑哪些因素来放弃Spark的方案？我想到了Spark的“单任务单处理器”的行为，您有没有更多的例子？

InfoQ：研讨会上用的库里还有许多不那么重要的服务，比如Apache Spark、原生Kafka、Cassanra、Redis、 PrestoDB 、 AirFlow 和MySQL等，都运行在由同一个镜像生成的Docker容器中。如果您要把这些服务产品化，假如还是用Docker的话，会有什么不同的作法吗？

Fregly：用一个单一的Docker容器作培训和演示都很方便，但却不能扩展。我们还有一个可用于生产环境的版本，每种服务都有自己的Docker镜像。Docker 1.10+极大地改进了Docker容器之间的通信。Docker 1.12+还原生地提供了对MacOS和Windows的支持。另外，我们还极大地使用了Spinnaker.io和Kubernetes来生成、部署和为我们的集群程序做版本管理。有许多这种模块都在合适的时间点对我们可用了。我们非常幸运，Apache软件组织、谷歌、Docker、Netflix等都为开源社区做出了极大贡献。我们是真真正正地站在了巨人的肩膀上。

InfoQ：在一个容器中运行所有东西的时候，您有没有发现Docker有什么有趣的新特性？如果有，是什么呢？

Fregly：从可扩展性和配置的角度我们没发现什么。很明显，一个可用于生产的分布式系统会和一个包含了日志、监控、一致性、可用性、性能、配置等等的单机系统有很大不同。这些都是众所周知的，当然我们也在一个分布式的版本中解决了这些问题。我们倒是没想到迭代式地构建这样的Docker镜像已经成了一种每天晚上都能做一遍的事。当我们不断地加进越来越多的现场演示和数据之后，这个单机版Docker镜像就已经变得越来越大。与碎片化的、按需下载的方法相比我们更喜欢这样全合一的方案，因为这样在研讨会上就会用得很方便。减少可变部分的数量让我们可以把同时参加研讨会的人数增加到200人以上，这样就让可以我们的受众大大增加。最近我们还曾运行过涉及约800个CPU、5TB的Spark集群处理的CPU和网络密集型Spark机器学习任务。

InfoQ：您是否认为Kafka 0.10版在把Zookeeper原生的包含进去之后会促进大家采用Kafka，或者还是希望ZooKeeper是个单独提供的产品？为什么？

Fregly：不幸的是，ZooKeeper承担的角色不太好。如果能避免，没人会喜欢这样的可替换的部分。不幸的是，ZooKeeper，或者类似的Paxos或RAFT实现等，对于各类分布式系统都是必需的，尤其是大规模的。你可以临时性地用一个共享文件系统或数据库来管理共享系统的状态，但很快，这个模块就会在上规模之后成为一个明显的瓶颈。ZooKeeper事实上非常稳定，也持续一段时间了。不幸的是，依赖ZooKeeper的系统在负载重时就会性能急剧下降，还会进一步的暴露问题。幸运的是，因为ZooKeeper太重要了，社区修复故障会相对较快。最近我有个PagerDuty的朋友Evan Gilman发表了一篇 博文 ，提到了他们在2015年发现的一个出了名的难解决的故障。我很喜欢这篇博文，不仅仅是因为它登上了Hacker News的榜首（恭喜你，Evan！），还因为它暴露的问题要涉及到高层ZooKeeper Java用户空间的代码和底层的IPSec/TCP系统空间代码。回到原来的问题，我不喜欢任何会阻挡大家使用Kafka的事情。正如Slack（之前在Cloudera）的一个很有趣的数据科学家 Josh Wills 所说，“Kafka就象氧气，说你在用Kafka就象你在用Linux一样……在旧金山你要是说这个那就实在太无趣了。”

InfoQ：在最近的一次研讨会上您提到可以把Elasticsearch用作数据库或分析引擎。在这些方面，哪一类的用例是Elasticsearch特别适用的呢？

Fregly：那些喜欢Datastax或Cassandra的人都不会喜欢我这么说，但这是事实。我看到很多小型或中型的系统正在从Cassandra迁移到Elasticsearch上。我并不是说Apple或Netflix会不再使用Cassandra了，这完全是荒谬的。但Elasticsearch的确对开发者来说是非常友好、容易安装、分布式和可扩展的。通常，我会看到各个团队最初采用MySQL或Cassandra做数据存储。不过一旦最初的功能增加了之后，业务很快就会需要全文搜索及地理信息搜索功能。团队在调研Elasticsearch一番后就会意识到它不仅仅是一个搜索引擎。于是他们会再做压力测试，就会发现没必要同时维护Cassandra和Elasticsearch，因为只用Elasticsearch就可以胜任两个任务了。值得一提的是Elasticsearch有个非常复杂的Spark SQL Connector，具有支持数据分区、断言下推、支持TF/IDF文档特性等。很幸运，今年早些在我的高级Spark和TensorFlow集会之前，就在旧金山举行的ElasticCon之前，我从Elastic公司邀请到了Elasticsearch Spark SQL Connector的作者 Costin Leau 来做了一次演讲。这里是当时的 视频 。

InfoQ：请问对于Spark开发社区来说，在技术和社区智慧方面您认为最大的挑战是什么？

Fregly：我觉得Apache Spark社区在倾听并采纳用户的反馈意见这方面做的很好。我见过很多Spark用户，对于Spark的各方面都觉得不算满意，但仍会继续使用它，因为他们坚信事情会变得更好。另一方面他们也做得非常好的就是在不断与最常见和最好用的各种工具做集成，像Parquet、Avro、Elasticsearch、Cassandra、Redshift、Kafka、Kinesis等。接下来我觉得Spark Streaming是主要的推动力。它需要在各方面经过改造，包括更好的社区支持、更好的稳定性、更好的状态管理机制、更具弹性（除了小型批量处理，还支持基于事件的处理），以及更清晰更连续的演进路线图。我非常高兴Michael Armbrust在Spark Streaming方面承担了更多的领导角色。我觉得我们接下来会在Streaming、SQL和机器学习的聚合方面看到一些很不错的进展。我们也会努力保持领先性，为这些革新扫清道路。

InfoQ：如果要说说在您主持过的关于PANCAKE STACK的各次研讨会中，有没有什么贯穿了各次的主题，或者让与会者体验了陡峭的学习曲线，或者在运行示例代码时解决了问题，那会是什么呢？

Fregly：核心主题就是端到端的机器学习流水线整合，从模型训练与评估到生产环境中的模型服务和预测。每次研讨会都各不相同，但那些都是与会者的主要收获。研讨会上用到的 代码库 里有完整的端到端的可供参考的机器学习流水线，与会者可以带回家，与朋友和同事分享。当然，不同的与会者的经验和技能水平相差很大。这样有时候会有一些负面评论，因为我总是在忙于解决大多数人的问题。当然我们会不断地用这些反馈来指导改进，让大家的体验更好。我们承认我们不可能让每个人都满意，所以如果有人认为研讨会不值得那张门票钱的话，我们会100%的退款。只要那个人提供了有建设性的反馈意见，我们完全不介意这样做。最后，我们总是过得很开心，这正是我们会继续做这样的研讨会的原因所在。接下来的几个月，我们还会把这样的研讨会 带到 欧洲和亚洲。

关于受访者

Chris Fregly 是PipelineIO的创始人，现在也在担任研究科学家。他也是Netflix OSS的代码提交者、Apache Spark贡献者、旧金山高级Spark与TensorFlow大会组织者、以及即将上市的新书“Advanced Spark”的作者。在此前，他也曾担任过Databricks的解决方案架构师、IBM Spark技术中心研究工程师、以及Netflix流数据工程师等。

阅读英文原文： Chris Fregly on the PANCAKE STACK Workshop and Data Pipelines