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

关键点

• 这种完全密集型、沉浸式的研讨会让参与者可以只用一个全功能的 Docker 镜像就可以很快地兴奋起来并投入其中了。在研讨会中，参与者在沙盘上就可以直接体验很多整合内容的细节。
• Apache Spark 社区也在做着一件很好的工作，他们倾听了用户反馈，正在把最常用最好用的可用工具都整合起来，包括 Parquet、Avro、Elasticsearch、Cassandra、Redshift、Kafka、Kinesis 等，其中 Spark Streaming 是向前推进的关键。在这次研讨会上也有关于这个整合的内容。
• 由于将蓬勃发展的开源运动和业界的支持结合起来，Spark 获得了极大的成功，正在将数据处理、机器学习和高级分析等带给广大普通用户。
• 以高度测量和自动化的方式进行模型改进、测试和部署是发现最优模型的基础，但现在经实践验证过的好解决方案并不多。

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 的“单任务单处理器”的行为，您有没有更多的例子？

Fregly：坦白地说我没发现太多的可以放弃 Apache Spark 的点。毫无疑问，大家都希望 Spark 能获得成功。不止一次，当我说服了客户在某种特殊场景下不要用 Spark（比如用 Spark GraphX 来做实时、增量的页面排名服务）之后，我却发现他们还用 Spark 实现了另外四种用例。

这里有几个不适用的例子，来源于 Spark 高层库：

Spark SQL

• 缺乏对 ANSI SQL 的完整支持：Spark 2.0 号称全面支持 ANSI SQL 2003
• 低性能：通常原因是集群大小不足、分区不够、或数据在分区之间不够分散

Spark Streaming

• 小批量处理导致了高延迟
• 持续运行任务的稳定性
• 在整个数据流、发送保证、容错和与外部事件源和存储的交互中难于定位问题

Spark ML

• 模型可用性：大多数 Spark 机器学习算法都是分布式的，利用了 Spark 的分布式运行时特性
• 性能：Spark 机器学习是一套通用的机器学习框架，对特定用例并不是性能最优的

Spark GraphX

• 批量式图分析引擎并不能替代 Neo4J 和 TitanDB 等在线的、增量型图算法和数据库
• 和 Spark 机器学习一样，缺少最及时的 Spark SQL DataFrame 支持（ GraphFrames 支持可能快出来了）
• 在 Apache Spark 社区做 GraphX 支持的人是出了名的少

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