Monthly Archives: 4月 2020

周骏:疫情推动的企业数字化转型与消费者体验重构

今天我会和大家分享的话题是,在疫情期间推动下的这样一个企业数字化转型和消费者的体验重构。

曾有一个MBA的学员提了个问题:谁领导了公司的数字化转型?是CEO吗?是CTO吗?都不是,是COVID-19。

这次疫情影响下,大家无法在办公室上班,尤其是传统的线下零售行业、餐饮业、旅游业等,这些行业要么行业本身停板,要么开启了全新的消费者互动模式。在这些模式下,很多企业开始进行数字化的尝试。

疫情改变了消费者与企业互动的途径,例如品牌零售行业从店铺内面对面的沟通转向了线上沟通,这会导致企业的服务逻辑、服务模式、服务态度都有所改变。怎么能够让消费者在新的渠道上适应他们的需求,更好地服务他们,是很多品牌需要考虑的一个问题。

很多企业都已经非常快速地做出了反应,纷纷开始做线上直播,例如两个快餐界的大佬麦当劳和肯德基。虽然直播的确帮助企业在疫情下找到了新的销售渠道,但是企业也要知道,每个企业通过直播与消费者保持持续互动的方式是不一样的,所以企业不能盲目跟风产出千篇一律的直播内容,而是需要抓住能够持续和消费者互动的方式。

麦当劳是CEO和CMO在直播间推广新品,直播平台选择的是非常年轻的B2B直播平台,很符合麦当劳现在年轻化的方向。肯德基则是采用全员直播的逻辑,把全国的各地的员工充分调动起来,与淘宝直播深度合作。


流量的数字化,并不代表企业数字化转型

企业的数字化转型不仅仅是流量的数字化。我们可以看到比亚迪、中石化、格力、空调、富士康等等这些企业都有开始生产口罩。这些能跨界生产口罩的企业,是因为他们有柔性的生产链,帮助企业应对整个市场的变化,找到产品变化的可能性。

以制造企业为例,真正有数字化能力的企业拥有柔性的制造链以及灵活应变的厂房设备、仓储、供应链,甚至内部员工的工作流等等。当然,很多企业会首先从流量的触点上去做数字化转型,因为这能很直观地让消费者感受到企业的数字化转型信号。但企业更需要做的是全方位的数字化转型,将数字化变成企业由内而外的核心能力,这样企业才能够在危机时快速做出应变。


疫情带来的消费者行为变化会改变哪些行业?

我引用了Bof的一段文字,消费者还需要时尚吗?答:需要。

消费者到底需要买什么样的衣服?如今收入受影响了,你会买什么样的新衣服?对于很多时尚行业,尤其是一些一二线的品牌,他们每年会搞几场大秀,在全球范围内把1000个人安排到某一个固定的地方,一起看一场重大的秀,这样的行为在疫情本身受影响的情况下,云走秀形式已经出现,未来现场大秀还有没有存在的必要?

服装行业线下营销部分的比重一定会在中长期减少非常大的比例,所以服装品牌应该在短期内重视这样一个话题:怎么更好地将各个平台上的消费者转化。

疫情对于整个食品行业的变化是非常大的,我们会发现消费者在吃这件事情上的购买行为也产生了很多新的变化。比方说我们看到全国人民下厨的技能都得到了大量的提升,近期热度十足的何炅同款泡面、小圆饼,其实也是让消费者对于食品原材料的需求产生了全新的变化。

目前整个生鲜配送市场突飞猛进,我们可以看到除了像叮咚买菜这样的一些生鲜配送,或者像盒马这样本身在这个领域已经有一定分量的玩家,一些连锁餐饮企业也开始在做生鲜原材料的配送,企业能够快速反应、应对跟进生鲜配送市场,就会赢得先机。

疫情期间有很多即食食品,需求在短期内急速上升,而且还有消费者DIY了很多即食食品的吃法,这一切都在助推整个市场变化。我们也预测在今年下半年会有很多新的产品出现,这些新产品会进一步的提升原来即食食品的口味、食用方式、食用场景,给消费者带来全新的体验。

主要在于大家在家里的时候产生了很多“宅”行为。比如,我们宅在家里保证基础生活的服务。当我们陆陆续续复工的时候,远程办公、远程云服务就加速渗透到了我们日常生活当中。

其次宅在家消磨时间的时候,有很多宅家游戏爆发了第二春。很重要的原因是当大家宅在家无聊的时候可能会突然间沉下心来,在自己DIY的游戏上花更多的时间精力,游戏的第二春一定程度上会给其他的游戏行业从业者带来很多新的可能性。

另外我们看到日化行业当中,尤其是一些消毒用品、日常生活用品等等,在整个疫情空期间突然间需求大增,这个行业在短期内产生了一个销量上的飞速增长。但这些企业需要控制好自己的物流链,让消费者在物资紧缺时仍然能够方便地买到这些产品,这就非常考验一个企业背后的数字化能力。数字化能力越强的企业,就会有更好的灵活应对能力。

疫情期间旅游业的持续低迷,例如航空公司、旅行社、OTA平台,甚至于民宿都受到了极大的影响。但目前当下对于旅游业来说,熬过去一定是关键,如今一些线上OTA也是通过社群在做营销、卖产品,他们不仅仅在卖旅游产品,还卖一些其他的生活用品。

这一切都是他们为了熬下去所去做的一些改变,这的确是一个快速应对的方式。在未来旅游业的发展中,消费者的出行会被各种各样的外界因素影响,那么旅游行业还有什么样的盈利可能性?所以这是一个非常关键的话题。

另外,目前中国的物流供应链在整体上我们觉得它已经处在非常稳定的状态,反观欧美国家因疫情影响,供应链受到重创。疫情带来的油价有史以来第一次出现负油价的情况,所以我们需要保持和供应链、供应商有很好的合作,来确保企业的生产制造过程是保持稳定的。


如何重构新时代的消费者体验

