大数据云安全策略4大窍门

大数据云安全策略4大窍门

云计算与大数据的结合可以说是天作之合。大数据需要灵活的计算环境,而后者可以快速、自动地进行扩展以支持海量数据。基础设施云可以精准地提供这些需求。但是无论什么时候对云计算展开讨论,我们都无法回避以下问题:

针对大数据的云安全策略是什么?

当在大数据使用案例中提及云安全策略时,我们希望任何安全解决方案都能够在不影响部署安全性的情况下提供与云一样的灵活性。在将大数据转移至云上时,以下四个小贴士可以让用户既能享受到云计算的灵活性又能获得严格的云安全策略。

1、将敏感数据加密(强烈推荐)

数据加密将会为你的云基础设施建起一堵“虚拟的墙”。部署云加密措施被认为是首要步骤,但是它们并不适合所有的解决方案。一些加密解决方案需要本地网关加密,这种方案在云大数据环境下无法很好的工作。还有一些解决方案(例如,由云服务提供商对数据进行加密)会迫使终端用户信任那些拥有密钥的人,而这些本身就蕴藏着危险和弱点。

近期的一些加密技术,如分裂密钥加密,都非常适合云计算。用户在享受基础设施云解决方案提供的优势的同时又可以将密钥保存在自己手中,让密钥处于安全状态下。为了能够让你的大数据环境获得最佳的加密解决方案,建议使用分裂密钥加密。

2、寻找在结构上能够扩展的云安全解决方案

在大数据当中,结构的每一个组件都应该能够扩展,云安全解决方案也不例外。在选择云安全解决方案时,用户需要确保它们在所有跨地区云部署点中都能够发挥作用。此外,它们在大数据基础设施当中必须要能够高效地扩展。表面上,这并不涉及硬件问题。但是由于硬件安全模块(HSM)不具扩展能力并且无法灵活适应云模式,因此它们不适合大数据使用案例。

为了获得必要的扩展性,建议使用专门针对云计算设计的云安全解决方案,它们的安全性可以等效(甚至是超过)基于硬件的解决方案。

3、实现最大程度的自动化

云安全架构无法轻易扩展这一因素导致大数据云计算机的研发受挫。传统加密解决方案需要HSM(硬件)单元。勿庸置疑,硬件部署无法实现自动化。

为了让云安全策略尽可能地实现自动化,用户应当选择虚拟工具解决方案,而不是硬件解决方案。用户需要明白可用的API(最好是闲置的API)也是云安全解决方案的一部分。虚拟工具加上闲置的API能够在云大数据使用案例中提供所需要的灵活性和自动化。

4、对数据安全永不妥协

虽然云安全通常十分复杂,但是用户在大数据部署当中还是会发现一些“安全捷径”。这些“安全捷径”通常貌似能够回避一些复杂设置,同时保持大数据结构“不受伤害”。

一些客户可能会使用免费的加密工具,并将密钥存储在硬盘(这种做法非常不安全,可能会导致加密数据被暴露在任何有访问虚拟硬盘权限的人面前),有些客户甚至不采取加密措施。这些捷径肯定并不复杂,但是很明显,它们并不安全。

在涉及大数据安全性时,用户应当根据数据的敏感程度进行分类,然后对它们采取相应的保护措施。在一些案例当中,结果往往是戏剧性的。并不是所有的大数据基础设施是安全的,如果处于风险当中的数据非常敏感或是属于管制数据,那么用户可能需要寻找替代方案。

针对大数据的云安全策略

只有为数据建立了最为严格的安全标准,大数据才能够不断地享受着由云计算提供的可扩展性、灵活性和自动化。加密被认为是保护云(大)数据的首要步骤。分裂密钥加密和同态密钥管理等新技术应当投入到保护敏感数据当中,同时用户还需要严格遵守HIPAA、PCI等规章制度。

作者:范范编译 | 来源:网界网

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

大数据云安全策略4大窍门

End.



转载请注明:36大数据 » 大数据云安全策略4大窍门

利用大数据技术进行图处理

利用大数据技术进行图处理

处理非常大型的图对象一直都是个挑战,但最近大数据技术的进步却让这一工作变得更具实践性。作为纽约市的一家专注于跨设备内容分发的创业公司,Tapad利用大数据技术处理TB级的数据,并已将图处理作为其商业模型的核心业务。

像Facebook和Twitter这样的社交网络,其数据天生就适合于图表示法。而对这方面属性不太明显的数据,我们也可以用图对象来表示,比如Tapad的设备图。Tapad的联合创始人兼CTO,Dag Liodden,解释了为什么对设备使用图表示法很有意义:

“Tapad采用面向图的方式对设备间的关系进行建模。在设备图中,我们把匿名标示符(如cookie ID)表示为节点并且追踪这些节点的市场信息。节点间的边则结合使用测定数据、概率统计模型以及机器学习技术计分或加权重。我们将‘设备’的概念定义为一个起始设备或节点(比如说某个浏览器的cookie ID)和由该起点出发的、在一组可定制边约束下能达到的节点集合(比如说一个Tablet和一个Connected TV的cookie ID)。相对于单个节点仅有的聚合信息,实际的图结构使我们能够在动态平衡数据准确度和规模方面更具灵活性,而且还能更容易地运用新的边推理模型来对图进行扩充。

用合适的工具完成合适的工作很重要,这个道理同样适用于图处理:对于通过传统工作负载就能处理的图对象,我们就没必要使用大数据技术。正如Dag所说:

“‘大数据’对我而言就像个门槛,跨过之后你就不能再使用少数通用的、现成的工具来存储和分析数据了,而是要依据具体的用例对不同的技术加以取舍。随着软硬件解决方案的进步和成熟,这些阈值每年都在变动,而我们所处理的数据集的大小以及所进行的分析的复杂程度亦是如此。”

对Facebook来说,这个阈值达到了几PB级,详情可参阅他们在2013纽约ACM SIGMOD大会上的报告。对Tapad而言,图对象的数据量虽然较小,但依然不可能用传统的方法来处理:

“全美的图对象当前有大约11亿个节点,它们代表着移动电话、平板、笔记本、游戏终端以及电视机。其中有些节点是临时的,比如因为浏览器使用非持久的cookie,导致节点缺少数据而没有边缘。非临时节点平均有大概5个边缘和约500个离散的信息片段与其相关联,如行为分段。实时图数据量达到了几TB级,而且我们还要跨多个数据中心每秒对其进行几十万次的读取、写入操作。图对象的更新实现了跨地域相互复制,每个数据中心由配备了20TB Flash SSD存储和2TB RAM的服务器来支撑。”

近几年涌现出很多处理大型图对象的技术,尤其是2013年,我们看到了几个新成员加入到该生态系统中。有两类系统值得考虑:

针对OLTP工作负载,能够快速低延迟访问小部分图数据的图数据库。
针对OLAP工作负载,能够对图对象中的大部分数据进行批处理的图处理引擎。

知名的图数据库已经很多了,但最近仍冒出了几个标新立异的项目。Neo4j算是最老牌、最成熟的图数据库之一,但因不支持分片而依然存在可伸缩性的问题。另一个相当年轻,却在2013年非常流行的数据库便是Titan。作为后端无关的图数据库,它支持HBase和Cassandra的可伸缩架构,并且如2013年的一篇博文所报道的,它在内部使用了一套优化的顶点和边表示法以使其能处理几十亿个边对象。

但你不必非要使用图特定数据库,更通用的可伸缩的NoSQL数据库也是有效的解决方案。基于Google BigTable并在2011年开源的Apache Accumulo就是一个通用数据库的例子,它的数据记录很灵活,所以也适合存储大型图对象,同时还可以用来存储含有类型化的边和权重的图对象,2013年发布的一份技术报告表明NSA也在使用它。Cassandra或者Aerospike则是另一种数据库,它们能通过适当的数据模型,用边、顶点和权重给图对象高效地建模。Facebook也构建了自己的解决方案,他们在被称为Tao的系统中使用了MySQL和Memcache组合,并正在使用这一方案为其用户提供社区图服务。据Dag所说,Tapad在其设备图的设计过程中也运用了同样的哲学:

“将实时的图对象保存在键值对存储中可以支持快速的遍历和更新。我们就是把图的快照周期性地存进HDFS,然后从中提取它们进行高级图处理并用其他数据流来扩充,之后再把结果回填至‘实时图’。虽然使用图特定的数据库会有一些优势,但以我们目前的设置,既可以在键值对存储中极快且简单地遍历图对象,还可在Hadoop上慢速但非常灵活地进行遍历和分析操作,对我们来说它工作的很好,至少现在如此。”

和存储于数据库中的图对象一样 ,可大规模进行的操作也只是局限于查找和小范围的遍历。至于在图对象中进行更加复杂的分析,就需要分布式的批处理框架。为了达到最佳性能,GraphLab框架使用了Message Passing Interaface(MPI)模型来调整并运行基于HDFS数据的复杂算法。而新近的框架如Apache Giraph和Apache Hama则基于Bulk Synchronous Paralle(BSP)范式,该范式是由Google的Pregel项目推广开的。而生态系统中最新的项目便是GraphX和Faunus。GraphX项目运行于2013年才问世的Spark之上,而Faunnus则通过用Hadoop运行MapReduce作业的方式来处理Titan数据库中图对象。Tapad正在运用这些新技术处理其离线图数据。按照Dag所说:

