1. 轻量级快速处理。着眼大数据处理，速度往往被置于第一位，我们经常寻找能尽快处理我们数据的工具。Spark允许Hadoop集群中的应用程序在内存中以100倍的速度运行，即使在磁盘上运行也能快10倍。Spark通过减少磁盘IO来达到性能提升，它们将中间处理数据全部放到了内存中。

Spark使用了RDD（Resilient Distributed Dataset）的理念，这允许它可以透明的内存中存储数据，只在需要时才持久化到磁盘。这种做法大大的减少了数据处理过程中磁盘的读写，大幅度的降低了所需时间。

2. 易于使用，Spark支持多语言。Spark允许Java、Scala及Python，这允许开发者在自己熟悉的语言环境下进行工作。它自带了80多个高等级操作符，允许在shell中进行交互式查询。

3. 支持复杂查询。在简单的“map”及“reduce”操作之外，Spark还支持SQL查询、流式查询及复杂查询，比如开箱即用的机器学习机图算法。同时，用户可以在同一个工作流中无缝的搭配这些能力。

4. 实时的流处理。对比MapReduce只能处理离线数据，Spark支持实时的流计算。Spark依赖Spark Streaming对数据进行实时的处理，当然在YARN之后Hadoop也可以借助其他的工具进行流式计算。对于Spark Streaming，Cloudera的评价是：

• 简单：轻量级且具备功能强大的API，Sparks Streaming允许你快速开发流应用程序。
• 容错：不像其他的流解决方案，比如Storm，无需额外的代码和配置，Spark Streaming就可以做大量的恢复和交付工作。
• 集成：为流处理和批处理重用了同样的代码，甚至可以将流数据保存到历史数据中。

5. 可以与Hadoop和已存Hadoop数据整合。Spark可以独立的运行，除了可以运行在当下的YARN集群管理之外，它还可以读取已有的任何Hadoop数据。这是个非常大的优势，它可以运行在任何Hadoop数据源上，比如HBase、HDFS等。这个特性让用户可以轻易迁移已有Hadoop应用，如果合适的话。

6. 活跃和无限壮大的社区。Spark起源于2009年，当下已有超过50个机构250个工程师贡献过代码，和去年六月相比，代码行数几乎扩大三倍，这是个令人艳羡的增长。

超越微型超级计算机，移动已经从各方各面向数据中心蔓延。智能设备剧增大大增加了处理这些数据的服务器压力，着眼我们日常使用的手机应用，图片分享、信息推送、推特、邮件服务等等，这些基于大规模云端基础设施的应用程序只不过是所有后台服务器运作的冰山一角。随着物联网的快速发展，数十亿美元的设备增长（不仅仅只是用户群的增加，也包括终端设备的增加），将逐渐显现出传统的基于电脑数据中心的淘汰趋势，传统数据中心已无力招架新的发展趋势。

移动设备的发展不仅对数据中心施压，也改变其运营模式，促使现有技术改革并为创业者提供新的机会。

移动供应链是如何改变数据中心的

1981年IBM第一台带有两个软盘驱动的PC诞生时，没有人能够想象到，它会成为继大型机之后数据中心技术最大的变革：在那之前，数据中心都是运行在unix小型计算机中。基于PC的架构开始接管数据中心之后，其价格开始降低。PC技术的革新创建了如今的数据中心模式——即x86虚拟服务器、Linux和Windows服务器——这些设备的费用及性能如今已经标准化。

当前，移动手机行业成为了创新发明的聚集地，也为小型应用规格开创了新的篇章：像是闪存、小型CPU、网络硬盘等等。也就是说，轻量级处理器（比如ARM）和低成本低功耗的移动组件将成为下一代数据中心基础设备，数据中心将因为智能手机以及互联网而重塑。

但所有这一切看起来似乎是违反常规的， 因为越多数据中心计算肯定意味着更大的CPU ，而这有可能导致其电力和冷却能力达到极限。虽然摩尔定律证实了我们能够拥有很强大的计算能力，但世界各地的数据、应用程序和计算资源的规模也都在倍增。数据中心内在的所有事物都在巨变，我们不能只依靠大型硬件来支撑移动行业革新。

