实时_实时数据库 - CSDN
  • 实时个性化推荐介绍

    2020-04-21 00:21:15
    作者丨gongyouliu编辑丨gongyouliu这是作者的第32篇文章,约1.5w字,阅读需90分钟随着互联网的深入发展和产品布局的多元化,越来越多的企业通过提供快节奏的产品及服务消...

    作者丨gongyouliu

    编辑丨gongyouliu

    这是作者的第32篇文章,约1.5w字,阅读需90分钟

    随着互联网的深入发展和产品布局的多元化,越来越多的企业通过提供快节奏的产品及服务消耗用户的碎片化时间,从而赢得用户的青睐。这类产品通过便捷的UI交互来跟用户进行实时互动,在极短的时间内给用户“奖赏”,让用户欲罢不能,根本停不下来。这类产品普遍用到的一个技术就是实时个性化推荐技术。

     

    相比于传统的个性化推荐每天更新用户的推荐结果,实时推荐基于用户最近几秒的行为实时调整用户的推荐结果。实时推荐系统让用户当下的兴趣立刻反馈到了推荐结果的变化上,可以给用户所见即所得的视觉体验,它牢牢地抓住了用户的兴趣,让用户沉浸在其中。实时推荐技术大量用于现在的主流产品上,基本上你常用的互联网APP的核心推荐算法都已经实时化了,包括头条、淘宝、快手、B站等等,毫不夸张地说实时推荐是推荐系统未来的发展趋势。

     

    在本篇文章中,我们就来讲解实时个性化推荐相关的知识点。具体来说,我们会从实时推荐系统背景介绍、实时推荐系统的价值、实时推荐系统的应用场景、实时推荐系统的整体架构、实时推荐系统的技术选型、实时推荐算法与工程实现介绍、构建实时推荐系统面临的困难与挑战、实时推荐系统的未来发展等8个方面来进行讲解。期望本文可以帮助读者全方位地了解实时推荐系统相关的业务、原理与技术细节,本文可以作为读者学习和构建实时推荐系统的参考指南。

     

    一、实时推荐系统背景介绍

    所谓实时推荐系统,就是根据用户当前行为或者用户的主动操作(如下拉、滑动等),推荐系统实时更新展示给用户的推荐结果,前端快速反应用户的兴趣变化,给用户视觉上的冲击与强感知。大家比较熟悉的实时推荐系统是今日头条、抖音、快手上的推荐(参见下面图1),通过下拉或者上下滑动来实时更新推荐列表。如果实时推荐的结果采用瀑布流的形式呈现给用户,一般也将实时推荐称为信息流推荐,如今日头条推荐、微信朋友圈“看一看”等都可以这么叫。

           图1:今日头条、抖音、快手上的实时推荐 

     

    实时推荐系统不是一种新的推荐算法(当然会对算法进行适当的调整优化,以适应实时性的需要),而是一种新的推荐形态,一种新的工程架构,是将传统的T+1(按天)推荐调整为秒级推荐,是处理效率的极大提升。处理速度提升了,当然对算法、工程架构、交互方式也提出了新的要求。

     

    任何事情的出现和发展一定是有相关背景的,实时推荐也不例外,我认为主要有如下几个原因导致实时推荐的出现和火爆:

     

    1. 技术的进步

    首先是智能手机的普及和摄像技术、无线网络的发展,让每个人都成为数据生产方,我们时时刻刻都在制造数据。数据量的爆发增长,推动了大数据与云计算技术的出现和发展。大数据和云计算让我们可以更快、更便捷、更高效地处理大规模的海量数据,实时数据处理成为可能,这是实时推荐系统出现的先决条件。

     

    2. 产品的“快消”化、用户时间的碎片化

    新技术本身就是一种资源,所以一般一种新技术出现会带来非常大的红利期,出现一段较长时间的技术应用爆发期。在新红利的刺激下,越来越多的创业者寻找机会和突破,期望从红利中分一杯羹。技术催化了各种各样的产品,像头条、快手、抖音等无不都是在这样的背景下产生的。这类产品有一个特点,属于“快消类”产品(用户消费一个标的物所花时间较短),消费的也是用户的碎片化时间,用户在地铁上、公交上、吃饭排队、甚至上厕所都可以高效使用这类产品。产品的“快消”化、用户时间的碎片化,这要求产品需要实时响应用户的需求,对用户的行为作出及时反馈,这正是实时推荐系统擅长的方向,因而实时推荐最早在这些产品上出现就不足为奇了。

     

    3. 人机交互方式的便捷性

    触屏技术的发展,让用户与产品交互更加方便快捷,交互可以在瞬间完成,毫无障碍,无任何学习成本。快捷的交互自然要求产品可以进行快速的响应,这也间接催生了实时推荐技术的普及和发展。

     

    4. 人天生喜欢动态变化的东西、人的需求也越来越主动

    移动互联网时代,用户每时每刻都在线。人的大脑是无法停下来的(即使是睡着了,也在做梦,大脑也没停),一定要注意到一件事情,这就是人的注意力,静止不变的东西是很难吸引用户兴趣的,实时推荐对用户反馈做实时调整,是动态变化的过程,更容易吸引用户的关注。年轻一代更希望对生活有控制权,对产品也一样,希望自己可以把控产品的交互逻辑和结果展示,实时个性化推荐的这种下拉更新推荐结果的方式就很自然地将控制权交给了用户。

     

    5. 信息产生的速度更加快速

    前面提到摄像头技术的发展等让信息产生的速度按照指数方式增长,信息产生的速度远大于人类消费信息的速度。而实时推荐提升了信息分发的效率,可以让信息得到更加有效的分发与利用,因此也是提升资源使用效率的一种方式。

     

    6. 激烈的产品竞争

    当移动互联网红利结束之时,没有太多新的流量注入,所有的产品在争夺固有的流量,产品之间的竞争愈发激烈,谁能更好地服务用户,谁就能在激烈的市场竞争中赢得主动权。实时个性化推荐由于跟用户的实时互动性,可以更好地满足用户的需求,让用户沉浸在其中,因此可以极大地提升用户的体验,这让实时推荐技术成为产品争夺用户和流量的有力武器。

     

     

    实时推荐是技术发展和产品迭代的必然趋势,也是人类自身诉求满足的有效方式,这只是实时推荐技术出现和发展的必要条件。实时推荐之所以这么火爆,成为当今绝大多数产品的标配,并且也是推荐系统未来发展的趋势,是因为实时推荐系统极具价值。实时推荐是非常有业务价值的,这就是我们下节要讲解的内容。

     

    二、实时推荐系统的价值

    实时推荐系统通过降低用户的行为和系统的反馈之间的时间间隔,让用户可以马上享受到自我行为的奖赏,这本身就是一种用户价值的体现。具体来说,实时推荐系统的价值至少可以从如下4个维度来体现。

     

    1. 提升用户体验,提升用户的满意度

    在实时推荐系统中,用户可以实时与推荐模块交互,推荐模型实时给用户做出反馈,提升了用户与产品交互的频率。用户的每次交互都带来了新的刺激,这让用户更愿意沉浸在其中,从而满足了用户的某种心理需求,而用户需求满足的程度决定了用户对产品的满意度。因此,实时个性化推荐一定是可以提升用户满意度的。

     

    2. 提升用户粘性,提升用户使用时长

    从产品来看,实时推荐可以让用户实时获得反馈,用户的需求得到即刻的满足,这让用户非常兴奋,停不下来,不知不觉中花了大把的时间,消费了大量的内容。总体来说,提升了用户的粘性,让用户更愿意驻留更多的时间。

     

    3. 增加内容的曝光、分发与消费

    实时个性化推荐大大提升了内容的流转效率,可以更快地将内容分发到每个用户手中,直观地呈现在用户眼前,内容不再是沉入信息海洋的石块,而是高效流转的“宝藏”。分发效率的提升,让内容制作方可以得到更多的曝光,获得更多用户的关注。更多的曝光和更多的粉丝,当然可以通过变现产生不菲的商业收入。

     

    4. 增加产品的商业化能力

    实时推荐增加了内容的曝光机会,提升了标的物的流转效率,让单个推荐位的点击和转化大大提升。好的实时推荐能够抓住用户的眼球,让用户沉浸其中,提升了用户购买商品(如果是电商实时推荐)的概率。即使是今日头条这类提供非卖品标的物的产品,实时推荐中还可以整合信息流广告,让更多的广告得到曝光,从而增加广告的CPM,这也是一种价值变现的好方式。

     

    正因为实时推荐的巨大价值,让当今的互联网产品开发者非常心动,期望在自己的产品中整合实时推荐功能。那么实时推荐可以用到哪些产品中呢?这就是下节要分享的主要内容。

     

    三、实时推荐系统的应用场景

    实时推荐系统根据用户的当下行为作出快速反馈,给用户提供所见即所得的推荐,这一般也要求用户的行为是可以在短期内完成的,即用户”消费“一个标的物不会花很长时间。推荐系统需要在短期内就知道用户是否对该标的物感兴趣,才能基于用户行为给用户实时反馈。

     

    基于上面的分析,我认为“内容”消费完所花时间较短,用户希望短时间获取信息的产品比较适合实时推荐,即提供“快消“类标的物的产品是比较适合做实时推荐的,而像长视频、小说阅读等APP是不太适合做实时推荐的。拿电影来说,用户看完一个电影需要花费2个小时左右,很大概率用户没有时间再接着去看另一部喜欢的。如果该电影用户看了几分钟就退出来了,这顶多算负反馈,没有正反馈(用户看完了或者看了很长时间),我们也没法给用户实时推荐他喜欢的,这也是这类产品不太适合做实时推荐的原因。

     

    前面已经提到长视频类、小说阅读类不适合做实时推荐。下面我们来列举一下适合做实时推荐的常用产品形态,给读者提供一个参考。适合做实时推荐的产品主要包括如下6大类别:

     

    1. 新闻资讯类

    用户阅读一条文本新闻时间一般不会很长,几分钟就够了,因此是满足做实时推荐条件的。如今日头条、腾讯新闻、网易新闻、趣头条、手机百度APP信息流等等都提供了实时推荐的能力。

           图2:今日头条、网易新闻、手机百度APP通过下拉滑动为用户提供实时个性化新闻推荐

     

    2. 短视频类

    短视频也是一类时长较短的产品,满足“快消”产品的特性,因此是实时推荐非常好的应用场景,目前主流的短视频应用,如快手、抖音、好看视频、哔哩哔哩等都提供了实时推荐形态。

           图3:快手、抖音、B站首页通过下拉滑动为用户提供实时个性化推荐

     

    3. 婚恋、陌生人社交类

    对于婚恋、陌生人交友类软件,用户只要对陌生人的长相或者相关简介有个基本了解就可以决定要不要聊下去,决策时间不需要很长,因此是适合做实时推荐的。像世纪佳缘、陌陌、探探等都提供了实时推荐能力。

           

    图4:陌陌、世纪佳缘、探探上下滑动或者通过左右滑动来选择感兴趣的人

     

    4. 直播类

    直播类虽然播放时长会很长(很多主播一次性可能直播几个小时),但用户只要进去看几分钟就可以知道是不是自己喜欢的类型了,因此直播类也是适合实时推荐的,像斗鱼、虎牙、映客等在首页就包含实时推荐模块。

            图5:斗鱼、虎牙、映客首页通过下拉滑动为用户提供实时个性化推荐

     

    5. 电商类

    电商类APP,如手机淘宝、京东、拼多多,首页都提供了实时推荐的能力,用户只要下拉刷新,系统会自动刷新给你的推荐结果。一般用户决定是否要买一个商品也不需要投入很多的时间决策,看下图片和详情页简介就知道了。因此,电商类产品是适合做实时推荐的。

           

    图6:淘宝、京东、拼多多首页通过下拉滑动为用户提供实时个性化推荐

     

    6. 音乐、电台类

    音乐类、电台类APP,用户消费一首歌也就几分钟,也是满足实时推荐场景的,下面这3个APP都提供了实时推荐的能力。

            

    图7:喜马拉雅、酷狗音乐、豆瓣FM上的实时个性化推荐

     

    我们在上面基本列举了市面上主流的提供了实时推荐能力的APP,这些APP都满足我们前面提到的可以做实时推荐的条件。当然这个条件不是绝对的,需要根据具体的应用场景和限制条件再综合分析。我们电视猫上在首页就提供了长视频的近实时推荐,电视猫的产品应用于家庭场景中,家中一般多人使用,用户平均使用时长比手机长得多,操作主要靠遥控器,操作相对手机端极为不便,并且用户可以一键(返回键)回到首页,这些条件导致首页暴露给用户是比较频繁的。因此,基于上面几个特点,我们在首页提供近实时反馈的兴趣推荐,只要用户看过某些视频时长达到一定值(我们认为用户喜欢)就更新兴趣推荐。

           

    图8:电视猫首页近实时反馈的兴趣推荐模块

     

    这里最后还要提一点,即使你的产品适合做实时推荐,实时推荐产品一定要放到首页这种用户触点多的位置,不然很难最大化发挥个性化推荐的价值。想象一下,你将实时个性化推荐产品安放到一个非常隐蔽的地方,用户很难找到,即使你推荐的再准有什么用呢?好的东西就是要让用户多使用,用户的反馈就是推荐模型的数据源,用户和产品互动的过程是一个正向的反馈环,交互越多,收集的数据就越多,基于这些数据训练出的推荐模型就越精准,通过用户与(实时推荐)产品的协同进化,推荐会越来越有商业价值。

    四、实时推荐系统的整体架构

    实时推荐系统需要基于用户的实时反馈行为来近实时更新用户的推荐结果,因此需要对推荐算法进行实时调整,实时数据处理与实时建模一定是实时推荐系统中最重要的一种技术。当前,推荐系统一般应用于提供toC服务的互联网产品中,这类产品用户基数大,数据量多,一般需要大数据平台来进行处理,对数据进行ETL、构建模型特征,我们这里讲解的实时推荐系统的整体架构是建立在大数据技术基础上的。

     

    在大数据的发展史上先后出现了两种数据处理的架构,这两种架构刚好也是实时推荐系统算法构建的原型,下面我们分别对这两种架构进行介绍,并说明怎么基于这两种架构来构建实时推荐系统。

     

    1. Lambda架构

    当前的主流大数据平台一般将用户行为日志分为离线部分和实时部分(参见下图)。离线部分进入数仓供离线任务进行处理,包括各种按天统计的报表、T+1的推荐业务(非实时推荐,一般每天更新一次)。实时部分一般进入消息队列(如Kafka),供实时处理程序消费,如各类实时监控、大屏展示报表等。

           图9:主流大数据平台将日志分别通过批和流两种逻辑进行分发,供不同业务处理

     

    Lambda架构(见参考文献1)就是上面这种思路的高度抽象,它是著名的流式处理框架Storm的作者Nathan Marz最先提出来的。Lambda架构一般分为3个模块:Batch Layer、Speed Layer、Serving Layer,Batch Layer负责处理离线的大规模数据,Speed Layer负责处理实时收集到的用户行为数据,而Serving Layer将离线和实时两部分结果基于一定的规则或算法进行汇集、排序,并最终对用户(既可以是终端用户也可以是公司内部的其他业务部门)提供服务,下图即是Lambda架构的抽象业务处理逻辑。

           图10:Lambda架构示意图

     

    一般用户行为数据从底层的数据源开始,按照一定的数据规范和协议(比如采用Json格式)进入大数据平台,在大数据平台中经过Kafka、Logstash等数据组件进行收集,然后分成两条线进行计算。一条线是进入流式计算平台(例如 Storm、Flink或者Spark Streaming),计算一些实时指标或训练实时模型;另一条线进入批量数据处理离线计算平台(例如Map Reduce、Hive,Spark SQL等),计算T+1的相关业务指标或者训练离线模型,这些指标或者模型(结果)需要第二天才能算出。

    Lambda架构历经多年发展,其优点是稳定,对于实时计算部分的计算成本可控,批量处理可以用晚上的时间来整体规划。将实时计算和离线计算高峰分开,可以极大化利用服务器资源,减少对用户的影响,这种架构支撑了数据行业的早期发展,但是它也有一些缺点,这些缺点导致Lambda架构不适应部分数据分析业务的需求,具体缺点如下:

    • 实时与批量计算结果不一致引起的数据口径问题:因为批量和实时计算走的是两套计算框架,使用的是不同的计算程序,算出的结果往往不同,特别是对于那些累积的指标,时间长了容易产生误差。因此,需要一套完善的机制来保证计算的一致性,纠正数据偏差。

    • 批量计算在计算窗口内存在无法算完的风险:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口用于离线计算,已经无法完成白天20多个小时累计的数据计算。怎么保证早上上班前准时出数据报表已成为大数据团队头疼的问题。集群之间不同作业之间的依赖关系及资源占用等更加剧了这种情况的发生。

    • 数据源变化都要重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都需要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不够迅速。

    • 服务器存储大:数据仓库的典型设计,会产生大量的中间结果表,造成数据急速膨胀,加大了服务器存储压力。

     

    上面对Lambda架构进行了初略的介绍,那么下面我们来讲解怎么基于Lambda架构来构建实时个性化推荐系统,我们先给出架构图(见下面图11),这里包含离线算法模块(对应Lambda架构中的Batch Layer)、实时算法模块(对应Lambda架构中的Speed Layer)、融合模块(是Lambda架构中Serving Layer抽取出来的一部分,对于推荐算法来说,它比一般的数据处理更复杂,为了减轻Serving层的压力,将复杂的与业务逻辑相关的计算操作独立出来形成一个单独的模块),下面我们来逐一说明各个模块的作用。

           图11:基于Lambda架构的实时个性化推荐算法架构

     

    • 离线算法模块

    离线算法模块基于用户长期行为数据训练召回模型和排序模型,最终生成离线推荐结果。离线部分由于使用的是历史数据,每天更新一次,模型可以较复杂,只要在一天之内计算完成即可,最终算出的是基于用户历史兴趣的推荐结果。

     

    • 实时算法模块

    实时算法模块基于用户最近的兴趣来获得给用户的推荐,比如可以基于用户最近一次操作的标的物,召回与该标的物最相似的标的物作为召回结果,后面可以基于用户整体兴趣对召回的标的物进行排序,获得用户的近实时推荐结果。

     

    • 融合模块

    融合模块基于给用户的离线推荐结果和实时推荐结果,通过利用合适的业务规则、策略以及复杂的排序算法对推荐结果进行排序,获得给用户的最终推荐。

     

    混合模块的具体实现方式可以多种多样,上面提到的是其中的一种,还可以基于生成的离线推荐结果,实时推荐基于近期兴趣读取并更新离线推荐结果获得最终的推荐。在电视猫中部分实时推荐就是采用的该方式:离线推荐结果插入CouchBase推荐库,实时推荐程序获得用户最后播放记录的相似视频,然后从CouchBase中读取该用户的推荐结果,将刚刚计算好的相似视频(基于一定规则)替换掉取出的推荐结果的部分视频,再插入CouchBase,从而修改了推荐结果,获得实时推荐的效果。

     

    对于业务规则比较简单的情况,可以将融合模块放到Web Server中(见下面图12),整体架构跟上面介绍的类似,只不过这里事先计算出离线推荐和实时推荐结果,最终在Web Server中对两类推荐结果进行聚合,而上面介绍的是将集合过程独立出来成为一个子模块。

           图12:在web server中进行融合的实时推荐业务架构图

     

    上述方法还可以进行适当的改进,就是首选利用历史数据训练好召回和排序模型,按照上面架构部署,等推荐业务跑起来后,直接就接入实时数据流,不需要再处理历史数据了(因为模型已经基于历史数据进行了训练),在实时流运行的过程中可以逐步迭代优化召回和排序模型。这里需要对模型进行实时学习更新,我们将这种学习过程称为增量学习。增量学习利用了最新的用户行为数据,一般可以稳定提升模型性能。在生产实践中,增量学习根据增量的时效性有三种不同粒度,其中T+1增量模式是,load已有模型的checkpoint,采用批训练模式,模型全量部署上线,更新时效性为天级别,小时级增量模式是,使用实时样本进行流式训练,但部署过程依旧采用全量模型切换,更新时效性为小时级。第三种(也是最完美的)增量学习解决方案是流式训练模型、实时用于模型预测,这种方案就不用离线模块了,这就是我们下面要讲到的Kappa架构了。

     

    Lambda架构采用分而治之的思路通过将用户行为分为离线部分和实时部分,分别进行处理和建模,最终再汇聚两部分的信息获得最终的结果。对于当前的实时推荐,Lambda架构是一种可行有效的实施方案。结合前面介绍的Lambda架构的缺点及作者自己实施实时推荐的经验,对于实时推荐系统,Lambda架构最大的问题主要有如下三点:

    • 实时处理和离线处理是不同的技术,实现离线推荐和实时推荐的模块需要采用不同的代码来实现,开发和维护成本明显偏高。

    • 在衔接实时推荐和离线推荐时,会存在信息的冗余或者缺失。离线推荐处理的数据到今天零点,而最理想的状态是实时从零点开始对当前所有的用户信息进行处理和建模,而在具体实施时,有各种问题、限制导致数据的衔接存在断档或者重复使用的情况。

    • 在最终给用户推荐时,需要融合实时推荐结果和离线推荐结果,进一步增加了流程和复杂度。

    鉴于上述问题,我们可以采用一套统一的处理架构,这就是下面我们要介绍的Kappa架构。

     

    2. Kappa架构

    Kappa 架构是LinkedIn的Jay Kreps结合实际经验和个人体会,针对Lambda架构进行深度剖析,分析其优缺点并采用的替代方案(读者可以查看参考文献2,对Kappa架构进行更深入了解)。Lambda 架构的一个很明显的问题是需要维护两套分别跑在批处理和实时计算系统上面的代码,而且这两套代码需要紧密配合,对增量求和统计还得产出一样的结果。因此对于设计这类系统的人来讲,要面对的问题是:为什么我们不能改进流计算系统让它能处理这些问题?为什么不能让流系统来解决数据全量处理的问题?流计算天然的分布式特性注定其扩展性比较好,能否加大并发量来处理海量的历史数据?基于种种问题的考虑,Jay提出了Kappa这种替代方案。

     

    Kappa架构通过剔除Lambda架构中的批处理部分简化了Lambda架构。为了取代批量处理,数据只需通过流式计算系统快速加工处理。Kappa体系结构中的规范数据存储不是使用类似于SQL的关系数据库或类似于Cassandra的键值存储,而是一个只能追加数据的不可变日志系统。从日志中,数据通过计算系统流式传输,并输入辅助存储器作为字典库供服务使用。典型的Kappa架构如下图:

           图13:Kappa架构

     

    Kappa架构的核心思想,包括以下三点:

    • 用Kafka或者类似MQ队列系统收集各种各样的数据,你需要几天的数据量就保存几天到消息队列中。

    • 当需要全量重新计算时,重新起一个流计算实例,从头开始读取数据进行处理,并输出到一个新的结果存储中。

    • 如果需要对业务流程和计算逻辑调整,重启一个新的计算实例,当新的实例做完后,停止老的流计算实例,并把老的一些结果删除。

    Kappa架构的优点在于将实时和离线代码统一起来,方便维护而且统一了数据口径的问题。而Kappa的缺点也很明显:

    • 流式处理对于历史数据的高吞吐量力不从心:所有的数据都通过流式计算,即便通过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。

    • 开发周期长:在Kappa架构下由于采集的数据格式的不统一,在对数据进行调整或兼容时每次都需要开发不同的Streaming程序,导致开发周期长。

    • 服务器成本浪费:Kappa架构的核心实现需要依赖外部高性能存储Redis、HBase等服务作为中间存储器。但是这2种系统组件,又并非专门设计来满足全量数据存储的,会占用较多的内存及CPU资源,对服务器成本有较大浪费。

     

    上面我们对Kappa架构进行了简单介绍,那么基于Kappa架构怎么构建推荐系统呢?其实这个问题是比较简单的,Kappa架构简化了Lambda架构,只保留了实时处理部分,针对推荐系统也是一样的。Kappa架构构建推荐系统只做实时推荐部分,具体架构图见下面图14。

           图14:基于Kappa架构的实时个性化推荐算法架构

     

    按照上面架构部署好推荐业务,算法在刚刚启动时,先将所有离线数据一次性按照实时流的方式灌入,逐步在线学习召回和排序模型,等历史数据处理好了,就直接处理流式数据了,最终变成了流式处理。这里需要强调的一点是,召回和排序模型是一个逐步学习和训练的过程,这对模型是有一定要求的,有些模型是不适合这样训练的。我们在电视猫的业务中对短视频的实时相似推荐就采用了这种模式,由于我们计算相似度是基于标签来计算的,就是简单的向量相似度计算,模型不复杂是可以采用上面的方法的。读者可以参考《基于Erlang语言的视频相似推荐系统》和《基于标签的实时短视频推荐系统》这两篇文章中的思路。

     

    另外一种方式是模型训练好,直接部署上去,根据用户最近的行为实时构建最新的特征向量,将新特征向量灌入模型,获得新的推荐。为了利用最新的数据,模型还可以隔一段时间重新训练一次。TensorFlow Serving就是采用的该模式,并且模型可以热更新,这类模型一般也是比较复杂的模型,如深度学习模型等。这里不是从零开始学习模型,而是预训练让模型有一个很高的起点,再从起点开始学习。训练模型的过程中也用到了离线技术,因此模糊了跟Lambda架构的关系。

     

    目前强化学习(强化学习是智能体(Agent)以“试错”的方式进行学习,通过与环境进行交互获得的奖赏指导行为,目标是使智能体获得最大的奖赏)在大的互联网公司已经部分用在推荐业务中(见参考文献10),强化学习这种跟环境进行实时交互的学习范式本质上就是Kappa架构。

     

     

    上面我们讲到的实时推荐的Lambda架构和Kappa架构都是采用了事先将推荐结果计算出来的方式,这属于事先计算型,实际上也是可以采用实时装配型的,对这两种推荐系统提供web服务的方式,读者可以参考《推荐系统提供web服务的2种方式》这篇文章进行详细了解,这里不赘述。

     

    上面我们对当前主流的两种实时推荐架构进行了说明,并没有讲相关的具体工程技术,我们在下一节对相关技术进行介绍。

     

    五、实时推荐系统的技术选型

    实时推荐系统与实时大数据处理密不可分,因此构建实时推荐系统的技术一定是离不开实时大数据技术的,目前比较主流的实时大数据处理框架主要有Spark Streaming, Flink 、Storm等,这些框架都可以用于做实时推荐。基于实时推荐的两种实现架构Lambda和Kappa,这里会涉及到离线处理和实时处理(Lambda有离线处理模块而Kappa没有,不过Kappa中涉及到的模型也会进行离线训练),下面我们分别从离线处理和实时处理的技术选型来分别介绍。

     

    1. 离线部分算法的技术选型

    离线部分可以选择的工业级技术有Spark、MapReduce、TensorFlow等。MapReduce由于对迭代运算不是很友好,不太适合复杂的机器学习模型,建议还是采用Spark和TensorFlow。

     

    Spark中包含很多数据ETL算子和算法库,很多算法可以直接使用,Spark MLlib中直接有ALS矩阵分解推荐算法,其他推荐算法也可以基于Spark的API自行开发。针对复杂的深度学习算法目前是不太适合在Spark上运行的,Spark的新版本3.0应该会增加对深度学习更好的支持。

     

    TensorFlow可以实现非常多的复杂算法,在工业界也非常流行。不过TensorFlow的分布式计算没有Spark这么友好。一般企业是基于Hadoop/Spark来构建大数据平台的,如果利用TensorFlow来实现部分算法的话,是需要打通大数据与TensorFlow两套体系的。

     

    基于上面的分析,作者建议如果在人力不足或者不是非用TensorFlow不可的情况下,还是采用Spark平台更合适,大数据和推荐两套业务共用了一套架构体系,技术栈更加统一简单。

     

    2. 实时部分算法的技术选型

    实时部分可以采用的技术非常多,常见的有Storm、Flink、Spark Streaming等。目前Storm没有以前那么流行了,建议还是采用Flink和Spark Streaming这两套中的一种。如果你们团队已经在使用Spark了,开始做实时处理或者实时推荐业务,那最好还是用Spark Streaming,毕竟都是Spark一套体系,API规范都保持一致,技术栈也更统一。Spark Streaming虽然实时性方面不如Flink,但是对于实时推荐来说,做到秒级实时就足够了。

     

     

    作者公司最早是基于Hadoop/Spark体系来构建大数据的,顺其自然地推荐系统也是基于Spark来构建的,最近几年开始做实时推荐,也是采用Spark Streaming框架,目前看下来,整套框架都可以很好地处理离线推荐、实时推荐等各类推荐场景。

     

    这些框架目前在云计算公司都有现成的PAAS或者SAAS服务可供选择,对于初创团队或者刚开始启动推荐业务的团队,建议可以采买相关云服务,这样整个系统更加轻量,维护成本低,团队应该将核心放到业务和算法上。

     

    六、实时推荐算法与工程实现介绍

    在第四第五节我们介绍了实时推荐系统的架构和技术选型,有了这些基础准备我们就能够非常方便地开发实时推荐算法了。推荐算法是推荐系统中最核心的组件之一,在本节我们就来讲讲有哪些可以用于实时推荐的算法。这里我们讲的实时推荐算法是指可以利用流数据来训练,可以进行在线学习的推荐算法,而不关注Lambda架构中离线部分的推荐算法。

     

    我们在前面的推荐算法系列文章中部分讲解了实时推荐算法的工程实现,这里将相关资源列举出来,读者可以进行有针对性地学习和了解。

     

    1. 实时协同过滤算法

    协同过滤推荐算法》第四节“近实时协同过滤算法的工程实现”对实时协同过滤算法进行了详细讲解,这里采用的是利用Spark Streaming和HBase作为算法实现和存储的工具。

     

    2. 实时矩阵分解算法

    矩阵分解推荐算法》第五节“近实时矩阵分解算法”对腾讯在2016年发表的一篇基于Storm来实现的近实时矩阵分解的算法原理及工程实现细节进行了介绍。

     

    3. 实时因子分解机

    因子分解机》第六节“近实时分解机”有对分解机实时实现的简单介绍,其中给了很多参考文献,可以作为读者学习的参考资料。

     

    4. 基于内容推荐的实时算法

    基于内容的推荐,不需要其他用户的行为,只需学习到待推荐用户的兴趣偏好特征就可以给用户进行推荐了,相比协同过滤类算法更简单更容易实现,因此也是非常适合做实时推荐的。作者在《基于Erlang语言的视频相似推荐系统》和《基于标签的实时短视频推荐系统》这两篇文章中基于电视猫的视频推荐场景分别对标的物关联标的物推荐、完全个性化推荐这两种推荐范式的实时实现进行了详细介绍,读者可以参考学习具体的实习思路,这两篇文章都是基于内容的推荐算法的实时化。

     

     

    业界比较出名的在线学习算FTRL(Google最早提出,见参考文献6),可以实时训练很多机器学习算法(如logistic回归),可以与推荐系统的排序阶段。当前比较热门的深度学习技术也可以进行在线学习,读者可以阅读参考文献4、5进行了解。在工业界,蚂蚁金服的AI团队对TensorFlow的底层架构进行了修改优化(见参考文献9),使之适应实时学习,并在支付宝的推荐业务中得到了很好的应用。

     

    参考文献7、8分别介绍了凤凰新闻和爱奇艺的实时推荐的工程实现细节,读者可以参考。另外参考文献3比较详细介绍了Netflix的推荐系统的工程实现介绍,其中也包括实时实现部分,采用的是Lambda架构的模式。Netflix推荐系统是业界做得非常好的典范,值得读者深入了解。从这篇参考文献也可以看到要做好实时推荐系统是非常复杂的,需要面临非常多的技术、工程挑战,在下一节我们就会对这方面进行详细介绍。

     

    七、构建实时推荐系统面临的困难和挑战

    实时推荐系统需要实时处理用户行为,并基于用户行为给用户提供近实时的推荐,时间上的及时响应,对整个推荐系统的架构、算法都提出了极高的要求。设计实时推荐系统面临的挑战主要体现在如下几个方面:

    1. 算法架构

    实时推荐系统需要实时收集用户行为,对用户行为进行实时ETL处理,实时挖掘用户兴趣变化,实时训练模型,实时更新推荐结果。对数据分析处理、数据存储、接口访问等需要提供基础能力支撑。整个推荐过程是一个相当长的链路,每一个环节都不能出错,对数据处理和分析响应的及时性要求极高。

    2. 算法模型

    对于在线学习类的推荐算法模型,构建实时推荐系统还需要模型层面的支持,不管是召回还是排序,都需要能够兼容实时数据,能够实时训练。传统的算法是不满足条件的,比如Logistic回归就不适合用于实时训练,它通过改进后的FTRL是可以进行实时训练的。

    3. 产品交互

    实时推荐的结果需要以用户易于理解和操作的方式展现给用户,因此需要设计一个良好的产品交互界面,让用户易于理解,易于操作,更好地感受到个性化推荐带来的价值。像今日头条首创的下拉的交互产品形态就是比较好的一种实时交互形态,用户完全掌握主动权,不喜欢就滑一滑获得新的一批推荐。

     

     

    总之,实时推荐系统是一个复杂的体系工程,我们需要在算法架构、算法模型、产品交互等多个方面做得出色才能打造出一个用户体验好、有商业价值的实时推荐系统。

    八、实时推荐系统的未来发展

    前面对实时推荐相关的产品、架构、算法等进行了深入的介绍,我们知道了实时推荐的价值和面临的挑战。很多公司的推荐产品也进行了实时化改造,充分享受到了实时推荐给产品带来的红利。实时推荐是随着移动互联网的起步和发展逐步发展成熟起来的,历史不超过10年,未来实时推荐还有很大的发展空间。在本节作者基于自己的理解来对实时推荐的未来发展进行一些预判和思考,希望给读者提供一些参考和借鉴。

     

    1. 实时推荐是未来推荐发展的方向

    实时推荐可以跟用户进行更加及时、高效地互动,有利于用户更好地使用产品,用户体验也更加真实自然,因此相比传统的T+1推荐系统更具商业价值。未来越来越多的企业会意识到实时推荐的价值,实时推荐一定是未来推荐系统发展的重点方向之一。

     

    随着网络基础设施在世界更广泛的范围覆盖,越来越多的人会享受到信息技术带来的红利,实时推荐系统也会覆盖到更多的人群。5G技术的发展,让人们获取信息更加方便及时,复杂的多媒体信息也可以在瞬间完成下载和上传,云计算、AI技术的发展可以让更多的复杂高效算法应用于实时推荐,这些基础技术条件的成熟驱动着实时推荐朝着更流行、更普及、更精准的方向发展。

     

    另外,社会的发展也让人类趋向于越来越个性化,人们期望更好地表达自我、满足自我,实时推荐可以让用户获得主动权和控制权,获得更加及时的反馈。信息的生产也将更加实时、多样、庞杂,这些信息的分发和消费问题都可以利用实时推荐来很好地解决。

     

    2. 每个人有望拥有为自己服务的个性化算法

    目前所有的实时推荐算法都是在云端部署,终端通过跟云端交互获得个性化推荐,这种方式会受到网络等多种外界因素的影响,对于及时跟用户交互是有一定副作用的。随着芯片技术和AI技术的进步,目前边缘计算是非常火的一个领域,边缘计算是在终端上直接完成计算,尽量不与或者少与云端交互,这极大地提升了处理的效率,受到网络等其他因素的影响也会更少,像无人驾驶这类技术的成熟是非常依赖边缘计算技术的进步的。

     

    对于实时推荐系统,在云端实时处理庞大海量的用户信息为用户进行推荐已经非常费力,在终端完成这个事情是一种比较有创意的想法。具体的做法可以是先在云端基于全量数据离线训练一个复杂的模型,并将该模型同步到终端,终端基于该模型和用户的实时交互信息,实时优化该模型,让该模型跟着用户的行为一起进化,最终越来越适配用户的兴趣特征。

             图15:在终端上增量学习模型,为用户提供更加个性化的实时推荐

     

    上面这种部署实时推荐算法的方式,更容易做到实时化,不受网络因素的影响,同时模型也是为用户量身打造的,更满足用户口味。当然,这对终端性能、存储能力、模型实时训练等提出了很高的要求但不可否认,这一定是一个值得尝试的,有巨大应用价值的方向。TensorFlow Lite已经朝着这个方向迈进了一大步,TensorFlow Lite 允许用户在多种设备上运行 TensorFlow 模型。在数据库方面,CouchBase也提供了CochBase Mobile解决方案,让移动端的数据存储跟云端可以做到实时联动。

     

    基于上面的介绍,我是非常看好实时推荐在终端上的部署的,虽然目前在业界没有成熟的终端推荐解决方案,但我相信那些有前瞻性思维的公司一定是在朝着这个方向尝试的。

     

    3. 实时推荐应用场景的多样性

    目前实时推荐系统主要应用于移动端,随着物联网和智能家居的发展,更多的智能终端产品如雨后春笋般出现,实时推荐系统一定会落地到更多的产品、应用到更多的场景中。

     

    我们公司的产品电视猫应该是业界比较早将实时推荐系统应用于家庭大屏中的,目前在短视频、首页长视频推荐都做到了实时化,并产生了巨大的业务价值。智能电视上的实时推荐应用目前只是起步阶段,当华为、OPPO等大厂入局家庭大屏,一定会带来更多的新应用,这时实时推荐就会蓬勃发展起来。

     

    在智能音箱、车载系统上,由于交互方式的变化(这些系统一般用语音进行交互),对产品形态有极大影响,目前作者还没有看到在这些硬件上有相关的智能推荐形态出现。由于交互方式的限制以及可能没有屏幕,这些硬件上如果有推荐形态,那也一定会采用实时推荐的模式。

     

    4. 实时交互方式趋于多元化

    目前移动屏上的实时推荐产品,用户都是通过滑动触摸的方式跟推荐系统交互的,这种交互方式是非常自然方便的,正因为方便的交互才让实时推荐有如此大的爆发力。

     

    在智能电视上的交互目前主要靠遥控器,作者在电视猫上部署的实时兴趣推荐(参见第三节的图8),由于是长视频推荐及遥控器交互的限制,目前没有直接的用户交互,当用户看一个节目再返回到兴趣推荐模块时,系统会自动更新推荐结果。而我们部署的短视频信息流推荐采用的是无限右滑的交互方式(见下面图16)。

           图16:电视猫音乐信息流推荐采用遥控器无限右滑的方式与用户进行交互

     

    前面提到的在智能音箱和车载软件上,用户的交互方式是语音交互,利用语音交互怎么进行个性化推荐,目前没有相关的产品形态出现,这值得大家来思考和探索。

     

    当然,随着VR/AR/MR等虚拟现实、增强现实技术的成熟和产品形态的完善,在这些智能设备上的实时推荐可以采用更多的交互方式,比如语音、手势、甚至表情、眼动、思维意识控制等。这些是更加遥远和值得期待的事情了。

    总结

    作者在这篇文章中对实时个性化推荐系统进行了全面的介绍。我们了解了实时推荐系统产生的背景,在社会发展、技术进步、交互便捷、信息爆炸、时间碎片化、激烈的市场竞争等多种因素的驱使下,实时推荐系统的出现是必然的现象。

     

    实时推荐系统相比传统的T+1推荐,可以更好地满足用户的诉求,让用户掌握更多的控制权,可以极大地提升用户体验,让用户沉浸其中,这也带来了极大的商业价值,因此实时推荐系统在各种移动产品中遍地开花,成为主流的推荐产品形态。

     

    实时推荐系统由于要对信息进行实时处理,对技术架构、工程体系、算法实现等多个方面提出了更高的要求,需要算法工程师采用创新的方式来实现,本文也对相关的架构和算法进行了比较全面的归纳和讲解。

     

    基于实时推荐系统的用户价值和商业价值,在5G技术、物联网、AI等多种技术的发展和驱动下,实时个性化推荐一定是未来推荐系统发展的核心方向,未来的产品有望在终端上为每个人部署个性化的、量身定制的实时个性化推荐。实时推荐系统也必将在应用场景、交互方式上进行发展和突破。

     

    本文从比较全面的视觉给读者提供了全新的思考维度来认识和了解实时推荐系统。鉴于实时推荐系统的重要性,每个从事推荐算法的工程师、产品经理(特别是数据和AI产品经理)、甚至是运营人员都需要对实时推荐有一定的了解,而本文是你了解实时推荐系统的一扇窗。

     

    参考文献

    1. [书] Big Data: Principles and best practices of scalable realtime data systems

    2. [Kappa架构介绍] http://milinda.pathirage.org/kappa-architecture.com/

    3. [System Architectures for Personalization and Recommendation] https://netflixtechblog.com/system-architectures-for-personalization-and-recommendation-e081aa94b5d8

    4. [2018] Online Deep Learning: Learning Deep Neural Networks on the Fly

    5. [2019] Addressing delayed feedback for continuous training with neural networks in CTR prediction

    6. [2011] Follow-the-regularized-leader and mirror descent: Equivalence theorems and l1 regularization

    7. [信息流推荐在凤凰新闻的业务实践] https://mp.weixin.qq.com/s/aCTP4OCGyWxWGrlCFHSYJQ

    8. [在线学习在爱奇艺信息流推荐业务中的探索与实践] https://mp.weixin.qq.com/s/aQOcnWV2L_VY3ChrSXXxWA

    9. [蚂蚁金服核心技术:百亿特征实时推荐算法揭秘] https://mp.weixin.qq.com/s/6h9MeBs89hTtWsYSZ4pZ5g

    10. [2018 Youtube] Top-K Off-Policy Correction for a REINFORCE Recommender System

     

     

    1.「视频课」如何成为一名优秀的推荐算法工程师?

    2. 推荐系统的人工调控

    3. 推荐系统与精细化运营

    4. 推荐系统提供web服务的两种方式

    5. 推荐算法推荐介绍

    6. 推荐系统的UI交互与视觉展示

    7. 从零开始构建企业级推荐系统

    8. 推荐系统之数据与特征工程

    9. 混合推荐系统介绍

    展开全文
  • 实时系统和非实时系统的区别

    千次阅读 2019-09-02 18:01:23
    嵌入式操作系统分为实时系统和非实时系统两类,常见的实时系统有:ThreadX、FreeRTOS、ucOS;常见的非实时系统有:windows、linux、Android。两类操作系统的主要区别在于任务调度处理方式不同,具体说明如下。 非...

    嵌入式操作系统分为实时系统和非实时系统两类,常见的实时系统有:ThreadX、FreeRTOS、ucOS;常见的非实时系统有:windows、linux、Android。两类操作系统的主要区别在于任务调度处理方式不同,常用的任务调度方式有两种:基于任务优先级的任务调度方式和基于时间片的任务调度方式:

    1. 基于任务优先级的调度方式:一旦内核把资源分配给某进程后,便让该进程一直执行,直到该进程完成或发生某事件而被阻塞(常见的方式主动调用delay),才再把处理机分配给其他进程,否则高优先级的任务会一直运行。所以这种情况下,如果某个高优先级的任务运行时间过长最好有阻塞机制,来让出CPU使其他低优先级的任务也有机会运行。
    2. 基于时间片的调度方式:这种方式下,所有任务的优先级相同,当内核给该进程分配的时间片结束后,内核会停止正在执行的这个进程,下一个时间片分配给其他进程执行,即便这个任务没有执行完也没有主动delay自己

    实时非实时任务调度的区别
    实时操作系统:一般使用基于优先级的调度方式,所以不同优先级的任务,完全基于优先权原则来运行,一旦高优先的任务就绪他可以无条件的,抢占任何正在执行的,低于自己优先级的进程,无论正在运行的进程是否已经进入内核调度。同时也存在基于时间片调度方式,如Freertos系统也有时间片调度模式,当几个任务的优先级相同时,会按照时间片来管理,在优先级相同的任务间切换运行。
    非实时操作系统:一般情况下没有任务优先级的概念(例外情况见补充说明),所有任务默认优先级相同,任务调度采用时间片调度方式。

    补充说明
    有些非实时系统也有优先级的概念,如果非实时系统也定义了优先级和实时操作系统的任务调度方式也是有区别的具体如下:
     任务调度原则不同:
    前提Task2 优先级大于Task1且Task1先准备就绪并且已经开始运行
    非实时系统:当Task2准备就绪时,不会马上切换到Task2,要等待Task1的时间片结束或者Task1主动挂起后,Task2才开始运行,然后一直运行,直到结束,系统才会再次给低优先级的Task1分配时间片。
    实时系统:当Task2准备就绪的那一刻开始,Task1直接就被内核挂起,Task2开始执行,直到结束,系统才会再次给低优先级的Task1分配时间片。
     任务调度的时间不同:
    非实时系统:任务调度不是严格实时的,如linux调度时间的最小单位为10ms,windows系统时间片也只是ms级别。
    实时系统:调度时间是us级的,而且一般小于10us。
     任务调度算法不同:
    实时系统:包含专有的任务调度算法,而且这也是实时系统的核心所在。
    非实时系统:无论是linux还是windows,都缺乏有效的实时任务的调度机制和调度算法。

    展开全文
  • 实时数仓

    千次阅读 2019-04-30 21:15:49
    从智能商业的角度来讲,数据的结果代表了用户的反馈,获取结果的及时性就显得尤为重要,快速的获取数据反馈能够帮助公司更快的做出决策,更好的进行产品迭代,实时数仓在这一过程中起到了不可替代的作用。...

    “数据智能” (Data Intelligence) 有一个必须且基础的环节,就是数据仓库的建设,同时,数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务。从智能商业的角度来讲,数据的结果代表了用户的反馈,获取结果的及时性就显得尤为重要,快速的获取数据反馈能够帮助公司更快的做出决策,更好的进行产品迭代,实时数仓在这一过程中起到了不可替代的作用。

    本文主要讲述知乎的实时数仓实践以及架构的演进,这包括以下几个方面:

     

    实时数仓 1.0 版本,主题: ETL 逻辑实时化,技术方案:Spark Streaming。

    实时数仓 2.0 版本,主题:数据分层,指标计算实时化,技术方案:Flink Streaming。

    实时数仓未来展望:Streaming SQL 平台化,元信息管理系统化,结果验收自动化。

    实时数仓 1.0 版本

    1.0 版本的实时数仓主要是对流量数据做实时 ETL,并不计算实时指标,也未建立起实时数仓体系,实时场景比较单一,对实时数据流的处理主要是为了提升数据平台的服务能力。实时数据的处理向上依赖数据的收集,向下关系到数据的查询和可视化,下图是实时数仓 1.0 版本的整体数据架构图。

    第一部分是数据采集,由三端 SDK 采集数据并通过 Log Collector Server 发送到 Kafka。第二部分是数据 ETL,主要完成对原始数据的清洗和加工并分实时和离线导入 Druid。第三部分是数据可视化,由 Druid 负责计算指标并通过 Web Server 配合前端完成数据可视化。对大数据的概念都是模糊不清的,大数据是什么,能做什么,学的时候,该按照什么线路去学习,学完往哪方面发展,想深入了解,想学习的同学欢迎加入大数据学习qq群:458345782,有大量干货(零基础以及进阶的经典实战)分享给大家,并且有清华大学毕业的资深大数据讲师给大家免费授课,给大家分享目前国内最完整的大数据高端实战实用学习流程体系 。

    其中第一、三部分的相关内容请分别参考:知乎客户端埋点流程、模型和平台技术,Druid 与知乎数据分析平台,此处我们详细介绍第二部分。由于实时数据流的稳定性不如离线数据流,当实时流出现问题后需要离线数据重刷历史数据,因此实时处理部分我们采用了 lambda 架构。

    Lambda 架构有高容错、低延时和可扩展的特点,为了实现这一设计,我们将 ETL 工作分为两部分:Streaming ETL 和 Batch ETL。

    Streaming ETL

    这一部分我会介绍实时计算框架的选择、数据正确性的保证、以及 Streaming 中一些通用的 ETL 逻辑,最后还会介绍 Spark Streaming 在实时 ETL 中的稳定性实践。

    计算框架选择

    在 2016 年年初,业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架,Spark Streaming 用 Micro Batch 模拟流式计算,前者比后者更实时,后者比前者吞吐量大且生态系统更完善,考虑到知乎的日志量以及初期对实时性的要求,我们选择了 Spark Streaming 作为实时数据的处理框架。

    数据正确性保证

    Spark Streaming 的端到端 Exactly-once 需要下游支持幂等、上游支持流量重放,这里我们在 Spark Streaming 这一层做到了 At-least-once,正常情况下数据不重不少,但在程序重启时可能会重发部分数据,为了实现全局的 Exactly-once,我们在下游做了去重逻辑,关于如何去重后面我会讲到。

    通用 ETL 逻辑

    ETL 逻辑和埋点的数据结构息息相关,我们所有的埋点共用同一套 Proto Buffer Schema,大致如下所示。

     

    message LogEntry {

    optional BaseInfo base = 1;

    optional DetailInfo detail = 2;

    optional ExtraInfo extra = 3;

    }

    BaseInfo:日志中最基本的信息,包括用户信息、客户端信息、时间信息、网络信息等日志发送时的必要信息。DetailInfo:日志中的视图信息,包括当前视图、上一个视图等用于定位用户所在位置的信息。ExtraInfo:日志中与特定业务相关的额外信息。

    针对上述三种信息我们将 ETL 逻辑分为通用和非通用两类,通用逻辑和各个业务相关,主要应用于 Base 和 Detail 信息,非通用逻辑则是由需求方针对某次需求提出,主要应用于 Extra 信息。这里我们列举 3 个通用逻辑进行介绍,这包括:动态配置 Streaming、UTM 参数解析、新老用户识别。

    动态配置 Streaming

    由于 Streaming 任务需要 7 * 24 小时运行,但有些业务逻辑,比如:存在一个元数据信息中心,当这个元数据发生变化时,需要将这种变化映射到数据流上方便下游使用数据,这种变化可能需要停止 Streaming 任务以更新业务逻辑,但元数据变化的频率非常高,且在元数据变化后如何及时通知程序的维护者也很难。动态配置 Streaming 为我们提供了一个解决方案,该方案如下图所示。

    我们可以把经常变化的元数据作为 Streaming Broadcast 变量,该变量扮演的角色类似于只读缓存,同时针对该变量可设置 TTL,缓存过期后 Executor 节点会重新向 Driver 请求最新的变量。通过这种机制可以非常自然的将元数据的变化映射到数据流上,无需重启任务也无需通知程序的维护者。

    UTM 参数解析

    UTM 的全称是 Urchin Tracking Module,是用于追踪网站流量来源的利器,关于 UTM 背景知识介绍可以参考网上其他内容,这里不再赘述。下图是我们解析 UTM 信息的完整逻辑。

     

    流量数据通过 UTM 参数解析后,我们可以很容易满足以下需求:

     

    查看各搜索引擎导流情况以及这些流量来自于哪些热门搜索词。

    市场部某次活动带来的流量大小,如:页面浏览数、独立访问用户数等。

    从站内分享出去的链接在各分享平台(如:微信、微博)被浏览的情况。

    新老用户识别

    对于互联网公司而言,增长是一个永恒的话题,实时拿到新增用户量,对于增长运营十分重要。例如:一次投放 n 个渠道,如果能拿到每个渠道的实时新增用户数,就可以快速判断出那些渠道更有价值。我们用下图来表达 Streaming ETL 中是如何识别新老用户的。

    判断一个用户是不是新用户,最简单的办法就是维护一个历史用户池,对每条日志判断该用户是否存在于用户池中。 由于日志量巨大,为了不影响 Streaming 任务的处理速度,我们设计了两层缓存:Thread Local Cache 和 Redis Cache,同时用 HBase 做持久化存储以保存历史用户。访问速度:本地内存 > 远端内存 > 远端磁盘,对于我们这个任务来说,只有 1% 左右的请求会打到 HBase,日志高峰期 26w/s,完全不会影响任务的实时性。当然本地缓存 LruCache 的容量大小和 Redis 的性能也是影响实时性的两个因素。

    Streaming ETL 除了上述几个通用场景外,还有一些其他逻辑,这些逻辑的存在有的是为了满足下游更方便的使用数据的需求,有的是对某些错误埋点的修复,总之 Streaming ETL 在整个实时数仓中处于指标计算的上游,有着不可替代的作用。

    Spark Streaming 在实时数仓 1.0 中的稳定性实践

    Spark Streaming 消费 Kafka 数据推荐使用 Direct 模式。我们早期使用的是 High Level 或者叫 Receiver 模式并使用了 checkpoint 功能,这种方式在更新程序逻辑时需要删除 checkpoint 否则新的程序逻辑就无法生效。另外,由于使用了 checkpoint 功能,Streaming 任务会保持和 Hdfs 通信,可能会因为 NameNode 的抖动导致 Streaming 任务抖动。因此,推荐使用 Direct 模式,关于这种模式和 Receiver 模式的详细对比,可以参考官方文档。

     

    保证 Spark Streaming 任务的资源稳定。以 Yarn 为例,运行 Streaming 任务的队列能够分配到的最小资源小于了任务所需要的资源,任务会出现频繁丢失 Executor 的情况,这会导致 Streaming 任务变慢,因为丢失的 Executor 所对应的数据需要重新计算,同时还需要重新分配 Executor。

     

    Spark Streaming 消费 Kafka 时需要做数据流限速。默认情况下 Spark Streaming 以尽可能大的速度读取消息队列,当 Streaming 任务挂了很久之后再次被启动时,由于拉取的数据量过大可能会导致上游的 Kafka 集群 IO 被打爆进而出现 Kafka 集群长时间阻塞。可以使用 Streaming Conf 参数做限速,限定每秒拉取的最大速度。

     

    Spark Streaming 任务失败后需要自动拉起。长时间运行发现,Spark Streaming 并不能 7 * 24h 稳定运行,我们用 Supervisor 管理 Driver 进程,当任务挂掉后 Driver 进程将不复存在,此时 Supervisor 将重新拉起 Streaming 任务。

    Batch ETL

    接下来要介绍的是 Lambda 架构的第二个部分:Batch ETL,此部分我们需要解决数据落地、离线 ETL、数据批量导入 Druid 等问题。针对数据落地我们自研了 map reduce 任务 Batch Loader,针对数据修复我们自研了离线任务 Repair ETL,离线修复逻辑和实时逻辑共用一套 ETL Lib,针对批量导入 ProtoParquet 数据到 Druid,我们扩展了 Druid 的导入插件。

    Repair ETL

    数据架构图中有两个 Kafka,第一个 Kafka 存放的是原始日志,第二个 Kafka 存放的是实时 ETL 后的日志,我们将两个 Kafka 的数据全部落地,这样做的目的是为了保证数据链路的稳定性。因为实时 ETL 中有大量的业务逻辑,未知需求的逻辑也许会给整个流量数据带来安全隐患,而上游的 Log Collect Server 不存在任何业务逻辑只负责收发日志,相比之下第一个 Kafka 的数据要安全和稳定的多。Repair ETL 并不是经常启用,只有当实时 ETL 丢失数据或者出现逻辑错误时,才会启用该程序用于修复日志。

    Batch Load 2 HDFS

    前面已经介绍过,我们所有的埋点共用同一套 Proto Buffer Schema,数据传输格式全部为二进制。我们自研了落地 Kafka PB 数据到 Hdfs 的 Map Reduce 任务 BatchLoader,该任务除了落地数据外,还负责对数据去重。在 Streaming ETL 阶段我们做到了 At-least-once,通过此处的 BatchLoader 去重我们实现了全局 Exactly-once。BatchLoader 除了支持落地数据、对数据去重外,还支持多目录分区(p_date/p_hour/p_plaform/p_logtype)、数据回放、自依赖管理(早期没有统一的调度器)等。截止到目前,BatchLoader 落地了 40+ 的 Kakfa Topic 数据。

    Batch Load 2 Druid

    采用 Tranquility 实时导入 Druid,这种方式强制需要一个时间窗口,当上游数据延迟超过窗值后会丢弃窗口之外的数据,这种情况会导致实时报表出现指标错误。为了修复这种错误,我们通过 Druid 发起一个离线 Map Reduce 任务定期重导上一个时间段的数据。通过这里的 Batch 导入和前面的实时导入,实现了实时数仓的 Lambda 架构。

    实时数仓 1.0 的几个不足之处

    到目前为止我们已经介绍完 Lambda 架构实时数仓的几个模块,1.0 版本的实时数仓有以下几个不足:

     

    所有的流量数据存放在同一个 Kafka Topic 中,如果下游每个业务线都要消费,这会导致全量数据被消费多次,Kafka 出流量太高无法满足该需求。

    所有的指标计算全部由 Druid 承担,Druid 同时兼顾实时数据源和离线数据源的查询,随着数据量的暴涨 Druid 稳定性急剧下降,这导致各个业务的核心报表不能稳定产出。

    由于每个业务使用同一个流量数据源配置报表,导致查询效率低下,同时无法对业务做数据隔离和成本计算。

    实时数仓 2.0 版本

    随着数据量的暴涨,Druid 中的流量数据源经常查询超时同时各业务消费实时数据的需求也开始增多,如果继续沿用实时数仓 1.0 架构,需要付出大量的额外成本。于是,在实时数仓 1.0 的基础上,我们建立起了实时数仓 2.0,梳理出了新的架构设计并开始着手建立实时数仓体系,新的架构如下图所示。

     原始层

    实时数仓 1.0 我们只对流量数据做 ETL 处理,在 2.0 版本中我们加入了对业务库的变更日志 Binlog 的处理,Binlog 日志在原始层为库级别或者 Mysql 实例级别,即:一个库或者实例的变更日志存放在同一个 Kafka Topic 中。同时随着公司业务的发展不断有新 App 产生,在原始层不仅采集「知乎」日志,像知乎极速版以及内部孵化项目的埋点数据也需要采集,不同 App 的埋点数据仍然使用同一套 PB Schema。

     明细层

    明细层是我们的 ETL 层,这一层数据是由原始层经过 Streaming ETL 后得到。其中对 Binlog 日志的处理主要是完成库或者实例日志到表日志的拆分,对流量日志主要是做一些通用 ETL 处理,由于我们使用的是同一套 PB 结构,对不同 App 数据处理的逻辑代码可以完全复用,这大大降低了我们的开发成本。

     汇总层之明细汇总

    明细汇总层是由明细层通过 ETL 得到,主要以宽表形式存在。业务明细汇总是由业务事实明细表和维度表 Join 得到,流量明细汇总是由流量日志按业务线拆分和流量维度 Join 得到。流量按业务拆分后可以满足各业务实时消费的需求,我们在流量拆分这一块做到了自动化,下图演示了流量数据自动切分的过程。

     

    Streaming Proxy 是流量分发模块,它消费上游 ETL 后的全量数据并定期读取埋点元信息,通过将流量数据与元信息数据进行「Join」完成按业务进行流量拆分的逻辑,同时也会对切分后的流量按业务做 ETL 处理。 只要埋点元信息中新增一个埋点,那么这个埋点对应的数据就会自动切分到该业务的 Kafka 中,最终业务 Kafka 中的数据是独属于当前业务的且已经被通用 ETL 和业务 ETL 处理过,这大大降低了各个业务使用数据的成本。

     汇总层之指标汇总

    指标汇总层是由明细层或者明细汇总层通过聚合计算得到,这一层产出了绝大部分的实时数仓指标,这也是与实时数仓 1.0 最大的区别。知乎是一个生产内容的平台,对业务指标的汇总我们可以从内容角度和用户角度进行汇总,从内容角度我们可以实时统计内容(内容可以是答案、问题、文章、视频、想法)的被点赞数、被关注数、被收藏数等指标,从用户角度我可以实时统计用户的粉丝数、回答数、提问数等指标。对流量指标的汇总我们分为各业务指标汇总和全局指标汇总。对各业务指标汇总,我们可以实时统计首页、搜索、视频、想法等业务的卡片曝光数、卡片点击数、CTR 等,对全局指标汇总我们主要以实时会话为主,实时统计一个会话内的 PV 数、卡片曝光数、点击数、浏览深度、会话时长等指标。

     指标汇总层的存储选型

    不同于明细层和明细汇总层,指标汇总层需要将实时计算好的指标存储起来以供应用层使用。我们根据不同的场景选用了 HBase 和 Redis 作为实时指标的存储引擎。Redis 的场景主要是满足带 Update 操作且 OPS 较高的需求,例如:实时统计全站所有内容(问题、答案、文章等)的累计 PV 数,由于浏览内容产生大量的 PV 日志,可能高达几万或者几十万每秒,需要对每一条内容的 PV 进行实时累加,这种场景下选用 Redis 更为合适。HBase 的场景主要是满足高频 Append 操作、低频随机读取且指标列较多的需求,例如:每分钟统计一次所有内容的被点赞数、被关注数、被收藏数等指标,将每分钟聚合后的结果行 Append 到 HBase 并不会带来性能和存储量的问题,但这种情况下 Redis 在存储量上可能会出现瓶颈。

     指标计算打通指标系统和可视化系统

    指标口径管理依赖指标系统,指标可视化依赖可视化系统,我们通过下图的需求开发过程来讲解如何将三者联系起来。

    需求方整理好需求文档后向数仓工程师提出需求并约会议评审需求,需求文档中必须包含指标的计算口径和指标对应的维度。

     

    数仓工程师根据需求文档对需求进行评审,评审不通过则返回需求方进一步整理需求并重新提需。

     

    在需求评审通过后,数仓工程师开始排期开发

     

    首先在可视化系统中创建一个数据源,这个数据源是后期配置实时报表的数据源,创建数据源也即在 HBase 中创建一张 HBase 表。

    针对该数据源创建指标列,创建指标列也即在 HBase 列族中创建列,创建指标列的同时会将该指标信息录入指标管理系统。

    针对该数据源绑定维表,这个维表是后期配置多维报表时选用维度值要用的,如果要绑定的维表已经存在,则直接绑定,否则需要导入维表。

    一个完整的数据源创建后,数仓工程师才能开发实时应用程序,通过应用程序将多维指标实时写入已创建的数据源中。

     

    需求方根据已创建的数据源直接配置实时报表。

     应用层

    应用层主要是使用汇总层数据以满足业务需求。应用层主要分三块:1. 通过直接读取指标汇总数据做实时可视化,满足固化的实时报表需求,这部分由实时大盘服务承担;2. 推荐算法等业务直接消费明细汇总数据做实时推荐;3. 通过 Tranquility 程序实时摄入明细汇总数据到 Druid,满足实时多维即席分析需求。

    实时数仓 2.0 中的技术实现

    相比实时数仓 1.0 以 Spark Streaming 作为主要实现技术,在实时数仓 2.0 中,我们将 Flink 作为指标汇总层的主要计算框架。Flink 相比 Spark Streaming 有更明显的优势,主要体现在:低延迟、Exactly-once 语义支持、Streaming SQL 支持、状态管理、丰富的时间类型和窗口计算、CEP 支持等。

    我们在实时数仓 2.0 中主要以 Flink 的 Streaming SQL 作为实现方案。使用 Streaming SQL 有以下优点:易于平台化、开发效率高、维度成本低等。目前 Streaming SQL 使用起来也有一些缺陷:1. 语法和 Hive SQL 有一定区别,初使用时需要适应;2.UDF 不如 Hive 丰富,写 UDF 的频率高于 Hive。

    实时数仓 2.0 取得的进展

    在明细汇总层通过流量切分满足了各个业务实时消费日志的需求。目前完成流量切分的业务达到 14+,由于各业务消费的是切分后的流量,Kafka 出流量下降了一个数量级。

    各业务核心实时报表可以稳定产出。由于核心报表的计算直接由数仓负责,可视化系统直接读取实时结果,保证了实时报表的稳定性,目前多个业务拥有实时大盘,实时报表达 40+。

    提升了即席查询的稳定性。核心报表的指标计算转移到数仓,Druid 只负责即席查询,多维分析类的需求得到了满足。

    成本计算需求得到了解决。由于各业务拥有了独立的数据源且各核心大盘由不同的实时程序负责,可以方便的统计各业务使用的存储资源和计算资源。

    实时数仓未来展望

    从实时数仓 1.0 到 2.0,不管是数据架构还是技术方案,我们在深度和广度上都有了更多的积累。随着公司业务的快速发展以及新技术的诞生,实时数仓也会不断的迭代优化。短期可预见的我们会从以下方面进一步提升实时数仓的服务能力:

     

    Streaming SQL 平台化。目前 Streaming SQL 任务是以代码开发 maven 打包的方式提交任务,开发成本高,后期随着 Streaming SQL 平台的上线,实时数仓的开发方式也会由 Jar 包转变为 SQL 文件。

    实时数据元信息管理系统化。对数仓元信息的管理可以大幅度降低使用数据的成本,离线数仓的元信息管理已经基本完善,实时数仓的元信息管理才刚刚开始。

    实时数仓结果验收自动化。对实时结果的验收只能借助与离线数据指标对比的方式,以 Hive 和 Kafka 数据源为例,分别执行 Hive SQL 和 Flink SQL,统计结果并对比是否一致实现实时结果验收的自动化。

    展开全文
  • 让linux变为实时操作系统

    万次阅读 2018-08-23 23:58:02
    我们知道,相对比vxworks,linux内核属于非实时操作系统,原因主要是: (1)实时任务抢占时间是不可预期的。 (2)为什么抢占是不可预期的呢?这涉及到内核中的抢占点知识,其中spin_lock锁,在unlock时是一个...

    我们知道,相对比vxworks,linux内核属于非实时操作系统,原因主要是:

    (1)实时任务抢占时间是不可预期的。

    (2)为什么抢占是不可预期的呢?这涉及到内核中的抢占点知识,其中spin_lock锁,在unlock时是一个抢占点,但是spinlock本身内部是不可以抢占的,这种api在内核中大量使用,事实上是spin_lock与spin_unlock之间临界区代码片段不可预期的。

    具体用一个例子来说明,为什么linux不是实时的。

    某场景:

    一个普通任务运行过程中,通过系统调用进入内核态拿了一把spin_lock这样的锁,在拿锁过程中,发生了硬件中断,于是cpu立即去处理硬件中断,在这个硬件中断处理函数(ISR)中唤醒了一个RT任务,硬件中断处理完后,还有可能处理软中断,也有可能没有,根据设备驱动实际场景决定(中断底半步)。当中断顶半步&底半步全部执行完后,事实上RT任务还是得不到运行的,因为前面有一个普通任务拿了spinlock锁,spinlock是会关抢占的,所以还要等到普通任务调用到spin_unlock的那一刻,RT任务才能进行抢占。

    由上面例子可以看出,从唤醒RT任务到RT任务被执行,这段时间是不可预期的,所以通常linux不是一个硬实时的系统。

     

    如何让linux变成一个硬实时操作系统呢?首先要知道什么是实时操作系统,实时操作系统的重要特性就是系统中的实时任务,要在一个可预期的时间范围内必须得到执行。当一个高优先级任务被唤醒执行,或主动执行时,他必须可以立即抢占其他任务,得到cpu的执行权,这段时间必须是可预期的。像我们所熟知的vxworks实时系统,可以做到10ns以内可预期。

    我们的linux内核属于宏内核,和vxworks微内核设计思想不一样,linux大量用在服务器、嵌入式领域。服务器更追求的是高密度计算,系统吞吐能力。很多产品、工程场景,并不要求有多么精准的实时性。

    回到正题。我们怎么提高linux实时性呢?其实kernel.org官方已经提供了相关补丁,我们只需要将开源linux内核打上rt补丁,就可以让linux变成实时操作系统。

    值得一提的是,不是每个linux版本都有实时补丁的,可以根据需要进行下载使用。比如我在用qemu做实验的时候使用了linux-4.4.97内核。对应的补丁为 patches-4.4.97-rt111.tar.gz。

    [34#yuchen@ubuntu kernel]# ls -l
    total 130484
    drwxr-xr-x 22 root root      4096 Apr 15 21:29 build
    drwxrwxr-x 25 root root      4096 Jul 12 20:49 linux-4.4.97
    -rwx------  1 root root 133077621 Feb 18  2018 linux-4.4.97.tar.gz
    drwxr-xr-x  2 5657 5657     40960 Aug 23 22:58 patches
    -rwx------  1 root root    485551 Apr 15 19:52 patches-4.4.97-rt111.tar.gz
    [35#yuchen@ubuntu kernel]#

    打补丁脚本:

    [35#yuchen@ubuntu kernel]# cat linux-4.4.97/patch.sh 
    #!/bin/sh
    
    for i in `ls ../patches/*.patch`
    do
            patch -p1 < $i
    done
    [36#yuchen@ubuntu kernel]#

    补丁原理:

    前面已经分析过,spin_lock锁会关掉cpu抢占调度,影响实时性。所以RT补丁将spin_lock锁变成可以抢占了,这样就不用等到unlock时才能调度到rt任务。

    RT补丁打入内核后,内核额外提供了几种抢占模型:

    ( ) No Forced Preemption (Server)                  ----不强制抢占

     (X) Voluntary Kernel Preemption (Desktop)         ----自愿抢占
     ( ) Preemptible Kernel (Low-Latency Desktop)    ----抢占式内核
     ( ) Preemptible Kernel (Basic RT)                        ----基本实时
     ( ) Fully Preemptible Kernel (RT)                          ----完全实时

    实时性依次增强,当我们配上Fully Preemptible Kernel时,内核代码中所有的mutex锁,sem信号量,spin_lock全部变成了实时锁,实时锁意味着任何地方都可以抢占,所以RT补丁后实时性就非常强了。但我们要知道实时性越强,吞吐能力就越弱。cpu频繁任务调度的开销也是不小哦!

    展开全文
  • 1)数据源是实时的不间断的,要求用户的响应时间也是实时的(比如对于大型网站的流式数据:网站的访问PV/UV、用户访问了什么内容、搜索了什么内容等,实时的数据计算和分析可以动态实时地刷新用户访问数据,展示网站...
  • 实时推荐系统的三种方式

    万次阅读 2016-01-04 22:30:47
     推荐系统介绍 自从1992年施乐的科学家为了解决信息负载的问题,第一次提出协同过滤算法,个性化推荐已经经过了二十几年的发展。1998年,林登和他的同事申请了“item-to-item”协同过滤技术的专利,经过多年...
  • 实时调度算法

    千次阅读 2018-11-28 20:06:06
    实时调度算法的分类 根据实时任务性质分类 硬实时调度算法:即任务必须在确定的时间内完成 软实时调度算法:即大部分任务必须在确定的时间内完成 根据调度方式分类 关于抢占式和非抢占式的定义这里不讲解 非抢占...
  • 实时直播网站

    万次阅读 2017-01-26 11:10:32
    全球眼官网:http://www.earthcam.cn/ 百度云直播官网:http://kankan.baidu.com/ 强大的国外网站:http://www.insecam.org/ 360水滴直播官网:http://jia.360.cn/pc/index.html ...
  • 基于 HTTP 的实时 Web 通信

    千次阅读 2019-02-10 21:28:19
    基于 HTTP 的实时 Web 通信 Web 应用的信息交互过程通常是客户端通过浏览器发出一个请求,服务器端接收和审核完请求后进行处理并返回结果给客户端,然后客户端...所以保持客户端和服务器端的信息同步是实时 Web ...
  • 分布式系统实时统计在线人数

    千次阅读 2017-04-19 11:07:45
    这里必须说明一点,很多情况下,用户是不会手动点击登出按钮的,所以我们无法拿到一个非常精确的实时在线的一个数据,只能拿到一个近似实时的一个值。我之前有篇文章说的是单点登陆,有兴趣可以参考下,单点登陆sso ...
  • 实时日志监控系统-全览

    万次阅读 2018-05-15 13:59:00
    大数据处理,大致可以分为两大模块:离线数据处理:比如说电商、运营商出现的大批...实时数据处理:对于有些业务需要,可能第二天或者更晚的时候进行分析无关紧要,但对于一些高频的金融交易来说,实时性就太重要了...
  • Python+OpenCV实时图像处理

    万次阅读 多人点赞 2020-05-28 12:36:03
    目录 ...初学OpenCV图像处理的小伙伴肯定对什么高斯函数、滤波处理、阈值二值化等特性非常头疼,这里给各位分享一个小项目,可通过摄像头实时动态查看各类图像处理的特点,也可对各位调参、测试...
  • VSCode设置网页代码实时预览

    万次阅读 多人点赞 2019-12-05 17:39:14
    目录 一、设置描述 二、操作步骤 一、设置描述 1.VSCode作为一款很不错的开发软件,相比DW更小巧,用来...其实我们可以在VSCode中配置一个网页服务器,修改完代码之后只需要保存代码浏览器就可以实时预览 二、...
  • 用C#绘制实时曲线图

    万次阅读 热门讨论 2017-04-25 09:05:38
    在实际项目中我们经常需要绘制一些实时的数据图片,比如当前各公司的用水量、用电量还有播放声音视频时实时显示当前的声频等等,在我们最熟悉的任务管理器也有这么一个功能,用来表示当前CPU的使用频率,最近笔者...
  • 微信小程序集成实时音视频通话功能 背景 在项目的开发当中,很多时候,我们会有音频、视频通话的需求,但是一般都不会自己来写,所以我们就需要借助第三方来实现。尤其是这次的项目开发当中,需要在微信小程序当中...
  • Linux操作系统实时性分析

    万次阅读 2016-12-11 14:01:55
    1. 概述 选择一个合适的嵌入式操作系统,可以考虑以下几个...没有一个绝对的数字可以告诉你什么是硬实时,什么是软实时,他们之间的界限也是十分模糊的,这与你选择什么样的CPU,它的主频、内存等参数有一定关系。如果
  • Linux内核能做到硬实时吗?

    万次阅读 2017-10-28 10:28:14
    Linux内核可以做到硬实时吗? 不能? 为什么? 因为Linux从调度一个实时进程到该实时进程实际投入运行之间的时间不可控,因此无法给予有硬实时需求的可预期延迟。调度了一个实时进程,仅仅意味着它可以运行,并不...
  • 使用Kettle实现数据实时增量同步

    万次阅读 多人点赞 2019-01-31 09:59:42
    本文介绍了使用Kettle对一张业务表数据(500万条数据以上)进行实时(10秒)同步,采用了时间戳增量回滚同步的方法。关于ETL和Kettle的入门知识大家可以阅读相关的blog和文档学习。 1. 时间戳增量回滚同步 ...
  • Qt绘制实时曲线图形简单例程 - Qt实时绘图

    万次阅读 多人点赞 2018-10-16 11:30:36
    本来是想写一篇上位机通过串口接收数据并进行简单实时动态画图的,但是网上关于Qt串口接收数据的博客已经非常多了,且也会导致内容太多,显得复杂,如果需要串口收发数据例程,网上随便百度就能收到了,也可以下载我...
  • 图解实时操作系统和非实时操作系统的区别

    万次阅读 多人点赞 2016-12-14 23:19:33
    对于实时操作系统(RTOS)和非实时操作系统,你能分别列举出来多少? 实时操作系统:uCOS/VxWorks/RTLinux 非实时操作系统:Linux/Windows/OSX 我也只能列举出来这么多了。 重点不在这里,重点在于他们之间的区别...
1 2 3 4 5 ... 20
收藏数 1,046,160
精华内容 418,464
关键字:

实时