就体验这件事作为出发,消费者体验有些时候是很片面的,他会用他自己的方式去体验企业的产品和服务。我们要做的就是真正站在消费者的立场上去做更多的思考。在这一点上我们有很多词汇,比方说同理心、共情能力等等。我们需要去站在消费者立场上找到更多洞察,找到更多对于品牌产品和服务的新思路。只有企业把整个消费者旅程设计的够完整、够清楚,才可能去预见到消费者在旅程过程当中可能会出现的问题。

举个例子:上图是一个体验设计师做的关于寿司店的消费者流程体验,他把整个过程当中消费者的行为充分考虑到了,大家应该都听过两个词,一个叫UI,一个叫UX,这里用更近准的描述来说应该是consumer journey或者user experience,这些词都是站在消费者的路径上去看待体验。

引入一个概念叫Service design,一定程度上它会比UX所要覆盖的范围更广泛。在2015年欧洲北欧的有一个在行业内有一定影响力的设计师讲过,服务设计最后带给消费者的意义是什么?是当大家售卖同样的产品的时候,消费者会因为你的服务以及整个的管理体系、运作模式带给他的体验感不同,最终他会更愿意购买你的产品,而不是别人的产品。

当我们考虑消费者体验的时候,怎么去做整个服务设计会非常重要。服务设计会需要考虑的面会远比我们讲consumer journey、user experience这些带来的更多。

如上图所示是一个服务体验公司的总结,可以看到user experience是中间的一个部分,同时我们需要把企业所能够提供的产品和服务,带进这样一个消费者体验路径去。而且我们要考虑企业的产品能对消费者产生什么样的意义?带来什么样的服务?能给消费者带来性价比的提升、还是价格的降低、还是速度的提升等等。

只有真正做好服务设计,企业才能构造一个真正符合消费者预期,并且整个服务设计所涵盖的领域会非常广,所有的这一切都需要整个企业内部不同能力的人跨界合作,跨学科、跨专业、多元能力的人在一块工作,才能真正做好服务设计,才能最后落实到一个对消费者有意义的体验上。


疫情期间企业在保守中创新

很多客户或者老板会提出说,要做一些创新的项目,要去做一些市场上全新的东西。但其实当我们设计出了一个新东西之后,老板就会产生一个担忧,这个东西会不会太行?

我们相信这个市场上有一些企业,它有能力去开拓一个全新的领域,但是更多的企业还是希望找到一个被市场认证的有效方法,再去做类似的复制。

怎么样在创新和保守之间找到一个平衡?创新的部分,更多的是企业是否能够快速的跟上整个社会的变化,整个消费者行为的变化,跟上当下疫情对消费者产生影响的变化,这是需要企业有足够的创新和快速反应能力的。所以我们又回到了最初,企业要养成快速应对危机的能力,数字化转型势在必行。

营销人员不得不知道的埋点知识


大家好,我是Linkflow COO徐涛,今天我想给大家介绍一下SDK也就是Linkflow的埋点功能。本次分享面向的对象是营销人员,大家不需要有什么太多的技术基础,就能够听懂这次分享。

SDK的应用场景

在介绍SDK的使用场景之前,我们首先需要了解一下客户互动的场景。

如上图所示,左边圆圈的外围有三个关键字,分别是 customer engagement,也就是客户互动;customer insights,即客户洞察;customer journey,客户旅程。

整个客户互动的流程就是企业采集所有客户触点上的互动信息(customer engagement),如微信的互动信息、H5的互动信息、小程序的互动信息,这些信息被采集进来之后,企业会做相应的客户洞察(customer insights),如打标签、报表分析、人群分组等等,基于这些洞察,企业就能够制定一些精准的营销策略。这些策略就需要通过客户旅程(customer journey)来落地执行。

当企业不断地与客户做互动,就能不断得到客户的行为信息并进行洞察,洞察之后制定策略,然后再通过客户旅程去执行,执行的过程当中又会产生新的互动,新的互动又会有新的洞察,再制定新的策略,再通过新的客户旅程去执行。这样周而复始不断的迭代,企业就能更加了解客户,对客户进行精准化或者个性化的营销。

在Linkflow的产品中,customer engagement、customer insights、customer journey这三大功能是一个基石,这其中具体包含5个模块,第1个模块就是应用对接,即多数据源的打通,SDK就属于这一个大模块中的一个功能。

除了应用对接多数据源打通以外,Linkflow还有统一的客户画像功能、客户旅程功能、报表分析、统计功能。这些模块会在其他的分享中进行详细的讲解,今天就不在这里赘述。

回到多数据源打通这一块,也就是SDK相关模块里面,它主要会有哪些相应的使用场景?在我看来,最主要的是以下4个应用场景。

营销活动的优化

在营销活动中我们非常需要客户的反馈,比如说推广的页面客户是否浏览,是否点击里面的按钮,以及一些成交的数据。数据都采集回来,才能观测到一个营销活动的一个效果是怎样的。

举个栗子:双11这样的营销活动,是会有不同的营销阶段,例如娱乐阶段、主力阶段和返场阶段。在不同阶段,企业需要做相应的统计、分析和优化。

在预热阶段,企业可以做一些测试,也就是利用SDK去采集客户的浏览行为、扫码行为、下单行为、退货行为等等。最终的测试结果就是什么样的产品或者什么样的活动,有较高的转化率。根据测试结果,企业就可以把这些转化率较好的活动放在主力阶段,也就双11当天来进行,从而实现营销优化。

广告投放的优化

在没有使用SDK之前,企业能够获取的数据仅仅是广告投放的展点销数据,但是这些数据实际上是不足以来告诉企业一个投放的效果是好是坏,因为广告平台只给了一部分数据,因为在展点销之后,被引流过来的客户会通过落地页跳转到企业官网或者APP,在官网和APP的行为追踪广告平台是不负责的。

这时,SDK就会去负责后续的数据采集。比如客户跳转到落地页之后,又进行了什么点击,提交什么表单,或者下了什么订单。这些行为再结合广告平台的展点销售数据,就可以比较好地评估一个广告投放的效果如何,最终来优化企业投放的关键字。