“目前,我们主要的图处理框架虽是Apache Giraph,但我们也在尝试Saprk GraphX和GraphLab。所有这些架构还都很年轻,学习曲线也颇为陡峭,而且全都有自己的优缺点及注意事项。举个例子,Giraph和GraphX由于能很好地支持我们的Hadoop架构所以很方便,但GraphLab却完全是因为其性能而更吸引我们。”

有些项目正试图提供统一的架构以支持OLTP和OLAP查询。来自Lab41的Dendrite就是这样一个项目,它利用基于Titan的GraphLab进行存储、处理,并用AngularJS实现可视化。因为这个非常年轻的项目在2014年年初才公开,所以社群反响有限,但是它试着顾及到所有用例,这应该有助于它的普及。

英语原文:

Processing extremely large graphs has been and remains a challenge, but recent advances in Big Data technologies have made this task more practical. Tapad, a startup based in NYC focused on cross-device content delivery, has made graph processing the heart of their business model using Big Data to scale to terabytes of data.

Social networks like Facebook or Twitter contain data that naturally lends itself to a graph representation. But graphs can be used to represent less obvious data, as in the case of Tapad’s device graph. Dag Liodden, Tapad’s co-founder and CTO, describes why using a graph representation for devices makes sense:

Tapad takes a graph-oriented approach to modeling relationships between devices. Anonymous identifiers (such as cookie IDs) are represented as nodes in our Device Graph and we track marketing information to these nodes. Edges between the nodes are scored / weighted using a combination of deterministic data and probabilistic statistical models / machine learning techniques. The concept of a “device” is defined as a starting device / node (let’s say the cookie ID of a browser) and the collections of nodes (let’s say the cookie IDs of a Tablet and a Connected TV) that are reachable from that starting point given a customizable set of edge constraints. Having an actual graph structure, as opposed to just aggregated information into a single node, gives us the flexibility to balance accuracy and scale dynamically as well as more easily augment the graph with new edge inference models.
Using the right tool for the right job is important, and the same goes for graph processing: there is no need to use Big Data technologies for graphs that can be handled by more traditional workloads, like Dag says:

“Big Data” to me is the threshold where you no longer can use a small set of general purpose, off-the-shelf tools to store and analyze your data, but instead have to tailor different technologies to address specific use cases. These thresholds keep moving every year as software and hardware solutions evolve and mature, but so does the size of the data sets we deal with and the level of sophistication of the analysis we need to perform.
For Facebook, this threshold is in the single digit petabytes, as detailed during their submission to the 2013 ACM SIGMOD conference in NYC. For Tapad, the amount of data in the graph is smaller but would still be impossible to process using traditional methods:

The US graph currently has about 1.1 billion nodes, representing mobile phones, tablets, laptops, gaming consoles and TVs. Some of these nodes are transient; for instance, due to a browser with non-persistent cookies, and thus have little data and no edges. The non-transient nodes have about five edges on average and around 500 discrete pieces of information, such as behavioral segments, associated with them. The live graph data weighs in at multiple TB and we read / write from / to it several hundred thousand times per second across multiple data centers. Updates to the graph are geographically cross-replicated and each data center is currently serving off of servers backed by 20 TB of Flash SSD storage and 2 TB of RAM.
The recent years have seen a surge in the number of technologies used to process graphs at scale, especially 2013 which saw several new additions to the ecosystem. There are two classes of systems to consider:

Graph databases for OLTP workloads for quick low-latency access to small portions of graph data.
Graph processing engines for OLAP workloads allowing batch processing of large portions of a graph.
The list of graph databases is already very long, but several projects have emerged and differentiated themselves recently. Neo4j is one of the oldest and most mature graph databases, but still suffers from scalability issues since it doesn’t support sharding yet. Another database that, albeit pretty young, has been gaining a lot of popularity in 2013 is Titan. As a backend-agnostic graph database, it can leverage both HBase and Cassandra’s scalable architecture and uses an optimized vertex and edge representation internally to allow it to scale to billions of edges as reported in a blog post in 2013.

But one does not need to use graph-specific databases, and more generic scalable NoSQL databases can also be an effective solution to the problem. Apache Accumulo, a technology based on Google’s BigTable and open-sourced in 2011, is an example of a generic database that can also be a good fit to store graphs at scale because records are flexible and can be used to store graphs with typed edges and weights, and is actually being used by the NSA according to a technical report published in 2013. Cassandra or Aerospike are other examples of databases that, with a proper data model, can effectively model a graph with edges, vertexes and weights. Facebook also built their own solution using MySQL and Memcache in a system called Tao, which is being used to serve the social graph to its users. And according to Dag, Tapad used the same philosophy in the design of their device graph:

The live graph lives in a key-value store to allow for fast traversals and updates. We regularly snapshot the graph into HDFS where it can be retrieved for more advanced graph processing and augmented with other data streams. The results are later fed back into the “live graph”. There are advantages to using a graph specific database, but our current setup with extremely fast, simple traversals of the graph in our key-value store and slow, but very flexible traversal and analysis on Hadoop is serving us well, at least for now.

Even with a graph stored in a database, the operations that can be performed at scale will likely be limited to lookups and small traversals. For more complex analysis on a larger portion of a graph, there is a need for batch processing distributed frameworks. For the best performance, the GraphLab framework uses the Message Passing Interface (MPI) model to scale and run complex algorithms using data in HDFS. More recent frameworks like Apache Giraph and Apache Hama are based on the Bulk Synchronous Parallel (BSP) paradigm popularized by Google’s Pregel project. And the latest additions to the ecosystem are the GraphX project running on top of Spark which was unveiled in 2013, and Faunus, which is using Hadoop to run MapReduce jobs to process graphs in a Titan database. Tapad is using these new technologies to process their offline graph data. According to Dag:

Currently, our main graph processing framework is Apache Giraph, but we are experimenting with Spark GraphX and Graphlab as well. All of these frameworks are still pretty young, the learning curve is pretty steep and all come with their own pros, cons and caveats. For instance, Giraph and GraphX are convenient as they fit nicely into our Hadoop infrastructure, but Graphlab is very appealing due to the sheer performance of it.

Some projects are attempting to provide a unified framework to answer both OLTP and OLAP queries. Dendrite from Lab41 is such a project that leverages GraphLab on top of Titan for storage and processing, and AngularJS for visualization. This is still a very young project unveiled in early 2014 so the community reaction is limited, but the fact that it attempts to cover every use case should help drive adoption.



转载请注明:36大数据 » 利用大数据技术进行图处理

中国大数据要发展必备三个条件

中国大数据要发展必备三个条件

大数据的经济价值已经被人们认可,大数据的技术也已经逐渐成熟,一旦完成数据的整合和监管,大数据爆发的时代即将到来。我们现在要做的,就是选好自己的方向,为迎接大数据的到来,提前做好准备。大数据概念的横空出世,有赖于短短几年出现的海量数据。据统计,互联网上的数据每两年翻一番,而目前世界上90%以上的数据都是最近几年才产生的。当然,海量数据仅仅是“大数据”概念的一部分,只有具备4个“V”的特征,大数据的定义才算完整,而价值恰恰是决定大数据未来走向的关键。

大数据发展必备三个条件

大数据的发展需要三个必要条件:数据源、数据交易、数据产生价值的过程。近年来,社交网络的兴起、物联网的发展和移动互联网的普及,诞生了大量有价值的数据源,奠定了大数据发展的基础。大数据时代到来的重要标志,则是大批专业级“数据买卖商”的出现,以及围绕数据交易形成的,贯穿于收集、整理、分析、应用整个流程的产业链条。大数据发展的核心,则是使用户从海量的非结构化数据和半结构化数据中获得了新的价值,数据价值是带动数据交易的原动力。

IBM、甲骨文、SAP近年纷纷斥巨资收购数据管理和分析公司,在这些互联网巨头的带动下,数据分析技术日渐成熟。2013年6月,爱德华·斯诺登将“棱镜计划”公之于众,“棱镜门”事件一方面说明大数据技术已经成熟;另一方面也佐证了现在阻碍大数据发展的不是技术,而是数据交易和数据价值。

大数据技术的发展促进了云计算的落地,云计算的部署完成又反过来加大了市场对数据创造价值的期待。大数据概念提出之后,市场终于看到了云计算的获利方向:各地的一级系统集成商与当地政府合作,建云数据中心;各大行业巨头在搭建各自行业的云平台;IT巨头想尽办法申请中国的公有云牌照。大数据促成了云计算从概念到落地。借助于智慧城市概念的普及,云计算基础设施已基本准备就绪,一方面完成了大数据应用的硬件基础;另一方面迫于回收云计算投资的压力,市场急需应用部署,大数据恰如雪中送炭,被市场寄予厚望。

现在,问题的核心指向了“数据如何创造价值?”

整合与开放是基石

大数据服务创业公司Connotate对800多名商业和IT主管进行了调查。结果显示,60%受调查者称:“目前就说这些大数据投资项目肯定能够带来良好回报尚为时过早。”之所以如此,是由于当前大数据缺乏必需的开放性:数据掌握在不同的部门和企业手中,而这些部门和企业并不愿意分享数据。大数据是通过研究数据的相关性来发现客观规律,这依赖于数据的真实性和广泛性,数据如何做到共享和开放,这是当前大数据发展的软肋和需要解决的大问题。

