安全有效地输出价值：大数据是这个游戏的名字
【编者按】Hadoop于2006年1月28日诞生，至今已有10年，它改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，形成了自己的极其火爆的技术生态圈，并受到非常广泛的应用。在2016年Hadoop十岁生日之际，InfoQ策划了一个Hadoop热点系列文章，为大家梳理Hadoop这十年的变化，技术圈的生态状况，回顾以前，激励以后。
要建立一个大数据系统，我们需要从数据流的源头跟踪到最后有价值的输出，并在现有的Hadoop和大数据生态圈内根据实际需求挑选并整合各部分合适的组件来构建一个能够支撑多种查询和分析功能的系统平台。这其中既包括了对数据存储的选择，也涵盖了数据线上和线下处理分离等方面的思考和权衡。此外，没有任何一个引入大数据解决方案的商业应用在生产环境上承担的起安全隐患。因此，本文将从计算框架，NoSQL数据库，大数据平台安全等三个方面详细阐述在将数据转换成价值的过程中可能产生的技术选型，对比分析不同的应对场景和未来的框架和技术发展方向。
计算框架篇
1．大数据的价值
只有在能指导人们做出有价值的决定时，数据才能体现其自身的价值。因此，大数据技术要服务于实际的用途，才是有意义的。一般来说，大数据可以从以下三个方面指导人们做出有价值的决定：
• 报表生成（比如根据用户历史点击行为的跟踪和综合分析、应用程序活跃程度和用户粘性计算等）；
• 诊断分析（例如分析为何用户粘性下降、根据日志分析系统为何性能下降、垃圾邮件以及病毒的特征检测等）；
• 决策（例如个性化新闻阅读或歌曲推荐、预测增加哪些功能能增加用户粘性、帮助广告主进行广告精准投放、设定垃圾邮件和病毒拦截策略等）。
进一步来看，大数据技术从以下三个方面解决了传统技术难以达成的目标（如图1）：
图1 大数据的价值
• 在历史数据上的低延迟（交互式）查询，目标是加快决策过程和时间，例如分析一个站点为何变缓慢并尝试修复它；
• 在实时数据上的低延迟查询，目的是帮助用户和应用程序在实时数据上做出决策，例如实时检测并阻拦病毒蠕虫（一个病毒蠕虫可以在1.3秒内攻击1百万台主机）；
• 更加精细高级的数据处理算法，这可以帮助用户做出“更好”的决策，例如图数据处理、异常点检测、趋势分析及其他机器学习算法。
2．蛋糕模式
从将数据转换成价值的角度来说，在Hadoop生态圈十年蓬勃成长的过程中，YARN和Spark这二者可以算得上是里程碑事件。Yarn的出现使得集群资源管理和数据处理流水线分离，大大革新并推动了大数据应用层面各种框架的发展（SQL on Hadoop框架，流数据，图数据，机器学习）。它使得用户不再受到MapReduce开发模式的约束，而是可以创建种类更为丰富的分布式应用程序，并让各类应用程序运行在统一的架构上，消除了为其他框架维护独有资源的开销。就好比一个多层蛋糕，下面两层是HDFS和Yarn，而MapReduce就只是蛋糕上层的一根蜡烛而已，在蛋糕上还能插各式各样的蜡烛。在这一架构体系中，总体数据处理分析作业分三块（图2），在HBase上做交互式查询（Apache Phoenix，Cloudera Impala等），在历史数据集上编写MapReduce程序抑或利用Hive等做批处理业务，另外对于实时流数据分析Apache Storm则会是一种标准选择方案。虽然Yarn的出现极大地丰富了Hadoop生态圈的应用场景，但仍存有两个显而易见的挑战：一是在一个平台上需要维护三个开发堆栈；二是在不同框架内很难共享数据，比如很难在一个框架内对流数据做交互式查询。这也意味着我们需要一个更为统一和支持更好抽象的计算框架的出现。
图2 基于Yarn上的开发堆栈
3．一统江湖
Spark的出现使得批处理任务，交互式查询，实时流数据处理被整合到一个统一的框架内（图3），同时Spark和现有的开源生态系统也能够很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。通过启用内存分布数据集，优化迭代工作负载，用户能够更简单地操作数据，并在此基础上开发更为精细的算法，如机器学习和图算法等。有三个最主要的原因促使Spark目前成为了时下最火的大数据开源社区（拥有超过来自200多个公司的800多个contributors）：
图3 Spark统一了开发框架
• Spark可以扩展部署到超过8000节点并处理PB级别的数据，同时也提供了很多不错的工具供应用开发者进行管理和部署；
• Spark提供了一个交互式shell供开发者可以用Scala或者Python即时性试验不同的功能；
• Spark提供了很多内置函数使得开发者能够比较容易地写出低耦合的并且能够并发执行的代码，这样开发人员就更能集中精力地为用户提供更多的业务功能而不是花费时间在优化并行化代码之上。
当然Spark也和当年的MapReduce一样不是万灵药，比如对实时性要求很高的流数据处理上Apache Storm还是被作为主流选择，因为Spark Streaming实际上是microbatch（将一个流数据按时间片切成batch，每个batch提交一个job）而不是事件触发实时系统，所以虽然支持者们认为microbatch在系统延时性上贡献并不多，但在生产环境中和Apache Storm相比还不是特别能满足对低延时要求很高的应用场景。比如在实践过程中，如果统计每条消息的平均处理时间，很容易达到毫秒级别，但一旦统计类似service assurance（确保某条消息在毫秒基本能被处理完成）的指标，系统的瓶颈有时还是不能避免。但同时我们不能不注意到，在许多用例当中，与流数据的交互以及和静态数据集的结合是很有必要的，例如我们需要在静态数据集上进行分类器的模型计算，并在已有分类器模型的基础上，对实时进入系统的流数据进行交互计算来判定类别。由于Spark的系统设计对各类工作（批处理、流处理以及交互式工作）进行了一个共有抽象，并且生态圈内延伸出了许多丰富的库（MLlib机器学习库、SQL语言API、GraphX），使得用户可以在每一批流数据上进行灵活的Spark相关操作，在开发上提供了许多便利。
Spark的成熟使得Hadoop生态圈在短短一年之间发生了翻天覆地的变化，Cloudera和Hortonworks纷纷加入了Spark阵营，而Hadoop项目群中除了Yarn之外已经没有项目是必须的了（虽然Mesos已在一些场合替代了Yarn），因为就连HDFS, Spark都可以不依赖。但很多时候我们仍然需要像Impala这样的依赖分布式文件系统的MPP解决方案并利用Hive管理文件到表的映射，因此Hadoop传统生态圈依然有很强的生命力。
另外在这里简要对比一下交互式分析任务中各类SQL on Hadoop框架，因为这也是我们在实际项目实施中经常遇到的问题。我们主要将注意力集中在Spark SQL, Impala和Hive on Tez上，其中Spark SQL是三者之中历史最短的，论文发表在15年的SIGMOD会议上，原文对比了数据仓库上不同类型的查询在Shark（Spark最早对SQL接口提供的支持）、Spark SQL和Impala上的性能比较。也就是说，虽然Spark SQL在Shark的基础上利用Catalyst optimizer在代码生成上做了很多优化，但总体性能还是比不上Impala，尤其是当做join操作的时候，Impala可以利用“predicate pushdown”更早对表进行选择操作从而提高性能。不过Spark SQL的Catalyst optimizer一直在持续优化中，相信未来会有更多更好的进展。Cloudera的Benchmark评测中Impala一直比其他SQL on Hadoop框架性能更加优越，但同时Hortonworks评测则指出虽然单个数据仓库查询Impala可以在很短的时间内完成，但是一旦并发多个查询Hive on Tez的优势就展示出来。另外Hive on Tez在SQL表达能力也要比Impala更强（主要是因为Impala的嵌套存储模型导致的），因此根据不同的场景选取不同的解决方案是很有必要的。
4．各领风骚抑或代有才人出？
近一年比较吸引人眼球的Apache Flink（与Spark一样已有5年历史，前身已经是柏林理工大学一个研究性项目，被其拥趸推崇为继MapReduce, Yarn, Spark之后第四代大数据分析处理框架），与Spark相反，Flink是一个真正的实时流数据处理系统，它将批处理看作是流数据的特例，同Spark一样它也在尝试建立一个统一的平台运行批量，流数据，交互式作业以及机器学习，图算法等应用。Flink有一些设计思路是明显区别于Spark的，一个典型的例子是内存管理，Flink从一开始就坚持自己精确的控制内存使用并且直接操作二进制数据，而Spark一直到1.5版本都还是试用java的内存管理来做数据缓存，这也导致了Spark很容易遭受OOM以及JVM GC带来的性能损失。但是从另外一个角度来说，Spark中的RDD在运行时被存成java objects的设计模式也大大降低了用户编程设计门槛，同时随着Tungsten项目的引入，Spark现在也逐渐转向自身的内存管理，具体表现为Spark生态圈内从传统的围绕RDD（分布式java对象集合）为核心的开发逐渐转向以DataFrame（分布式行对象集合）为核心。总的来说，这两个生态圈目前都在互相学习，Flink的设计基因更为超前一些，但Spark社区活跃度大很多，发展到目前毫无疑问是更为成熟的选择，比如对数据源的支持（HBase, Cassandra, Parquet, JSON, ORC）更为丰富以及更为统一简洁的计算表示。另一方面，Apache Flink作为一个由欧洲大陆发起的项目，目前已经拥有来自北美、欧洲以及亚洲的许多贡献者，这是否能够一改欧洲在开源世界中一贯的被动角色，我们将在未来拭目以待。