APP或者网站的优化

很多互联网创业公司在APP或者网站上线时,都要使用SDK来获取用户的浏览轨迹和习惯,从而更好的优化APP或者网站的布局。关于这个场景我就不用多说了,大家都非常熟悉。
个性化的客户旅程

这是其他的SDK产品很少提及的。因为Linkflow除了对采集道德客户行为进行洞察和优化,我们还会利用SDK为客户提供个性化的客户旅程。比如说通过JS SDK在网页端针对不同的人群客户进行弹窗。在其他方面,比如个性化的短信或者微信营销,也都是通过服务端、SDK的方式来实现。


SDK的种类


如上图所示,SDK分为4种,分别是代码埋点、全埋点、可视化埋点,以及服务端埋点。面前三种都是跟前端页面相关的,最后一种是和后端服务相关的。

可视化埋点

前面三种和页面相关的埋点方式中,可视化埋点目前来说还不是很流行,虽然它非常的方便,在埋点时不需要有IT支持,只要通过一个可视化的工具,在UI上进行圈选,然后就能够将SDK埋进去。但是它有一个弱点,就是在页面改版后,比如说排版发生调整,或者风格发生了调整。这时,所有的页面埋点都需要重新做,这个情况就会带来大量的工作量。对于网站或者APP,可能每三个月就会改版一次,整个页面布局就会发生重大的变化。如果每三个月都要把所有的埋点重新做一遍,工作量和代价是非常巨大的。所以可视化埋点不是很流行。

也就是说,对于APP或者网站前端UI的埋点来说,最主要使用的是代码埋点和全埋点。

全埋点

全埋点的意思非常简单,也就是说我只要把一个JS SDK或者一个SDK放到这个页面里面,就需要做其他任何的事情。这时系统就会自动采集页面的PV和到UV,实现最低力度的用户行为监控。如果企业只需要采集PV和UV,就可以直接使用全埋点。比如一个APP或者网站刚上线时,企业想要评估各页面的设计体验,就可以使用全埋点,因为它比较方便,不需要写代码,只要放一段JS SDK在里面,就能够实现页面的一个监控。

但是,全埋点也有一个劣势,就是数据的准确性不高,因为它只能监控到页面维度,也就是企业只知道客户到达这个页面,但在页面里面的具体的行为是捕获不到的。所以全埋点的好处是简单快捷,它的劣势是粒度太粗,不适合做精细化的监控。

怎么来弥补全埋点的这个缺陷?那就是代码埋点。

代码埋点

代码埋点实际上是在全埋点的基础上,进行更细粒度的行为监控,比如加入购物、加入收藏夹等动作。

进行代码埋点采集时,企业首先要定义需要采集的事件,再由开发人员在页面里写相应的埋点代码。它的优势就是力度更细,能采集到更精细的动作,便于业务人员进行更好的分析。

但劣势是什么?很明显,代码埋点的工作量和成本肯定要比全埋点高,因为它需要程序员介入。

所以使用代码埋点还是全埋点,需要业务人员结合业务需求和业务阶段进行取舍。比如,早期的时候,全埋点就可以完成监控分析等基础的优化指标。等到中后期时页面和用户量也比较多了,企业想对用户进行更精细的行为分析时,就可以采用代码埋点。

服务端埋点

介绍完前端的UI的埋点,我们最后看一下服务端的埋点。服务端埋点是应用在某些无法在前端页面放置SDK的情况。

举个最典型的例子就是微信公众号的行为监控,因为企业不可能把SDK放到微信里去,那么企业如何能捕获粉丝在微信公众号里的行为?这时就要利用服务端,也就是API的对接。微信公众平台提供了相应的开放接口供我们调用,我们就能通过API的对接来监控粉丝在公众号里的行为,比如说扫码行为、关注行为、取关行为、点击菜单行为等等。

服务端对接的优势就是它非常准确,因为关注、点击菜单等行为都是非常准确的,也是实时的,而且数据也是结构化的。

但是,它的劣势就是前端的上下文环境拿不到,比如说客户的 cookie、IP地址都是拿不到的,因为这些信息在API里面没有提供。在其他的服务端对接时,企业认为很重要的一些前端数据也不一定能拿得到。比如企业想要获取电商平台的订单信息,这肯定是要通过API来获取的。但在订单信息里不会显示这个订单是来自哪一个营销活动,所以这是服务端埋点一个较大的缺陷,即采集的数据受限于API接口提供的能力。


SDK的功能

Identify

它是用来识别客户的。一开始客户是匿名的,在前端页面、小程序、APP里,客户刚进来的时候只有cookie,当客户授权登录后,他就从一个匿名客户就变成了一个有名有姓的实名用户,这时就需要通过identity的方式,把匿名的用户变成一个实名用户。

Page

page这个功能就是采集pv和uv。这个功能对大家来说是隐形的,也就是把SDK放进页面或者APP之后,它会自动去采集pv和uv,是无需做干预的。它采集回来的数据可以做一些粗粒度的统计分析。

Track

Track对一些精细化的行为事件的进行一一追踪。也就是说在一个页面里,客户具体做了什么动作,都要通过track这个模块来进行采集,从而进行后续相应的分析。

Alias

现在,多渠道营销是非常普遍的,这就意味着客户会通过不同的渠道与企业进行交互,并在不同渠道产生账号。比如说他在微信里面是这个人,在小程序里是另外一个人,在网页里又是一个人,企业怎么把同一个人在不同渠道的身份进行合并,这就需要alias功能模块。

它会使用一些通用的标识,来判定这几个账号是属于同一个人的。比如同样的手机号、同样的邮箱,或者在微信体系里通过open ID或者union ID来实现判断合并。


SDK采集的数据类型

用户信息

比如说用户的一些身份信息,如cookie、IP地址,在微信环境下,微页面还能告诉你它的open ID以及其他实名信息,如姓名、昵称、手机号、邮箱等等。
用户行为信息