2012年美国大选,奥巴马因数据整合而受益。在奥巴马的竞选团队中有一个神秘的数据挖掘团队,他们通过对海量数据进行挖掘帮助奥巴马筹集到10亿美元资金;他们通过数据挖掘使竞选广告投放效率提升了14%;他们通过制作“摇摆州”选民的详细模型,每晚实施6.6万次模拟选举,推算奥巴马在“摇摆州”的胜率,并以此来指导资源分配。奥巴马竞选团队相比罗姆尼竞选团队最有优势的地方:对大数据的整合。奥巴马的数据挖掘团队也意识到这个全世界共同的问题:数据分散在过多的数据库中。因此,在前18个月,奥巴马竞选团队就创建了一个单一的庞大数据系统,可以将来自民意调查者、捐资者、现场工作人员、消费者数据库、社交媒体,以及“摇摆州”主要的民主党投票人的信息整合在一起,不仅能告诉竞选团队如何发现选民并获得他们的注意,还帮助数据处理团队预测哪些类型的人有可能被某种特定的事情所说服。正如竞选总指挥吉姆·梅西纳所说,在整个竞选活中,没有数据做支撑的假设很少存在。

2012年3月,美国奥巴马政府宣布投资2亿美元启动“大数据研究和发展计划”,将“大数据研究”上升为国家意志。一个国家拥有数据的规模和运用数据的能力将成为综合国力的重要组成部分。国内智慧城市建设目标之一就是实现数据的集中共享。

合作共赢的商业模式

随着云计算、大数据技术和相关商业环境的不断成熟,越来越多的“软件开发者”正在利用跨行业的大数据平台,打造创新价值的大数据应用,而且这一门槛正在不断降低。因为首先,数据拥有者能够以微乎其微的成本获取额外的收入,提高利润水平;其次,大数据设备厂商需要应用来吸引消费者购买设备,发展合作共赢的伙伴关系势必比单纯销售设备要有利可图,一些具有远见的厂商已经开始通过提供资金、技术支持、入股等方式来扶持这些“软件开发者”;第三,行业细分市场的数据分析应用需求在不断加大,对于整个大数据产业链来说,创新型的行业数据应用开发者必将是未来整个大数据产业链中最为活跃的部分。

未来,有三种企业将在”大数据产业链“中处于重要地位:掌握海量有效数据的企业,有着强大数据分析能力的企业,以及创新的“软件开发者”。社交网络、移动互联网、信息化企业、电信运营商都是海量数据的制造者,Facebook公司手中掌握着8.5亿用户,淘宝注册用户超过3.7亿,腾讯的微信用户突破3亿,这些庞大用户群所提供的数据,正在等待时机释放出巨大商业能量。可以预测,在不久的将来,Facebook、腾讯、电信运营商等海量数据持有者或者自我延伸成为数据分析提供商,或者与IBM、ZTE等企业密切对接成为上下游合作企业,大数据产业链将在某个爆发时点到来之际,以令人惊讶的速度成长壮大。

警惕大数据的危害

大数据时代,传统的随机抽样被“所有数据的汇拢”所取代,人们的思维决断模式,已可直接根据“是什么”来下结论,由于这样的结论剔除了个人情绪、心理动机、抽样精确性等因素的干扰,因此将更精确、更有预见性。不过,由于大数据过于依靠数据的汇集,一旦数据本身有问题,就很可能出现“灾难性大数据”,即因为数据本身的问题,而导致错误的预测和决策。

大数据的理论是“在稻草堆里找一根针”,而如果“所有稻草看上去都挺像那根针”呢?过多但无法辨析真伪和价值的信息和过少的信息一样,对于需要作出瞬间判断、一旦判断出错就很可能造成严重后果的情况而言,同样是一种危害。“大数据”理论是建立在“海量数据都是事实”的基础上,而如果数据提供者造假呢?这在大数据时代变得更有害,因为人们无法控制数据提供者和搜集者本人的偏见。拥有最完善数据库、最先接受“大数据”理念的华尔街投行和欧美大评级机构,却每每在重大问题上判断出错,这本身就揭示了“大数据”的局限性。

不仅如此,大数据时代造就了一个数据库无所不在的世界,数据监管部门面临前所未有的压力和责任:如何避免数据泄露对国家利益、公众利益、个人隐私造成伤害?如何避免信息不对等,对困难群体的利益构成伤害?在有效控制风险之前,也许还是让“大数据”继续待在笼子里更好一些。

大数据的经济价值已经被人们认可,大数据的技术也已经逐渐成熟,一旦完成数据的整合和监管,大数据爆发的时代即将到来。我们现在要做的,就是选好自己的方向,为迎接大数据的到来,提前做好准备。

via:CIO时代网

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

中国大数据要发展必备三个条件

End.



转载请注明:36大数据 » 中国大数据要发展必备三个条件

大数据领域的顶级开源工具大集合

随着大数据与预测分析的成熟,开源作为底层技术授权解决方案的最大贡献者的优势越来越明显。

如今,从小型初创企业到行业巨头,各种规模的供应商都在使用开源来处理大数据和运行预测分析。借助开源与云计算技术,新兴公司甚至在很多方面都可以与大厂商抗衡。

大数据领域的顶级开源工具大集合

以下是一些大数据方面的顶级开源工具,分为四个领域:数据存储、开发平台、开发工具和集成、分析和报告工具。

数据存储:

 

  • Apache Hadoop– Cloud Foundry(VMware), Hortonworks, Hadapt
  • NoSql 数据库 – MongoDB, Cassandra, Hbase
  • SQL 数据库 – MySql(Oracle), MariaDB, PostgreSQL, TokuDB

开发平台:

  • Apache Hadoop平台 – Impala(开源大数据分析引擎); Lingual(ANSI SQL); Pattern(analytics);Cascading(开源大数据应用程序开发框架)
  • Apache Lucene和 Solr平台
  • OpenStack(构建私有云和公有云)
  • Red Hat (搭载 Hadoop 服务器的标准 Linux 发行版)
  • REEF(微软的Hadoop开发者平台)
  • Storm(集成了各种排队系统和数据库系统)

开发工具和集成:

  • Apache Mahout(机器学习的编程语言)
  • Python 和 R(预测分析编程语言)

分析和报告工具:

  • Jaspersoft(报告和分析服务器)
  • Pentaho(数据集成和业务分析)
  • Splunk(IT分析平台)
  • Talend(大数据集成,数据管理和应用集成)

以上就是我们总结的大数据方面不错的工具,希望对您有所帮助。

via:CSDN

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

大数据领域的顶级开源工具大集合

End.



转载请注明:36大数据 » 大数据领域的顶级开源工具大集合

从百度视频看大数据与人工智能

从百度视频看大数据与人工智能

[核心提示] 大数据的应用决策可以拆解成两种层面,第一种是利用个体数据为个体进行决策,第二种是利用群体数据为群体进行决策。结合的案例,看看大数据与人工智能是具体如何应用的。

近日,了解到百度视频在升级迭代上利用大数据做了很多事情,这让我真实的感受到了大数据的价值。其中我将大数据的应用决策拆解成两种层面,第一种是利用个体数据为个体进行决策,第二种是利用群体数据为群体进行决策。

以下,结合百度视频已经实现以及将要实现的案例,来看下大数据与人工智能是具体如何应用的。

大数据个性化决策

个性化决策无疑是难度最高的,因为个性化决策是根据用户行为记录来为用户做出相应的推荐。

百度在无线端有大量的产品,其中用户数过亿的 APP 就多达 14 款。百度内部有专门的团队,分析用户在这些 APP 中的行为,利用算法估算用户的年龄、性别、职业、兴趣等特征。

这一技术在百度工程师那里称为用户建模,这些数据来自于用户手机里安装的百度应用如“百度地图”、“百度贴吧”、“百度魔图”外加一些使用百度开放接口的应用诸如“糗事百科”等等,百度是能够通过这些数据进而来为用户建立动态模型。

从百度视频看大数据与人工智能

百度视频的个性化推送是典型的利用群体智慧来解决个体需求的例子。传统的视频 APP 通常以广播的方式为用户推送视频,即每个用户收到的消息内容是一样的,无法满足用户个性化的需求。百度视频的做法是,分析用户的历史观看记录,同时结合用户的性别、年龄、地域等特征,为用户建立兴趣模型,将用户可能感兴趣但却未观看过的视频推送给用户。

比如一个经常上动漫贴吧的用户,百度通过搜集大数据后判断其是 20 岁左右的大学生,在个性化推送上就和其他人群就有所不同,可能就会推送一些大学生圈子里比较流行的动漫以及韩剧之类。

简而言之,用户使用的百度系以及带有百度接口产品的产品越多,百度就能越能为用户建立个人模型,所有使用过的产品的数据会汇聚到百度云端,人工智能最后再绘制出一个人的画像,百度再根据这个画像再为每个应用进行大数据决策推送,再根据用户的反馈结果进行迭代试错,当然这是机器学习的部分,不必要再深入讨论下去。我画了一个简单的百度个性化推荐原理。

从百度视频看大数据与人工智能

大数据群体化决策

个体与群体的价值思辨

之前我对百度个性化推送提出过缺陷的质疑,一旦当用户更换手机之后,百度就无法再次为其建立个人画像模型,进而也就失去了对于个人的意义,百度又要重新建立个人数据,十分麻烦。

而深入了解百度的大数据之后让我感到更有一番深度,百度的大数据并非只为个体用户服务,更重要的是建立群体宏观行为模型,通过这一整套模型为群体进行宏观决策,而群体决策部分的重要战略意义远远大于个体意义。

