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

  • 时间:
  • 浏览:1
  • 来源:甘肃快3注册平台-甘肃快3官网平台_甘肃快3官网

数据时代,大数据计算或者渗透到了各行各业,业务沉淀数据,数据计算产生新的业务价值,大数据计算正不断地用這個 法子推动业务向前发展。电商双11,商家与消费者狂欢的面前,同样离不开大数据计算带来的价值贡献,不为什么么是应用这么 广泛的“实时计算”。

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

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

流式数据一经下发,就都需用立即参与计算,一块儿将计算结果投入到业务应用中,这我太少 我太少 我太少 我太少 实时计算。实时数据计算我觉得早或者进入到大伙儿 生活的方方面面了,比如天气预报,要我大伙儿 的习惯是每天接收一次天气预报信息,现在则都需用实时查看天气预测,同有三个 时间点的天气预测会随着时间的接近这么 准确,这我太少 我太少 我太少 我太少 监测数据下发更新及实时数据计算带来的效果。

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

实时数据来源我太少 、数量这么 大,每年的数据量全部都是成倍地增长,这对实时计算有一种是利好的,都需用有更多的应用场景、更好的应用效果,还或者促成一点革命性的变化。这么 ,大数据实时计算还能做哪些?

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

金融风控是另有一种典型的实时计算应用场景。对金融业务這個 风险敏感的业务来说,仅仅能把数据可视化是远远匮乏的,它需用流计算系统不能利用一点风险模型的匹配规则,去实时分 析海量的用户行为数据,发现异常事件、判断风险等级,并作出相应的风险控制法子,自动化地去做报警通知、改变业务流程。通过实时计算做金融风控,带来的好处是减慢、更准、更广。一点一点相似风控我太少 我太少 我太少 我太少 的事件驱动计算场景,实时计算都能出理 好。

实时计算在推荐领域的应用也或者深会入了。不论是新闻推荐、音乐推荐还是读书推荐,基本都或者做到了千人千面,每此人 接收到的推送内容全部都是根据此人 兴趣偏好量身定制的。而用户的兴趣偏好,往往是通过实时数据计算不断在更新的。 以新闻推送为例,当用户点击三根条推送消息时,面前产品我觉得时刻在对用户的行为做实时分 析,实时更新用户的兴趣偏好,不断发现用户新的兴趣点,对用户这么 了解,最后给用户推送他更感兴趣的内容。再以音乐推荐为例,或者有三个 用户某段时间收藏了几首悲伤的歌曲,通过实时数据分析,系统都需用识别出這個 信息,一块儿有针对性的推送一点歌曲去抚慰用户。這個 场景是还不能了实时计算不能出理 的,也最能体现实时计算的价值。

我太少 的实时计算场景会被开发出来,未来大伙儿 对“一切全部都是变化之中”的感受会越来深会刻。

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

实时计算这么 好,在实现层面应该为什么么做,哪些困难和挑战是需用出理 的?

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

分布式实时计算面临的挑战包括我太少 我太少 我太少 我太少 有方面。数据从下发、到计算、到输出整个过程需用做到低延迟,除了计算节点有一种采用“增量计算”的模型,需用求上游数据传输模块具有很高的吞吐能力,或者具备数据缓存的能力,在大流量场景下都需用起到缓冲的作用,下游输出模块也需用做数据压缩、批量输出等优化,以保证输出结果的实时性。低延迟這個 大前提对实时计算系统的一点形态提出了更高的要求。比如双11深夜0点的要我,极少量消费者在同一时刻下单支付,这是涌进实时计算系统的瞬时数据量是巨大的,系统需用有强大的并行出理 数据的能力,将极少量瞬时流量合理分配到成百上千个计算节点,并将哪些节点的计算结果汇聚到一块儿计算出有三个 总体的结果,在高吞吐的情形下仍保证低延迟。

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

和低延迟同样关键的挑战是准确性。“增量计算”模型和传统“批量计算”模型是有区别的,我太少 我太少 我太少 我太少 有还不能了照搬过往的技术经验,或者就会有准确性方面的大问題。需用考虑清楚新进入的数据怎样才能叠加到老的计算结果上,一点场景下甚至要支持从老的计算结果中撤出 要素计算值,以保证最终结果的准确性。

分布式系统中的某个节点老出故障是很常见的,实时流计算系统的故障恢复能力也相当重要,或者当故障趋于稳定时,系统需用快速恢复,或者系统的输出更新或者就停滞了,实时性也就无从谈起。一块儿故障趋于稳定我太少 我太少 我太少 我太少 能破坏“增量计算”這個 模型,或者退化到“批量计算”的模型就又得还不能了实时的计算结果了,或者结果准确性也难以保证。

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

对于开发人员而言,写有三个 分布式守护进程比写单机守护进程会困难一点,而写有三个 分布式实时计算守护进程,会更难。好在业界有一点开源的流计算引擎帮助完成了不少工作,开发人员都需用使用哪些流计算引擎完成流计算任务的开发,大伙儿 或者不再需用关心计算任务怎样才能下发到多个计算节点上、数据在计算节点间怎样才能传输等大问題,只需用专注于计算逻辑的开发、控制好不同计算阶段的计算并行度。

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

且不考虑实时流计算系统怎样才能出理 易用性這個 大问題,看下计算机科学发展过程中,相似大问題是为什么么出理 的。大伙儿 希望编程都需用容易一点,我太少 我太少 我太少 我太少 有我太少 的高级编程语言被伟大的发明出来了;大伙儿 希望数据计算都需用容易一点,或者全部都是了数据库,以及SQL语言——形态化查询语言;到了大数据时代,大伙儿 还在折腾离线批量计算的要我,就遇到的依靠计算引擎编程多样化的大问題,最终通过把SQL语言应用到分布式离线计算系统上,出理 了這個 大问題。而现在实时计算的比较慢发展的现在,是算不算同样都需用用SQL语言去出理 這個 大问題?答案是肯定的。不过有一点细节的大问題需用去推敲求证。

实时流计算中的数据流,都需用理解为一张动态的数据表

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

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

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

实时流计算系统的易用性,是都需用用SQL语言来出理 的,网易流计算平台Sloth的生产实践也证实了這個 理论。用户不再需用学习各种计算引擎的编程接口,不再需用调试分布式计算守护进程,不再需用此人 维护流计算系统,只需用把我太少 我太少 我太少 我太少 跑在离线平台上的SQL迁移到实时流计算平台上,就都需用完成多样化的实时计算逻辑。

用户端的工作大大减少了,实时流计算平台的工作势必是要增加的,其中比较困难的要素是怎样才能把SQL查询转化成实际的计算逻辑,实现有三个 支持流式SQL的计算引擎,相似数据库引擎的角色,或者就像要我讨论的,這個 引擎的计算逻辑需用符合“增量计算”模型。一块儿为了能让实时计算结果应用到各种各样的业务场景中,计算引擎需用不能对接各种存储角色,比如数据、消息队列、离线存储等。

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

本文由站长之家用户投稿,未经站长之家同意,严禁转载。如广大用户大伙儿 ,发现稿件趋于稳定不实报道,欢迎读者反馈、纠正、举报大问題(反馈入口)。

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