除了用户信息之外,SDK还会采集用户的行为信息,除了基础浏览行为之外,SDK还能捕获更多的行为信息,如加入收藏夹、提交表单、提交订单等。

广告投放信息

广告投放信息就是在落地页采集到的referrer网址信息,就能指明这个落地页是来自哪个广告平台的。在落地页上一般都会有些utm参数,这个参数SDK也会采集。

其他信息

在前端UI里我们还能采集到的一些其他信息,如浏览器信息、设备信息、地理位置信息等。

SEM广告信息

对于SEM广告我们还可以捕获广告的账户信息、计划信息、创意信息、以及关键词信息。
微信公众号信息

关注行为、取关行为、留言、扫码、菜单点击等行为同样可以被采集。

信息流广告信息

信息流广告信息和SEM广告信息类似,也是采集广告的计划、广告主、广告主属性、以及展点销信息。

表单信息

最后一个也是大家比较常用的,例如金数据表单、问卷网表单、问卷星表单等。
以上就是SDK的知识科普,在视频中还为大家介绍了SDK的应用案例,帮助大家更形象的能够了解SDK可以应用在什么样的业务场景里,欢迎大家扫码观看视频课程。

Kafka为什么这么快?

译文:钟涛

公众号:分布实验室

在过去的几年里,软件架构领域发生了巨大的变化。人们不再认为所有的系统都应该共享一个数据库。微服务、事件驱动架构和CQRS(命令查询的责任分离 Command Query Responsibility Segregation)是构建当代业务应用程序的主要工具。除此以外,物联网、移动设备和可穿戴设备的普及,进一步对系统的近实时能力提出了挑战。

首先让我们对“快”这个词达成共识,这个词是多方面的、复杂的、高度模糊的。一种解释是把”延迟、吞吐量和抖动“作为对“快”的衡量指标。还有,比如工业应用领域,行业本身设置了对于“快”的规范和期望。所以,“快”在很大程度上取决于你的参照体系是什么。

Apache Kafka以牺牲延迟和抖动为代价优化了吞吐量,但并没有牺牲,比如持久性、严格的记录有序性和至少一次的分发语义。当有人说“Kafka速度很快”,并假设他们至少有一定的能力时,你可以认为他们指的是Kafka在短时间内分发大量记录的能力。

Kafka诞生于LinkedIn,当时LinkedIn需要高效地传递大量信息,相当于每小时传输数TB的数据量。在当时,消息传播的延迟被认为是可以接受的。毕竟,LinkedIn不是一家从事高频交易的金融机构,也不是一个在确定期限内运行的工业控制系统。Kafka可用于近实时系统。

注意:“实时”并不意味着“快”,它的意思是“可预测的”。具体来说,实时意味着完成一个动作具有时间限制,也就是最后期限。如果一个系统不能满足这个要求,它就不能被归类为”实时系统“。能够容忍一定范围内延迟的系统被称为“近实时”系统。从吞吐量的角度来说,实时系统通常比近实时或非实时系统要慢。

Kafka在速度上有两个重要的方面,需要单独讨论。第一个是与客户端与服务端之间的低效率实现有关。第二个源自于流处理的并行性。


服务端优化

日志的存储

Kafka利用分段、追加日志的方式,在很大程度上将读写限制为顺序I/O(sequential I/O),这在大多数的存储介质上都很快。人们普遍错误地认为硬盘很慢。然而,存储介质的性能,很大程度上依赖于数据被访问的模式。同样在一块普通的7200 RPM SATA硬盘上,随机I/O(random I/O)与顺序I/O相比,随机I/O的性能要比顺序I/O慢3到4个数量级。此外,现代的操作系统提供了预先读和延迟写的技术,这些技术可以以块为单位,预先读取大量数据,并将较小的逻辑写操作合并成较大的物理写操作。因此,顺序I/O和随机I/O之间的性能差异在闪存和其他固态非易失性介质中仍然很明显,不过它们在旋转存储,比如固态硬盘中的性能差异就没有那么明显。

记录的批处理

顺序I/O在大多数存储介质上都非常快,可以与网络I/O的最高性能相媲美。在实践中,这意味着一个设计良好的日志持久化层能跟上网络的读写速度。事实上,Kafka的性能瓶颈通常并不在硬盘上,而是网络。因此,除了操作系统提供的批处理外,Kafka的客户端和服务端会在一个批处理中积累多个记录——包括读写记录,然后在通过网络发送出去。记录的批处理可以缓解网络往返的开销,使用更大的数据包,提高带宽的效率。

批量压缩

当启用压缩时,对批处理的影响特别明显,因为随着数据大小的增加,压缩通常会变得更有效。特别是在使用基于文本的格式时,比如JSON,压缩的效果会非常明显,压缩比通常在5x到7x之间。此外,记录的批处理主要作为一个客户端操作,负载在传递的过程中,不仅对网络带宽有积极影响,而且对服务端的磁盘I/O利用率也有积极影响。

便宜的消费者

不同于传统的消息队列模型,当消息被消费时会删除消息(会导致随机I/O),Kafka不会在消息被消费后删除它们——相反,它会独立地跟踪每个消费者组的偏移量。可以参考Kafka的内部主题__consumer_offsets了解更多。同样,由于只是追加操作,所以速度很快。消息的大小在后台被进一步减少(使用Kafka的压缩特性),只保留任何给定消费者组的最后已知偏移量。

将此模型与传统的消息模型进行对比,后者通常提供几种不同的消息分发拓扑。一种是消息队列——用于点对点消息传递的持久化传输,没有点对多点功能。另一种是发布订阅主题允许点对多点消息通信,但这样做的代价是持久性。在传统消息队列模型中实现持久化的点对多点消息通信模型需要为每个有状态的使用者维护专用消息队列。这将放大读写的消耗。消息生产者被迫将消息写入多个消息队列中。另外一种选择是使用扇出中继,扇出中继可以消费来自一个队列中的记录,并将记录写入其他多个队列中,但这只会将延迟放大点。并且,一些消费者正在服务端上生成负载——读和写I/O的混合,既有顺序的,也有随机的。