我对此的理解为:如果我们将人类整体行为看做为个体行为,那么同样的作为个人总有一些误操作,一些随机的非主流的边缘操作,而这些边缘操作对于机器学习来说只是噪声而非信号,是需要进行过滤的,那么机器就需要过滤掉这些没有价值的数据,将有价值的信号数据沉淀与固定下来,为整体行为进行决策。

 从百度视频看大数据与人工智能

所以在某种程度上,我们都会陷入个性化至上的错觉,而忽略群体数据决策的价值。再回到百度之前的个性化推送功能,这些推送一定是事先经过群体过滤过后的信号,再向用户推送后才会更戳中人心。比如百度通过数据判断出最新流行的韩剧是《来自星星的你》,而不是过气的《大长今》,继而向用户推荐《星星》,这些都不是人工的,完全是自动生成的。

也就是,这场思辨中我得出了一个关于大数据的重要结论,机器为个人的数据提供个人喜好的小范围数据,而群体大数据决策后的结果在为个体扩大范围。

个性化推送为个人提供确定性,为群体提供不确定性。而群体决策为个人提供不确定性,为群体提供确定性。

二者的噪声互为价值,二者的信号互为干扰。

人工智能或许永远无法超越人类

上次我和赵云峰还有刘峰老师在 3W 咖啡里讨论了人工智能的未来,其中我们谈论到了图灵测试,我们分析到图灵测试的程序虽然越来越厉害了,但这依然是工具而已,本质上人与人的博弈罢了,机器永远无法脱离人类进行自学习。

 从百度视频看大数据与人工智能

那么这里回到百度视频上来,百度目前做到了平均给每部视频贴上上百个标签,而且这些标签根据时间还在不断的更新与迭代,不仅如此,这些标签还在不断的自行关联。所以百度视频能够做到,搜索诸如“高智商电影”会出现《盗梦空间》、《禁闭岛》、《源代码》等等这样的关联。

有人问,这些成百上千的标签都是人工匹配的吗?如果这样,百度人力需要很多啊。实际上标签是机器全自动做好的。但制定标签还是需要人,机器应当是通过用户先搜索到某个关键词然后经过一系列的行为判断该关键词与某电影的关系,通过大量用户的反复出现的数据,机器再建立出这些关联。

假如有一天机器能够完全通过独立的自我学习,通过自身而不借助人类去关联这些标签词汇与电影的关系。那一刻才能算是真正实现了人工智能。

这只能说明我和赵云峰还有刘老师在 3W 咖啡的谈话是多么无聊的正确,对于机器来说,人类就像他们的发动机,他们无法做到产生真正的意识,他们无法像人类一样进行自我追问一切的起源,0 与 1 的结构。

是啊,人类是多么孤独,因为只有人类才会意识到自己的孤独,而机器不会。但又或许,是我们正在共同创造机器的意识吧,这个超级有机体将会成为我们。

最后奉上,根据理论,未来的大数据的群体与个人结合的私人定制图。

从百度视频看大数据与人工智能

via:极客公园  作者:承哲

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

从百度视频看大数据与人工智能

End.

 



转载请注明:36大数据 » 从百度视频看大数据与人工智能

马航M370航班失联搜救中的统计数据分析

马航M370航班失联搜救中的统计数据分析

大数据时代如何活用数据可视化、大数据与众包、群体智慧、贝叶斯方法等为失联搜救出谋献策?请看下文。

引子

“MH370”作为航班代码,是近日震惊世界的马来西亚航空公司客机失去联络事件(后简称“马航事件”)留给公众最深刻的数字印象。时至今日,有关马航事件的调查和搜救工作仍在继续。遗憾的是直到截稿时间,MH370航班的残骸仍未找到。

在历史上的多次飞机船只等交通工具出现失联情况的突发事件中,数据的收集、分析以及信息的及时发布都在搜寻中起到过关键的作用。比如在2009年,法国航空公司曾有一架民航客机失去联络和踪迹。当时,有不少基于数据分析的文献为失事飞机的搜寻提供了援助。前事不忘,后事之师。本文旨在基于统计学领域的相关知识结合大众可以获知的信息来对马航事件进行了解和分析。本文秉持科普视角,试图阐述在应对马航事件过程中数据收集和数据分析所起到的作用,继而为寻找失联飞机提供一些思路。我们将以寻找失事飞机和船只的事件为线索,来梳理其中涉及到的数据分析思路,以试图减少大家的猜疑和困惑。

一、信息可视化助公众了解事件

马航事件牵动全球关注。在马航事件发生之后,很多公众几乎每天第一时间关注媒体报道——看一看飞机找到了没有。回顾在马航事件发生后各界媒体发布的图表、报告和多媒体新闻,其信息之多和繁杂致使公众没有足够时间和精力去了解事件进展。这时如果能用几张简洁明了的图表把新闻内容展示出来,往往能对公众了解事件进展起到事半功倍的效果。这就是信息可视化,或称为数据可视化。我们根据信息的内容分三部分介绍数据可视化在马航事件信息传递过程中的作用。

直观了解事件进展

我们或许很难用三言两语把马航事件的来龙去脉描述清楚,如果把马航事件用文字表述出来亦须耗费不少篇章。单纯的描述有时候并不利于公众了解事件。相反地,信息可视化则可直观地刻画马航事件。图1-1为马来西亚最初发布的关于马航MH370航班失联的消息。图1-2为马来西亚其后发布的马航MH370航班被侦察到的地理坐标。图1-3为最终被搜救队伍估计的马航MH370航班最后一次向卫星传出信号的可能位置。三幅图通过把相关地理位置刻画在二维平面,并且把关键的时间、地点、区域在二维平面标明,使得公众可以很直观地了解马航事件,非常有效地、避免误导地传递了关键信息。公众甚至无需阅读图中注释即可了解马航事件梗概。

马航M370航班失联搜救中的统计数据分析
图1-1 马航MH370客机首次宣告失联

马航M370航班失联搜救中的统计数据分析

图1-2 马航MH370客机关键坐标

马航M370航班失联搜救中的统计数据分析
图1-3 马航MH370客机最后一次向卫星传出信号的可能位置

迅速了解搜救区域

目前,越来越多证据表明失联客机可能在印度洋中,因此,一个非常自然的疑问就是飞机残骸到底在哪里?卫星数据成为回答这个问题最受重视的信息来源。由于非专业人士很难读懂原始卫星数据,数据可视化可以帮助公众迅速了解搜救区域。图1-4展示了有关马航MH30航班的搜救区域。在图1-4中,圆点标记出疑似残骸所在的区域,圆点的颜色代表不同的发现日期。将有关疑似残骸的信息可视化到图表并配上适当的解释,可以帮助公众在短时间内了解正在被搜寻和将要被搜寻的区域以及已经搜寻到的疑似残骸。可视化方法显然比冗长的文字描述有效很多。此外,根据卫星对南印度洋上浮标的追踪数据,图1-5刻画了在3月8日至3月24日期间残骸的移动轨迹。由图1-5我们可以得到一些或能有助搜救的推测,譬如,不同区域疑似残骸的移动趋势截然不同,相比北端疑似残骸而言,南端疑似残骸向东运动的趋势更为明显等。

马航M370航班失联搜救中的统计数据分析
图1-4 马航MH370客机搜救区域

马航M370航班失联搜救中的统计数据分析

图1-5 疑似残骸标记物在三月八日至三月二十四日的移动轨迹

了解搜救条件

搜救条件,意为搜索救援行动的基础,包括搜救设备,搜救区域的气象情况等等。由于媒体报道较少,公众对搜救条件的了解相对少。事实上,大洋气象复杂,海洋的搜救条件往往比陆地的搜救条件要恶劣,因而此番搜救是一个巨大考验。图1-6的图(a)和图(b)分别描述了3月16日南印度洋的风速和浪高。在两幅图中,颜色越深的区域,风浪越小,颜色越接近白色的区域,风浪越大。综合图(a)和图(b),搜救海域位于南印度洋风浪最大区域的西北角,并且在图中部分搜救海域泛白,可见搜救条件恶劣。

马航M370航班失联搜救中的统计数据分析
图1-6 三月十六日(a)相关搜救海域的风速;(b)相关搜救海域的浪高

二、大数据和众包

当像飞机失联这样的突发事件发生时,搜索的第一步当然是要把它失联前所有的数据信息都收集在一起分析。航空公司,各国政府,各国军方的各种飞行数据,雷达数据,通讯数据都被用来帮忙。对这些数据的分析我们会在后面详细介绍。虽然,我们会理所当然地认为数据短缺似乎并不应当发生在这个大数据时代。但是,由于数据量大,数据源多,噪声大,从大数据中找到有价值的信息有可能变得更难。众包平台(Crowdsourcing)应运而生。

众包是什么呢?根据维基百科,“众包”这个概念最早出现于2005年。“外包”作为“众包”的姐妹词更为人熟知。“外包”指把工作任务交给非本公司的组织或者个人完成。“众包”,顾名思义,指把工作任务交给广大人民群众去完成。当今众包几乎都由网友完成。众包所交付的任务可以有任意的形式和内容。这些任务可以具体到找图片或编译代码,也可以是寻求一个答案或一个主意。例如,网友在知乎提问,世纪佳缘把其实际自动配对的难题放到网上作为建模竞赛,乃至有些人在微博上贴出失物照片以寻找失主,都属于广义上众包的范畴。

3月8日,DigitalGlobe公司在马航MH370航班离开马来西亚海岸几个小时后,调整了其高分辨率卫星群的位置,以获取尽可能多的图片数据。3月10日,DigitalGlobe公司把这些图片放到了众包平台Tomnod上,首个小时图片访问量达六万个。每当突发事件出现,众包平台就会推出活动专页,让热心网友在大量实时高分辨率卫星图片中寻找线索。在马航事件中,全民找飞机就是一次非常典型的众包案例。

