双11黑科技揭秘:大数据实时计算如何为你量身定制?

  • 时间:
  • 浏览:1
  • 来源:1.5分赛车官网-10分6合平台_10分彩网投平台

数据时代,大数据计算许多渗透到了各行各业,业务沉淀数据,数据计算产生新的业务价值,大数据计算正不断地用什儿 土依据 推动业务向前发展。电商双11,商家与消费者狂欢的肩上,同样离不开大数据计算带来的价值贡献,很重是应用没有 广泛的“实时计算”。

现实世界中,数据连续产生,并被实时下发和计算

我们都都都不 做数据计算,挖掘产品商业价值,首要解决的问题图片图片是数据的问题图片图片。现实世界里,数据往往是随着时间的推进连续产生的,比如用户浏览商品,一系列的鼠标点击操作,会产生一连串的后台数据;开车使用手机导航,GPS定位每隔一段时间更新一次,也会不断产生日志数据;用户浏览新闻推送、搜索歌曲、监控摄像头定时下发图片上传到云端存储、视频直播等等场景,这肩上生成的数据都不 连续产生的。连续产生的业务数据,又被实时下发起来,就形成了数据流。

流式数据一经下发,就可可不都可以能立即参与计算,一起将计算结果投入到业务应用中,这许多 实时计算。实时数据计算着实早许多进入到我们都都都生活的方方面面了,比如天气预报,后来 我们都都都的习惯是每天接收一次天气预报信息,现在则可可不都可以能实时查看天气预测,同另兩个 时间点的天气预测会随着时间的接近没有 准确,这许多 监测数据下发更新及实时数据计算带来的效果。

 根据兴趣量身定制,实时计算让产品没有 了解用户

实时数据来源没有 来太满、数量没有 大,每年的数据量都不 成倍地增长,这对实时计算四种 是利好的,可可不都可以能有更多的应用场景、更好的应用效果,还许多促成许多革命性的变化。没有 ,大数据实时计算还能做那些?

在网易,考拉海购双11、618海淘盛典等活动期间,不会有一块网易有数大屏幕实时展示当前最新的销售总额、每个商品品类的销售比例、订单增长趋势、活跃用户地理位置等,各种维度的信息都不 一块屏幕上不断跳动。每个用户每笔订单所产生的影响不会实时更新到大屏上。什儿 可视化的实时应用效果,除了增添一份电商狂欢节的氛围,更易于发现数据价值,指导市场运营、辅助商业决策。

金融风控是另四种 典型的实时计算应用场景。对金融业务什儿 风险敏感的业务来说,仅仅能把数据可视化是远远过低的,它须要流计算系统可不都可以利用许多风险模型的匹配规则,去实八时析海量的用户行为数据,发现异常事件、判断风险等级,并作出相应的风险控制土依据 ,自动化地去做报警通知、改变业务流程。通过实时计算做金融风控,带来的好处是调快、更准、更广。许多许多同类于风控另另兩个 的事件驱动计算场景,实时计算都能解决好。

实时计算在推荐领域的应用也许多越深入了。不论是新闻推荐、音乐推荐还是读书推荐,基本都许多做到了千人千面,每被委托人接收到的推送内容都不 根据被委托人兴趣偏好量身定制的。而用户的兴趣偏好,往往是通过实时数据计算不断在更新的。 以新闻推送为例,当用户点击一条条推送消息时,肩上产品着实时刻在对用户的行为做实八时析,实时更新用户的兴趣偏好,不断发现用户新的兴趣点,对用户没有 了解,最后给用户推送他更感兴趣的内容。再以音乐推荐为例,许多另兩个 用户某段时间收藏了几首悲伤的歌曲,通过实时数据分析,系统可可不都可以能识别出什儿 信息,一起有针对性的推送许多歌曲去抚慰用户。什儿 场景是没有 实时计算可不都可以解决的,也最能体现实时计算的价值。

没有 来太满的实时计算场景会被开发出来,未来我们都都都对“一切都不 变化之中”的感受会没有 深刻。

 从“先存后算”到“边算边存”,实时计算不再怕“大”数据

实时计算没有 好,在实现层面应该为甚做,有那些困难和挑战是须要解决的?