Kafka中的消费者是“便宜的”,只要他们不改变日志文件(只有生产者或Kafka的内部进程被允许这样做)。这意味着大量消费者可以并发地从同一主题读取数据,而不会使集群崩溃。添加一个消费者仍然有一些成本,但主要是顺序读取夹杂很少的顺序写入。因此,在一个多样化的消费者系统中,看到一个主题被共享是相当正常的。

未刷新的缓冲写操作

Kafka性能的另一个基本原因是,一个值得进一步研究的原因:Kafka在确认写操作之前并没有调用fsync。ACK的唯一要求是记录已经写入I/O缓冲区。这是一个鲜为人知的事实,但却是一个至关重要的事实。实际上,这就是Kafka的执行方式,就好像它是一个内存队列一样——Kafka实际上是一个由磁盘支持的内存队列(受缓冲区/页面缓存大小的限制)。

但是,这种形式的写入是不安全的,因为副本的出错可能导致数据丢失,即使记录似乎已经被ACK。换句话说,与关系型数据库不同,仅写入缓冲区并不意味着持久性。保证Kafka持久性的是运行几个同步的副本。即使其中一个出错了,其他的(假设不止一个)将继续运行——假设出错的原因不会导致其他的副本也出错。因此,无fsync的非阻塞I/O方法和冗余的同步副本组合为Kafka提供了高吞吐、持久性和可用性。


客户端优化

大多数数据库、队列和其他形式的持久性中间件都是围绕全能服务器(或服务器集群)和瘦客户端的概念设计的。客户端的实现通常被认为比服务器端简单得多。服务器会处理大部分的负载,而客户端仅充当服务端的门面。

Kafka采用了不同的客户端设计方法。在记录到达服务器之前,会在客户端上执行大量的工作。这包括对累加器中的记录进行分段、对记录键进行散列以得到正确的分区索引、对记录进行校验以及对记录批处理进行压缩。客户端知道集群元数据,并定期刷新元数据以跟上服务端拓扑的更改。这让客户端更准确的做出转发决策。不同于盲目地将记录发送到集群并依靠后者将其转发到适当的节点,生产者客户端可以直接将写请求转发到分区主机。类似地,消费者客户端能够在获取记录时做出更明智的决定,比如在发出读查询时,可以使用在地理上更接近消费者客户端的副本。(该特性是从Kafka的2.4.0版本开始提供。)

零拷贝

一种典型的低效方式是在缓冲之间复制字节数据。Kafka使用由生产者、消费者、服务端三方共享的二进制消息格式,这样即使数据块被压缩了,也可以不加修改地传递数据。虽然消除通信方之间的数据结构差异是重要的一步,但它本身并不能避免数据的复制。

Kafka使用Java的NIO框架,特别是java.nio.channels.FileChannel的transferTo()方法,在Linux和UNIX系统上解决了这个问题。此方法允许字节从源通道传输到接收通道,而不需要将应用程序作为传输中介。了解NIO的不同之处,请思考传统的方法会怎么做,将源通道读入字节缓冲区,然后作为两个独立的操作写入接收器通道:

File.read(fileDesc, buf, len);
Socket.send(socket, buf, len);

可以用下图来表示。

虽然这副图看起来很简单,但是在内部,复制操作需要在用户态和内核态之间进行四次上下文切换,并且在操作完成之前要复制四次数据。下图概述了每次步骤的上下文切换。


详细说明:

  1. 初始的read()方法导致上下文从用户态切换到内核态。文件被读取,它的内容被DMA(Direct Memory Access 直接存储器访问)引擎复制到内核地址空间中的缓冲区。这与代码段中使用的缓冲区是不同的。
  2. 在read()方法返回之前,将数据从内核缓冲区复制到用户空间缓冲区。此时,我们的应用程序可以读取文件的内容了。
  3. 随后的send()方法将切回到内核态,将数据从用户空间缓冲区复制到内核地址空间——这一次是将数据复制到与目标套接字相关联的另一个缓冲区中。在后台,由DMA引擎接管,异步地将数据从内核缓冲区复制到协议栈。send()方法在返回之前不会等待这个操作完成。
  4. send()方法调用返回,切回用户态。

尽管用户态与内核态之间的上下文切换效率很低,而且还需要进行额外的复制,但在许多情况下,它可以提高性能。它可以充当预读缓存,异步预读取,从而提前运行来自应用程序的请求。但是,当请求的数据量远远大于内核缓冲区的大小时,内核缓冲区就成为了性能瓶颈。不同于直接复制数据,而是迫使系统在用户态和内核态之间频繁切换,直到所有数据都被传输。

相比之下,零拷贝方法是在单个操作中处理的。前面例子中的代码可以改写为一行代码:

fileDesc.transferTo(offset, len, socket);

下面详细解释说明是零拷贝。


在这个模型中,上下文切换的数量减少到一个。具体来说,transferTo()方法指示块设备通过DMA引擎将数据读入读缓冲区。然后,将数据从读缓冲区复制到套接字缓冲区。最后,通过DMA将数据从套接字缓冲区复制到NIC缓冲区。


因此,我们将复制的数量从4个减少到3个,并且其中只有一个复制操作涉及到CPU。我们还将上下文切换的数量从4个减少到2个。

这是一个巨大的改进,但还不是查询零拷贝。在运行Linux内核2.4或更高版本时,以及在支持gather 操作的网卡上,可以进一步优化。如下图所示。


按照前面的示例,调用transferTo()方法会导致设备通过DMA引擎将数据读入内核缓冲区。但是,对于gather 操作,读缓冲区和套接字缓冲区之间不存在复制。相反,NIC被赋予一个指向读缓冲区的指针,连同偏移量和长度。在任何情况下,CPU都不涉及复制缓冲区。

文件大小从几MB到1GB的范围内,传统拷贝和零拷贝相比,结果显示零拷贝的性能提高了两到三倍。但更令人印象深刻的是,Kafka使用纯JVM实现了这一点,没有本地库或JNI代码。