DigitalGlobe公司卫星群中的5颗卫星,每天环绕地球75圈。这些卫星最初都用于与人道主义相关的目的。例如,如图2-1所示,这些卫星曾用于追踪上帝抵抗军在民主刚果共和国、苏丹南部以及中非共和国整个土地上的大规模动向,以预测和挫败上帝抵抗军的下一次攻击。后来这些卫星被越来越多地用于协助处理突发事件。去年,DigitalGlobe公司曾经提供覆盖了几千万平方公里的图片以寻找一架在美国爱达荷州坠毁的轻型飞机。如今,众包几乎成为了航空意外等意外事件的首要解决途径之一。一位前Tomnod员工曾表示,在马航事件发生伊始,Tomnod就收到来自美国政府的非官方请求,甚至收到来自保险公司的请求——各界都想知道关于马航事件的众包专页将何时上线。

在DigitalGlobe公司发布至Tomnod众包页面的卫星照片中,一个像素覆盖50厘米的土地空间或水域空间。 在NASA陆地卫星提供的卫星照片中,一个像素却要覆盖大约30米的土地空间或水域空间,即一架喷气机可能在图像中只占用一个像素。

马航M370航班失联搜救中的统计数据分析
图2-1 苏丹国,苏丹港,2011年10月8号, DigitalGlobe, satellite GeoEye-1

DigitalGlobe公司几乎在获知马航事件的第一时间就展开了他们的行动。他们专门设立一个首窥(First Look)小组负责随时随刻对推特和新闻进行实时监控,以应对马航事件以及类似事件。首窥小组成员首先要决定卫星该飞往何处,然后他们开始调整系统让卫星到位。像地震这类事件,需要灾难发生之前的数据以期在搜救中进行对比。像马航事件,则需要根据新闻对正确监测位置进行推测,以安排卫星。“他们像使用谷歌地图一样搜寻地图,查完一个,然后继续到下一个区域,并尝试检查尽可能多的图片。我们时刻都有几百几千人做这一切。但这项任务是非常困难的,你需要小心地区分云,波浪和残骸,以期找到一两个可能有价值的点。当你真的去找图片的时候,你会惊奇地发现许多云彩看起来有多像船。我们用一组算法来对人群意见进行排名,看看那些地方大家都同意有问题.例如,如果100人中99个人都点击了一个有趣的小像素,这个像素就是真正有价值的。在这里,该算法通过数据进行筛选,看看哪些图片是可靠的,哪些不可靠,所以也许不应该得到同样的重视。之后,这些筛选出来的图片再由我们的分析师进行细查,并派人去现场搜救。”

众包并非万能,却能体现“众人拾柴火焰高”、“一方有难八方支援”的人道主义精神。Tomnod社区,作为一个众包平台,被认为是一个高尚的社区,由于其习惯于在寻常的大片陆地、冰原或水域寻找不易被察觉的关键图片。DigitalGlobe公司方面曾表示:“就像爱达华州空难一样,今天我们正在大海捞针。检查所有像素是很困难的,更何况我们正在寻找的东西没有确定特征。我猜想在这个阶段——我也希望我们是错的 ——我们找的东西看起来不像普通飞机。就是为什么我们要请求公众的帮助。”

众包这么好,以后是不是啥人也不要请,薪水也不要付了呢?当然不是!网友参与,纯粹出于个人兴趣,干活的质量和耐心,纯靠个人责任心。诚然网友里面“油菜花”很多,可是活儿的质量不能保证。因此众包仅限于那种大量重复性劳动,并且不需要太多技能,一般有一台电脑一根网线就能干,比如这次全民找飞机。顺便说Tomnod上那个专页现在还在,感兴趣的网友可以加入进去,期望能找到飞机残骸或者燃油泄漏的痕迹,据悉直到现在还有几千全球网友在继续这项工作。同时,如何客观分析众包平台上得出结论和数据也是统计学家关心的问题。

三、群体智慧

在寻找失事飞机、海底沉船、或珍珠宝藏过程中,当可用数据极其缺乏时,群体智慧 The Wisdom of Crowds 也可以派上用场。

1968年5月,美国潜艇蝎子号(Scorpion)在完成北大西洋参观后,在返回纽波特纽斯(Newport News)途中消失了。虽然海军知道蝎子号最后一次报告的位置,但是海军对蝎子号发生的事故一无所知,只能模糊得知在最后无线电联系后蝎子号前进的距离。为了寻找蝎子号,海军划定了一个半径32千米,数千英尺深的圆形海域。这几乎是一个不可能完成的任务。当时,人们想到的最可行方案是聘用三四个潜艇和海洋环流顶级专家来推断蝎子号的位置。但是,在雪莉•桑塔格(Sherry Sontag)和克里斯托弗•德鲁(Christopher Drew)的书《Blind Man’s Bluff: The Untold Story of American Submarine Espionage》中记载,一个叫约翰•克雷文(John Craven)的海军军官提出了一个不同的计划。

首先,克雷文列出一系列能够解释蝎子号事故的场景。接着,他组建了一个囊括各方面专家的团队。团队成员包括数学家、潜艇专家和救助人员等。有趣的是,他非但不是要求团队成员互相协商寻求一个答案,反而请每个成员提供自己对每个可能场景的发生概率的猜测。为了让事情变得更有趣,他把一瓶芝华士作为猜中的奖品。于是团队成员开始对潜艇可能遇到的麻烦、潜艇的下沉速度、下沉角度等因素下注。

可以预见,团队成员个人推测信息无法告诉克雷文蝎子号的具体位置,但克雷文认为,如果他能把所有答案加在一起,构建一个蝎子号出事全景的复合图像,他应该会得到对潜艇最终位置的很好估计。而这正是他所做的。他收集了所有的猜测,并使用贝叶斯方法来估计蝎子号的最终位置。当一切完成后,克雷文得到一个该团队对于潜艇位置的集体估计。

克雷文最后得到的位置和任何一个团队成员猜测的位置都不同。换句话说,没有一个成员规划的场景和克雷文使用所有收集到的信息构成的场景是重合的。克雷文最后的估计才是真正的集体判断,是该团队作为一个整体取得的,而不是团队中最聪明的人的判断。最后事实证明这个集体的判断非常精彩。在蝎子号消失后的第五个月,海军发现了它。它和克雷文最后得到的位置只差约200米。

这个故事的惊人之处在于是团队成员在几乎没有任何线索和证据的情况下做出的推断。真正的数据只是很小的碎片。没有人知道为什么潜艇沉没,没有人有任何行驶速度和下沉速度的信息。然而,即使在组里没有人知道任何这些事情的情况下,该团队作为一个整体表现得相当出色。

统计学家弗朗西斯•高尔顿(Francis Galton)在1906年最先提出群体智慧。在普利茅斯出席了一个农场活动时,他被一个重量猜测比赛所吸引。比赛目标是猜一头牛被屠宰后的重量。那次大约有800名男女老幼参加了比赛,每人写下自己的猜测。猜得最接近牛的屠宰后重量的人得奖。比赛结束后高尔顿拿着所有记录做统计分析。他发现,所有参赛者猜测的平均值1197磅和实际重量1198磅仅差一磅。集体的猜测不仅比比赛的实际赢家准确,而且也比养牛和宰牛专家所做的猜测准确。

有这个话题兴趣的读者可以参看詹姆斯•索罗维基(James Surowiecki)的书《群体的智慧》(The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations)。在马航事件中,也有人提出是否可以用群体的智慧的方法来寻找它,但目前还没人实现这个想法。

四、贝叶斯与决策

当我们在搜救过程中逐渐收集到更多更准确的数据,科学地结合现有数据、科学知识、以及主观经验无疑可为找寻失联客机带来一线曙光。在统计学领域,贝斯方法(Bayesian Methods)提供了一个可以将观测数据、科学知识以及各种经验结合在一起的应用框架。

我们用一个简单例子来说明一下这个框架。假设有一个布袋,装有10个黑球和5个白球,那么随机取出一个球是白色的概率是5/15,即1/3。生活中的情况要更复杂一些——有时我们根本不能事先知道在布袋里到底有几个黑色或者白色的球。这也正是我们有时会进行抽样调查的原因。在不清楚整体情况时,我们会随机抽取一些样本,通过对样本分析以了解整体的情况。若我们不断累积经验,我们的猜测将愈加接近真实情况。贝叶斯方法,作为一种科学的方法,其本质也正是通过不断积累经验,更新对整体的认识 ,从而对真实情形进行把握。

例如,在开始的时候,我们并不知道布袋中白球的比例,那这个比例对我们而言可能是0,也可能是1,或者是1/3,1/5等等。即所有这些比例对我们来说可能性都差不多。假定我们有放回地抽取了六次球,发现有两次抽到的是白球,有四次抽到的是黑球(记做事件A)。利用这六次抽取球的结果,我们大可猜测——在事件A发生的情况下,袋子中白球的比例是1/3的可能性就比较大了。如果加入一些更具体的概率模型和先验知识,用条件概率的计算来计算看到事件A以后我们对袋子内可能情况的描述,就是贝叶斯方法。

