本篇文章的大部分信息收集于36kr,另附了本人的一些想法
一.Nokia衰败的经过2007 年初,iPhone闪亮登场。2007年末,Google展示了 Android操作系统:两者的到来宣告了同一件事——“智能”手机的“智能”可不是 Symbian 想的那么简单。
放弃 Symbian是诺基亚的必经之路。不过,放弃 Symbian必须是逐步的,因为 Symbian截至到目前仍然是诺基亚智能手机领域的主力军。在诺基亚转战到另一平台(无论是 Meego还是 WP,这里暂不讨论)之前,Symbian必须能够给诺基亚一个平稳的过渡。
2011年2月份CEO Elop的计划:
关于塞班部分的实际情况:
关于功能手机的实际情况
Win Phone的实际情况
虽然诺基亚的旗舰机 lumia 920 在欧洲广受欢迎,但据诺基亚刚刚发布的财报,第三季度,诺基亚 Lumia 系列手机销量降至 290 万部,低于分析师预期的 293 万部,也大大低于上一季度售出的 400 万部。目前为止,诺基亚已在 WP 平台损失了近 25 亿美元。
从上面四幅图可以看出,Elope提出的三条腿计划的效果并没有想象中的那么,塞班系统的手机大大的脱离了当初的期望,连主力军的功能手机也出现了一定的减少,而期望最大的windows
Mobile的手机只达到了预期的很少一部分。三条腿计划没有保住任何一个领域,在这关键时刻,微软又给了Nokia的背后一刀。
重磅一击:微软给诺基亚的背后一刀
诺基亚和微软合作基于的是 WP7 平台,整个 Lumia 产品线搭载的也是 WP7 操作系统。但是,在今年 6 月 20 日,微软正式发布 Windows Phone 8,宣布 WP7 生命周期终止,正式退出市场,同时还宣布所有 WP7 手机全部不能升级到 WP8 系统。这当头一棒是彻底把诺基亚打懵了,之后诺基亚 Lumia 系列无论是在销量还是价格上都大受影响。照此看来,诺基亚的这最后一条最关键的腿也算是折了。而 Elop 本人也承认诺基亚过去本可在 WP 平台上做的更好。不过 Elop 同时也表示,产品没问题,诺基亚不会改变策略,未来诺基亚还会坚守 WP 平台,并且相信这会是一笔好生意。
二.Nokia现在的现状:与微软联姻Nokia的处境如此糟糕,还能够挣扎着逆袭吗?那么如何挣扎呢?
Nokia向智能领域发展是个正确的决定,但Android联盟早已形成,诺基亚加进去只能成为三星、HTC的小跟班,再没机会回到曾经的辉煌。只能与微软的windows Phone联姻,在windows phone领域有所突破。
(1)联姻的挑战
诺基亚的重点市场在欧洲和亚洲地区——Windows Phone想要在智能手机平台取得一席之地,就必须在美国市场拿出有说服力的表现。这就是两者的联姻后的一个大的挑战,得需要他们共同解决。
(2)联姻的好处
诺基亚急需一款优秀的操作系统能够和他杀手级的硬件设计和技术进行双剑合璧。和诺基亚恰好相反,微软优势在软件,缺点是没有硬件,两者天生绝配。
除了拥有顶级的硬件团队,诺基亚还拥有全世界覆盖面最广的运营商渠道,这将帮助微软省不少力。诺基亚还有非常优秀的地图服务。不要小看了地图服务。如果你仔细想想用户在移动端的使用场景,你会发现地图一直是用户行为的中心。
微软用诺基亚地图不是白用的,给了诺基亚数十亿美金,还包括广告分成。利益不止如此。对诺基亚来说,将自家地图植入 WP平台,意味着自己在 WP平台的核心地位将更加稳固,别的 WP厂商将会对诺基亚产生依赖性。
对于我来说,还是很看好Nokia,相信他与微软齐心协力也能打造windows phone生态系统,相信Nokia能够王者归来。下面列出证据。
三.Nokia 王者归来的证据 1.塞班虽不是核心,但依旧重要:低端市场智能手机虽火,但在覆盖的用户数还远不到地球总人口的 1/4,在低端市场,塞班仍将是诺基亚“攻城略地”的主力。例:印度拥有 12 亿的人口,却只有 6300万人能够接入互联网。所以塞班在低端市场还有潜力。
2.设计:解除人们对iphone、android手机的审美疲劳(Nokia win phone手机的概念设计)
苹果的 iPhone代表了一大阵营,安卓手机算是 iPhone衍生出的一个变种,他们对用户界面的设计都是类似的。而诺基亚要独树一帜,要让用户一眼就能从 Modern UI(原 Metro UI)特有的“动态方块”上获取包括时间、运行中程序在内的信息,而方块式的用户界面也与诺基亚手机的整体造型产生了里外一致的呼应效果。
我相信在iphone和android手机界面的轰炸下,Nokia能够让人眼前一亮。
3.新鲜配置
Nokia也做了十几年的老大,自然积累了大量的技术,这为Nokia的逆袭提供了支持。下面以4100像素为例。该技术是Nokia花费5年时间的研究成果。
诺基亚 4100万像素的手机 808 PureView 赚足了人们的眼球,我们未来仍然有机会在 WP手机上看到该技术,诺基亚智能手机部门主管 Jo Harlow虽未明确提及一个时间表,但是她说:“我根本不担心我们将该技术引入 WP平台所遇到的技术难题。”
诺基亚 Lumia 900非合约裸机版售价 450美元,元件成本 209美元;而苹果 16G版的 iPhone 4S的非合约裸机版售价为 649美元,元件成本 190美元。
成本上的差异主要是因为 Lumia使用了更大的屏幕和更先进的无线芯片——Lumia 900支持 4G LTE网络,而 iPhone不行。该成本差异也同时反映了苹果对供应链的把控能力之强,它能从供应商那里拿到更低的价格。
单从性价比来说,还是能够吸引到不少人。
6.CEO魄力:欢迎其它手机厂商加入 WP平台Elop 甚至表示:“诺基亚欢迎 HTC、三星或是微软等其它厂商推出 Windows Phone 手机,因为这些投资能够促进整个生态系统的发展,给 WP注入一针兴奋剂。”诺基亚一点都不担心物极必反,最终被微软或其它厂商抢去 老大哥地位,因为身上有两个筹码:
筹码一:和微软的亲密联盟,让诺基亚在 WP 平台上有独特优势
其他厂商的手机给用户的是一种标准的 Win8体验,而诺基亚的 WP将具备更多的独特功能,具备更多的创新,以区别于其他手机。
筹码二:微软只有心打造平台,根本无心插足硬件
自从Nokia衰弱之后,很多人都不看好Elop,认为他应该下台,但是我一直都支持他,甚至有人说,Nokia只能投入android的怀抱才有救,我不认为,android如见这么成熟,各大厂商已经有了自己的支持者,如果Nokia现在才加入,只能做跟班小弟。Elope现在的心态也是很好的,先齐心协力把windowsphone的生态系统打造出来,Nokia才有出路。
7.Lumia全线上阵诺基亚第三季度不出意外地亏损了。财报显示,诺基亚营收下滑至 72.39亿欧元,营业亏损为 5.76亿欧元。手机出货量 8290万部,同比下滑 22%。
最引人注目的是诺基亚最新旗舰 Lumia 920的销量。第三季度 Lumia的销量为 290万部,比上一季度的 400万部下降了 28%,这是自发布以来,Lumia系列销量首次下滑。分析师认为,Lumia本身产品没问题,主要原因是客户都在期待搭载 WP8的 Lumia。
在明年,诺基亚的 Lumia将扩大产品线,争取在各个方面都能和 iPhone以及 Android手机对打,为开发者和消费者提供智能手机的第三大阵营。
我很期待2013年的这场好戏。
四、总结上面列出了那么多的证据,总结几条:
(1)过去的积累
包括一流的硬件技术,全球的运营商
(2)所选的新平台
Nokia与微软的合作是必然的,因为windows phone还很年轻,很有潜力,不仅能够让Nokia重新在手机领域突破找到自己的位置,微软也能借机推广自己的平台。有利益那必须有风险,他们必须共同克服。
(3)性价比
Nokia很理智的降低价格,虽然现在过得很困难,但是让人接受Nokia只能手机才是关键。相信高性价比能吸引一些人。
总之,我还是很看好Nokia的,希望它真的能够如我期望那样,王者归来。
奥古斯塔·爱达·金,勒芙蕾丝伯爵夫人(英语:Augusta Ada King, Countess of Lovelace,1815年12月10日-1852年11月27日),原名奥古斯塔·爱达·拜伦(Augusta Ada Byron),通称爱达·勒芙蕾丝(Ada Lovelace),又译阿达·奥古斯塔,是著名英国诗人拜伦之女。被后人公认为第一位计算机程序员。
爱达是她诗人父亲—拜伦与母亲安妮·伊莎贝拉·米尔班奇(英语:Anne Isabella Milbanke)唯一的合法子嗣。她的名字取自拜伦的异母的姊妹奥古斯塔·李(英语:Augusta Leigh)。拜伦与安妮贝拉的婚事是在奥古斯塔为了避免丑闻,而怂恿拜伦与安妮贝拉结合的产物。然而,在1816年1月16日,安妮贝拉还是离开拜伦,带着一个月大的爱达离开。同年4月21日,拜伦签下了分居协议,并离开英国。
爱达从未见过她同父异母的妹妹阿拉格·拜伦(英语:Allegra Byron),阿拉格是拜伦与克莱尔·克莱蒙(英语:Claire Clairmont)所出,但于1822年死去,享年5岁。至于爱达的另一位亲戚奥古斯塔·李之女伊丽莎白·梅朵拉·李(英语:Elizabeth Medora Leigh)则有与她照过面,并由爱达的母亲告知爱达与梅朵拉彼此的身世。
Hadoop(大数据分析领域无可争辩的王者)专注于批处理。这种模型对许多情形(比如为网页建立索引)已经足够,但还存在其他一些使用模型,它们需要来自高度动态的来源的实时信息。为了解决这个问题,就得借助 Nathan Marz 推出的 Storm(现在在 Twitter 中称为 BackType)。Storm 不处理静态数据,但它处理预计会连续的流数据。考虑到 Twitter 用户每天生成 1.4 亿条推文 (tweet),那么就很容易看到此技术的巨大用途。
但 Storm 不只是一个传统的大数据分析系统:它是复杂事件处理 (CEP) 系统的一个示例。CEP 系统通常分类为计算和面向检测,其中每个系统都可通过用户定义的算法在 Storm 中实现。举例而言,CEP 可用于识别事件洪流中有意义的事件,然后实时地处理这些事件。
Nathan Marz 提供了在 Twitter 中使用 Storm 的大量示例。一个最有趣的示例是生成趋势信息。Twitter 从海量的推文中提取所浮现的趋势,并在本地和国家级别维护它们。这意味着当一个案例开始浮现时,Twitter 的趋势主题算法就会实时识别该主题。这种实时算法在 Storm 中实现为 Twitter 数据的一种连续分析。
Storm 与传统的大数据
Storm 与其他大数据的不同之处在于它的处理方式。Hadoop 在本质上是一个批处理系统。数据被引入 Hadoop 文件系统 (HDFS) 并分发到各个节点进行处理。当处理完成时,结果数据返回到 HDFS 供始发者使用。Storm 支持创建拓扑结构来转换没有终点的数据流。不同于 Hadoop 作业,这些转换从不停止,它们会持续处理到达的数据。
大数据实现
Hadoop 的核心是使用 Java? 语言编写的,但支持使用各种语言编写的数据分析应用程序。最新的应用程序的实现采用了更加深奥的路线,以充分利用现代语言和它们的特性。例如,位于伯克利的加利福尼亚大学 (UC) 的 Spark 是使用 Scala 语言实现的,而 Twitter Storm 是使用 Clojure(发音同 closure)语言实现的。
Clojure 是 Lisp 语言的一种现代方言。类似于 Lisp,Clojure 支持一种功能性编程风格,但 Clojure 还引入了一些特性来简化多线程编程(一种对创建 Storm 很有用的特性)。Clojure 是一种基于虚拟机 (VM) 的语言,在 Java 虚拟机上运行。但是,尽管 Storm 是使用 Clojure 语言开发的,您仍然可以在 Storm 中使用几乎任何语言编写应用程序。所需的只是一个连接到 Storm 的架构的适配器。已存在针对 Scala、JRuby、Perl 和 PHP 的适配器,但是还有支持流式传输到 Storm 拓扑结构中的结构化查询语言适配器。
Storm 的关键属性
Storm 实现的一些特征决定了它的性能和可靠性的。Storm 使用 ZeroMQ 传送消息,这就消除了中间的排队过程,使得消息能够直接在任务自身之间流动。在消息的背后,是一种用于序列化和反序列化 Storm 的原语类型的自动化且高效的机制。
Storm 的一个最有趣的地方是它注重容错和管理。Storm 实现了有保障的消息处理,所以每个元组都会通过该拓扑结构进行全面处理;如果发现一个元组还未处理,它会自动从喷嘴处重放。Storm 还实现了任务级的故障检测,在一个任务发生故障时,消息会自动重新分配以快速重新开始处理。Storm 包含比 Hadoop 更智能的处理管理,流程会由监管员来进行管理,以确保资源得到充分使用。
Storm 模型
Storm 实现了一种数据流模型,其中数据持续地流经一个转换实体网络(参见 图 1)。一个数据流的抽象称为一个流,这是一个无限的元组序列。元组就像一种使用一些附加的序列化代码来表示标准数据类型(比如整数、浮点和字节数组)或用户定义类型的结构。每个流由一个惟一 ID 定义,这个 ID 可用于构建数据源和接收器 (sink) 的拓扑结构。流起源于喷嘴,喷嘴将数据从外部来源流入 Storm 拓扑结构中。
图 1. 一个普通的 Storm 拓扑结构的概念性架构
接收器(或提供转换的实体)称为螺栓。螺栓实现了一个流上的单一转换和一个 Storm 拓扑结构中的所有处理。螺栓既可实现 MapReduce 之类的传统功能,也可实现更复杂的操作(单步功能),比如过滤、聚合或与数据库等外部实体通信。典型的 Storm 拓扑结构会实现多个转换,因此需要多个具有独立元组流的螺栓。喷嘴和螺栓都实现为 Linux? 系统中的一个或多个任务。
可使用 Storm 为词频轻松地实现 MapReduce 功能。如 图 2 中所示,喷嘴生成文本数据流,螺栓实现 Map 功能(令牌化一个流的各个单词)。来自 “map” 螺栓的流然后流入一个实现 Reduce 功能的螺栓中(以将单词聚合到总数中)。
图 2. MapReduce 功能的简单 Storm 拓扑结构
请注意,螺栓可将数据传输到多个螺栓,也可接受来自多个来源的数据。Storm 拥有流分组 的概念,流分组实现了混排 (shuffling)(随机但均等地将元组分发到螺栓)或字段分组(根据流的字段进行流分区)。还存在其他流分组,包括生成者使用自己的内部逻辑路由元组的能力。
但是,Storm 架构中一个最有趣的特性是有保障的消息处理。Storm 可保证一个喷嘴发射出的每个元组都会处理;如果它在超时时间内没有处理,Storm 会从该喷嘴重放该元组。此功能需要一些聪明的技巧来在拓扑结构中跟踪元素,也是 Storm 的重要的附加价值之一。
除了支持可靠的消息传送外,Storm 还使用 ZeroMQ 最大化消息传送性能(删除中间排队,实现消息在任务间的直接传送)。ZeroMQ 合并了拥塞检测并调整了它的通信,以优化可用的带宽。
Storm 示例演示
现在让我们通过实现一个简单的 MapReduce 拓扑结构的代码(参见 清单 1),看一下 Storm 示例。这个示例使用了来自 Nathan 的 Storm 入门工具包(可从 GitHub 获取)(参见 参考资料 获取链接)的巧妙设计的字数示例。此示例演示了 图 2 中所示的拓扑结构,它实现了一个包含一个螺栓的 map 转换和包含一个螺栓的 reduce 转换。
清单 1. 为图 2 中的 Storm 构建一个拓扑结构
清单 1(添加了行号以供引用)首先使用 TopologyBuilder 声明一个新拓扑结构。接下来在第 3 行,定义了一个喷嘴(名为 spout),该喷嘴包含一个 RandomSentenceSpout。RandomSentenceSpout 类(也就是 nextTuple 方法)发出 5 个随机句子的其中一个作为它的数据。setSpout 方法末尾的 5 参数是一个并行性提示(或要为此活动创建的任务数)。
在第 5 和 6 行。我定义了第一个螺栓(或算法转换实体),在本例中为 map(或 split)螺栓。这个螺栓使用 SplitSentence 令牌化输入流并将其作为输出的各个单词发出。请注意,第 6 行使用了 shuffleGrouping,它定义了对此螺栓(在本例中为 “spout”)的输入订阅,还将流分组定义为混排。这种混排分组意味着来自喷嘴的输入将混排 或随机分发给此螺栓中的任务(该螺栓已提示具有 4 任务并行性)。
在第 8 和 9 行,我定义了最后一个螺栓,这个螺栓实际上用于 reduce 元素,使用该元素的输入作为 map 螺栓。WordCount 方法实现了必要的字数统计行为(将相似的单词分组到一起,以维护总数),但不是混排的,所以它的输出是一致的。如果有多个任务在实现 reduce 行为,那么您最终会得到分段的计数,而不是总数。
第 11 和 12 行创建和定义了一个配置对象并启用了 Debug 模式。Config 类包含大量配置可能性(参见 参考资料,获取有关 Storm 类树的更多信息的链接)。
第 14 和 15 行创建了本地集群(在本例中,用于定义本地模式的用途)。我定义了我的本地集群、配置对象和拓扑结构的名称(可通过 builder 类的 createTopology 元素获取)。
最后,在第 17 行,Storm 休眠一段时间,然后在第 19 行关闭集群。请记住,Storm 是一个持续运行的操作系统,所以任务可存在相当长时间,不断处理它们订阅的流上的新元组。
您可在 Storm 入门工具包中了解这个非常简单的实现的更多信息,包括喷嘴和螺栓的细节。
使用 Storm
Nathan Marz 编写了一组简单易懂的文档,详细介绍了如何安装 Storm 来执行集群模式和本地模式的操作。本地模式无需一个庞大的节点集群,即可使用 Storm。如果需要在一个集群中使用 Storm 但缺乏节点,也可在 Amazon Elastic Compute Cloud (EC2) 中实现一个 Storm 集群。请参见 参考资料 获取每个 Storm 模式(本地、集群和 Amazon EC2)的参考信息。
其他开源的大数据
自 Google 在 2004 年推出 MapReduce 范式以来,已诞生了多个使用原始 MapReduce 范式(或拥有该范式的质量)的。Google 对 MapReduce 的最初应用是建立万维网的索引。尽管此应用程序仍然很流行,但这个简单模型解决的问题也正在增多。
表 1 提供了一个可用开源大数据的列表,包括传统的批处理和流式处理应用程序。在将 Storm 引入开源之前将近一年的时间里,Yahoo! 的 S4 分布式流计算平台已向 Apache 开源。S4 于 2010 年 10 月发布,它提供了一个高性能计算 (HPC) 平台,向应用程序开发人员隐藏了并行处理的复杂性。S4 实现了一个可扩展的、分散化的集群架构,并纳入了部分容错功能。
表 1. 开源大数据
更多信息
尽管 Hadoop 仍然是宣传最多的大数据分析,但仍可能存在许多其他的,每种都具有不同的特征。我在过去的文章中探讨了 Spark,它纳入了数据集的内存中处理功能(能够重新构建丢失的数据)。但 Hadoop 和 Spark 都专注于大数据集的批处理。Storm 提供了一个新的大数据分析模型,而且因为它最近被开源,所以也引起广泛的关注。
与 Hadoop 不同,Storm 是一个计算系统,它没有包括任何存储概念。这就使得 Storm 能够用在各种各样的上下文中,无论数据是从一个非传统来源动态传入,还是存储在数据库等存储系统中(或者由一个控制器用于对其他一些设备(比如一个交易系统)进行实时操作)都是如此。
请参见 参考资料 获取有关 Storm 的更多信息的链接,了解如何让一个集群正常运行,以及其他大数据分析(包括批处理和流式处理)。
参考资料
-
复杂事件处理 是 Storm 以及其他许多(比如 Yahoo! 的 S4)实现的模式。Storm 与 S4 之间的一个重要区别在于,Storm 在面对故障时提供了有保障的消息处理,而 S4 可能丢失消息。
-
Nathan Marz(Storm 背后的重要开发人员)为他的新产品编写了多篇有趣且实用的介绍文章。对 Storm 的最早介绍来自 2011 年 5 月的 Storm 预览:能够实时处理的 Hadoop - BackType Technology,随后是
8 月推出的 A Storm is coming: more details and plans for release。
-
Storm 维基 提供了有关 Storm、它的理论基础的大量优秀文档,以及有关获取 Storm 和设置新项目的各种教程。您还将找到一些有关 Storm 的许多方面的实用文档,包括 Storm 在本地模式、集群模式和在 Amazon 上的使用。
-
Spark,一种快速数据分析替代方案(M. Tim Jones,developerWorks,2011 年 11 月)介绍了 UC Berkeley 的内存中弹性数据分析平台。
-
应用程序虚拟化的过去与未来(M. Tim Jones,developerWorks,2011 年 5 月)详细介绍了虚拟化在语言抽象方面的使用。Storm 使用基于虚拟机的语言 Clojure 来实现,还使用
Java 技术和许多其他语言来构建它的内部(螺栓)应用程序。
-
GitHub 上提供了 Storm 的一个 thorough class tree exists,详细介绍了 Storm 的类和接口。
- Hadoop 已开始解决简单批处理以外的模型。例如,通过调度,Hadoop 可调整其处理数据的方式,以便更多地关注交互性,而不是批量数据处理。在 Hadoop 中的调度(M. Tim Jones,developerWorks,2011 年 12 月)中了解有关 Hadoop 调度的更多信息。