避免垃圾回收

大量使用通道、缓冲区和页面缓存还有一个额外的好处——减少垃圾收集器的工作负载。例如,在32 GB RAM的机器上运行Kafka将产生28-30 GB的页面缓存可用空间,完全超出了垃圾收集器的范围。吞吐量的差异非常小(大约几个百分点),但是经过正确调优的垃圾收集器的吞吐量可能非常高,特别是在处理短生存期对象时。真正的收益在于减少抖动。通过避免垃圾回收,服务端不太可能遇到因垃圾回收引起的程序暂停,从而影响客户端,加大记录的通信延迟。

与初期的Kafka相比,现在避免垃圾回收已经不是什么问题了。像Shenandoah和ZGC这样的现代垃圾收集器可以扩展到巨大的、多TB级的堆,在最坏的情况下,并且可以自动调整垃圾收集的暂停时间,降到几毫秒。现在,可以看见大量的基于Java虚拟机的应用程序使用堆缓存,而不是堆外缓存。

流处理的并行性

日志的I/O效率是性能的一个重要方面,主要的性能影响在于写。Kafka对主题结构和消费生态系统中的并行性处理是其读性能的基础。这种组合产生了整体非常高的端到端消息吞吐量。将并发性深入到分区方案和使用者组的操作中,这实际上是Kafka中的一种负载均衡机制——将分区平均地分配到各个消费者中。将此与传统的消息队列进行比较:在RabbitMQ的设置中,多个并发的消费者可以以轮询的方式从队列中读取数据,但这样做会丧失消息的有序性。

分区机制有利于Kafka服务端的水平扩展。每个分区都有一个专门的领导者。因此,任何重要的多分区的主题都可以利用整个服务端集群进行写操作。这是Kafka和传统消息队列的另一个区别。当后者利用集群来提高可用性时,Kafka通过负载均衡来提高可用性、持久性和吞吐量。

发布具有多个分区的主题时,生产者指定发布记录时的分区。(可能有一个单分区主题,那就不是问题了。)可以通过指定分区索引直接完成,或通过记录键间接完成,记录键通过计算散列值确定分区索引。具有相同散列值的记录共享相同的分区。假设一个主题有多个分区,那么具有不同键的记录可能会出现在不同的分区中。然而,由于散列冲突,具有不同散列值的记录也可能最终出现在同一个分区中。这就是散列的本质。如果你理解了散列表的工作方式,一切都很自然了。

记录的实际处理由消费者完成,在一个可选的消费者组中完成。Kafka保证一个分区最多只能分配给消费者组中的一个消费者。(为什么用”最多“,当所有消费者都离线时,那就是0个消费者了。)当组中的第一个消费者订阅主题时,它将接收该主题上的所有分区。当第二个消费者订阅主题时,它将接收到大约一半的分区,从而减轻第一个消费者的负载。根据需要添加消费者(理想情况下,使用自动伸缩机制),这使你能够并行地处理事件流,前提是你已经对事件流进行了分区。

以两种方式控制记录的吞吐量:

  1. 主题分区方案。应该对主题进行分区,最大化事件流的数量。换句话说,只有在绝对需要时才提供记录的顺序。如果任何两个记录不存在关联,它们就不应该被绑定到同一个分区。这意味着要使用不同的键,因为Kafka使用记录键的散列值作为分区映射的根据。
  2. 组中消费者的数量。你可以增加消费者的数量来均衡入站记录的负载,消费者的数量最多可以增加到和分区数量一样多。(你可以增加更多的消费者,但每个分区最多只能有一个的活动消费者,剩下的消费者将处于闲置状态。)请注意,你可以提供一个线程池,根据消费者执行工作负载的不同,消费者可以是一个进程或一个线程。

如果你想知道Kafka为什么这么快,它是如何做到的,以及它是否适合你,我想你现在已经有了答案了。

为了更清楚地说明问题,Kafka不是最快的消息中间件,吞吐量也不是最大的。有其他平台能够提供更高的吞吐量——有些是基于软件的,有些是基于硬件的。很难同时做到吞吐量大且延迟低,Apache Pulsar[1]是一个有前途的技术,可扩展,更好的吞吐量-延迟配置文件,同时提供顺序性和持久性。采用Kafka的理由是,作为一个完整的生态系统,它在整体上仍然是无与伦比的。它展示了出色的性能,同时提供了一个丰富和成熟的环境,Kafka仍在以令人羡慕的速度增长。

Kafka的设计者和维护者在设计一个以性能为核心的解决方案时做了大量的工作。它的设计元素中很少有让人觉得是事后才想到的,或者是补全的。从将工作负载转移到客户端,到服务端日志的持久性、批处理、压缩、零拷贝I/O和并行流处理——Kafka向任何其他消息中间件厂商发起挑战,无论是商业的还是开源的。最令人印象深刻的是,它做到了这一点,却没有牺牲持久性、记录有序性和至少一次分发的语义。

Kafka不是最简单的消息中间件平台,还有许多需要改进的地方。在设计和构建高性能事件驱动系统之前,必须掌握总体和部分的顺序、主题、分区、消费者和消费者组的概念。虽然知识曲线很陡峭,但值得你花时间去学习。如果你知道这个谚语“red pill”(red pill,指为了达到对某种事物的深度探索或追求,选择去思考,不放弃,继续走下去,哪怕这条路多难走。)

Linkflow荣获「国家高新技术企业」认证

文丨娜可露露
近日,Linkflow荣获“国家高新技术企业”认证。

全国高新技术企业认定是由国家科技部、财政部、税务总局组成领导小组,在国家重点支持的高新技术领域内,对持续进行研究开发与技术成果转化,形成企业核心自主知识产权,并以此为基础开展生产经营活动的企业的认可。

经上海市科学技术委员会、上海市财政局、上海市国家税务局、上海市地方税务局等部门,以自主知识产权、研发人员占比、研发投入、创新能力、企业收入等维度作为评估标准,Linkflow最终以超标准的成绩成功入选“国家高新技术企业”行列。