再比如说我们去一个陌生的餐馆吃饭。我们因为之前不了解这家餐厅,以至于我们似乎只能随机的做出一个判断。但是贝叶斯方法建议我们去利用可能积累的经验来提供判断的线索。比如,我们的经验是:通常那些坐满了客人的餐厅的食物要更美味些,而那些客人寥寥的餐厅的食物可能不那么可能。这样,我们可以观察餐厅的上座率,从而利用这一条件改变我们的判断:在坐满了客人的条件下,餐厅的食物可口的概率比较大。所以说,在我们认识事物不全面的情况下,贝叶斯方法是一种很好的利用经验帮助作出更合理判断的方法。

现在我们已经对贝叶斯方法有了一定了解,下面我们谈谈如何利用贝叶斯方法帮助寻找失事马航MH370客机呢?对于失事飞机,我们不仅需要找到它的三维坐标,同样需要找到它的失事原因。新线索的出现,帮助我们积累了经验,从而改变飞机是由于自然事故还是遭遇劫机等人为事故造成的概率。两者的概率大小分别由Pr(自然事故|找到的线索)和Pr(遭遇劫机等人为事故|找到的线索)描述。当然,我们还可以利用一些其他的线索帮助我们改变判断,比如飞机的原计划航线,风速,洋流,以及扫描过的海域的情况。法航事件的飞机残骸搜寻工作给我们提供了一个参考案例。

马航M370航班失联搜救中的统计数据分析
图4-1 飞机残骸可能地点的后验概率分布图(概率由大到小的顺序为:红、橙、黄、绿、蓝)

接着,我们来回顾贝叶斯方法在法航事件搜救过程中的应用。在2009年6月1日早晨,法航447航班在暴风雨中失去了联系。2010年7月,法国航空事故调查处委任Metron负责重新检查分析已有的搜救信息以便绘制一副飞机残骸可能地点的概率分布图,如图4-1所示,概率由大到小的顺序为:红、橙、黄、绿、蓝。2011年1月20日,法国航空事故调查处于其网站刊登了分析结果。直到2011年4月8日,法国航空事故调查处发言人表示2011年1月20日刊出分析结果暗示,在图2-1中的一个圆形范围内有很大可能性会发现飞机残骸;并且,在对该区域进行持续一周的搜寻之后,残骸被发现。随后,飞行数据记录器和驾驶舱语音记录器被找到。最终确认残骸的位置离图4-1中的概率中心位置并不远,可见贝叶斯方法非常有效。

基于贝叶斯方法对整体概率进行计算所利用的信息来自四个阶段的搜寻工作。阶段一:利用被动声学技术搜寻水下定位信号器。法航447装备的飞行数据记录器和驾驶舱语音记录器可以帮助分析事故发生时的状况。同时,在飞机沉入水中时,飞机装配的水下定位信号器发出信号协助通讯。水下定位信号器的电池可以工作至少30天,平均可以工作40天。搜寻持续了31天并于2009年7月10日停止。两台搜救船——费尔蒙特冰川号和探险号,均装备了美国海军提供的声波定位装置——参与了搜救。阶段二:旁侧声呐搜寻。在声波搜寻结束后,BEA决定使用Pourquoi Pas 提供的IFREMER旁侧声呐技术继续搜寻。在本阶段,一些由于时间关系未能在第一阶段搜寻的海域也被搜寻。阶段三:旁侧扫描声呐搜寻。 阶段四:即我们在上一段提及的利用贝叶斯方法进行搜救,并最终找到了飞机残骸。图4-2展示了搜救过程。

马航M370航班失联搜救中的统计数据分析
图4-2 飞机残骸地点的后验概率分布计算过程

由法航事件,我们可以看到贝叶斯方法确实可以为搜救飞机残骸提供理论依据。由于既得数据有时并不能为计算后验概率提供太多信息,我们需要纠集所有有用的信息,并使所有信息都可以转化为贝叶斯方法中的先验信息。诚如香港城市大学Nozer Singpurwalla教授所言,即使在数据量极为丰富的情况下,应用贝叶斯方法的时候都应考虑专家的主观判断、证据以及想象力。在搜寻飞机的过程中,搜寻队可以估算出已经搜寻过得海域中存在残骸但由于失误没有找到的概率、坏掉一个信号器与坏掉两个信号器是否是独立事件等等。

五、结束语

除了数据分析与统计方法在上面几个方面的应用,其实我们可以看到整个搜寻过程就是一个通过数据收集,数据分析,统计推断,再收集,再分析,再推断,不断提高我们对事件的估计和把握的过程。从科学研究到日常决定,我们都是在不断重复类似这样的过程。多了解一些统计和分析的方法对我们做科学决策肯定会有帮助。

就在本文收稿的时候,搜寻前方传来消息:“在距离珀斯约1600公里处南印度洋水域负责搜寻失联航班的中国舰艇海巡01轮通过黑匣子搜寻仪,侦听到疑似马航失联航班的信号。”而后澳大利亚方面也几次探测到水下信号。希望这些发现和数据信息能够为我们找到马航370提供最新的强心剂。

作 者: 统计之都创作小组(邓一硕,关菁菁,刘辰昂,邱怡轩,施涛,熊熹,周祺)
校 对: 汤涛,香港浸会大学数学讲座教授

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

马航M370航班失联搜救中的统计数据分析

End.



转载请注明:36大数据 » 马航M370航班失联搜救中的统计数据分析

继Cloudera之后,MapR宣布对Spark的完全支持

继Cloudera之后,MapR宣布对Spark的完全支持

Spark,发源于美国加州大学伯克利分校AMPLab的集群计算平台,当下已成为Apache基金会的顶级项目。而在不久前,知名Hadoop解决方案供应商Cloudera已宣布了其发行版对Spark的支持。毫无疑问,Spark已成为流行的大数据计算框架之一,而据Gigaom Derrick Harris的一则消息,MapR近日也宣布了对Spark的支持,同时这个Hadoop先锋的支持将更加彻底。

下为译文:

MapR是知名的Hadoop供应商,最近该公司为其Hadoop发行版中添加了完整的Spark堆栈。这是一项明智之举,更说明Spark很可能成为未来的数据处理框架。

MapR也是应用Apache Spark的先驱者,周二,MapR宣布将整合Spark栈至其Hadoop版本,并将此作为与Spark初创公司Databricks(Opm Stoica,创始人及CEO,见上图)合作的一部分。Spark使处理大数据工作负载变得更为便捷,也使得大数据工作负载编程变得更容易。

Spark最初是加州伯克利大学开发的一款内存处理框架,随后它逐渐流行起来,但它真正的崛起还是在2013年9月——被Databricks正式推出。随后,Cloudera将Spark整合到其Hadoop发行版(作为与Databricks合作的一部分)。同时,许多按Hadoop设计的项目和公司都计划将支持Spark或直接转向Spark。

这其中包括Cloudera的Oryx项目,分析初创公司Platfora,甚至包括Apache Mahout项目;也包括参与Databricks认证程序的公司们。

Spark现在如此盛行,这是因为它既做到了MapReduce可以做到的,还做到了MapReduce没能做到的。MapReduce是传统的Hadoop数据处理框架,它速度慢(它采用的是批处理),编程繁琐。Spark快捷、灵活——这使得Spark可以更好的处理诸如机器学习、图形处理和、交互式查询类的任务——而且易于编程。Spark是用Scala写的,不过它也支持Java,Python与R语言。

继Cloudera之后,MapR宣布对Spark的完全支持

YARN是资源管理系统,也是Hadoop 2.0的一部分,YARN允许多处理框架同时运行于同一集群,这些框架都有访问Hadoop分布式文件系统进行存储的权限。这使得Hadoop对Spark的支持成为可能。

MapR的这条新闻最有趣的地方是,MapR提供了对Spark栈的全部支持——这包括Shark SQL查询引擎(它本质上说一个更快Apache Hive)和MLLib机器学习库——然而Cloudera却不支持Shark。这大概是因为Cloudera还在力推它的Impala SQL查询引擎,而MapReduce也没有包括这个引擎。MapR一直引领交互SQL查询项目Apache Drill的发展;此外随着Drill的到来,MapR也添加了对HP Vertica的本地支持。

从MapR的角度,通过整合Spark这一用户需求的功能提高了其在业界的地位(先前MapR受到的关注度是远少于竞争对手Cloudera和Hortonworks的)。例如,MapR现在开发了自己的HBase NoSQL数据存储,相较于其他Hadoop发行版包含的开源版本,这个数据存储功能更齐全。

正是诸如Spark类的技术——以及任何可以运行在YARN上的技术——使得Hadoop成为有潜力颠覆现有数据行业供应商的新生力量。Apache Hadoop一直提供廉价、开源的存储,不过现在生态系统已经将Hadoop变为一个可以在数据之上做很多事情的平台。在未来的几年,我们将看到更多的分析应用、甚至是数据库采用Spark或类似的技术作为引擎。

原文链接: Spark is now part of MapR’s Hadoop distro, too(翻译/蔡仁君 责编/仲浩)via:CSDN

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

继Cloudera之后,MapR宣布对Spark的完全支持

End.



转载请注明:36大数据 » 继Cloudera之后,MapR宣布对Spark的完全支持

大数据分析与应用案例介绍

大数据分析与应用案例介绍

从所周知,大数据已经不简简单单是数据大的事实了,而最重要的现实是对大数据进行分析,只有通过分析才能获取很多智能的,深入的,有价值的信息。那么越来越多的应用涉及到大数据,而这些大数据的属性,包括数量,速度,多样性等等都是呈现了大数据不断增长的复杂性,所以大数据的分析方法在大数据领域就显得尤为重要,可以说是决定最终信息是否有价值的决定性因素。基于如此的认识,大数据分析普遍存在的方法理论有哪些呢?