首先从整体架构看,数据计算,无外乎三样东西:数据输入→计算→数据输出。传统的计算模型,以数据库为例,是先将数据存储在另兩个 数据表中,用户通过执行查询一段话触发数据库的计算操作,最后数据库完成计算后输出结果。什儿 “先存后算”的模型在大数据实时计算场景下是行不通的。我们都都都所要计算的数据很“大”,另兩个 计算结果所涉及的源数据许多是带有过往一天的数据,许多是上千亿条数据记录。许多每增加许多新数据,都把所有数据都重新计算一遍,另另兩个 的开销是非常大的,最终的效果会是很“慢”,达没有 实时的效果。比较合理的做法是“边算边存”,意思是数据进入实时计算系统后,不一定须要先存储起来,可可不都可以能直接参与计算,许多这里的计算不算把当前新增的数据在后来 历史数据的计算结果上做“增量计算”,同一条数据不重复参与计算,计算完成后来 ,再把计算结果保存起来,供业务使用,这时数据存储的压力也小了许多。一起“大”意味着数据并发很高,每秒许多须要计算上千万条新数据,另另兩个 的计算量都不 单机能承受的,许多大数据实时计算要解决好的是分布式系统架构下的一系列技术问题图片图片。

分布式实时计算面临的挑战包括许多方面。数据从下发、到计算、到输出整个过程须要做到低延迟,除了计算节点四种 采用“增量计算”的模型,须要求上游数据传输模块具有很高的吞吐能力,许多具备数据缓存的能力,在大流量场景下可可不都可以能起到缓冲的作用,下游输出模块也须要做数据压缩、批量输出等优化,以保证输出结果的实时性。低延迟什儿 大前提对实时计算系统的许多特性提出了更高的要求。比如双11半夜0点的后来 ,几滴 消费者在同一时刻下单支付,这是涌进实时计算系统的瞬时数据量是巨大的,系统须要有强大的并行解决数据的能力,将几滴 瞬时流量合理分配到成百上千个计算节点,并将那些节点的计算结果汇聚到一起计算出另兩个 总体的结果,在高吞吐的请况下仍保证低延迟。

从“批量计算”到“增量计算”,最具挑战的是准确性和易用性

和低延迟同样关键的挑战是准确性。“增量计算”模型和传统“批量计算”模型是有区别的,许多没有 照搬过往的技术经验,许多就会有准确性方面的问题图片图片。须要考虑清楚新进入的数据怎样叠加到老的计算结果上,许多场景下甚至要支持从老的计算结果中撤回累积计算值,以保证最终结果的准确性。

分布式系统中的某个节点出先故障是很常见的,实时流计算系统的故障恢复能力也相当重要,许多当故障发生时,系统须要快速恢复,许多系统的输出更新许多就停滞了,实时性也就无从谈起。一起故障发生许多 能破坏“增量计算”什儿 模型,许多退化到“批量计算”的模型就又得没有 实时的计算结果了,许多结果准确性也难以保证。

事实上网易大数据在实现自研流计算平台Sloth的过程中,遇到并克服了上述技术难点。网易流计算平台Sloth作为另兩个 平台化的产品,在产品易用性、多租户隔离方面做了几滴 的工作。就实时计算而言,易用性是另兩个 比较值得讨论的方面。

对于开发人员而言,写另兩个 分布式tcp连接比写单机tcp连接会困难许多,而写另兩个 分布式实时计算tcp连接,会更难。好在业界有许多开源的流计算引擎帮助完成了不少工作,开发人员可可不都可以能使用那些流计算引擎完成流计算任务的开发,我们都都都许多不再须要关心计算任务怎样下发到多个计算节点上、数据在计算节点间怎样传输等问题图片图片,只须要专注于计算逻辑的开发、控制好不同计算阶段的计算并行度。

以计算一篇文章的单词数为例,另兩个 分布式计算tcp连接的内容许多包括另兩个 累积,首先是用哪十几个 计算节点一起把每一行文本拆分成另兩个 另兩个 的单词;第二步是用另外许多计算节点去统计单词的个数(考虑到数据量巨大的请况,这里有必要用多个节点去做计算);第三步是由另兩个 计算节点把上游各各节点算出的累积计数汇聚成另兩个 总的计数。另另兩个 另兩个 最简单的场景,须要开发的代码量最少 是50行。实际业务场景下,数据流经的计算节点远远不止十个 ,计算类型也比基础的求和僵化 许多,许多即使有了流计算引擎,分布式实时计算tcp连接的开发仍然是比较困难的。再进一步看,即使开发完成了,还须要把几滴 的时间投入到调试、计算框架维护等方面,一旦计算需求发生变化,所有的工作都须要重新迭代一遍,这是个比较痛苦的过程。怎样让流式计算tcp连接更易编写,是实时计算平台须要去完成的挑战。