当然，我们这里讨论的数据中心重大变革并不只简单体现在设备大小上，更多体现在移动产业链中支持商用组件的网络和存储设备优化上，体现在那些专有系统的硬件设备性能上。

想象一下，一堆超便宜，像手机一样的机器，它们之间都由超级复杂的软件互连，彻底替代这些远程控制冰箱大小的机器盒子，这将是怎样的一幅画面。

你见过一个带风扇或者冷却装置的移动电话吗？肯定没见过，因为移动设备在设计时就做好了适应巨大温差的准备，做好了转变电力和温差的相关优化功能。因此基于移动设备的数据中心，电力和温控成本将大幅降低，使用的电量将越来越少，占用的CPU也有可能变小；新的数据中心会因为使用移动供应链体系的底层硬件设备而更加高效且便宜。

当然，集合更小型终端设备并不意味着牺牲企业级的性能或处理器速度。Facebook，Google和Twitter等大规模的应用程序服务企业已经开始应用基于移动基础设施的数据中心。这也意味着数据中心架构不再受制于华尔街，像Google和Facebook这种使用商用硬件设备实现关键业务、每天服务数十亿用户的企业，为什么要复制银行业的传统运营架构？

值得关注的是：当Google和Facebook这种规模的数据中心变得更易于个人操作时将会发生什么？

基于移动设备的数据中心为初创企业提供了巨大机会

移动设备不仅仅改变了数据中心的构成，也构建了新一代企业的发展形态。重点不在于初创企业如何挑战Intel这类大型传统企业（不过这也有可能发生），而在于初创企业如何利用不同类别的硬件，如ARM处理器、闪存和网络硬盘，创建支持大软件的系统，并以此避免传统运营商在硬件设备及本地安装中获取丰厚利润。

基于数据中心体系结构从硬件到软件的这一转变，我们不再需要购买大量的服务资源，即可访问计算机网络堆栈中的所有业务层（比如访问Actifio，Coho Data，Cumulus Networks， Mesosphere等，这些只是我们投资组合里的例子）。

这并不意味所有的产品都要部署在云端，但意味着所有产品都将以服务的形式存在。由于很多移动端应用程序作为服务交付于云端，很多情况下，企业将不知不觉的转型云端基础设施。应用于基础设施的SaaS模式意味着企业可在部门级别使用相关工具，即它们可以在没有IT部门协助的前提下使用。企业可以在购买产品之前在云端试用，而不再需要花费长时间的概念验证和昂贵的beta测试；用户可以拥有及时更新，而不再需要为了新产品产品发布等待一年之久。

所有这些新的应用模式减少了产品生产周期，也同时意味着传统技术的落后，这一现象在全新的SaaS销售及客户服务模式、收入确认模式、工程、开发等领域犹为显著。为了跟上时代的脚步，企业们将不得不适应下一代云基础设施。

而对于初创企业来说，移动产业链的硬件组合、开源模块构建、SaaS模式，意味着整个计算机产业运营模式终于可以开始再造了。

在此之前，初创企业不得不适应传统的计算机—网络—数据库的运营模式，及其每一层的API。如果市场主导者不想初创公司使用相关产品，只需将相关APIs使用权限设置为“对不起，不支持”，初创公司就玩完了。

如今，初创公司不会再遇到这样尴尬的场景，新的运营模式可为每一层基础设施提供解决方案……企业不再需要必须成为其中一部分，可以摆脱现有的传统堆栈方式。而且在这些新的平台上创建新的应用程序及业务将为这些初创公司获得全新的利益，这是一个前所未有的新机遇。

因产品快速迭代而出现的“天天更”现象被用户强烈吐槽，安卓应用的更新问题实在是太鸡肋。任何产品的更新，肯定都是奔着用户去的（极少数是为了刷存在感），或是因为修正了产品的BUG，或是因为UI发生变化，或是因为功能升级，但是这些都是基于产品自身的，对于用户来说，并不是那么回事。