1. 可视化分析。大数据分析的使用者有大数据分析专家,同时还有普通用户,但是他们二者对于大数据分析最基本的要求就是可视化分析,因为可视化分析能够直观的呈现大数据特点,同时能够非常容易被读者所接受,就如同看图说话一样简单明了。

2. 数据挖掘算法。大数据分析的理论核心就是数据挖掘算法,各种数据挖掘的算法基于不同的数据类型和格式才能更加科学的呈现出数据本身具备的特点,也正是因为这些被全世界统计学家所公认的各种统计方法(可以称之为真理)才能深入数据内部,挖掘出公认的价值。另外一个方面也是因为有这些数据挖掘的算法才能更快速的处理大数据,如果一个算法得花上好几年才能得出结论,那大数据的价值也就无从说起了。

3. 预测性分析。大数据分析最终要的应用领域之一就是预测性分析,从大数据中挖掘出特点,通过科学的建立模型,之后便可以通过模型带入新的数据,从而预测未来的数据。

4. 语义引擎。非结构化数据的多元化给数据分析带来新的挑战,我们需要一套工具系统的去分析,提炼数据。语义引擎需要设计到有足够的人工智能以足以从数据中主动地提取信息。

5.数据质量和数据管理。大数据分析离不开数据质量和数据管理,高质量的数据和有效的数据管理,无论是在学术研究还是在商业应用领域,都能够保证分析结果的真实和有价值。

大数据分析的基础就是以上五个方面,当然更加深入大数据分析的话,还有很多很多更加有特点的、更加深入的、更加专业的大数据分析方法。

大数据应用与案例分析

1. 大数据应用案例之:医疗行业

Seton Healthcare是采用IBM最新沃森技术医疗保健内容分析预测的首个客户。该技术允许企业找到大量病人相关的临床医疗信息,通过大数据处理,更好地分析病人的信息。

在加拿大多伦多的一家医院,针对早产婴儿,每秒钟有超过3000次的数据读取。通过这些数据分析,医院能够提前知道哪些早产儿出现问题并且有针对性地采取措施,避免早产婴儿夭折。

它让更多的创业者更方便地开发产品,比如通过社交网络来收集数据的健康类App。也许未来数年后,它们搜集的数据能让医生给你的诊断变得更为精确,比方说不是通用的成人每日三次一次一片,而是检测到你的血液中药剂已经代谢完成会自动提醒你再次服药。

2. 大数据应用案例之:能源行业

智能电网现在欧洲已经做到了终端,也就是所谓的智能电表。在德国,为了鼓励利用太阳能,会在家庭安装太阳能,除了卖电给你,当你的太阳能有多余电的时候还可以买回来。通过电网收集每隔五分钟或十分钟收集一次数据,收集来的这些数据可以用来预测客户的用电习惯等,从而推断出在未来2~3个月时间里,整个电网大概需要多少电。有了这个预测后,就可以向发电或者供电企业购买一定数量的电。因为电有点像期货一样,如果提前买就会比较便宜,买现货就比较贵。通过这个预测后,可以降低采购成本。

维斯塔斯风力系统,依靠的是BigInsights软件和IBM超级计算机,然后对气象数据进行分析,找出安装风力涡轮机和整个风电场最佳的地点。利用大数据,以往需要数周的分析工作,现在仅需要不足1小时便可完成。

3. 大数据应用案例之:通信行业

XO Communications通过使用IBM SPSS预测分析软件,减少了将近一半的客户流失率。XO现在可以预测客户的行为,发现行为趋势,并找出存在缺陷的环节,从而帮助公司及时采取措施,保留客户。此外,IBM新的Netezza网络分析加速器,将通过提供单个端到端网络、服务、客户分析视图的可扩展平台,帮助通信企业制定更科学、合理决策。

电信业者透过数以千万计的客户资料,能分析出多种使用者行为和趋势,卖给需要的企业,这是全新的资料经济。

中国移动通过大数据分析,对企业运营的全业务进行针对性的监控、预警、跟踪。系统在第一时间自动捕捉市场变化,再以最快捷的方式推送给指定负责人,使他在最短时间内获知市场行情。

NTT docomo把手机位置信息和互联网上的信息结合起来,为顾客提供附近的餐饮店信息,接近末班车时间时,提供末班车信息服务。

4、大数据应用案例之:零售业

“我们的某个客户,是一家领先的专业时装零售商,通过当地的百货商店、网络及其邮购目录业务为客户提供服务。公司希望向客户提供差异化服务,如何定位公司的差异化,他们通过从 Twitter 和 Facebook 上收集社交信息,更深入的理解化妆品的营销模式,随后他们认识到必须保留两类有价值的客户:高消费者和高影响者。希望通过接受免费化妆服务,让用户进行口碑宣传,这是交易数据与交互数据的完美结合,为业务挑战提供了解决方案。”Informatica的技术帮助这家零售商用社交平台上的数据充实了客户主数据,使他的业务服务更具有目标性。

零售企业也监控客户的店内走动情况以及与商品的互动。它们将这些数据与交易记录相结合来展开分析,从而在销售哪些商品、如何摆放货品以及何时调整售价上给出意见,此类方法已经帮助某领先零售企业减少了17%的存货,同时在保持市场份额的前提下,增加了高利润率自有品牌商品的比例。

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号dashuju36:

大数据分析与应用案例介绍

End.



转载请注明:36大数据 » 大数据分析与应用案例介绍

简单实用的电商数据分析方法论

简单实用的电商数据分析方法论

导读:说到数据分析,大家可能就会想到回归,聚类什么的,不过对于电商的小伙伴来说,这些都太复杂了。而实际分析的时候,其实并不需要这么复杂的算法,大家需要的只是:

  • 对比
  • 细分
  • 转化
  • 分类

只要掌握了这四种思想,基本上已经可以应付日常的分析工作了。

对比思想

数据对比主要是横向和纵向两个角度,指标间的横向对比帮助我们认识预期值的合理性,而指标自身在时间维度上的对比,即我们通常说的趋势分析。

店铺的成交额分析为例:

纵向对比

我们可以把最近30天的成交额显示在坐标轴上,这样就可以很明显的看到最近的成交额是否达到了预期,当然我们也可以以周或者月(或者季度,年等等)为单位。

所有的分析其实都必须要考虑实际的场景,我们看到今天的成交额比昨天大也许说明的问题还是很有限,因为今天和昨天的性质可能未必一样,例如今天可能是周六,或者恰好是节假日等等。所以我们在做纵向对比的时候,例如要判断今天(假设是周六)的成交额是否合理,除了看最近30天的趋势数据,我们还可以考虑:

  • 最近10周的周六成交额趋势
  • 如果今天恰好是一个节日,例如双十一,那么可以考虑和上一年的双十一做一个对比。(说明:因为间隔时间比较长,数据反映出来的意义可能比较有限)

横向对比

例如我们说,店铺这周的成交额上涨了10%,那我们是不是应该高兴呢?

当然应该高兴,不过这个上涨的背后是否隐含着什么危机呢?当然是有的,例如你的竞争对手们这周的成交额都上涨了20%!当你洋洋得意的时候,可能已经被竞争对手拉开距离了。

也就是说,我们对一个现象判断好不好,这是需要一个参照系的。在现在的电商时代,你完全有可能知道竞争对手的成交额上涨了多少的。

再举一个更常见的例子:

假如我在不同的地方(或者平台)开了很多家店铺,某商品的成交额在A店铺上涨了10%,那这个是否值得高兴?

这个显然未必,我们还要对比商品A在各家店铺的上涨情况,例如可以对比平均曲线。

细分思想

使用转化的思想,我们已经基本可以判断一个指标(例如成交额)是否合理了。不过还仅仅知道是否合理是不够的,我们还需要知道问题所在,这时可以用上细分的思想了。通过细分的思想,我们可以对分析对象剥丝抽茧,逐步定位到问题点。细分的角度可以有很多,越细分越能准确描述问题。

例如,我们通过查看趋势,知道了这个月成交额下降了这个问题后,现在我们用细分的思想来找出问题的所在:

成交额细分

成交额 = 客单价 X 客户数

对比客单价和客户数的趋势,就可以判断出影响成交额变化的主要因素是什么,如果是客户数问题,我们则对客户数进行细分,如果是客单价问题,则对客单价进行细分。

客户数细分

客户数 = 新客户 + 老客户  老客户 = 二次成交客户 + 多次成交客户

一段时间内的新客户反映的是店铺的引流效果,而老客户反馈的是店铺的产品质量,服务质量和客户维护营销等。

对于店铺来说,促成二次成交都是非常重要的,特别是对于电商客户,因为对于电商,客户转移的成本比线下低很多。

客单价细分

客单价 = 成交价 X 人均成交数

人均成交数这是店铺一个非常值得关注的指标,它能最直接地反馈出店铺在服务质量和客户维护营销等方面的效果,如果该值过小表明店铺的客户流失率很大,应该重点关注。

成交价反馈的通常是导购的能力,促销活动的效果等,具体还可以对这个指标进行分解。

成交价细分

成交价 = 件单价 X 连带率

成交价的上升或者下跌,反映的问题可能很多,对其进行分解后就很明确了。

件单价的变化通常是有促销的力度,商品结构和消费结构(例如季节因素等)变化引起的。

连带率这个反馈的是店铺内导购的能力,或者促销手段(例如买一送一等)的效果,也是店铺管理人员重点要关注的指标。