从2011年起,Linkflow团队就开始深耕数字营销领域,从App运营到全渠道零售软件、营销自动化都有非常深的理解。

2017年3月,Linkflow正式成立,主要成员来自于SAP,微软,爱立信,中国电信等大型企业,拥有丰富的创业经验和强大的SaaS开发实力。

2017年6月,获得了第一个500强付费客户,并成立南京和广州分公司。

2017年11月,获得光速中国与真格基金联合天使投资。

2018年1月,南京研发中心入选南京321人才计划。

2018年8月,获得金沙江创投的百万美元A轮融资。

2019年5月,在CSIC 2019年度SaaS领域的权威创新评选中,荣获“年度最具创新SaaS产品”奖项。

2019年9月,入选微软加速器2019秋季班。

2020年1月 荣获2019中国零售创新峰会“年度最佳数字中台技术创新奖”。

Linkflow始终致力于为客户提供第一流的营销技术解决方案,通过低代码客户数据中台(CDP)帮助企业充分激活数据金库,赋予定义数据驱动流程的能力,支撑企业业务的数字化转型,让数据流动起来。

截至目前,Linkflow已服务包括平安、宝马、雅培在内的50+顶级企业。

在线旅游企业:提升在线客服的智能响应力

案例背景

所谓OTA(在线旅游企业),从它开头第一个字母就可以发现他的业务大多发生在线上,因此大量客户的咨询会在线上渠道例如微信、官网发生。而线上不同于传统的面对面模式,其带来的一大挑战便是如何及时响应客户询问。

面对这个挑战,有人认为可以根据客户问题中的关键字在微信中设置自动回复,但是客户提问的内容千差万别,企业很难穷尽客户的提问内容。

又有人会说,那也直接使用人工客服系统,当然,这也是一个解决方法,但这需要大量客服人员支持,运营成本将大幅上升。

除了上述问题,还有一个问题一直困扰OTA的运营人员:如何根据营销效果,实时调整营销策略,控制运营成本。如果一味提升优惠/奖励力度,虽然能吸引到大量客户,但是运营成本却居高不下,甚至会形成不良循环。

综上所诉,我们总结下来,OTA行业的核心诉求如下:

  • 及时响应客户需求,提升客户满意度
  • 实时获取营销效果,最小化客户激活成本

那接下来,我们就聊聊Linkflow是如何帮助OTA企业解决这两大诉求的。


解决方案

打通客服系统实现智能切换,高效响应客户诉求

前面我们提到,OTA行业客户的咨询大都出现在线上,并且越来越倾向于通过微信聊天的方式进行。那如何在保证客户满意度的前提下,又可以减少使用客服人员呢?

Linkflow通过自身强大和灵活的对接能力,可以快速对接OTA企业现有的客服系统,并结合Linkflow的客户旅程功能,在自动回复和人工回复中进行灵活切换。

首先,OTA的运营人员,可以通过Linkflow的报表功能,分析客户历史咨询内容,分析出高频咨询词汇。然后通过客户旅程,配置关键字自动回复。这样当客户咨询的内容中包含特定关键字时系统便可以自动进行回复。

针对需要人工客服接入的情况,Linkflow通过与现有客服系统的对接,提供了“关键字开启微信客服会话”功能。

运营人员可以设定特定关键字以打开客服系统接口。一旦用户回复的内容中包含该关键字,Linkflow会自动停止所有客户旅程自动回复,并将该客户的信息(最近聊天记录、客户基础画像、标签等)发送给人工客服,人工客服根据Linkflow发来的内容可以快速了解客户信息,从而与客户进行有效沟通,及时解决客户咨询问题。当客服对话结束后,客服系统会通过接口告知Linkflow,重新启动Linkflow客户旅程自动回复功能。

营销效果全局监测,最小化客户激活成本

Linkflow系统可以通过不同功能模块从多个维度分析营销效果:

  • 漏斗报表分析整体营销流程效果
  • 客户旅程转化目标分析单个营销过程效果
  • 客户分析报表分析个人营销效果

然后综合营销效果对应调整营销策略和营销手段,例如优惠金额,活动内容等。

举例来说,当某个活动是通过发放优惠券来吸引客户下单时,起初企业会发放中等面额的优惠券。运营一段时间后通过优惠券使用情况可以发现某些客户会积极参与活动,而某些客户没有参加。

这时,我们就可以针对这两个不同人群进行运营策略调整,通过分组和客户旅程进行个性化运营。对于积极参与的人群,适当降低优惠券金额,发送低面额的优惠券,而针对那群没参加的客户发送高面额的优惠券。再过一段时间后在进行分析和运营调整。

其目的就是尽可能找到每个客户的最低激活条件,从而在不降低客户活跃度的前提下,减少运营成本。


服务成果

客户响应率上升20%
运营成本下降10%

OLAP、OLTP的介绍和比较

原创作者:阿尼古
 
公众号: 小生love生活

OLTP与OLAP的介绍

数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

OLTP 系统强调数据库内存效率,强调内存各种指标的命令率,强调绑定变量,强调并发操作;
OLAP 系统则强调数据分析,强调SQL执行市场,强调磁盘I/O,强调分区等。

OLTP与OLAP之间的比较:

OLTP,也叫联机事务处理(Online Transaction Processing),表示事务性非常高的系统,一般都是高可用的在线系统,以小的事务以及小的查询为主,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中,单个数据库每秒处理的Transaction往往超过几百个,或者是几千个,Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等,如美国eBay的业务数据库,就是很典型的OLTP数据库。

OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
(1)CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上,逻辑读总量等于单个语句的逻辑读乘以执行次数,如果单个语句执行速度虽然很快,但是执行次数非常多,那么,也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读,或者是减少它们的执行次数。另外,一些计算型的函数,如自定义函数、decode等的频繁使用,也会消耗大量的CPU时间,造成系统的负载升高,正确的设计方法或者是优化方法,需要尽量避免计算过程,如保存计算结果到统计表就是一个好的方法。

