实时计算应用场景

标签: 实时计算 Facebook 实时 | 发表时间:2011-08-18 23:43 | 作者:yiihsia JHavaC
出处:http://www.yiihsia.com

实时计算的概念很难定义,每个人对这四个字的理解可能都不同。个人观点主要分为两块:数据的实时入库和数据的实时计算。

数据实时入库的时候,一般都需要对原始数据做一定的处理再入库。能在这个步骤计算尽量在这里完成。 这个类似数据的预算后入库,然后提供直接读取服务。对用户的延时性上最好。

然而有一些对数据的计算并不能通过预算解决全部问题,比如搜索。这篇主要讲实时计算的应用场景,技术架构、实现细节以后写。

实时计算比较常在数据分析类应用中出现,由于数据分析时刷选条件多样性与多变性,使数据无法预算,所以只能通过后期的实时计算。

Facebook的实时系统中大量应用到了hadoop、hbase。


他们的项目需求主要有:
1. Elasticity(伸缩性)

2. High write throughput(高写吞吐量)

3. Efficient and low-latency strong consistency semantics within a data center(单个data center内高性能、低延迟的强一致性)

4. Efficient random reads from disk(disk的高性能随机读)

5. High Availability and Disaster Recovery(高可靠性、灾后恢复能力)

6. Fault Isolation(错误隔离)

7. Atomic read-modify-write primitives(read-modify-write原子操作)

8. Range Scans(范围扫描)

Facebook对HBase、HDFS做了大量优化,但毕竟是基于MapReduce(IO是硬伤),再优化也无法达到互联网应用级别的响应延时。用户搜索“2011手机” 又选择了属性:智能机、直板,想看这个月满足这些条件的交易在不同省份的分布。如果过个10s以上才返回数据分析结果,我都不好意思说自己是做互联网的。

上面的是Facebook实时分析系统的需求,我们的实时计算系统的主要需求如下:

1、海量数据
2、提供各类计算
3、支持任何条件的搭配
4、实时响应(秒级)
5、结果精确

所以我们需要放弃MapReduce的思想,自己设计新的计算架构。 乍一看需求,和搜索很类似。的确,实时计算中大量用到了搜索技术。

与搜索的主要区别:

目的不同:搜索的目的是排序、实时计算的目的是汇总计算
结果不同:搜索返回的是list、实时计算返回的是计算的精确结果
读取数据不同:搜索可以根据权重取topN的数据做排序、实时计算需要获取所有满足条件的数据做计算。

想象一个应用场景(假设我需要的属性都能获得):

1、我想知道昨天访问我博客的访问量 —> 这个很简单,根本不需要实时计算
2、我想知道昨天来自每个省份对我博客的访问量 —> 这个也简单,我提前把每个省的访问量都预算好就行了
3、我想知道昨天来自每个省份不同性别的访问量分布 —> 这个也不难,也就36*2 = 72条记录,我也提前预算好了。
4、我想知道昨天来自每个省份不同性别不同年龄的访问量分布 —-> 有点够呛,不过也不难 ,继续预算
5、我想知道昨天来自每个省份不同性别不同年龄不同职业的访问量分布 —> 数据量开始膨胀,预算时间也开始变久,数据已经快上亿级别了。而且你会发现,很多组合的预算都是没有意义的,比如 “上海+女+99岁+狙击手”、“西藏 + 女 + 屠夫” 这样的查询组合根本不可能有数据。
6、我想知道昨天来自每个省份不同性别不同年龄不同职业不同名族的访问量分布 —> 不考虑预算了,数据量早就上亿了,而且很多计算都是没有意义的。So 实时计算的作用发挥了。

总结下:

当数据量很大,同时发现无法穷举所有可能条件的查询组合 或者 大量穷举出来的条件组合无用的时候是实时计算最佳的应用场景。

猜你喜欢:
Zoie实现实时搜索的原理
Facebook技术体系窥探之基础组件
海量数据实时计算随笔
Facebook技术体系窥探之P级数据
用好Cache,优化应用
无觅

相关 [实时计算 应用] 推荐:

实时计算应用场景

- JHavaC - yiihsia[互联网后端技术]_yiihsia[互联网后端技术]
实时计算的概念很难定义,每个人对这四个字的理解可能都不同. 个人观点主要分为两块:数据的实时入库和数据的实时计算. 数据实时入库的时候,一般都需要对原始数据做一定的处理再入库. 能在这个步骤计算尽量在这里完成. 这个类似数据的预算后入库,然后提供直接读取服务. 然而有一些对数据的计算并不能通过预算解决全部问题,比如搜索.