细分思想其实就是不断用更小的量化指标去细分一个大的指标,从而达到定位问题的目的。

转化思想

细分的思想可以从纵向定位问题,但是单单细分是不够的。这些指标是从哪里来的,每一个步骤的转化率怎么样,哪一个步骤的转化不好,可以改善?这些通过转化率都可以分析出来。

例如我们要分析本周的活跃客户数(有成交的客户数),那么我们就要分析这些活跃的客户数是从哪里来的,梳理一下可以简单分为以下4个步骤:

进入店铺的客户数 ==》浏览过商品的客户数 ==》下单的客户数 ==》交易成功的客户数

这里4个步骤就会有3个转化率,哪些步骤转化率比较高,哪些步骤转化率比较低,历史趋势怎么样,是否合理,是否有改进的空间等等。通过应用转化的思想,能够有效的指导和优化实际的运营工作。

分类思想

上面我们已经介绍了对比,细分和转化三种实用的数据分析思想,现在我们还有再介绍一种非常实用的思想,那就是分类思想。

分类思想简单的说,就是把一些对象,按照某种规则,划分为若干个类别,然后分析各个类别的特征,并以此来指导我们的行动。

严格说,分类其实也是细分的一种,不过因为它比较重要,所以独自开来。

分类思想的应用很多,例如对客户的分类,我们可以用RFM分析模型,也可以用简单的利用某个指标的值(例如渠道标识,这样我们就可以分析到各个渠道客户的质量等)。基于这些客户的分类,我们就可以进行精准的客户营销了。

在电商或者零售业上,我们经常做的分类还有商品分类,经典的有按照品类分类,或者ABC分类,这些对于我们做商品运营都是非常重要的。

当然还有非常复杂的分类方法,例如聚类算法,不过这些不在我们的讨论范围内。

小结

对比,细分,转化和分类,其实都是很简单的数据分析思想,不过如果你掌握了,并且培养这样的意识,那一定会受益终身。

最后:

所有数据分析方法思想都只是术,真正的道是你对数据使用场景的深刻理解。离开了使用场景,数据就毫无价值。

 via:淘经验

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号:dashuju36

简单实用的电商数据分析方法论

End.

 



转载请注明:36大数据 » 简单实用的电商数据分析方法论

小应用撬动大世界,介绍4个真正使用大数据的方法

小应用撬动大世界,介绍4个真正使用大数据的方法

大数据已经在媒体和IT企业中大量提及,但是有多少企业真正在使用大数据?又有多少企业从大数据中受益呢?真正使用好大数据是不容易的事情。

2014年,美国的中西部和东北部遭遇了最恶劣的气候。美国的西南航空是美国最大的廉价航空。因者暴风雪,取消了上百家航班。上千上万的乘客准备打电话,以及通过网络支持重新预订航班,但是发现系统已经过载。最后这些旅客转向了滞留旅客的最后求助者:Twitter。

你可以想象一下,12000条充满各种愤怒的微博在6个暴风雪的日子里,把西南航空彻底淹没了。每天的峰值达到3000条微博。而另一端,作为这家航空公司的最后一招,派出了7个社交媒体专家。

这个例子似乎很极端,但是你不能保证自己不会遇到类似的事件,就是被社交媒体的需求和数据给吞没。很多大品牌,如可口可乐和NBA,每天有成千上万条社交媒体互动,从Twitter上的提及,以及Facebook上“赞”,到客户贴的问题和抱怨,以及分享公司最近新闻的博文。

慢慢地,一些公司发现了把这种数据的头疼变成一种资源。大数据其实就是企业和客户之间数字交互的洪流,一直也被炒作为新世纪的“原油”,表面上有巨大价值,如果不提炼,什么用也没有。这个挑战就是先进的软件套件和分析专家必须大体明白这些每天收集的兆兆字节的原始信息的意义。

社交媒体正在不断提供普通公司进入大数据神秘世界的入场券。配以新的,用户友好的分析工具,企业最终发现实用的,成本友好的方法,来处理客户和潜在客户上数字信息的井喷。

在西南航空的案例里,他们的社交媒体不仅能调节这个大风暴,也能从这个事件中收获积极情绪,以及比以往更多的粉丝。这是猜测大数据,正确的工具去化解它,在成功中就能扮演重要角色。

美国一家拥有800万用户的社交媒体管理系统公司HootSuite,它的CEO,Ryan Holmes最近在INC上撰文,对于那些指望利用社交媒体成为自己的优势,提出应用以下这些分析技术将是一个好的开始:

用过滤器从背景噪音中分离重要信息。Dell公司每天在11种语言的社交媒体渠道会收到超过25000个提及。从一个实际的业务角度来说,这些种的绝大多数是不重要的。但是通过使用社交媒体和分析工具,Dell能过滤出真正有用的信息:那种拥有成千上万粉丝的,有影响力的Twitter用户,贴在受人尊敬的博客和论坛上的故事,如果不被解决,就会扩散的紧急客户需求。

这些工具每个都使用自己专有的算法来实时确定最急迫的信息,考虑关键词、观点和其他定制化领域。最终的结果是社交媒体数据的洪水减少成可管理的溪流。公司能立即启动分流坏消息,帮助散布好消息,把简洁的信息分配给营销、销售、客户服务或者其他部门的人进行跟进。

跟踪整个信息量的变化。2013年9月2日晚上,关于英国航空的微博数量开始异常飙升。这个信息不是好的。不满的Twitter用户Hasan Syed生气自己的行李被航空公司丢了,发布了一个信息,“不要乘@英国航空,他们的客户服务糟糕透顶。”他不是把这个微博发给他的粉丝,而是把这个信息发给了纽约和英国的大约50000个其他用户,这两个地方都是英国航空的主要市场。

难以置信的是,英国航空的员工最后看见这个信息,并且姗姗来迟企图用道歉来灭火。这时,这个故事已经从社交媒体升华了,在大西洋两边的新闻载体传开了,从BBC到《时代》杂志。

用一些很简单的分析工具,在这个事件中的许多麻烦都能避免。社交媒体信息量的变化,像英国航空经历的,经常暗示有特别意义的事情出现,或好或坏,比如这个事件。当任何在活动异常出现时,可以设置警报来管理公司名字提及和其他关键词和问题警告电子邮件。这能使企业走在PR灾难之前,处理关注,阻止问题发酵失控。

植入自动跟踪情绪的工具。回到2009,一个小鼻屎给达美乐Pizza带来一个大问题。一个员工拍了一张工作时抠鼻子的视频,并上传到YouTube上。可以想象,在这段视频被撤下钱,这个脚本泛滥了,至少被看了一百万次。对于达美乐而言,这个视频和接下来的海啸,出现在从《纽约时报》到NBC这样的媒体上,把这个故事变成了“鼻屎门”,把已经很低的顾客评级又拉下不少。

为了反击,达美乐改变了菜谱,提供退钱保证,并设立一个网站,就餐者能上传他们食品的真正影像。在此期间,他们追踪社交媒体上的公众意见的变化,以便来调整他们推广每个方面的调调。最终,这个几百万美元的“我的过错”成为一个戏剧化的成功。美国地区的销售在推广之后的一个季度增长了14%,并且在接下来的一年,股价飙升了75%。

今天这种细微的性感追踪能即可实现。社交分析软件,这种软件能扫描自动上千上万信息的文本,来揭示积极情绪、负面情绪和中立情绪的分享。这样就给企业一个实时的窗口来观察如何感受他们产品、品牌、竞争对手,或者任意关键词组合。

通过不断监控搜索词,品牌能明白对于事件的内外舆论反应如何变化,企业能相应地转变策略。

选择能展现出时髦报告的软件。寒冷天气不是西南航空在近些年面对的唯一PR挑战。一次一个飞行员无意丢下一个收音机,里面以同性恋数落他的空乘人员充满了整个德州领空。整个事件吸引了超过1万社交媒体的提及。那是在机身飞行中有一个时间空挡,当事件发生时,乘客用免费的WI-FI来微博整个事件。

然而,尽管这些,西南航空可以避免这些伤痛。事实上,在2013年航空质量评级中,这家公司排名第一。一大部分,无疑必须面对航空公司的充满激情的社交媒体社区,这个社区有1.6百万的Twitter粉丝,以及4.2百万的Facebook的喜欢者。西南航空的社交业务和倾听团队花了多年培养和扩大了这个社区,改善了航空公司的曝光率,提升了忠诚度,并帮助了它成长,尽管有偶尔的PR失误。

然而,对公司高管在结果上的无情关注,交流社交媒体的价值不总是容易的。深深的怀疑主义在许多高管中持守,他们认为Twitter和Facebook代表着少有趣味的宠物视频,或者“最多”就是社交的“软”工具而已。

分析提供了一种解药。现在的工具包括高级回报功能,能拿出董事会需要的图表,追踪品牌全部曝光的变化和随时的性感变化,以及面对竞争对手的比较增长。利用这些可视化的帮助,营销和社区团队能展现给平静心态的高管,社交媒体确实对业务有意义。

看完这篇文章,不知道你对大数据应用找到了让老板们认可的突破点没有?小的应用,可以撬动一个大世界。

扫描微信下面二维码,随时了解大数据最新动向,添加36大数据官方微信公共帐号:dashuju36

小应用撬动大世界,介绍4个真正使用大数据的方法

End.



转载请注明:36大数据 » 小应用撬动大世界,介绍4个真正使用大数据的方法