双11黑科技：大数据实时计算量身定制

数据时代，大数据计算已经渗透到了各行各业，业务沉淀数据，数据计算产生新的业务价值，大数据计算正不断地用这种方式推动业务向前发展。电商双11，商家与消费者狂欢的背后，同样离不开大数据计算带来的价值贡献，特别是应用越来越广泛的“实时计算”。

现实世界中，数据连续产生，并被实时采集和计算

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

流式数据一经采集，就可以立即参与计算，同时将计算结果投入到业务应用中，这就是实时计算。实时数据计算其实早已经进入到人们生活的方方面面了，比如天气预报，以前人们的习惯是每天接收一次天气预报信息，现在则可以实时查看天气预测，同一个时间点的天气预测会随着时间的接近越来越准确，这就是监测数据采集更新及实时数据计算带来的效果。

根据兴趣量身定制，实时计算让产品越来越了解用户

实时数据来源越来越多、数量越来越大，每年的数据量都在成倍地增长，这对实时计算本身是利好的，可以有更多的应用场景、更好的应用效果，还可能促成一些革命性的变化。那么，大数据实时计算还能做什么？

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

金融风控是另一种典型的实时计算应用场景。对金融业务这种风险敏感的业务来说，仅仅能把数据可视化是远远不够的，它需要流计算系统能够利用一些风险模型的匹配规则，去实时分析海量的用户行为数据，发现异常事件、判断风险等级，并作出相应的风险控制措施，自动化地去做报警通知、改变业务流程。通过实时计算做金融风控，带来的好处是更快、更准、更广。其他许多类似风控这样的事件驱动计算场景，实时计算都能解决好。

实时计算在推荐领域的应用也已经很深入了。不论是新闻推荐、音乐推荐还是读书推荐，基本都已经做到了千人千面，每个人接收到的推送内容都是根据个人兴趣偏好量身定制的。而用户的兴趣偏好，往往是通过实时数据计算不断在更新的。 以新闻推送为例，当用户点击一条条推送消息时，背后产品其实时刻在对用户的行为做实时分析，实时更新用户的兴趣偏好，不断发现用户新的兴趣点，对用户越来越了解，最后给用户推送他更感兴趣的内容。再以音乐推荐为例，如果一个用户某段时间收藏了几首悲伤的歌曲，通过实时数据分析，系统可以识别出这一信息，同时有针对性的推送一些歌曲去抚慰用户。这种场景是只有实时计算才能解决的，也最能体现实时计算的价值。

越来越多的实时计算场景会被开发出来，未来人们对“一切都在变化之中”的感受会越来越深刻。

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

实时计算这么好，在实现层面应该怎么做，有哪些困难和挑战是必须解决的？

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

分布式实时计算面临的挑战包括很多方面。数据从采集、到计算、到输出整个过程必须做到低延迟，除了计算节点本身采用“增量计算”的模型，还要求上游数据传输模块具有很高的吞吐能力，并且具备数据缓存的能力，在大流量场景下可以起到缓冲的作用，下游输出模块也需要做数据压缩、批量输出等优化，以保证输出结果的实时性。低延迟这个大前提对实时计算系统的其他特性提出了更高的要求。比如双11凌晨0点的时候，大量消费者在同一时刻下单支付，这是涌进实时计算系统的瞬时数据量是巨大的，系统需要有强大的并行处理数据的能力，将大量瞬时流量合理分配到成百上千个计算节点，并将这些节点的计算结果汇聚到一起计算出一个总体的结果，在高吞吐的情况下仍保证低延迟。

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

和低延迟同样关键的挑战是准确性。“增量计算”模型和传统“批量计算”模型是有区别的，所以不能照搬过往的技术经验，否则就会有准确性方面的问题。需要考虑清楚新进入的数据如何叠加到老的计算结果上，有些场景下甚至要支持从老的计算结果中撤除部分计算值，以保证最终结果的准确性。

分布式系统中的某个节点出现故障是很常见的，实时流计算系统的故障恢复能力也相当重要，因为当故障发生时，系统必须快速恢复，否则系统的输出更新可能就停滞了，实时性也就无从谈起。同时故障发生也不能破坏“增量计算”这个模型，否则退化到“批量计算”的模型就又得不到实时的计算结果了，而且结果准确性也难以保证。

（编辑：555手机网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!