国外英文网站,网页设计软件最好用,vi设计找哪家公司,深圳 网站设计 公司背景 随着整个中国互联网下半场的到来#xff0c;用户红利所剩无几#xff0c;原来粗放式的发展模式已经行不通#xff0c;企业的发展越来越趋向于精耕细作。美团的价值观提倡以客户为中心#xff0c;面对海量的用户行为数据#xff0c;如何利用好这些数据#xff0c;并通… 背景 随着整个中国互联网下半场的到来用户红利所剩无几原来粗放式的发展模式已经行不通企业的发展越来越趋向于精耕细作。美团的价值观提倡以客户为中心面对海量的用户行为数据如何利用好这些数据并通过技术手段发挥出数据的价值提高用户的使用体验是我们技术团队未来工作的重点。 大众点评在精细化运营层面进行了很多深度的思考我们根据用户在App内的操作行为的频次和周期等数据给用户划分了不同的生命周期并且针对用户所处生命周期制定了不同的运营策略比如针对成长期的用户主要运营方向是让其了解平台的核心功能提高认知比如写点评、分享、收藏等。同时我们还需要为新激活用户提供即时激励这对时效性的要求很高从用户的行为发生到激励的下发需要在毫秒级别完成才能有效提升新用户的留存率。 所以针对这些精细化的运营场景我们需要能够实时感知用户的行为构建用户的实时画像。此外面对大众点评超大数据流量的冲击我们还要保证时效性和稳定性这对系统也提出了非常高的要求。在这样的背景下我们搭建了一套用户行为系统User Action System以下简称UAS。 面临的问题 如何实时加工处理海量的用户行为数据我们面临以下几个问题 上报不规范 点评平台业务繁多用户在业务上产生的行为分散在四处格式不统一有些行为消息是基于自研消息中间件Mafka/Swallow有些行为消息是基于流量打点的Kafka消息还有一些行为没有对应的业务消息收集处理工作是一个难点。上报时效性差 目前大部分行为我们通过后台业务消息方式进行收集但是部分行为我们通过公司统一的流量打点体系进行收集但是流量打点收集在一些场景下无法满足我们的时效性要求如何保证收集处理的时效性我们需要格外关注。查询多样化 收集好行为数据之后各个业务对用户行为的查询存在差异化比如对行为次数的统计不同业务有自己的统计逻辑。无法满足现有业务系统的查询需求如何让系统既统一又灵活这对我们的业务架构能力提出了新要求。针对问题模型方案思考 格式统一 面对繁杂的格式我们如何进行统一在这里我们参考了5W1H模型将用户的行为抽象为以下几大要素 其中行为作用的地方这里一般都是作用对象的ID比如商户ID评论ID等等。 行为的属性代表的是行为发生的一些额外属性比如浏览商户的商户品类、签到商家的城市等。 上报统一 对于用户行为的上报之前的状态基本只有基于流量打点的上报虽然上报的格式较为标准化但是存在上报延时数据丢失的情况不能作为主要的上报渠道因此我们自建了其他的上报渠道通过维护一个通用的MAPI上报通道直接从客户端通过专有的长连接通道进行上报保证数据的时效性上报后的数据处理之后进行了标准化再以消息的形式传播出去并且按照一定的维度进行了TOPIC的拆分。目前我们是两个上报通道在不同场景使用对外是无感知的。 服务统一 不同场景下对用户行为处理的数据规模要求时效性要求也是不一样的比如有些场景需要在用户行为上报之后立刻做相关的查询因此写入和查询的性能要求很高有些场景下只需要进行行为的写入就可以采取异步的方式写入针对这样不同的场景我们有不同的解决方案但是我们统一对外提供的还是UAS服务。 架构统一 从数据的收集上报到处理分发到业务加工到持久化UAS系统架构需要做到有机的统一既要能满足日益增长的数据需求同时也要能够给业务充分的灵活性起到数据中台的作用方便各个业务基于现有的架构上进行快速灵活的开发满足高速发展的业务。 系统整体架构 针对这样一些想法开始搭建我们的UAS系统下图是UAS系统目前的整体架构 数据源简介 我们处理的数据源分为实时数据源和离线数据源 实时数据源主要分两块一块是基于客户端打点上报另外一块是我们的后台消息这两部分是基于公司的消息中间件Mafka和开源消息中间件Kafka以消息的形式上报上来方便我们后续的处理MQ的方式能够让系统更好的解耦并且具备更高的吞吐量还可以指定消费的起始时间点做到消息的回溯。历史数据的来源主要是我们的Hive和HDFS可以方便的做到大数据量的存储和并行计算。离线计算简介 在离线处理这块主要包含了MR模块和Spark模块我们的一些ETL操作就是基于MR模块的一些用户行为数据的深度分析会基于Spark去做其中我们还有一个XT平台是美团点评内部基于Hive搭建的ETL平台它主要用来开发数据处理任务和数据传输任务并且可以配置相关的任务调度信息。 实时计算简介 对于用户行为的实时数据处理我们使用的是Storm实时大数据处理框架Storm中的Spout可以方便的对接我们的实时消息队列在Bolt中处理我们的业务逻辑通过流的形式可以方便的做到业务数据的分流、处理、汇聚并且保持它的时效性。而且Storm也有比较好的心跳检测机制在Worker挂了之后可以做到自动重启保证任务不挂同时Storm的Acker机制可以保持我们实时处理的可靠性。 接下来我们按照用户行为数据的处理和存储来详细介绍我们的系统。 数据的处理 离线处理 离线数据的处理主要依赖的是我们的数据开发同学在构建用户行为的数据仓库时我们会遵循一套美团点评的数据仓库分层体系。 同时我们会出一些比较通用的数据方便线上用户使用比如我们会根据用户的行为发放勋章奖励其中一个勋章的发放条件是用户过去30天的浏览商户数量我们不会直接出一个30天的聚合数据而是以天为周期做一次聚合然后再把30天的数据聚合这样比较通用灵活一些上层应用可以按照自己的业务需求进行一些其他时间段的聚合。 在数据的导入中我们也有不同的策略 比如用户的行为路径分析中我们在Hive中计算好的结果数据量是非常庞大的但是Hive本身的设计无法满足我们的查询时效性要求为了后台系统有比较好的体验我们会把数据导入到ES中这里我们无需全量导入只要抽样导入即可这样在满足我们的查询要求的同时也能提高我们的查询效率。在导入到一些其他存储介质中传输的效率有时候会成为我们的瓶颈比如我们导入到Cellar中数据量大写入效率也不高针对这种情况我们会采用增量导入的方式每次导入的数据都是有发生变化的这样我们的导入数据量会减少从而减小我们的传输耗时。实时处理 实时处理这块我们构建了基于点评全网的流量网关所有用户产生的行为数据都会通过实时上报通道进行上报并且会在我们的网关中流转我们在这里对行为数据做一些加工。 Reader 我们目前使用的是Storm的Spout组件对接我们的实时消息基于抽象的接口未来可以扩展更多的数据来源比如数据库、文件系统等。 Parser Parser是我们的解析模块主要具备以下功能 我们会对字段做一些兼容不同版本的打点数据可能会有差异。JSON串的处理对于多层的JSON串进行处理使得后续可以正常解析。时间解析对于不同格式的的上报时间进行兼容统一。Transformer Transformer是我们的转换模块它是一种更加高级的处理过程能够提供给业务进行灵活的行为属性扩展 1. 比如需要根据商户ID转换出商户的星级、品类等其他信息我们可以在我们的明细扩展层配置一个Transformer。 2. 或者业务有自己的转换规则比如他需要把一些字段进行合并、拆分、转换都可以通过一个Transformer模块解决这个问题。 Sender Sender是我们的发送模块将处理好的数据按照不同的业务数据流进行转发一般我们是发送到消息队列中Sender模块可以指定发送的格式、字段名称等。 目前我们的实时处理基本上已经做到可视化的配置之前需要几人日才能做到的用户行为数据分发和处理现在从配置到验证上线只需要几分钟左右。 近实时处理 在近线计算中我们会把经过流量网关的数据通过Kafka2Hive的流程写入到我们的Hive中整个过程的时延不超过15分钟我们的算法同学可以利用这样一些近实时的数据再结合其他的海量数据进行整体的加工、存储主要针对的是一些时效性要求不高的场景。 通过上面三套处理方法离线、实时、近实时我们可以很好的满足业务不同的时效性需求。 数据的存储 经过实时处理之后基本上已经是我们认为的标准化数据我们会对这些数据进行明细存储和聚合存储。 明细存储 明细的存储是为了保证我们的数据存储能够满足业务的查询需求这些明细数据主要是用户的一些核心操作行为比如分享、浏览、点击、签到等这些数据我们会按照一定的粒度拆分存储在不同的搜索集群中并且有一定的过期机制。 上图是我们的处理方式: 通过Transformer业务方可以通过自己的服务对数据的维度进行扩展从而Sender发出的Message就是满足业务需求的数据。然后在Kafka2Hive这一步会去更新对应的Hive表结构支持新的扩展数据字段同时在XT作业中可以通过表的关联把新扩展的字段进行补齐。重跑我们的历史之后我们的全量数据就是已经扩展好的字段。同时我们的实时数据的写入也是扩展之后的字段至此完成了字段的扩展。NoSQL存储 通过明细数据的存储我们可以解决大部分问题。虽然搜索支持的查询方式比较灵活但是某些情况下查询效率会较慢平均响应时间在20ms左右对一些高性能的场景或者一些基础的用户行为画像这个响应时间显然是偏高的。因此我们引入了NoSQL的存储使用公司的存储中间件Squirrel和Cellar其中Cellar是基于淘宝开源的Tair进行开发的而Squirrel是基于Redis-cluster进行开发的两者的差异就不在此赘述简单讲一下我们的使用场景 对于冷热比较分明单个数据不是很大小于20KB过大会影响查询效率并且value不是复杂的我们会使用Cellar比如一些低频次的用户行为数据。在大并发下对于延迟要求极为敏感我们会使用Redis。对于一些复杂的数据结构我们会使用到Redis比如会用到Redis封装好的HyperLogLog算法进行数据的统计处理。系统特性 灵活性 构建系统的灵活性可以从以下几个方面入手 对用户的行为数据可以通过Transformer组件进行数据扩展从而满足业务的需求业务只需要开发一个扩展接口即可。第二个方面就是查询我们支持业务方以服务注册的方式去编写自己的查询逻辑或者以插件的形式托管在UAS平台去实现自己负责的业务逻辑比如同样一个浏览商户行为有些业务的逻辑是需要看某批用户最近7天看了多少家3星商户并且按照shopID去重有些业务逻辑可能是需要看某批用户最近7天浏览了多少个品类的商户。因此这些业务复杂的逻辑可以直接托管在我们这里对外的接口吐出基本是一致的做到服务的统一。我们系统目前从实时分发/计算/统计/存储/服务提供是一套比较完备的系统在不同的处理阶段都可以有不同的组件/技术选型根据业务的需求我们可以做到灵活的组合、搭配。低延时 对于一些跨周期非常长存储非常大的数据我们采用了Lambda架构既保证了数据的完备性又做到了数据的时效性。其中Batch Layer为批处理层会有固定的计算视图对历史数据进行预计算生成离线结果Speed Layer为实时计算层对实时数据进行计算生成增量的结果最终Server Layer合并两个视图的数据集从而来提供服务。 可用性 数据可用性 前面提到了我们采用Lambda架构处理一些数据但是离线数据有时候会因为上游的一些原因处理不稳定导致产出延迟这个时候为了保证数据的准确性我们在Speed Layer会多保留两天的数据 保证覆盖到全量数据。如图所示 服务的可用性 在服务的可用性方面我们对接入的服务进行了鉴权保证服务的安全可靠部分核心行为我们做了物理上的隔离保证行为数据之间不会相互影响同时接入了公司内部基于Docker的容器管理和可伸缩平台HULK能做到自动扩容。对于数据使用有严格权限审计并且做了相关数据脱敏工作。 监控 从用户行为数据的产生到收集分发到最后的处理我们都做到了相关的监控比如因为我们的代码改动发生处理时长变长我们可以立马收到相关的报警检查是不是代码出问题了。或者监控到的行为产生次数和历史基线比发生较大变化我们也会去追踪定位问题甚至可以早于业务先发现相关问题。下图是分享商户行为的一个监控 结语 用户行为系统搭建之后目前 处理的上报数据量日均在45亿。核心行为的上报延迟从秒级降低到毫秒级。收录用户行为数十项提供用户行为实时流。提供多维度下的实时服务日均调用量在15亿左右平均响应时间在3ms99线在10ms。目前系统承载的业务还在不断增长中相比以前的T1服务延时大大提升了用户体验。我们希望构建用户行为的中台系统通过我们已经抽象出的基础能力解决业务80%的问题业务可以通过插件或者接口的形式在我们的中台上解决自己个性化的问题。 未来展望 目前我们的实时计算视图比较简单做的是相对比较通用的聚合计算但是业务的聚合规则可能是比较复杂且多变的不一定是直接累加未来我们希望在聚合计算这块也能直接通过配置的方式得到业务自定义的聚合数据快速满足线上业务需求。 同时用户的实时行为会流经我们的网关我们对用户行为进行一些特征处理之后结合用户过去的一些画像数据进行用户意图的猜测这种猜测是可以更加贴近业务的。 作者简介 朱凯资深工程师2014年加入大众点评先后从事过账号端/商家端的开发有着丰富的后台开发架构经验同时对实时数据处理领域方法有较深入的理解目前在点评平台负责运营业务相关的研发工作构建精细化运营的底层数据驱动能力着力提升用户运营效率。重点打造点评平台数据中台产品——灯塔。