且不考虑实时流计算系统怎样解决易用性什儿 问题图片图片,看下计算机科学发展过程中,同类于问题图片图片是为甚解决的。我们都都都希望编程可可不都可以能容易许多,许多没有 来太满的高级编程语言被创造发明出来了;我们都都都希望数据计算可可不都可以能容易许多,许多都不 了数据库,以及SQL语言——特性化查询语言;到了大数据时代,我们都都都还在折腾离线批量计算的后来 ,就遇到的依靠计算引擎编程僵化 的问题图片图片,最终通过把SQL语言应用到分布式离线计算系统上,解决了什儿 问题图片图片。而现在实时计算的比较慢发展的现在,算不算同样可可不都可以能用SQL语言去解决什儿 问题图片图片?答案是肯定的。不过有许多细节的问题图片图片须要去推敲求证。

实时流计算中的数据流,可可不都可以能理解为一张动态的数据表

上文提及了离线批量计算模型和实时增量计算模型是有差异的,当SQL语言分别作用与批量计算和流式计算时,其语义也是须要发生变化的。批量计算和流式计算最主要的区别是前者计算的数据是有限的、后者计算的数据是无限的是不断下发进入系统的。当另兩个 SQL查询作用在一批离线数据上面时,计算完成、输出结果,这条SQL查询也就完成了。映射到流式计算,当SQL查询触发计算,它是我太满 结束了的,许多数据在持续不断地流入,按照离线SQL的语义,SQL结束了后来 ,计算我太满 输出结果,这显然都不 流计算期望的效果,许多流式SQL其本质应当是定义一系列流计算任务,一起那些任务是边执行边输出计算结果的。

离线SQL解决的是静态数据表,而流式SQL解决的是数据流,SQL的计算语义(如求和、平均值、数据表连接等)作用在数据流上算不算合理。理解什儿 问题图片图片须要做另兩个 概念上的转换:离线SQL是把静态的数据表转再加另一张静态数据表;而实时流计算中的数据流,可可不都可以能理解为一张动态的数据表(数据会不断增长的动态数据表)。不同的时刻什儿 数据表又不同的样子,执行SQL会得到不同的计算结果,把那些不同的计算结果像电影幻灯片放映一样串联起来,我们都都都就得到了一张动态的结果表——流式SQL做的工作许多 把一张动态数据表转再加另一张动态数据表,另另兩个 流SQL的计算语义就比较容易理解了。实时流计算系统要解决的问题图片图片就缩小到了“怎样实现动态数据表的计算”上来。

流SQL引擎的自动优化是当前主要的技术突破方向

实时流计算系统的易用性,是可可不都可以能用SQL语言来解决的,网易流计算平台Sloth的生产实践也证实了什儿 理论。用户不再须要学习各种计算引擎的编程接口,不再须要调试分布式计算tcp连接,不再须要被委托人维护流计算系统,只须要把另另兩个 跑在离线平台上的SQL迁移到实时流计算平台上,就可可不都可以能完成僵化 的实时计算逻辑。

用户端的工作大大减少了,实时流计算平台的工作势必是要增加的,其中比较困难的累积是怎样把SQL查询转化成实际的计算逻辑,实现另兩个 支持流式SQL的计算引擎,同类于数据库引擎的角色,许多就像后来 讨论的,什儿 引擎的计算逻辑须要符合“增量计算”模型。一起为了能让实时计算结果应用到各种各样的业务场景中,计算引擎须可不都可以能对接各种存储角色,比如数据、消息队列、离线存储等。

双11大屏许多 大数据实时流计算的四种 应用场景,未来会有没有 来太满的实时计算场景,比如除了文本计算实时化,图像、语音计算也可可不都可以能实时化,在线机器学习,物联网实时计算等。实时数据以及实时流计算场景的类型都不 指数增长的,实时计算引擎会面临不小的挑战。基于SQL的流式计算描述也正在向前演化,会没有 来太满的纳入流计算特有的属性,比如输出触发、过期数据解决、多种规则的数据窗口划分等。流SQL引擎的自动优化也是当前主要的另兩个 技术突破方向,相信未来实时流计算会随着技术的进步,应用得跟深入、更广泛。

本文由站长之家用户投稿,未经站长之家同意,严禁转载。如广大用户我们都都都,发现稿件发生不实报道,欢迎读者反馈、纠正、举报问题图片图片(反馈入口)。

免责声明:本文为用户投稿的文章,站长之家发布此文仅为传递信息,不代表站长之家赞同其观点,不对对内容真实性负责,仅供用户参考之用,不构成任何投资、使用建议。请读者自行核实真实性,以及许多发生的风险,任何后果均由读者自行承担。