数据时代, 大数据计算已经渗透到了各行各业, 业务沉淀数据, 数据计算产生新的业务价值, 大数据计算正不断地用这种方式推动业务向前发展. 电商双11, 商家与消费者狂欢的背后, 同样离不开大数据计算带来的价值贡献, 特别是应用越来越广泛的 '实时计算' . 现实世界中, 数据连续产生, 并被实时采集和计算 我们要做数据计算, 挖掘产品商业价值, 首要解决的问题是数据的问题. 现实世界里, 数据往往是随着时间的推进连续产生的, 比如用户浏览商品, 一系列的鼠标点击操作, 会产生一连串的后台数据; 开车使用手机导航, GPS定位每隔一段时间更新一次, 也会不断产生日志数据; 用户浏览新闻推送, 搜索歌曲, 监控摄像头定时采集图片上传到云端存储, 视频直播等等场景, 这背后生成的数据都是连续产生的. 连续产生的业务数据, 又被实时采集起来, 就形成了数据流. 流式数据一经采集, 就可以立即参与计算, 同时将计算结果投入到业务应用中, 这就是实时计算. 实时数据计算其实早已经进入到人们生活的方方面面了, 比如天气预报, 以前人们的习惯是每天接收一次天气预报信息, 现在则可以实时查看天气预测, 同一个时间点的天气预测会随着时间的接近越来越准确, 这就是监测数据采集更新及实时数据计算带来的效果. 根据兴趣量身定制, 实时计算让产品越来越了解用户 实时数据来源越来越多, 数量越来越大, 每年的数据量都在成倍地增长, 这对实时计算本身是利好的, 可以有更多的应用场景, 更好的应用效果, 还可能促成一些革命性的变化. 那么, 大数据实时计算还能做什么? 在网易, 考拉海购双11, 618海淘盛典等活动期间, 都会有一块网易有数大屏幕实时展示当前最新的销售总额, 每个商品品类的销售比例, 订单增长趋势, 活跃用户地理位置等, 各种维度的信息都在一块屏幕上不断跳动. 每个用户每笔订单所产生的影响都会实时更新到大屏上. 这种可视化的实时应用效果, 除了增添一份电商狂欢节的氛围, 更易于发现数据价值, 指导市场运营, 辅助商业决策. 金融风控是另一种典型的实时计算应用场景. 对金融业务这种风险敏感的业务来说, 仅仅能把数据可视化是远远不够的, 它需要流计算系统能够利用一些风险模型的匹配规则, 去实时分析海量的用户行为数据, 发现异常事件, 判断风险等级, 并作出相应的风险控制措施, 自动化地去做报警通知, 改变业务流程. 通过实时计算做金融风控, 带来的好处是更快, 更准, 更广. 其他许多类似风控这样的事件驱动计算场景, 实时计算都能解决好. 实时计算在推荐领域的应用也已经很深入了. 不论是新闻推荐, 音乐推荐还是读书推荐, 基本都已经做到了千人千面, 每个人接收到的推送内容都是根据个人兴趣偏好量身定制的. 而用户的兴趣偏好, 往往是通过实时数据计算不断在更新的. 以新闻推送为例, 当用户点击一条条推送消息时, 背后产品其实时刻在对用户的行为做实时分析, 实时更新用户的兴趣偏好, 不断发现用户新的兴趣点, 对用户越来越了解, 最后给用户推送他更感兴趣的内容. 再以音乐推荐为例, 如果一个用户某段时间收藏了几首悲伤的歌曲, 通过实时数据分析, 系统可以识别出这一信息, 同时有针对性的推送一些歌曲去抚慰用户. 这种场景是只有实时计算才能解决的, 也最能体现实时计算的价值. 越来越多的实时计算场景会被开发出来, 未来人们对 '一切都在变化之中' 的感受会越来越深刻. 从 '先存后算' 到 '边算边存' , 实时计算不再怕 '大' 数据 实时计算这么好, 在实现层面应该怎么做, 有哪些困难和挑战是必须解决的? 首先从整体架构看, 数据计算, 无外乎三样东西: 数据输入→计算→数据输出. 传统的计算模型, 以数据库为例, 是先将数据存储在一个数据表中, 用户通过执行查询语句触发数据库的计算操作, 最后数据库完成计算后输出结果. 这种 '先存后算' 的模型在大数据实时计算场景下是行不通的. 我们所要计算的数据很 '大' , 一个计算结果所涉及的源数据可能是涵盖过往一天的数据, 可能是上千亿条数据记录. 如果每增加一些新数据, 都把所有数据都重新计算一遍, 这样的开销是非常大的, 最终的效果会是很 '慢' , 达不到实时的效果. 比较合理的做法是 '边算边存' , 意思是数据进入实时计算系统后, 不一定需要先存储起来, 可以直接参与计算, 而且这里的计算是把当前新增的数据在之前历史数据的计算结果上做 '增量计算' , 同一条数据不重复参与计算, 计算完成之后, 再把计算结果保存起来, 供业务使用, 这时数据存储的压力也小了很多. 同时 '大' 意味着数据并发很高, 每秒可能需要计算上千万条新数据, 这样的计算量不是单机能承受的, 所以大数据实时计算要解决好的是分布式系统架构下的一系列技术问题. 分布式实时计算面临的挑战包括很多方面. 数据从采集, 到计算, 到输出整个过程必须做到低延迟, 除了计算节点本身采用 '增量计算' 的模型, 还要求上游数据传输模块具有很高的吞吐能力, 并且具备数据缓存的能力, 在大流量场景下可以起到缓冲的作用, 下游输出模块也需要做数据压缩, 批量输出等优化, 以保证输出结果的实时性. 低延迟这个大前提对实时计算系统的其他特性提出了更高的要求. 比如双11凌晨0点的时候, 大量消费者在同一时刻下单支付, 这是涌进实时计算系统的瞬时数据量是巨大的, 系统需要有强大的并行处理数据的能力, 将大量瞬时流量合理分配到成百上千个计算节点, 并将这些节点的计算结果汇聚到一起计算出一个总体的结果, 在高吞吐的情况下仍保证低延迟. 从 '批量计算' 到 '增量计算' , 最具挑战的是准确性和易用性 和低延迟同样关键的挑战是准确性. '增量计算' 模型和传统 '批量计算' 模型是有区别的, 所以不能照搬过往的技术经验, 否则就会有准确性方面的问题. 需要考虑清楚新进入的数据如何叠加到老的计算结果上, 有些场景下甚至要支持从老的计算结果中撤除部分计算值, 以保证最终结果的准确性. 分布式系统中的某个节点出现故障是很常见的, 实时流计算系统的故障恢复能力也相当重要, 因为当故障发生时, 系统必须快速恢复, 否则系统的输出更新可能就停滞了, 实时性也就无从谈起. 同时故障发生也不能破坏 '增量计算' 这个模型, 否则退化到 '批量计算' 的模型就又得不到实时的计算结果了, 而且结果准确性也难以保证. 事实上网易大数据在实现自研流计算平台Sloth的过程中, 遇到并克服了上述技术难点. 网易流计算平台Sloth作为一个平台化的产品, 在产品易用性, 多租户隔离方面做了大量的工作. 就实时计算而言, 易用性是一个比较值得讨论的方面.  对于开发人员而言, 写一个分布式程序比写单机程序会困难一些, 而写一个分布式实时计算程序, 会更难. 好在业界有一些开源的流计算引擎帮助完成了不少工作, 开发人员可以使用这些流计算引擎完成流计算任务的开发, 他们可能不再需要关心计算任务如何分发到多个计算节点上, 数据在计算节点间如何传输等问题, 只需要专注于计算逻辑的开发, 控制好不同计算阶段的计算并行度. 以计算一篇文章的单词数为例, 一个分布式计算程序的内容可能包括三个部分, 首先是用几个计算节点共同把每一行文本拆分成一个一个的单词; 第二步是用另外一些计算节点去统计单词的个数 (考虑到数据量巨大的情况, 这里有必要用多个节点去做计算) ; 第三步是由一个计算节点把上游各各节点算出的部分计数汇聚成一个总的计数. 这样一个最简单的场景, 需要开发的代码量大约是200行. 实际业务场景下, 数据流经的计算节点远远不止3个, 计算类型也比基础的求和复杂很多, 所以即使有了流计算引擎, 分布式实时计算程序的开发仍然是比较困难的. 再进一步看, 即使开发完成了, 还需要把大量的时间投入到调试, 计算框架维护等方面, 一旦计算需求发生变化, 所有的工作都需要重新迭代一遍, 这是个比较痛苦的过程. 如何让流式计算程序更易编写, 是实时计算平台需要去完成的挑战. 且不考虑实时流计算系统如何解决易用性这个问题, 看下计算机科学发展过程中, 类似问题是怎么解决的. 人们希望编程可以容易一些, 所以越来越多的高级编程语言被发明出来了; 人们希望数据计算可以容易一些, 然后就有了数据库, 以及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引擎的自动优化也是当前主要的一个技术突破方向, 相信未来实时流计算会随着技术的进步, 应用得跟深入, 更广泛.
数据时代, 大数据计算已经渗透到了各行各业, 业务沉淀数据, 数据计算产生新的业务价值, 大数据计算正不断地用这种方式推动业务向前发展. 电商双11, 商家与消费者狂欢的背后, 同样离不开大数据计算带来的价值贡献, 特别是应用越来越广泛的 '实时计算' . 现实世界中, 数据连续产生, 并被实时采集和计算 我们要做数据计算, 挖掘产品商业价值, 首要解决的问题是数据的问题. 现实世界里, 数据往往是随着时间的推进连续产生的, 比如用户浏览商品, 一系列的鼠标点击操作, 会产生一连串的后台数据; 开车使用手机导航, GPS定位每隔一段时间更新一次, 也会不断产生日志数据; 用户浏览新闻推送, 搜索歌曲, 监控摄像头定时采集图片上传到云端存储, 视频直播等等场景, 这背后生成的数据都是连续产生的. 连续产生的业务数据, 又被实时采集起来, 就形成了数据流. 流式数据一经采集, 就可以立即参与计算, 同时将计算结果投入到业务应用中, 这就是实时计算. 实时数据计算其实早已经进入到人们生活的方方面面了, 比如天气预报, 以前人们的习惯是每天接收一次天气预报信息, 现在则可以实时查看天气预测, 同一个时间点的天气预测会随着时间的接近越来越准确, 这就是监测数据采集更新及实时数据计算带来的效果. 根据兴趣量身定制, 实时计算让产品越来越了解用户 实时数据来源越来越多, 数量越来越大, 每年的数据量都在成倍地增长, 这对实时计算本身是利好的, 可以有更多的应用场景, 更好的应用效果, 还可能促成一些革命性的变化. 那么, 大数据实时计算还能做什么? 在网易, 考拉海购双11, 618海淘盛典等活动期间, 都会有一块网易有数大屏幕实时展示当前最新的销售总额, 每个商品品类的销售比例, 订单增长趋势, 活跃用户地理位置等, 各种维度的信息都在一块屏幕上不断跳动. 每个用户每笔订单所产生的影响都会实时更新到大屏上. 这种可视化的实时应用效果, 除了增添一份电商狂欢节的氛围, 更易于发现数据价值, 指导市场运营, 辅助商业决策. 金融风控是另一种典型的实时计算应用场景. 对金融业务这种风险敏感的业务来说, 仅仅能把数据可视化是远远不够的, 它需要流计算系统能够利用一些风险模型的匹配规则, 去实时分析海量的用户行为数据, 发现异常事件, 判断风险等级, 并作出相应的风险控制措施, 自动化地去做报警通知, 改变业务流程. 通过实时计算做金融风控, 带来的好处是更快, 更准, 更广. 其他许多类似风控这样的事件驱动计算场景, 实时计算都能解决好. 实时计算在推荐领域的应用也已经很深入了. 不论是新闻推荐, 音乐推荐还是读书推荐, 基本都已经做到了千人千面, 每个人接收到的推送内容都是根据个人兴趣偏好量身定制的. 而用户的兴趣偏好, 往往是通过实时数据计算不断在更新的. 以新闻推送为例, 当用户点击一条条推送消息时, 背后产品其实时刻在对用户的行为做实时分析, 实时更新用户的兴趣偏好, 不断发现用户新的兴趣点, 对用户越来越了解, 最后给用户推送他更感兴趣的内容. 再以音乐推荐为例, 如果一个用户某段时间收藏了几首悲伤的歌曲, 通过实时数据分析, 系统可以识别出这一信息, 同时有针对性的推送一些歌曲去抚慰用户. 这种场景是只有实时计算才能解决的, 也最能体现实时计算的价值. 越来越多的实时计算场景会被开发出来, 未来人们对 '一切都在变化之中' 的感受会越来越深刻. 从 '先存后算' 到 '边算边存' , 实时计算不再怕 '大' 数据 实时计算这么好, 在实现层面应该怎么做, 有哪些困难和挑战是必须解决的? 首先从整体架构看, 数据计算, 无外乎三样东西: 数据输入→计算→数据输出. 传统的计算模型, 以数据库为例, 是先将数据存储在一个数据表中, 用户通过执行查询语句触发数据库的计算操作, 最后数据库完成计算后输出结果. 这种 '先存后算' 的模型在大数据实时计算场景下是行不通的. 我们所要计算的数据很 '大' , 一个计算结果所涉及的源数据可能是涵盖过往一天的数据, 可能是上千亿条数据记录. 如果每增加一些新数据, 都把所有数据都重新计算一遍, 这样的开销是非常大的, 最终的效果会是很 '慢' , 达不到实时的效果. 比较合理的做法是 '边算边存' , 意思是数据进入实时计算系统后, 不一定需要先存储起来, 可以直接参与计算, 而且这里的计算是把当前新增的数据在之前历史数据的计算结果上做 '增量计算' , 同一条数据不重复参与计算, 计算完成之后, 再把计算结果保存起来, 供业务使用, 这时数据存储的压力也小了很多. 同时 '大' 意味着数据并发很高, 每秒可能需要计算上千万条新数据, 这样的计算量不是单机能承受的, 所以大数据实时计算要解决好的是分布式系统架构下的一系列技术问题. 分布式实时计算面临的挑战包括很多方面. 数据从采集, 到计算, 到输出整个过程必须做到低延迟, 除了计算节点本身采用 '增量计算' 的模型, 还要求上游数据传输模块具有很高的吞吐能力, 并且具备数据缓存的能力, 在大流量场景下可以起到缓冲的作用, 下游输出模块也需要做数据压缩, 批量输出等优化, 以保证输出结果的实时性. 低延迟这个大前提对实时计算系统的其他特性提出了更高的要求. 比如双11凌晨0点的时候, 大量消费者在同一时刻下单支付, 这是涌进实时计算系统的瞬时数据量是巨大的, 系统需要有强大的并行处理数据的能力, 将大量瞬时流量合理分配到成百上千个计算节点, 并将这些节点的计算结果汇聚到一起计算出一个总体的结果, 在高吞吐的情况下仍保证低延迟. 从 '批量计算' 到 '增量计算' , 最具挑战的是准确性和易用性 和低延迟同样关键的挑战是准确性. '增量计算' 模型和传统 '批量计算' 模型是有区别的, 所以不能照搬过往的技术经验, 否则就会有准确性方面的问题. 需要考虑清楚新进入的数据如何叠加到老的计算结果上, 有些场景下甚至要支持从老的计算结果中撤除部分计算值, 以保证最终结果的准确性. 分布式系统中的某个节点出现故障是很常见的, 实时流计算系统的故障恢复能力也相当重要, 因为当故障发生时, 系统必须快速恢复, 否则系统的输出更新可能就停滞了, 实时性也就无从谈起. 同时故障发生也不能破坏 '增量计算' 这个模型, 否则退化到 '批量计算' 的模型就又得不到实时的计算结果了, 而且结果准确性也难以保证. 事实上网易大数据在实现自研流计算平台Sloth的过程中, 遇到并克服了上述技术难点. 网易流计算平台Sloth作为一个平台化的产品, 在产品易用性, 多租户隔离方面做了大量的工作. 就实时计算而言, 易用性是一个比较值得讨论的方面.  对于开发人员而言, 写一个分布式程序比写单机程序会困难一些, 而写一个分布式实时计算程序, 会更难. 好在业界有一些开源的流计算引擎帮助完成了不少工作, 开发人员可以使用这些流计算引擎完成流计算任务的开发, 他们可能不再需要关心计算任务如何分发到多个计算节点上, 数据在计算节点间如何传输等问题, 只需要专注于计算逻辑的开发, 控制好不同计算阶段的计算并行度. 以计算一篇文章的单词数为例, 一个分布式计算程序的内容可能包括三个部分, 首先是用几个计算节点共同把每一行文本拆分成一个一个的单词; 第二步是用另外一些计算节点去统计单词的个数 (考虑到数据量巨大的情况, 这里有必要用多个节点去做计算) ; 第三步是由一个计算节点把上游各各节点算出的部分计数汇聚成一个总的计数. 这样一个最简单的场景, 需要开发的代码量大约是200行. 实际业务场景下, 数据流经的计算节点远远不止3个, 计算类型也比基础的求和复杂很多, 所以即使有了流计算引擎, 分布式实时计算程序的开发仍然是比较困难的. 再进一步看, 即使开发完成了, 还需要把大量的时间投入到调试, 计算框架维护等方面, 一旦计算需求发生变化, 所有的工作都需要重新迭代一遍, 这是个比较痛苦的过程. 如何让流式计算程序更易编写, 是实时计算平台需要去完成的挑战. 且不考虑实时流计算系统如何解决易用性这个问题, 看下计算机科学发展过程中, 类似问题是怎么解决的. 人们希望编程可以容易一些, 所以越来越多的高级编程语言被发明出来了; 人们希望数据计算可以容易一些, 然后就有了数据库, 以及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引擎的自动优化也是当前主要的一个技术突破方向, 相信未来实时流计算会随着技术的进步, 应用得跟深入, 更广泛.
|