以微信为例，从4.5版本到5.3.1中间经历了十来个版本的更新，包括搜狐新闻客户端、爱奇艺、喜马拉雅电台等也都经历了多个版本的更新，只有极少数移动互联网应用是常年不更新的，基本上这种应用活跃度都不会太高。

首先我们来看更新的优势。

1. 修复漏洞。基本上安卓应用都会有部分BUG出现，一方面是安卓系统的问题，另一方面也是产品设计等问题。所以我们经常会在各大应用商店的更新列表里看到，XXX应用需要升级，升级原因，“修复产品BUG”等字眼，产品自身肯定是希望能够修复各种问题的。
2. 让产品更好。微信5.3版本出现的时候，很多用户都提出了“扁平化”的概念，包括微信在内，其他安卓应用都会为了让产品更好，更符合用户的浏览习惯、使用习惯、在功能上更完善，而推出新版本的应用。

至于所谓的存在感，对于几大热门安卓应用来说，完全没这个必要。打开应用APP，打开应用商店类产品，系统都会提示用户来更新，很多应用甚至强制绑定用户去更新，不更新就没法用。

长期处于更新状态的安卓应用遇到问题了，用户可能会一两次选择更新产品，但并不会每次都会按照系统提示去更新应用，这就给用户造成了对于系统提示的应用更新视而不见的尴尬局面，即使应用已经更新了十几个版本，用户还是在用最初的版本，因为在最基本的需求上，如聊天、听音乐、看电影等方面，新旧版本之于“内核”上无太大变化。

安卓应用的另一个迷局在于整个安卓应用生态上，基本上几大应用中心控制着移动应用分发的入口，依靠自身获得大量用户的移动应用并不多。

百度手机助手、应用宝、搜狗手机助手、360手机助手、91手机助手、豌豆荚、金山手机助手、PP助手，这些是第三方的应用中心，vivo应用中心、小米应用中心，以及其他国产手机也开通了自己的应用中心，几大国产手机的出货量也不在少数，他们也掌控着部分的移动应用分发入口。

从上面来看，整个安卓应用分发中心多达几十种，还有各种知名不知名的，作为一款移动应用，要想通过各大移动应用来提升分发量，就需要和这多达数十款的移动应用相配合。

也就是说某款移动应用一款版本想要在几大应用中心上更新版本，是需要和这数十款应用中心相互配合的，可能会因为各种审核等原因周期增长。

应用中心一多，就给移动应用自身带来了麻烦，很多“不热门”的应用中心，要被选择性抛弃，只选择几大热门应用中心进行更新，但是大牌往往并不好伺候。

所以我们经常遇到的一个问题是，从某安卓应用中心下载某应用，打开后系统又提示用户进行升级，用户不能一次性通过应用中心下载到最新版的应用。当然，这里面会涉及到多方面的因素，但是对于用户来说，这个是鸡肋的，在非WiFi环境下，用户是不会选择下载的，应用自身试图更新的“良苦用心”被浪费了。

总结一下安卓应用更新遇到的两个迷局，一个是基于自身方向的，几乎半个月一个月更新一次，用户难以跟上应用更新的节奏，到后来就不去更新了。另一个迷局是基于平台方向的，即自身平台的版本和应用中心的版本不一致，用户需要先下载再更新，明显增加了一个动作，而且还是耗费流量的动作，有些有PC端网站的，也经常出现移动端和PC端的版本不一致的局面。

移动应用的每一次更新几乎耗费了整个团队的精力，但是现在面临的是如何与用户和谐的相互更新，不能应用更新，而用户完全忽视，这完全就是吃力不讨好的事儿。

在安卓的大应用生态体系中，众多的应用中心带给厂商们的不仅只有分发量了，还有来自诸多平台之间的相互配合等问题，如何让用户下载到和应用相同版本的应用，是当前非常值得思量的事情。

关于自身方向上的更新问题，我认为不应当频繁让用户去更新新版本的APP，应当选择适当的周期，为用户提供有价值的更新，避免让用户陷入“该软件一直在更新”的死水潭中去。至于平台方向上，应当选择同步，避免让用户做重复的动作，损精伤流，同时有选择性的放弃掉分发量低的应用中心，主攻分发量大的平台，这样能集中团队的精力。