(2)磁盘子系统在OLTP环境中,它的承载能力一般取决于它的IOPS处理能力. 因为在OLTP环境中,磁盘物理读一般都是db file sequential read,也就是单块读,但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候,就会出现大的性能问题。

OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术,Cache决定了很多语句不需要从磁盘子系统获得数据,所以,Web cache与Oracle data buffer对OLTP系统是很重要的。另外,在索引使用方面,语句越简单越好,这样执行计划也稳定,而且一定要使用绑定变量,减少语句解析,尽量减少表关联,尽量减少分布式事务,基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高,批量更新时要分批快速提交,以避免阻塞的发生。

OLTP 系统是一个数据块变化非常频繁,SQL 语句提交非常频繁的系统。 对于数据块来说,应尽可能让数据块保存在内存当中,对于SQL来说,尽可能使用变量绑定技术来达到SQL重用,减少物理I/O 和重复的SQL 解析,从而极大的改善数据库的性能。

这里影响性能除了绑定变量,还有可能是热快(hot block)。 当一个块被多个用户同时读取时,Oracle 为了维护数据的一致性,需要使用Latch来串行化用户的操作。当一个用户获得了latch后,其他用户就只能等待,获取这个数据块的用户越多,等待就越明显。 这就是热快的问题。 这种热快可能是数据块,也可能是回滚端块。 对于数据块来讲,通常是数据库的数据分布不均匀导致,如果是索引的数据块,可以考虑创建反向索引来达到重新分布数据的目的,对于回滚段数据块,可以适当多增加几个回滚段来避免这种争用。

OLAP,也叫联机分析处理(Online Analytical Processing)系统,有的时候也叫DSS决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,考核的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数,这个时候,Cache基本是没有效果的,数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽,如4Gb的光纤接口。

在OLAP系统中,常使用分区技术、并行技术。
分区技术在OLAP系统中的重要性主要体现在数据库管理上,比如数据库加载,可以通过分区交换的方式实现,备份可以通过备份分区表空间实现,删除数据可以通过分区进行删除,至于分区在性能上的影响,它可以使得一些大表的扫描变得很快(只扫描单个分区)。另外,如果分区结合并行的话,也可以使得整个表的扫描会变得很快。总之,分区主要的功能是管理上的方便性,它并不能绝对保证查询性能的提高,有时候分区会带来性能上的提高,有时候会降低。

并行技术除了与分区技术结合外,在Oracle 10g中,与RAC结合实现多节点的同时扫描,效果也非常不错,可把一个任务,如select的全表扫描,平均地分派到多个RAC的节点上去。

在OLAP系统中,不需要使用绑定(BIND)变量,因为整个系统的执行量很小,分析时间对于执行时间来说,可以忽略,而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引,物化视图,对于大的事务,尽量寻求速度上的优化,没有必要像OLTP要求快速提交,甚至要刻意减慢执行的速度。

绑定变量真正的用途是在OLTP系统中,这个系统通常有这样的特点,用户并发数很大,用户的请求十分密集,并且这些请求的SQL 大多数是可以重复使用的。
对于OLAP系统来说,绝大多数时候数据库上运行着的是报表作业,执行基本上是聚合类的SQL 操作,比如group by,这时候,把优化器模式设置为all_rows是恰当的。 而对于一些分页操作比较多的网站类数据库,设置为first_rows会更好一些。 但有时候对于OLAP 系统,我们又有分页的情况下,我们可以考虑在每条SQL 中用hint。 如:
Select  a.* from table a;


分开设计与优化

在设计上要特别注意,如在高可用的OLTP环境中,不要盲目地把OLAP的技术拿过来用。

如分区技术,假设不是大范围地使用分区关键字,而采用其它的字段作为where条件,那么,如果是本地索引,将不得不扫描多个索引,而性能变得更为低下。如果是全局索引,又失去分区的意义。

并行技术也是如此,一般在完成大型任务时才使用,如在实际生活中,翻译一本书,可以先安排多个人,每个人翻译不同的章节,这样可以提高翻译速度。如果只是翻译一页书,也去分配不同的人翻译不同的行,再组合起来,就没必要了,因为在分配工作的时间里,一个人或许早就翻译完了。

位图索引也是一样,如果用在OLTP环境中,很容易造成阻塞与死锁。但是,在OLAP环境中,可能会因为其特有的特性,提高OLAP的查询速度。MV也是基本一样,包括触发器等,在DML频繁的OLTP系统上,很容易成为瓶颈,甚至是Library Cache等待,而在OLAP环境上,则可能会因为使用恰当而提高查询速度。

对于OLAP系统,在内存上可优化的余地很小,增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法,当然这也意味着系统成本的增加。

比如我们要对几亿条或者几十亿条数据进行聚合处理,这种海量的数据,全部放在内存中操作是很难的,同时也没有必要,因为这些数据快很少重用,缓存起来也没有实际意义,而且还会造成物理I/O相当大。 所以这种系统的瓶颈往往是磁盘I/O上面的。

对于OLAP系统,SQL 的优化非常重要,因为它的数据量很大,做全表扫描和索引对性能上来说差异是非常大的。


其他

Oracle 10g以前的版本建库过程中可供选择的模板有:
Data Warehouse (数据仓库)
General Purpose  (通用目的、一般用途)
New Database
Transaction Processing  (事务处理)
Oracle 11g的版本建库过程中可供选择的模板有:
一般用途或事务处理
定制数据库

数据仓库

个人对这些模板的理解为:

联机分析处理(OLAP,On-line Analytical Processing),数据量大,DML少。使用数据仓库模板
联机事务处理(OLTP,On-line Transaction Processing),数据量少,DML频繁,并行事务处理多,但是一般都很短。使用一般用途或事务处理模板。

决策支持系统(DDS,Decision support system),典型的操作是全表扫描,长查询,长事务,但是一般事务的个数很少,往往是一个事务独占系统。