生态系统简析Spark Streaming：Spark Streaming实质上仍然是批处理，但是把之前大的批处理拆为小的batch。同时，当下Spark Streaming已支持限流，当流量很大时，Spark可以挡住。此外，它还可以支持实时机器学习。在Spark Streaming中，数据丢失一般因为两种情况——worker failure和driver failure。在之前版本中，可能会存在小部分的数据丢失，而在1.2版本发布后，reliable receiver模式保证了所有数据不会丢失，这点在Kafka的连接上非常适用。 MLlib：当下的算法已经非常丰富，包括分类、聚类、回归、协同过滤、降维等等。ML Pipeline可以大幅度的减少开发时间，它可以帮开发者打通数据收集、数据清理、特征提取，模型训练，测试、评估、上线整个流程。 Graphx：在这里，Spark的优势是既能处理表视图，也能处理图视图。 Spark SQL：Spark生态圈中最火的组件，目的很简单，用来支持SQL标准。对比Spark SQL，因为基于MapReduce的进程模型，Hive中存在许多一直未修复的多线程bug。值得一提的是，Spark SQL的贡献者中，一半以上是华人。
Tachyon可以支撑几乎所有框架 Tachyon：内存分布式系统，让不同的Job或者框架分享数据，从而绕过HDFS，以更快地速度执行。同时，它还可以避免任务失败时的数据重算。最后，Tachyon可以让系统避免多次GC。 SparkR：让R语言调用Spark。原理是Spark Context通过JNI调用Java Spark Context，随后通过Worker上的Excutor调用R的shell来执行。现在存在的问题是，每次task执行时都需要启动R shell，所以还亟待优化。
BlinkDB，一个任性的数据库 BlinkDB：很任性的一个数据库，允许操作者带着time bounds或者error bounds去查。原理是在原始数据上维护一组多维样本，当然其中还需要一个动态的样本选择策略。 JobServer：提供了一个RESTful接口来提交和管理Apache Spark job、jars及job contexts，即Spark as a Service。 刘奇：Codis Design & Implementation 刘奇（@goroutine），豌豆荚资深系统架构师 在刘奇的分享中，他首先介绍了Redis在豌豆荚的使用历程——单实例==》多实例，业务代码中做sharding==》单个Twemproxy==》多个Twemproxy==》Codis，豌豆荚自己开发的分布式Redis服务。在大规模的Redis使用过程中，他们发现Redis受限于多个方面：单机内存有限、带宽压力、单点问题、不能动态扩容以及磁盘损坏时的数据抢救。 通过刘奇我们了解到，Redis通常有3个使用途径：客户端静态分片，一致性哈希；通过Proxy分片，即Twemproxy；还有就是官方的Redis Cluster，但至今无一个新版本。随后刘奇更详细的分析了为什么不使用Twemproxy和Redis Cluster： Twemproxy：最大的痛点是无法平滑的扩容或者缩容，甚至修改配置都需要重启服务；其次，不可运维，甚至没有Dashboard。 Redis Cluster（官方）：无中心化设计，程序难以编写；代码有点吓人，clusterProcessPacket函数有426行，人脑难以处理所有的状态切换；迟迟没有正式版本，等了4年之久；目前还缺乏最佳实践，没有人编写Redis Cluster的若干条注意事项；整个系统高度耦合，升级困难。 刘奇表示，虽然我们有众多的选择，比如Tair、Couchbase等，但是如果你需要更复杂和优秀的数据结构，Redis可称为不二之选。基于这个原因，在Redis之上，豌豆荚设计了Codis，并将之开源。 |