实时计算框架 Flink 在教育行业的应用实践

- - U刻
如今,越来越多的业务场景要求 OLTP 系统能及时得到业务数据计算、分析后的结果,这就需要实时的流式计算如 Flink 等来保障. 例如,在 TB 级别数据量的数据库中,通过 SQL 语句或相关 API 直接对原始数据进行大规模关联、聚合操作,是无法做到在极短的时间内通过接口反馈到前端进行展示的. 若想实现大规模数据的 “即席查询”,就须用实时计算框架构建实时数仓来实现.

你了解实时计算吗?

- - 程序师
我们以热卖产品的统计为例,看下传统的计算手段:. 将用户行为、log等信息清洗后保存在数据库中.. 将订单信息保存在数据库中.. 利用触发器或者协程等方式建立本地索引,或者远程的独立索引.. join订单信息、订单明细、用户信息、商品信息等等表,聚合统计20分钟内热卖产品,并返回top-10.. 这是一个假想的场景,但假设你具有处理类似场景的经验,应该会体会到这样一些问题和难处:.

Storm实时计算:流操作入门编程实践

- - 简单之美
Storm是一个分布式是实时计算系统,它设计了一种对流和计算的抽象,概念比较简单,实际编程开发起来相对容易. 下面,简单介绍编程实践过程中需要理解的Storm中的几个概念:. 一个Topology运行以后就不能停止,它会无限地运行下去,除非手动干预(显式执行bin/storm kill )或意外故障(如停机、整个Storm集群挂掉)让它终止.

Kafka+Spark Streaming+Redis实时计算整合实践

- - 简单之美
基于Spark通用计算平台,可以很好地扩展各种计算类型的应用,尤其是Spark提供了内建的计算库支持,像Spark Streaming、Spark SQL、MLlib、GraphX,这些内建库都提供了高级抽象,可以用非常简洁的代码实现复杂的计算逻辑、这也得益于Scala编程语言的简洁性. 这里,我们基于1.3.0版本的Spark搭建了计算平台,实现基于Spark Streaming的实时计算.

唯品会实时计算平台的演进之路

- -
先介绍一下我们整个平台的现状,按计算的话,分为 Storm、Spark、Flink 三个主要的计算引擎,Flink 相应的应用数量目前少一些,不过按照整个计算引擎的发展方式,后续我们还是希望以 Flink 为主做相应的业务推进. 实时推荐引擎:这块是非常核心的业务,对于大数据来说这些都是个性化推荐、实时推荐;.

滴滴实时计算发展之路及平台架构实践

- - zhisheng的博客
滴滴的核心业务是一个实时在线服务,因此具有丰富的实时数据和实时计算场景. 本文将介绍滴滴实时计算发展之路以及平台架构实践. 随着滴滴业务的发展,滴滴的实时计算架构也在快速演变. 到目前为止大概经历了三个阶段:. 下图标识了其中重要的里程碑,稍后会给出详细阐述:. 在2017年以前,滴滴并没有统一的实时计算平台,而是各个业务方自建小集群.

【转】使用Storm处理事务型实时计算需求时的几处难点

- - 互联网 - ITeye博客
接触流计算领域不长时间,对这个领域可以说还是个门外汉. 最近在做实时计算相关的应用,简单说下自己的感受,以后再展开来讨论. 比流量或者订单淘宝可以把我们甩出几条大街. 淘宝的兄弟可以自豪地说他们的实时应用已经承受住了双十一全世界范围内最大的单日数据流的冲击. 而阿里巴巴中文站的流量和订单与淘宝相比则少的可怜.

GetEd2k (Android应用)

- 某牢 - eMule Fans 电骡爱好者
GetEd2k是一个Android应用程序,作者是anacletus. 此应用可以帮助你把网页中的电驴(eDonkey) 链接添加到你个人电脑的电驴客户端里,不过前提是你的客户端开启了用于远程控制的Web interface(Web服务器,网页接口,Web界面),当然,eMule(电骡), MLDonkey 和 aMule 都支持该功能,所以这三种主流电驴客户端的用户都可以使用GetEd2k.

fixed应用

- - ITeye博客
今天在逛人人网时,发现人人网首页左侧的“应用动态”,随着我页面向下滚动,一直固定在网站的左侧. 但这效果存在一点瑕疵,在拖动过程中存在一点抖动(ie下),不是非常平滑. 我尝试使用jquey实现了该效果,也解决了抖动的问题. 创建一个ID为sideBar的div,将它的position设置为absolute.