很多人爱去阿里云国际站购买云服务器，但是我们都知道阿里云国际站使用国内身份信息是无法注册的，需要信用卡或者PayPal账户。如果你没有这两样东西，可以有一个简单的途径就是选择阿里云国际渠道注册生成的阿里云国际账号是不需要绑定信用卡或PayPal的。阿里云国际站Lin是一家阿里云国际站正規渠道商，可以帮你注册购买阿里云国际版。购买和后期服务器管理操作还是在阿里云官方网站。下面就来说说如何开通！！！阿里云国际版和国内版之间区别，产品和服务的日常价格基本上是没啥区别的，但是国际版的产品越高配价格越划算，性价比越高，双十一活动价格也是比日常价便宜得多。阿里云中国版云安全中心日常价既然阿里云国际版跟中国版的产品、价格都差距不大，那为什么还要区分开这两个站点呢？原因是阿里云中国站的主体注册在中国大陆，受大陆地方法律监管，对标国内几大云厂商，如腾讯云、华为云，主要是为大陆内的企业客户提供产品和服务。阿里云国际站的主体注册地在国外，受国外地方法律监管，对比中国版最大的区别在于不用实名认证，仅需一个邮箱即可注册。那么，阿里云国际版国内可以注册吗？注册流程是怎样的呢？较之以往，阿里云国际版虽然可以只用邮箱注册，免除实名这一步骤，但注册后需要绑定PayPal信用卡或其他海外支付方式，对于部分客户来说还是有门槛的，账户使用不当还会遭受风控。但现在，我们可以通过将自己注册的阿里云国际版账号绑定在经销商名下，通过经销商对账号进行代充值，那么我们就可以跟经销商之间进行结算，支持多种货币支付方式，包括人民币，量大还能申请特殊折扣优惠，账号安全也能得到保障，免受风控。

阿里云国际站版都可以购买那些地域的不用备案的服务器呢？　　阿里云国际站全球节点IP多个国家美国代充值美元代付方式。　　香港（中国），韩国-首尔，亚太东南1-新加坡，澳大利亚-悉尼，泰国-曼谷，马来西亚-吉隆坡，印度尼西亚-雅加达，菲律宾-马尼拉，日本-东京，美国西部1-硅谷，美国东部1-佛吉尼亚，欧洲中部1-德国-法兰克福，英国-伦敦，迪拜，孟买，韩国　　多种支付方式，免备案，无需绑定信用卡　　提供邮箱和手机号即可办理阿里云国际站业务。　　阿里云国际版和国内版之间区别，产品和服务的日常价格基本上是没啥区别的，但是国际版的产品越高配价格越划算，性价比越高，双十一活动价格也是比日常价便宜得多。　　既然阿里云国际版跟中国版的产品、价格都差距不大，那为什么还要区分开这两个站点呢？　　原因是阿里云中国站的主体注册在中国大陆，受大陆地方法律监管，对标国内几大云厂商，如腾讯云、华为云，主要是为大陆内的企业客户提供产品和服务。　　阿里云国际站的主体注册地在国外，受国外地方法律监管，对比中国版最大的区别在于不用实名认证，仅需一个邮箱即可注册。　　那么，阿里云国际版国内可以注册吗？注册流程是怎样的呢？　　较之以往，阿里云国际版虽然可以只用邮箱注册，免除实名这一步骤，但注册后需要绑定PayPal，信用卡或其他海外支付方式，对于部分客户来说还是有门槛的，账户使用不当还会遭受风控。　　但现在，我们可以通过将自己注册的阿里云国际版账号绑定在经销商-123clouds名下，通过经销商-123clouds对账号进行代充值，支持多种货币支付方式，包括人民币，量大还能申请特殊折扣优惠，账号安全也能得到保障，免受风控。　　注册开通阿里云国际版之前我们需要两样东西：　　1.一个邮箱　　2.海外手机号：支持全球各国，中国大陆方向除外。美国手机号可以考虑使用GoogleVoice，香港手机号：无忧行和易博通。　　开户过程　　一、联系阿里云国际站渠道分销商-123clouds给您发账号注册邀请链接　　二、通过123clouds发给你的邀请链接（点击clickhere）创建新账户，注意地区不要随便选，如果准备了香港手机号就选香港，美国就选美国，否则过不了验证。　　三、完善账单信息　　账单信息可随便写，但是个人建议写完自己记住了。　　四、信息保存后进入如下提示，恭喜你，账号注册完成了！　　充值方式　　打开费用中心即可看到阿里云额度支付方式（分销商充的余额），充值后就开始对云产品进行采购了。　　分销商123clouds可算是一家爱国的良心分销商，支持人民币付款，支持的充值方式非常多，微信，支付宝，港币对公账户，美金对公账户，甚至还支持U币。　　另外如果你的阿里云国际版遇到了支付方式困难，无法续费，比如之前绑定的PP被封或者信用卡到期，也可以通过我们申请把你的账户关联123clouds分销商，帮你充余额续费阿里云国际版。

阿里云国际版和国内版之间区别，产品和服务的日常价格基本上是没啥区别的，但是国际版的产品越高配价格越划算，性价比越高，双十一活动价格也是比日常价便宜得多。既然阿里云国际版跟中国版的产品、价格都差距不大，那为什么还要区分开这两个站点呢？原因是阿里云中国站的主体注册在中国大陆，受大陆地方法律监管，对标国内几大云厂商，如腾讯云、华为云，主要是为大陆内的企业客户提供产品和服务。阿里云国际站的主体注册地在国外，受国外地方法律监管，对比中国版最大的区别在于不用实名认证，仅需一个邮箱即可注册。那么，阿里云国际版国内可以注册吗？注册流程是怎样的呢？较之以往，阿里云国际版虽然可以只用邮箱注册，免除实名这一步骤，但注册后需要绑定PayPal信用卡或其他海外支付方式，对于部分客户来说还是有门槛的，账户使用不当还会遭受风控。但现在，我们可以通过将自己注册的阿里云国际版账号绑定在经销商-123clouds名下，通过经销商-123clouds对账号进行代充值，那么我们就可以跟经销商之间进行结算，支持多种货币支付方式，包括人民币，量大还能申请特殊折扣优惠，账号安全也能得到保障，免受风控。123clouds作为阿里云国际版战略级经销商，专业为全球企业客户提供阿里云国际版开户注册、认证、充值等服务，通过开通阿里云国际版只需要一个邮箱，不需要PayPal信用卡就可以帮你开通、充值、新购、续费阿里云国际版，并且多币种支付。注册开通阿里云国际版之前我们需要两样东西：1.一个邮箱2.海外手机号：支持全球各国，中国大陆方向除外。美国手机号可以考虑使用Google Voice ， 香港手机号：无忧行和易博通。开户过程一、联系阿里云国际站渠道给您发账号注册邀请链接二、通过 aliyun166发给你的邀请链接（点击click here）创建新账户，注意地区不要随便选，如果准备了香港手机号就选香港，美国就选美国，否则过不了验证。三、完善账单信息帐单信息可随便写，但是个人建议写完自己记住了。四、信息保存后进入如下提示，恭喜你，账号注册完成了！充值方式打开费用中心即可看到阿里云额度支付方式（分销商充的余额），充值后就开始对云产品进行采购了。支持多币种结算，美元为主。

开发者学堂课程【消息队列 RocketMQ 5.0 云原生架构升级课程： RocketMQ 5.0 多样消费功能详解消息过滤】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1234/detail/18399RocketMQ5.0 多样消费功能详解-消息过滤 内容介绍一、消费过滤概念介绍二、电商场景应用三、Rocket MQ 的过滤模式四、最佳实践介绍五、上手 EDMO 演示 一、消费过滤概念介绍首先在消息中间件使用的过程中，一个主题所对应的消费者，他想要通过规则只消费这个主题下面具有某些特征的消息，然后过滤掉自己不关心的消息,这个功能的话叫消息过滤.这组图中所描述的：生产者会向一个主题发送很多不同类型的一个消息，然后通过颜色来标识它们，其中有橙色的、黄色的，还有灰色的，这个主题的话它有对应的两个消费者，一个消费者他想要消费承受的消息,第二个，消费者的话，他想要消费黄色的和灰色的一个消息，那么想要达到这样的一个效果的话，就需要通过消息过滤这个功能来实现。 二、电商场景应用 那以常见的一个电商的一个场景为例，来看看那个消息过滤在实际应用过程中起到的作用。那电商平台在设计的时候往往会存在系统拆分系功能模块多，调用链路长，以及系统依赖复杂的一个特点，消息中间件在其中就起到了一个异不解偶异不通信的一个作用。特别是在双11这样一个流量高峰期，消息中间件还起到一个削峰填谷的一个作用,那么在消息中间的使用方面的话，电商平台会因为覆盖的一个业务众多，还会定义很多的一个消息主题，然后消息的收发量的话，也会随着的一个交易量以及订阅系统的一个数量的增加而增大,那随着业务系统的一个水平拆解以及垂直业务的一个增加，相应的一个消息的主题，也会呈现出一个高订阅笔和低投机比的一个状态,高利率比主要是指一个消息的一个主题，他被很多的一个消费者进行了订阅，比如说这个比例是1:300，那低投低比的话主要是指在如此高的一个订阅的一个比的一个情况下，那一条消息的话却只需要投递给少量的一个消费者，比如说只有15个，然后其他的285个那个消费者的话，都对这个消息进行一个过滤。举例来说，在一个交易链路中，一个订单的一个处理流程，它会分为下单支付，还有物流发货的一个流程,那么这个流程就会涉及到一个订单的操作以及订单的一个状态机的一个变化,那么下游的系统的话，包括积分物流通知，还有实时计算这个系统，他们是通过消息中间件来去监听这个订单的一个变更消息，但是他们对这个订单的一个不同状态的一个消息有着一个不同的一个需求。比如说积分系统它只关心的一个下单的一个消息，然后只要下单的话，就扣减那个积分，然后物流系统的话，它只要关心的话，是支付消息以及收货的消息,比如说支付的话，就会去通知商家发货，那用户确认收货的话就会去完成整个物流订单。那么实时计算这种系统的话，它可能需要统计订单不同状态下的一个数据，所以他所有的消息他都要消费。那试想一下，就是如果没有消息过滤这个功能的话，该去如何支持这样的一个功能，这边的话想到了有两个方案，第一个方案的话就是基于主题的一个深度的拆分，然后将不同的消息发送到不同的主题上面，然后这对于生产者来说的话，也就意味着消费者他有多少个消费场景，那就需要新建多少个topic，这就无疑对生产者带来了一个巨大的一个维护成本。对于消费者来说的话，消费者可能会需要同时订阅多个topic，那这同时也会带来一些维护成本,另外的话就是消息被那个主题拆分之后，他们的资金的一个消费顺序就没有办法保证了。比如说一个订单，它涉及到一个下单和支付的一个操作，那这个这两个消息的话显然是需要被顺序进行处理了。那第二个方面的话主要是消费者收到消息之后，自行进行本地的一个过滤，那这就意味着所有的消息都会推送到消费者端，做一个计算，那这无疑就会增加了一个网络带宽的一个成本，同时也增加了一个增加了消费者在那个内存和CPU上面的一个消耗。那么有了消息过滤这个功能之后的话，生产者就只需要向一个主题去投递消息，然后服务端的话根据订阅规则进行计算，然后并按需的投递到每一个消费者，然后这样生产者和消费者他们的代码维护也就非常的友好，同时也能很大程度的去降低整个网络的一个带宽，减少了这个消费者的一个内存占用和CPU的一个消耗，Rocket MQ它是众多消息中间件中为数不多的支持消息过滤的一个系统，这也是他能够作为业务集成消息首选方案的一个重要的一个基础之一。 三、Rocket MQ 的过滤模式那在功能层面的话，Rocket MQ它支持两种过滤方式，分别是tag标签过滤和SQL属性过滤。那下面就对这两种过滤模式进行功能上的一些介绍以及技术原理的一个分析。（1）tag标签过滤及原理首先来介绍一下tag标签过滤，它是Rocket MQ提供了一个最基础的一个消息过滤能力，它主要是基于生产者为消息设置了一个tag标签来进行匹配的，那tag过滤的话在语法方面的话，它支持单tag的一个匹配，然后多tag的匹配，还有全坦克的匹配，三种语法在使用方式上面，消息在发送的时候，只需要在这个消息上面设置一个标签，然后在订阅的时候，就可以通过设置单个标签，多个标签以及所有标签来进行消息的匹配就可以了。那么Rocket MQ实现它的一个原理是怎么样的，首先就是在消息存储的时候，Rocket MQ是通过iPad only的这种方式，来将所有的主题的消息写在一个logo文件中，然后这可以有效的提升了那个消息的写入速率，为了消费时候能够快速的检索到消息，那它会在后台以异步任务的方式，将消息的一个位点以及消息的大小，还有消息标签值存储在一个consume cue的一个索引文件中，那加上这个 tag标签存在这个索引文件中，其实就是为了支持通过标签来进行消息的过滤的时候，可以在索引这个层面，就把这个小企的标签能够获取到，然后就不需要去文件中去获取这个标签了，减少了读取这个文件的一个系统l和内存的一个开销。Rocket MQ里面去存储标签的哈希值的话，主要是为了能够保证整个Rocket MQ的一个文件能够正常的一个处理，然后这样可以有效的减少的存储空间，还要提升整个索引一个查询的一个读取的一个效率，那整个tag标签过滤的一个流程。是这样的，首先就是生产者对消息打上自己的一个业务标签之后，发送到给的一个 broken broker，收到这个消息之后会写入到Rocket MQ中里面去，然后通过异步现成的这种方式，将消息分发到的一个Rocket MQ里面，然后Rocket MQ里面就会去存储这个消息的一个标签的哈希值，消费者在启动的时候的话，他会先去像block注册它，然后将它的订阅关系去上传到高端，会将这个订阅关系以及标签的这个哈希值保存在那个内存中。那当消费者去拉取消息的时候，block会去根据它的定义关系以及它对应的队列去consumqueue里面去检索消息，那就会将订阅关系里面的一个标签希值跟cosplay里面消息的哈希值做一个比较，如果匹配的话，就会发送给的一个消费者，但是希匹配的话并不代表它一定是相等的，所以消费者在收到这个消息之后，也会将这个消息中的一个真实的一个标签值和订阅关系里面的一个标签值做一个精确的匹配，然后匹配成功之后才会去进行消费。 （2）SQL属性过滤及原理 Rocket MQ的第二种那个过滤，模式的话就是SQL过滤，然后它是Rocket MQ提供了一种比较高级的一个过滤模式，它是通过生产者在发送消息的时候，在消息上面设置一个多个业务属性，然后订阅者在匹配的时候，可以通过 SQL这种表达式对这个属性进行过滤。然后在过滤语法方面的话，它主要支持一些常用的一些授课语法，包括一些数字的一些比较，字符串的一个比较，还有一些看空的一些运算，可以支持比较复杂的一个逻辑的运算。那在使用上面的话，发送消息的时候，只要在消息上面设置的一个属性，然后在订阅的时候，就可以订阅单个属性，也可以订阅多个属性，当然也可以定义所有的属性。Rocket MQ中那个 SQL过滤的一个实验原理是这样的，首先搜狗过滤是是需要将消息的一个属性和circle表达式来进行一个匹配的，那这对服务端的一个内存以及CPU的消耗会有很大的开销。为了降低这样的一个开销，罗特梅q采用了一个不容过滤器这种方式来进行优化，那当布洛克收到消息之后，会预先对那个通过一计算的方式，将所有的订阅进行消息的一个匹配，然后如果匹配的话，然后会将这个结果写到一个不容过滤器的一个位图里面去，然后存储在的一个消费队列Rocket MQ里面的一个扩展文件里面。然后在消费的时候，block会使用这个 不能过滤器的一个位图，然后通过和消费者的一个SQL进行一个不能过滤器的一个过滤，然后这样的话就可以避免在消息一定不匹配的这种情况下，就不需要去 communicate logo里面去将这个消息的属性给拉出来，然后再进行一个 circle的匹配了，这就可以有效的降低生效匹配的一个计算的一个消息量，同时也减少了那个服务端的内存和 CPU的一个开销。那么整个circle过滤的一个处理流程是这样的，首先消费者通过心跳去上传订阅关系，如果block判断它是有circle过滤的话，它就会通过不容过滤器这种算法，然后生成这个 circle所对应的sql过滤器的这个匹配参数，然后存储在这样的一个 consumer philter dater中，然后生产者在发送消息的时候，在消息上面设置自己的一个业务属性，然后发送到给的博客端。block 收到这个消息之后就会写入到Rocket MQ那个的logo里面去，然后通过一部现成的这种方式去分发到的casi cue里面，在写入之前，会将这个消息的一个属性跟他所有的订阅关系的Rocket MQ进行一个匹配。那如果通过了就会将这个不能过去的匹配参数合并成一个完整的一个部分过滤器的一个位图，存储在这个 cosmic的一个弹性的一个文件里面去。那消费者在消费这个消息的时候，那block就会去获取到这个Rocket MQ里面每个消息的一个消费过滤位图，然后跟跟这个消费者的 circle的一个过滤匹配参数，做一个不能过去的一个过滤。然后如果是匹配的话，那就说明可能是需要被投递给消费者，如果是不批的话就需要被过滤掉。然后不能过于去返回匹配成功。 就需要将消息从里面去读取出来，然后将它的属性跟这个表达式再做一次，这个表达是一个精确的一个匹配。然后如果这次再匹配的话，就会去投递给的消费者。

导读：消息服务作为应用的通信基础设施，是微服务架构应用的核心依赖，也是实践云原生的核心设计理念的关键技术，通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点，所以消息服务的云原生化是至关重要的。来源 | 阿里巴巴云原生公众号从虚拟化技术诞生以来，IaaS/PaaS/SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年，Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。有了“云原生”这个概念后，我们就一直在思考传统的消息中间件需要做些什么才能加上云原生这个修饰词，而这也正是本书探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。《云原生消息队列Apache RocketMQ》一书将为你详细解答。本书亮点​从演进路线出发，揭晓云原生时代消息中间件发展历程以双十一实践为例，解读 RocketMQ 的强大功能实战演练，教你打造定制化 DevOps 平台免费下载点击链接即可免费下载电子书：https://developer.aliyun.com/topic/download?spm=a2c6h.12873639.0.0.fec61a0aibp5f0&id=1217​注：所有书中实战的部分都可以登录阿里云知行动手实验室 https://start.aliyun.com/ 进行免费实操。精彩内容抢先看​《开篇：云原生时代消息中间件的演进路线》《Apache RocketMQ 的 Service Mesh 开源之旅》《阿里的 RocketMQ 如何让双十一峰值之下 0 故障》《云原生时代 RocketMQ 运维管控的利器 - RocketMQ Operator》《基于 RocketMQ Prometheus Exporter 打造定制化 DevOps 平台》《当 RocketMQ 遇上Serverless，会碰撞出怎样的火花》

推荐系统常用数据集和验证方法01、推荐技术简介在大数据和人工智能时代，智能推荐系统和技术已经成为电商、资讯、娱乐、教育、旅游和招聘等众多在线服务平台的核心技术、标准配置和重要引擎，用于帮助用户从海量物品中快速地找到他们感兴趣的物品（例如商品、新闻、视频、课程、景点和岗位等），特别是用户不容易发现的长尾物品（tail items），有效地缓解了信息过载（information overload）问题。例如，抖音海外版TikTok推荐算法凭借其精准的视频推荐和有效的新领域拓展等功能，被《麻省理工科技评论》（MIT Technology Review）评为2021年全球十大突破性技术之一。需要说明的是，物品可以是一组物品（例如旅游套餐推荐等），而用户也可以是一群用户（例如户外集体活动推荐等）。同时，有些场景中用户也可以作为“物品”，例如社交平台上的好友推荐等，即给用户推荐有相似兴趣的用户。如图1-1所示，在推荐系统中，通过对用户行为和其他信息的建模，相关算法和技术能较为有效地挖掘和学习用户的真实偏好，进而为用户提供精准的个性化推荐服务，这一过程可以简单地概括为“行为→偏好→推荐”。与信息检索中的“查询串­→­相关性→匹配”相比，至少可以看到两方面的重要区别：（1）行为 vs. 查询串，前者关注用户与系统的互动，后者侧重用户主动查询的内容；以及（2）偏好 vs. 相关性，前者关注用户的个性化需求，后者侧重查询串与候选文档（或网页）在内容方面的匹配程度。在电商、资讯等众多应用场景中，相较于物品的描述、用户的画像和行为的上下文等其他信息，用户行为往往是与用户的偏好最直接相关的，例如，用户购买商品和阅读新闻等的行为较能体现用户的喜好和兴趣。因此，对用户行为数据的建模，受到了学术界和工业界的广泛关注，并且在知名学术期刊和学术会议上发表了大量相关的研究论文（请参见附录1和附录2）。美国国防部（Department of Defense, DoD）也在2014年将一个类似的问题——对人类行为的计算机建模——列为六大颠覆性基础研究领域之一。在推荐系统领域，科研人员对用户的各种行为数据进行了较为深入的研究，主要包括以下几种类型：（1）显式反馈，例如用户对物品的1~5分的数值评分（numerical rating）行为和喜欢/不喜欢的二值评分（binary rating）行为，以及点赞（like）等单值行为；（2）隐式反馈（又称为单类反馈），例如用户对物品的点击（click）、浏览（browse/view/examination）、收藏（collect/favorite）、加入购物车（add-to-cart）和购买（purchase）等行为；（3）异构反馈，例如同时包含两种或两种以上的显式反馈和/或隐式反馈；以及（4）序列反馈，例如在隐式反馈中包含时序信息。需要说明的是，在一个真实的应用中，为了更加准确地学习用户偏好，我们除了需要考虑上述的多类型行为（multi-type behavior），还可以考虑：（1）多方面行为（multi-aspect behavior），如用户对物品的价格、质量和售后服务等不同方面的反馈；（2）多粒度行为（multi-granularity behavior），如用户对商品、品牌、商家和品类等不同粒度的反馈；（3）多模态行为（multi-modal behavior），如文本评论行为和数值反馈行为等；以及（4）多领域行为（multi-domain behavior），如用户在电商、资讯和社交等不同领域的行为。02、常用数据集和验证方法1●常用数据集1）MovieLens电影评分数据集MovieLens电影评分数据集是推荐算法研究中最常用的数据集之一，由美国明尼苏达大学（University of Minnesota）的GroupLens研究组收集和发布，包含了多个在不同时间段内收集到的规模各不相同的子数据集，例如，最经典的由943个用户对1682部电影的100,000条评分记录组成的MovieLens 100K数据集（1998年4月发布）、由6040个用户对3952部电影的1,000,209条评分记录组成的MovieLens 1M数据集（2003年2月发布）和由71567个用户对10681部电影的10,000,054条评分记录组成的MovieLens 10M数据集（2009年1月发布），以及较新的在2019年12月发布的MovieLens 25M数据集，等等。考虑到推荐系统数据的稀疏性问题，MovieLens数据集中仅保留了评分记录数不小于20的用户的数据。并且，除了最基本的(用户ID,物品ID,评分,时间戳)信息外，MovieLens数据集还提供了一些用户的基本信息（性别、年龄和职业）和物品的描述信息（电影名、电影类型和上映日期）。2）Netflix电影评分数据集Netflix电影评分数据集也是一个推荐算法研究中常用的历史比较悠久的数据集，由电影租赁网站Netflix在2005年底发布，用于Netflix百万美元竞赛，以激励人们设计和开发更好的推荐算法。Netflix数据集中包含了在1998年10月至2005年12月期间，480189个匿名的Netflix用户对17770部电影的99,072,112条评分记录（包含评分日期），并且包含了电影的标题和发行年份信息。3）Amazon电商评论数据集美国加州大学圣迭戈分校（University of California, San Diego）的Julian McAuley教授在其个人主页上发布了他的研究团队收集的一些推荐系统数据集，其中有一个从知名电商平台Amazon上收集到的关于商品的评论数据集。Amazon数据集包含了1996年5月至2014年7月期间的约1.4亿条评论数据（每条评论由评分及文字评论等组成），并且给出了一些商品的描述、类别、价格、品牌和图像特征等信息。为了方便研究，研究人员还将原数据集按照商品类别分为24个较小的子数据集，例如，图书数据集、电子产品数据集和电子游戏数据集等。4）天猫电商多行为数据集天猫（Tmall）电商多行为数据集[1]是在IJCAI 2015竞赛中发布的，包含了一些天猫用户在“双十一”前6个月的匿名行为日志。一条行为记录对应的信息有：用户ID、物品ID、时间戳和行为类型等等。其中，记录的行为类型包括点击、加入购物车、购买和收藏。Tmall数据集还提供了用户的性别和年龄等信息，以及物品的类别、商家和品牌等信息。2●验证方法1）交叉验证法对于不考虑序列信息的推荐问题，我们可以使用交叉验证法（cross validation）来对模型进行训练和验证，具体方法为：对于一个数据集，将它随机分成k（例如k=5）个大小相同的子集，每次取其中一个子集作为测试集，其余k-1个子集共同构成训练集，如此重复次，最后取在k个不同测试集上的结果的平均值作为最终的评估结果。注意，在一些算法中，我们可能需要先使用一个较小的验证集来寻找最优的模型参数，这种情况下，我们可以先固定一个测试集作为验证集来进行调参。2）留一法留一法（leave-one-out）是交叉验证法的一个特例，即将数据集中的每个样本都分到一个不同的子集中（即k等于数据集的大小），只选取一个样本用作测试，其余数据全部用于训练。在推荐算法研究中，留一法多用于引入序列信息的情况。通常，为了评估模型对用户行为序列的预测能力，我们将每个用户的最后一次行为记录划入测试集，其余记录划入训练集。注意，在进行正式的模型测试前，为了调节模型参数，可以将每个用户的倒数第二次行为记录划入一个新增加的验证集，然后使用剩下的训练集数据来训练模型并观察在各参数下的表现。3）强泛化效果验证和弱泛化效果验证在推荐技术的验证中，比较主流的模型效果验证方法包括强泛化效果验证和弱泛化效果验证。强泛化效果验证先对用户进行划分从而得到训练集用户图片、验证集用户图片和测试集用户图片，使得图片，再将每一位用户的交互数据划分到对应的数据中。显然，验证集用户和测试集用户的交互数据没有出现在训练过程中，因此模型需要具备较强的泛化能力才能获得较好的推荐效果。弱泛化效果验证则将每一位用户的交互数据按照设定的阈值划分到训练集、验证集和测试集中，因此验证集用户和测试集用户在训练过程中会以训练集用户的角色出现并参与到训练过程中。显而易见，弱泛化效果验证在验证和测试模型效果时，需要衡量模型在每一个用户上的推荐效果，当用户数目较多时，这种验证方式相较于强泛化效果验证而言效率较低，并且由于验证集用户和测试集用户在训练中已经出现并参与了训练，因此弱泛化验证对模型泛化能力要求相对较低。

Dubbo3 已经全面取代 HSF2 成为阿里的下一代服务框架，2022 双十一基于 Dubbo3 首次实现了关键业务不停推、不降级的全面用户体验提升，从技术上，大幅提高研发与运维效率的同时地址推送等关键资源利用率提升超 40%，基于三位一体的开源中间件体系打造了阿里在云上的单元化最佳实践和统一标准，同时将规模化实践经验与技术创新贡献开源社区，极大的推动了开源技术与标准的发展。本文是 Dubbo 社区贡献者宋小生基于 Dubbo3 3.0.8 版本撰写的源码解析博客，在 Dubbo3 开源&内部技术栈统一的情况下，期望能对集团内的开发者了解 Dubbo3 背后的实现原理有所帮助。可点此查看 博客原文 。本篇是宋小生系列 11/30 篇。同时，由 Dubbo3 团队领导的源码解读系列也正在进行中，感兴趣的同学可加入钉钉群了解详情： 2816500319411.1 简介先贴个代码用来参考: DubboBootstrap bootstrap = DubboBootstrap.getInstance(); bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider")) .registry(new RegistryConfig("zookeeper://127.0.0.1:2181")) .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1)) .service(service) .start() .await(); 上个博客我们说了 RegistryConfig对象的创建,启动器对象在启动之前是要初始化一些配置信息的,这里我们来看这一行代码协议配置信息:.protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))11.2 协议的配置相关下面的配置来源于官网服务提供者协议配置。对应的配置类： org.apache.dubbo.config.ProtocolConfig。同时，如果需要支持多协议，可以声明多个 <dubbo:protocol> 标签，并在 <dubbo:service> 中通过 protocol 属性指定使用的协议。属性对应URL参数类型是否必填缺省值作用描述兼容性id string可选dubbo配置关联协议BeanId，可以在<dubbo:service protocol="">中引用此ID，如果ID不填，缺省和name属性值一样，重复则在name后加序号。2.0.5以上版本namestring必填dubbo性能调优协议名称2.0.5以上版本portint可选dubbo协议缺省端口为20880，rmi协议缺省端口为1099，http和hessian协议缺省端口为80；如果没有配置port，则自动采用默认端口，如果配置为-1，则会分配一个没有被占用的端口。Dubbo 2.4.0+，分配的端口在协议缺省端口的基础上增长，确保端口段可控。服务发现服务端口2.0.5以上版本hoststring可选自动查找本机IP服务发现-服务主机名，多网卡选择或指定VIP及域名时使用，为空则自动查找本机IP，-建议不要配置，让Dubbo自动获取本机IP2.0.5以上版本threadpoolthreadpoolstring可选fixed性能调优线程池类型，可选：fixed/cached2.0.5以上版本threadsthreadsint可选200性能调优服务线程池大小(固定大小)2.0.5以上版本iothreadsthreadsint可选cpu个数+1性能调优io线程池大小(固定大小)2.0.5以上版本acceptsacceptsint可选0性能调优服务提供方最大可接受连接数2.0.5以上版本payloadpayloadint可选8388608(=8M)性能调优请求及响应数据包大小限制，单位：字节2.0.5以上版本codeccodecstring可选dubbo性能调优协议编码方式2.0.5以上版本serializationserializationstring可选dubbo协议缺省为hessian2，rmi协议缺省为java，http协议缺省为json性能调优协议序列化方式，当协议支持多种序列化方式时使用，比如：dubbo协议的dubbo,hessian2,java,compactedjava，以及http协议的json等2.0.5以上版本accesslogaccesslogstring/boolean可选 服务治理设为true，将向logger中输出访问日志，也可填写访问日志文件路径，直接把访问日志输出到指定文件2.0.5以上版本pathstring可选 服务发现提供者上下文路径，为服务path的前缀2.0.5以上版本transportertransporterstring可选dubbo协议缺省为netty性能调优协议的服务端和客户端实现类型，比如：dubbo协议的mina,netty等，可以分拆为server和client配置2.0.5以上版本serverserverstring可选dubbo协议缺省为netty，http协议缺省为servlet性能调优协议的服务器端实现类型，比如：dubbo协议的mina,netty等，http协议的jetty,servlet等2.0.5以上版本clientclientstring可选dubbo协议缺省为netty性能调优协议的客户端实现类型，比如：dubbo协议的mina,netty等2.0.5以上版本dispatcherdispatcherstring可选dubbo协议缺省为all性能调优协议的消息派发方式，用于指定线程模型，比如：dubbo协议的all, direct, message, execution, connection等2.1.0以上版本queuesqueuesint可选0性能调优线程池队列大小，当线程池满时，排队等待执行的队列大小，建议不要设置，当线程池满时应立即失败，重试其它服务提供机器，而不是排队，除非有特殊需求。2.0.5以上版本charsetcharsetstring可选UTF-8性能调优序列化编码2.0.5以上版本bufferbufferint可选8192性能调优网络读写缓冲区大小2.0.5以上版本heartbeatheartbeatint可选0性能调优心跳间隔，对于长连接，当物理层断开时，比如拔网线，TCP的FIN消息来不及发送，对方收不到断开事件，此时需要心跳来帮助检查连接是否已断开2.0.10以上版本telnettelnetstring可选 服务治理所支持的telnet命令，多个命令用逗号分隔2.0.5以上版本registerregisterboolean可选true服务治理该协议的服务是否注册到注册中心2.0.8以上版本contextpathcontextpathString可选缺省为空串服务治理 2.0.6以上版本同样官网提供的参数里面并未包含所有的属性 下面我就将其余的属性列举一下方便学习参考:变量类型说明threadnameString线程池名称corethreadsInteger线程池核心线程大小aliveInteger线程池keepAliveTime，默认单位时间单位。毫秒exchangerString交换器配置信息如何交换promptString命令行提示符statusString状态检查sslEnabledBooleanssl是否启用11.3 协议配置对象创建与添加前面例子中调用的代码 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))这里我们配置了协议类型为dubbo 端口为-1则会分配一个没有被占用的端口继续看下DubboBootstrap的protocol方法public DubboBootstrap protocol(ProtocolConfig protocolConfig) { //配置信息转List return protocols(singletonList(protocolConfig)); }继续看protocols方法 ,这个代码与前面两个博客中看到的向配置管理器添加配置对象的逻辑是一样的这里就不说了可以看前面的博客《9-Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig》 public DubboBootstrap protocols(List<ProtocolConfig> protocolConfigs) { if (CollectionUtils.isEmpty(protocolConfigs)) { return this; } for (ProtocolConfig protocolConfig : protocolConfigs) { protocolConfig.setScopeModel(applicationModel); configManager.addProtocol(protocolConfig); } return this; }

1前言“世上无难事，只要不集成。”数据中台开发阶段的前期工作，最困难就是数据集成了。刚开始数据建模做的好坏，业务做的好坏，似乎都有情可原，但是数据集成不上来，一切业务远景就如地基不牢的高楼随时都可能倾覆。从之前的项目经验来看，数据加工的建模方法和SQL语言都是较为标准化的，在项目中与阿里云第一次合作的伙伴和客户对于数据集成的学习和掌握都是较为困难。尤其是之前没有类似需要数据集成系统的企业，对数据集成工作的理解不是过于简单，就是过于担忧，又或者过于严苛。究其原因，还是对数据集成工作做什么都不了解，进而有很多误解。2DataWorks的数据集成早年DataWorks是只有离线集成，没有实时集成的功能，因为其定位主要是基于MaxCompute的离线开发平台。但是这几年在面向DataOps的发展上，定位已经是全能的大数据开发平台，可以基于多种引擎做数据开发。例如holo这种实时数仓的产品。所以，实时数据集成也是箭在弦上，终于做了一些对应的功能，作为一个资深用户还是很惊喜。但是目前从实际使用上来看，实时集成功能虽然弥补了功能上的缺陷，但是与离线集成的强大比起来，还是有所欠缺。首先是惊喜的部分。实时数据集成的直接构建了一键同步的功能，把复杂的配置实时同步任务，归档到log表，然后从Log表又merge到全量表的所有逻辑都包含在内了，真的实现了一步获得数据。从实际使用上来看，客户和伙伴学习配置一个实时数据集成任务与学习配置一个离线任务的成比起来更低。大部分人一次就配置成功，获得感很强。从资深用户的角度看，这种强大的整合能力也让实际运维的任务变得非常少，可以大大减轻开发人员的工作量，简直是梦想的彼岸。之前在一个部委大型项目上，我们的数据集成表高达几十万，每天调度运行的任务都是以十万计，无效运维压力山大。然后是欠缺的部分。从实际使用上来看，单个一键同步任务所承载的任务数量还是需要限制。整合虽然带来了好处，屏蔽了细节，但是任务太多在一起局部异常会影响全局，影响范围也会变大。再就是目前实时集成并没有缓冲的机制，再遇到源端数据库批量处理的时候，比较容易进程异常，需要针对性的调整内存参数后才可以恢复，也影响了数据产出的时效。再就是目前实时集成在混合云只支持oracle和mysql这两种数据库，支持的数据库种类还是非常的少。3实时集成就可以解决全部问题我敢相信，在设计之初，开发人员一定是想用实时集成替代离线集成，因为相比离线集成实时集成更加完美。而且，我在之前的文章中也讲过真实的集成场景，实时数据集成一定是主流，离线集成应该是辅助。数据本身就是实时产生的，没有哪个原始数据不是实时产生的，只有后续的数据处理过程才可能离线。所以，本质上来说，原始的数据都是实时的，只有实时集成才能提供更高时效的数据用于数据分析。以最常用的数据库实时集成为例。数据库记录了业务系统的操作型数据，业务系统本身就是实时在变化的。网页日志记录了网页访问的信息，这个过程产生的数据也是实时的。音视频数据流也是实时产生并且存储传输的。那么离线数据是怎么来的呢？离线数据只是实时在变化的数据在某个时点的一个切片。我们在做离线集成的时候，其实是向数据源端发起了一个某个时点数据的访问请求。例如向某个数据库提交了一个SQL，数据库会返回提交这个时点数据表的一个时点切片。这只是这个数据库表的某个时点状态，过了这个时点再提交，数据表返回就可能不同。实时集成就像接了一个石油管道，石油会源源不断的从数据源流到数据中台中去。但是这个管道投资是巨大的，如果管道中的油一直都是满载的传输还可以，实际上的数据产生更像是变幻莫测的天气，白天热晚上冷，偶尔刮风下雨，偶尔气候灾害。所以，实时集成也有自己的缺陷。相比之下离线集成占用管道的时间是短暂的，但是都是满载的，效率上会更高。实时集成的主要缺陷就是投资大，缺乏灵活性。为实时集成配置的资源不可以按照最小评估，必须按照最高的去评估。不管是传统的OGG这种历史长达几十年的产品，还是DataWorks这种新秀，都是会经常遇到突发的数据洪流导致进程崩溃。很多DBA或者数据库从业人士，一提到OGG就都头大，运维复杂压力大，稳定性也是差强人意。个人认为这主要还是因为成本效率的问题，经济划算的去运行，就得接受部分情况下的异常。那么是什么原因导致的异常呢？一般来说，很少是因为业务系统本身的原因，因为大部分交易型系统不是双十一那种场景，数据库系统一般都被用来做与人相关的处理，本身就是离散的。我遇到的100%的数据库实时集成问题的原因无外乎两种，一种是后台运维批量更新，另外一种是后台批量数据处理（存储过程出个报表，做批量计算）。所以本质的原因是：数据库没有做交易型的业务，去做了批量型系统。在遇到这种场景，实时同步就会很崩溃，因为大部分时候都是乖乖宝，但是突然就变身了绿巨人，一下子就可以把实时同步进程搞崩溃。而且，这种情况，因为有人的参与，变得不可预测。4要为你的系统做出选择谈到这里，你就知道应该怎么做了。交易型可预测的部分做实时，因为实时简单可靠，运维起来容易。不可预测的批量运维，和批量数据处理应该走离线，因为这两种操作本身就是一种离线处理。再就是经济性，如果不考虑成本，那其实可以尽可能全搞成实时，我用超大的资源浪费来满足各种不可预测的异常，来保障我的运转。就像我们国家的春运，是不是要把系统设计成春运不堵车的模式，还是设计成平时不堵车的模式，还是看够不够豪。而我们做一般的小项目还是要考量一下的，下面是总结：方案交易发生类型集成成本实时集成实时高离线集成离线/实时低 集成原则：1-费用紧张，资源有限，尽可能使用离线集成。2-批处理数据（主要指源端数据是批量产生，或者双十一式爆发式产生）集成，尽量走离线。如果确实预算非常充足，资源非常丰富，也可以走实时集成（很多时候，源端都可能扛不住）。3-交易型数据集成，尽量走实时，如果资源有限可以走离线。4-大表，例如数据超过200W、存储超过1G，尽量走实时，这种表一般在业务系统中数量不会超过表数量的20%。离线集成时效性很难满足要求，当然也不是不行。一般离线集成的表在1-10亿这个级别也是可以一战（与系统资源相关）。再大基本上就很难了，集成时间过久，业务系统没有足够的快照空间，事务会报错，集成就会失败。5-小表，例如常年不动的代码表，10W以下的小表，大概都能在30秒-3分钟内完成，建议走离线。毕竟实时挺贵，这些小表，还是打包搞过来比较适合。 就到这里了，我为什么写这么多集成的文章，真的很头疼。我每年都要给新的伙伴和客户教集成，每次还总能遇到新问题，把我搞的很狼狈。虽然集成看起来好像简单，但是真正客户化的把集成方案设计好，真的还是需要下一番功夫。欢迎大家交流数据集成相关问题。

作者 | 愈安来源 | 阿里巴巴云原生公众号2020 年双十一交易峰值达到 58.3 W 笔/秒，消息中间件 RocketMQ 继续数年 0 故障丝般顺滑地完美支持了整个集团大促的各类业务平稳。2020 年双十一大促中，消息中间件 RocketMQ 发生了以下几个方面的变化：云原生化实践：完成运维层面的云原生化改造，实现 Kubernetes 化。性能优化：消息过滤优化交易集群性能提升 30%。全新的消费模型：对于延迟敏感业务提供新的消费模式，降低因发布、重启等场景下导致的消费延迟。云原生化实践1. 背景Kubernetes 作为目前云原生化技术栈实践中重要的一环，其生态已经逐步建立并日益丰富。目前，服务于集团内部的 RocketMQ 集群拥有巨大的规模以及各种历史因素，因此在运维方面存在相当一部分痛点，我们希望能够通过云原生技术栈来尝试找到对应解决方案，并同时实现降本提效，达到无人值守的自动化运维。消息中间件早在 2016 年，通过内部团队提供的中间件部署平台实现了容器化和自动化发布，整体的运维比 2016 年前已经有了很大的提高，但是作为一个有状态的服务，在运维层面仍然存在较多的问题。中间件部署平台帮我们完成了资源的申请，容器的创建、初始化、镜像安装等一系列的基础工作，但是因为中间件各个产品都有自己不同的部署逻辑，所以在应用的发布上，就是各应用自己的定制化了。中间件部署平台的开发也不完全了解集团内 RocketMQ 的部署过程是怎样的。因此在 2016 年的时候，部署平台需要我们去亲自实现消息中间件的应用发布代码。虽然部署平台大大提升了我们的运维效率，甚至还能实现一键发布，但是这样的方案也有不少的问题。比较明显的就是，当我们的发布逻辑有变化的时候，还需要去修改部署平台对应的代码，需要部署平台升级来支持我们，用最近比较流行的一个说法，就是相当不云原生。同样在故障机替换、集群缩容等操作中，存在部分人工参与的工作，如切流，堆积数据的确认等。我们尝试过在部署平台中集成更多消息中间件自己的运维逻辑，不过在其他团队的工程里写自己的业务代码，确实也是一个不太友好的实现方案，因此我们希望通过 Kubernetes 来实现消息中间件自己的 operator 。我们同样希望利用云化后云盘的多副本能力来降低我们的机器成本并降低主备运维的复杂程度。经过一段时间的跟进与探讨，最终再次由内部团队承担了建设云原生应用运维平台的任务，并依托于中间件部署平台的经验，借助云原生技术栈，实现对有状态应用自动化运维的突破。2. 实现整体的实现方案如上图所示，通过自定义的 CRD 对消息中间件的业务模型进行抽象，将原有的在中间件部署平台的业务发布部署逻辑下沉到消息中间件自己的 operator 中，托管在内部 Kubernetes 平台上。该平台负责所有的容器生产、初始化以及集团内一切线上环境的基线部署，屏蔽掉 IaaS 层的所有细节。Operator 承担了所有的新建集群、扩容、缩容、迁移的全部逻辑，包括每个 pod 对应的 brokerName 自动生成、配置文件，根据集群不同功能而配置的各种开关，元数据的同步复制等等。同时之前一些人工的相关操作，比如切流时候的流量观察，下线前的堆积数据观察等也全部集成到了 operator 中。当我们有需求重新修改各种运维逻辑的时候，也再也不用去依赖通用的具体实现，修改自己的 operator 即可。最后线上的实际部署情况去掉了图中的所有的 replica 备机。在 Kubernetes 的理念中，一个集群中每个实例的状态是一致的，没有依赖关系，而如果按照消息中间件原有的主备成对部署的方案，主备之间是有严格的对应关系，并且在上下线发布过程中有严格的顺序要求，这种部署模式在 Kubernetes 的体系下是并不提倡的。若依然采用以上老的架构方式，会导致实例控制的复杂性和不可控性，同时我们也希望能更多的遵循 Kubernetes 的运维理念。云化后的 ECS 使用的是高速云盘，底层将对数据做了多备份，因此数据的可用性得到了保障。并且高速云盘在性能上完全满足 MQ 同步刷盘，因此，此时就可以把之前的异步刷盘改为同步，保证消息写入时的不丢失问题。云原生模式下，所有的实例环境均是一致性的，依托容器技术和 Kubernetes 的技术，可实现任何实例挂掉（包含宕机引起的挂掉），都能自动自愈，快速恢复。解决了数据的可靠性和服务的可用性后，整个云原生化后的架构可以变得更加简单，只有 broker 的概念，再无主备之分。3. 大促验证上图是 Kubernetes 上线后双十一大促当天的发送 RT 统计，可见大促期间的发送 RT 较为平稳，整体符合预期，云原生化实践完成了关键性的里程碑。性能优化1. 背景RocketMQ 至今已经连续七年 0 故障支持集团的双十一大促。自从 RocketMQ 诞生以来，为了能够完全承载包括集团业务中台交易消息等核心链路在内的各类关键业务，复用了原有的上层协议逻辑，使得各类业务方完全无感知的切换到 RocketMQ 上，并同时充分享受了更为稳定和强大的 RocketMQ 消息中间件的各类特性。当前，申请订阅业务中台的核心交易消息的业务方一直都在不断持续增加，并且随着各类业务复杂度提升，业务方的消息订阅配置也变得更加复杂繁琐，从而使得交易集群的进行过滤的计算逻辑也变得更为复杂。这些业务方部分沿用旧的协议逻辑（Header 过滤），部分使用 RocketMQ 特有的 SQL 过滤。2. 主要成本目前集团内部 RocketMQ 的大促机器成本绝大部分都是交易消息相关的集群，在双十一零点峰值期间，交易集群的峰值和交易峰值成正比，叠加每年新增的复杂订阅带来了额外 CPU 过滤计算逻辑，交易集群都是大促中机器成本增长最大的地方。3. 优化过程由于历史原因，大部分的业务方主要还是使用 Header 过滤，内部实现其实是aviator 表达式。仔细观察交易消息集群的业务方过滤表达式，可以发现绝大部分都指定类似MessageType == xxxx这样的条件。翻看 aviator 的源码可以发现这样的条件最终会调用 Java 的字符串比较String.compareTo()。由于交易消息包括大量不同业务的 MessageType，光是有记录的起码有几千个，随着交易业务流程复杂化，MessageType 的增长更是繁多。随着交易峰值的提高，交易消息峰值正比增长，叠加这部分更加复杂的过滤，持续增长的将来，交易集群的成本极可能和交易峰值指数增长，因此决心对这部分进行优化。原有的过滤流程如下，每个交易消息需要逐个匹配不同 group 的订阅关系表达式，如果符合表达式，则选取对应的 group 的机器进行投递。如下图所示：对此流程进行优化的思路需要一定的灵感，在这里借助数据库索引的思路：原有流程可以把所有订阅方的过滤表达式看作数据库的记录，每次消息过滤就相当于一个带有特定条件的数据库查询，把所有匹配查询（消息）的记录（过滤表达式）选取出来作为结果。为了加快查询结果，可以选择 MessageType 作为一个索引字段进行索引化，每次查询变为先匹配 MessageType 主索引，然后把匹配上主索引的记录再进行其它条件(如下图的 sellerId 和 testA )匹配，优化流程如下图所示：以上优化流程确定后，要关注的技术点有两个：如何抽取每个表达式中的 MessageType 字段？如何对 MessageType 字段进行索引化？对于技术点 1 ，需要针对 aviator 的编译流程进行 hook ，深入 aviator 源码后，可以发现 aviator 的编译是典型的Recursive descent，同时需要考虑到提取后父表达式的短路问题。在编译过程中针对 messageType==XXX 这种类型进行提取后，把原有的 message==XXX 转变为 true/false 两种情况，然后针对 true、false 进行表达式的短路即可得出表达式优化提取后的情况。例如：表达式： messageType=='200-trade-paid-done' && buyerId==123456 提取为两个子表达式： 子表达式1（messageType==200-trade-paid-done）：buyerId==123456 子表达式2（messageType!=200-trade-paid-done）：false具体到 aviator 的实现里，表达式编译会把每个 token 构建一个 List ，类似如下图所示(为方便理解，绿色方框的是 token ，其它框表示表达式的具体条件组合)：提取了 messageType ，有两种情况：情况一：messageType == '200-trade-paid-done'，则把之前 token 的位置合并成true，然后进行表达式短路计算，最后优化成 buyerId==123456 ，具体如下：情况二：messageType != '200-trade-paid-done'，则把之前 token 的位置合并成 false ，表达式短路计算后，最后优化成 false ，具体如下：这样就完成 messageType 的提取。这里可能有人就有一个疑问，为什么要考虑到上面的情况二，messageType != '200-trade-paid-done'，这是因为必须要考虑到多个条件的时候，比如：(messageType=='200-trade-paid-done' && buyerId==123456) || (messageType=='200-trade-success' && buyerId==3333)就必须考虑到不等于的情况了。同理，如果考虑到多个表达式嵌套，需要逐步进行短路计算。但整体逻辑是类似的，这里就不再赘述。说完技术点 1，我们继续关注技术点 2，考虑到高效过滤，直接使用 HashMap 结构进行索引化即可，即把 messageType 的值作为 HashMap 的 key ，把提取后的子表达式作为 HashMap 的 value ，这样每次过滤直接通过一次 hash 计算即可过滤掉绝大部分不适合的表达式，大大提高了过滤效率。3. 优化效果该优化最主要降低了 CPU 计算逻辑，根据优化前后的性能情况对比，我们发现不同的交易集群中的订阅方订阅表达式复杂度越高，优化效果越好，这个是符合我们的预期的，其中最大的 CPU 优化有32%的提升，大大降低了本年度 RocketMQ 的部署机器成本。全新的消费模型 —— POP 消费1. 背景RocketMQ 的 PULL 消费对于机器异常 hang 时并不十分友好。如果遇到客户端机器 hang 住，但处于半死不活的状态，与 broker 的心跳没有断掉的时候，客户端 rebalance 依然会分配消费队列到 hang 机器上，并且 hang 机器消费速度很慢甚至无法消费的时候，这样会导致消费堆积。另外类似还有服务端 Broker 发布时，也会由于客户端多次 rebalance 导致消费延迟影响等无法避免的问题。如下图所示：当 Pull Client 2 发生 hang 机器的时候，它所分配到的三个 Broker 上的 Q2 都出现严重的红色堆积。对于此，我们增加了一种新的消费模型 —— POP 消费，能够解决此类稳定性问题。如下图所示：POP 消费中，三个客户端并不需要 rebalance 去分配消费队列，取而代之的是，它们都会使用 POP 请求所有的 broker 获取消息进行消费。broker 内部会把自身的三个队列的消息根据一定的算法分配给请求的 POP Client。即使 Pop Client 2 出现 hang，但内部队列的消息也会让 Pop Client1 和 Pop Client2 进行消费。这样就 hang 机器造成的避免了消费堆积。2. 实现POP 消费和原来 PULL 消费对比，最大的一点就是弱化了队列这个概念，PULL 消费需要客户端通过 rebalance 把 broker 的队列分配好，从而去消费分配到自己专属的队列，新的 POP 消费中，客户端的机器会直接到每个 broker 的队列进行请求消费， broker 会把消息分配返回给等待的机器。随后客户端消费结束后返回对应的 Ack 结果通知 broker，broker 再标记消息消费结果，如果超时没响应或者消费失败，再会进行重试。POP 消费的架构图如上图所示。Broker 对于每次 POP 的请求，都会有以下三个操作：对应的队列进行加锁，然后从 store 层获取该队列的消息；然后写入 CK 消息，表明获取的消息要被 POP 消费；最后提交当前位点，并释放锁。CK 消息实际上是记录了 POP 消息具体位点的定时消息，当客户端超时没响应的时候，CK 消息就会重新被 broker 消费，然后把 CK 消息的位点的消息写入重试队列。如果 broker 收到客户端的消费结果的 Ack ，删除对应的 CK 消息，然后根据具体结果判断是否需要重试。从整体流程可见，POP 消费并不需要 reblance ，可以避免 rebalance 带来的消费延时，同时客户端可以消费 broker 的所有队列，这样就可以避免机器 hang 而导致堆积的问题。

4982亿，是2020年天猫双十一成交额最终定格的数字。在这背后，是人类历史上最大规模的人机协同，更是数字世界史无前例的巅峰挑战。阿里云新一代云原生数仓Hologres作为双十一背后重要的技术支撑，消费者的每一次搜索、浏览、收藏、加购，都会变成实时数据流入Hologres进行存储，并与天猫上沉淀的历史离线数据进行交叉比对。2020双十一，Hologres顶住了5.96亿每秒的实时数据洪峰，单表存储高达2.5PB。基于万亿级数据对外提供多维分析和服务，99.99%的查询可以在80ms以内返回结果，真正做到数据的实时及离线一体化，支持在线应用服务。Hologres诞生到参与2020年史上最强双十一的三年多时间里，完成不少从0到1的突破：从一个业务到数百业务实例，覆盖了阿里巴巴集团内90%以上业务场景，包括双十一实时直播间、智能推荐、阿里妈妈数据平台、国际站数据平台、菜鸟数据平台、友盟+全域数据分析、CCO智能客服、新零售数据平台、考拉、饿了么等业务。集群规模从0到近万台，且存储集群和计算集群使用率都比较高，并完成了系统产品化-上云-商业化的三级跳，完美赋能阿里云公共云+专有云+金融云业务。提出HSAP（HybridServing & Analytics Processing）服务分析一体化的系统设计理念，同一份数据同时满足实时离线在线场景的计算需求，极大的简化了数仓架构的复杂度，降低了成本，重新定义数仓趋势。同时，有关Hologres的技术解读Paper入选数据库顶会VLDB《Alibaba Hologres: ACloud-Native Service for Hybrid Serving/Analytical Processing》（http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf）值此之际，我们也将首次对外公开Hologres的核心底层技术，揭秘Hologres为何能支撑阿里巴巴核心场景的落地。 一、传统数仓痛点1）传统数据仓库痛点目前来说，大数据相关的业务场景一般有实时大屏、实时BI报表、用户画像和监控预警等，如下图所示。实时大屏业务，一般是公司领导层做决策的辅助工具，以及对外成果展示，比如双十一实时成交额大屏等场景。实时BI报表，是运营和产品经理最常用到的业务场景，适用于大部分的报表分析场景。用户画像，常用在广告推荐场景中，通过更详细的算法给用户贴上标签，使得营销活动更加有针对性，更加有效的投放给目标人群。预警监控大屏，比如对网站、APP进行流量监控，在达到一定阈值的时候可以进行报警。 对于上面这些大数据业务场景，业界在很早之前就开始通过数据仓库的建设来满足这些场景的需求，比较传统的做法是如下图所示的离线数据仓库，其大致流程就是：首先将各类数据收集起来，然后经过ETL处理，再通过层层建模对数据进行聚合、筛选等处理，最后在需要的时候基于应用层的工具对数据进行展现，或者生成报表。上面这种方式虽然可以对接多种数据源，但是存在一些很明显的痛点：ETL逻辑复杂，存储、时间成本过高；数据处理链路非常长；无法支持实时/近实时的数据，只能处理T+1的数据。2）Lambda架构痛点随着实时计算技术的兴起，出现了Lambda架构。Lambda架构的原理如下图所示，其思路其实是相当于在传统离线数仓的基础上再加上一个处理实时数据的层，然后将离线数仓和实时链路产生的数据在Serving层进行Merge，以此来对离线产生的数据和实时产生的数据进行查询。从2011年至今，Lambda架构被多数互联网公司所采纳，也确实解决了一些问题，但是随着数据量的增大、应用复杂度的提升，其问题也逐渐凸显，主要有：由多种引擎和系统组合而成，开发和维护成本高，学习成本高；数据在不同的View中存储多份，空间浪费，数据一致性的问题难以解决；从使用上来说，Batch，Streaming以及Merge Query等处理过程中均使用不同的language，使用起来并不容易；学习成本非常高，增大了应用成本。上面讲到的问题，在阿里内部其实也都遇到过。如下图所示是阿里巴巴在2011-2016年沉淀下来的一套实时数仓架构，其本质上也是Lambda架构，然而随着业务量及数据的增长，关系复杂度越来越大，成本急剧增加，因此，我们迫切的需要一种更优雅的方案去解决类似的问题。二、HSAP：服务分析一体化基于上述背景，我们提出了HSAP（Hybrid Serving and AnalyticalProcessing）理念，它既能支持很高QPS场景的查询写入，又能将复杂的分析场景在一套体系里面完成。那么，HSAP理念落地的核心是什么？首先，要有一套非常强大的存储，能够同时存储实时数据和离线数据，统一数据存储；同时还要有一种高效的查询服务，在同一个接口下（比如SQL），能够支持高QPS的查询，支持复杂的分析以及联邦查询和分析；系统能够直接对接前端应用，例如报表和在线服务等，不需要再额外的导入导出就能即席分析，统一数据服务，减少数据移动。三、关于Hologres基于HSAP的设计理念，我们要开发并落地出相应的产品，于是便诞生了Hologres。Hologres是基于HSAP服务分析一体化理念的最佳落地实践，兼容PostgreSQL生态、支持MaxCompute数据直接查询，支持实时写入实时查询，实时离线联邦分析，低成本、高时效帮助企业快速构筑流批一体的实时数仓。Hologres这个词是Holographic和Postgres的组合，Postgres比较好理解，代表着Hologres兼容PostgreSQL生态。而Holographic需要展开分享，先看下图：Holographic中文翻译是"全息"，就是大家经常听到的3D全息投影技术的"全息"。而Holographic Principle（全息原理）在物理学中是用来描述一个空间的性质可编码在其边界上。上图是一副假想中黑洞的图片，距离黑洞一定距离处于可以逃逸出黑洞引力的临界点构成了Event Horizon，就是图中发亮光的那一圈。全息原理认为所有落入黑洞的物体信息内容可能会被完全包含在Event Horizon的表面。Hologres要做的事情就是对数据黑洞中的全部信息做存储和各种类型的计算。四、Hologres核心技术揭秘Hologres架构非常简单，是存储计算分离的架构，数据全部存在一个分布式文件系统中，系统架构图如下图所示：服务节点Backend真正去接收数据、存储和查询，并且能够支持数据的计算；执行引擎Frontend接收路由分发的SQL，然后生成逻辑执行计划，再通过优化器生成分布式的物理执行计划，发布到Backend做分布式的执行；接入端由LBS做相应的负载均衡任务。下图中黄色部分均部署在容器中，整个分布式系统可以做到高度容错。兼容PostgreSQL生态，在上层可以直接对接开源或者商业化的开发/BI工具，开箱即可用。存储计算分离Hologres采用存储计算分离架构，用户可以根据业务需求进行弹性扩缩容。分布式存储中，常用的架构有如下三种：Shared Disk/Storage：就是在存储集群上挂载了很多磁盘，每个计算节点都可以直接访问这些共享盘；Shared Nothing：架构就是每个计算节点自己挂载存储，节点之间可以通信，但是各个节点之间的盘不共享，存在资源浪费的情况；Storage Disaggregation：就是相当于把存储集群看做一个大的磁盘，每个计算节点都可以访问，且每个计算节点都有一定的缓存空间，可以对缓存数据进行访问，也无需关心存储集群的管理，这种存储计算分离的架构便于灵活扩容，能够有效节省资源。流批一体的存储Hologres定位是流批一体统一存储。对于典型的Lambda架构，是将实时数据通过实时数据的链路写入到实时数据存储中，离线数据通过离线数据的链路写入到离线存储中，然后将不同的Query放入不同的存储中，再做Merge，由此带来多份存储开销和应用层复杂的Merge操作。而通过Hologres，数据收集之后可以走不同的处理链路，但是处理完成之后的结果都可以直接写入Hologres，这样就解决了数据的一致性问题，也不需要去区分离线表和实时表，降低了复杂度，也大大降低了使用者的学习成本。存储引擎Hologres底层支持行存储和列存储两种文件格式，行存适用于基于PK的点查场景，列存适用于OLAP复杂查询场景。对于两种存储格式Hologres在底层处理也有略微不同，如图所示。数据写入的时候先写log，log存储在分布式文件系统，保证整个服务的数据不会丢失，因为即便服务器挂掉也可以从分布式系统中恢复。Log写完之后再写MemTable，就是内存表，这样系统才认为是数据写入成功。MemTable有一定的大小，写满了之后会将其中的数据逐渐Flush到文件中，文件是存储在分布式系统中的。而对于行存储和列存储的区别就在Flush到文件的这个过程中，这个过程会将行存表Flush成行存储的文件，列存表会Flush成列存文件。在Flush的过程中会产生很多小文件，后台会将这些小文件合并成一个大文件。执行引擎Hologres执行引擎是通用的分布式查询引擎，侧重于优化高并发低延迟的实时查询。通用是指可以表达和高效地执行所有类SQL查询。其它的分布式查询引擎，有的专注优化实时表的常用单表查询，但是对复杂查询表现不佳；有的支持复杂查询，但是实时场景性能要差一截。Hologres的理念是不做妥协，对这些场景都要瞄准极致性能。Hologres执行引擎能够做到对各种查询类型的高性能处理，主要是基于以下特点：端到端的全异步处理框架，可以避免高并发系统的瓶颈，充分利用资源，并且最大可能地避免存储计算分离系统带来的读数据延迟的影响。查询用异步算子组成的执行图DAG表示，可以方便对接查询优化器，利用业界各种查询优化技术。算子内部处理数据时最大可能地使用向量化执行。和存储引擎的深度集成，灵活的执行模型，能够充分利用各种索引，并且最大化地延迟向量物化和延迟计算，避免不必要的读数据和计算。对常见实时数据应用查询模式的自适应增量处理。对一些查询模式的独特优化。优化器Hologres的目标就是用户开箱即可用，即通过SQL就能完成日常所有的业务分析需求，无需再做额外的建模处理等操作。基于新的硬件技术，Hologres设计并实现了自己独特的计算和存储引擎，而优化器扮演的角色就是将用户执行的SQL高效的运行在计算引擎上。Hologres优化器采用基于代价的优化器，能够生成复杂的联邦查询执行计划，尽可能发挥多套计算引擎的能力。同时，在长期与业务打磨的过程当中，也积累沉淀了大量的业务优化手段，让Hologres的计算引擎在不同的业务场景下都能够发挥极致的性能。HOS&HoloFlowHologres最核心的组件名叫blackhole，是一款完全自研的存储计算引擎，采用异步编程方式开发。blackhole的底层提炼出了灵活高效的异步框架：holo-os（简称HOS）。在实现高性能的同时，还实现了load balance，解决了query长尾问题；实现了资源的高利用率、以及多种共享与隔离的机制。于此同时，holo-os还推广到了分布式环境，发展出了holo-flow分布式任务调度框架，这样就能保证在分布式环境下也能享受到单机调度的灵活性。FrontendFrontend是Hologres的接入层，兼容PostgreSQL协议，负责用户请求的接入、处理以及元数据的管理。但由于PostgreSQL是单机系统，处理高并发的用户请求能力有限。而Hologres面对的是复杂的业务场景以及需要支持万甚至亿级别的用户请求，所以在实现上Frontend采用分布式，通过多版本控制+元数据同步等方式实现了多Frontend之间信息实时同步，再配合LBS层的负载均衡实现了完全线性扩展和超高QPS的能力。扩展执行引擎在Frontend的基础上，Hologres也提供多扩展执行引擎。PQE（P Query Engine)：运行SQL以及各种Function的执行器，Hologres兼容Postgres提供扩展能力，支持PG生态的各种扩展组件，如Postgis，UDF（pl/java，pl/sql,pl/python）等，完美满足不同场景不同用户的需求，从而提供更多的计算能力。SQE（S Query Engine）：无缝对接MaxCompute(ODPS)的执行器，实现对MaxCompute的native访问，无需迁移和导入数据，就可以高性能和全兼容的访问各种MaxCompute文件格式，以及Hash/Range clustered table等复杂表，实现对PB级离线数据的交互式分析。生态与数据集成Hologres作为流批一体的实时数仓，支持多种异构数据源的实时、离线写入，包括MySQL、Datahub等，能够达到每秒千万条的实时写入能力，写入即可查和每秒千万次的点查能力。而这些强大的能力都是基于Hologres的JDBC接口。Hologres在接口上完全兼容PostgreSQL（包括语法、语义、协议等），可以直接使用PostgreSQL的JDBC Driver去连接Hologres，并进行数据的读写。目前市面上的数据工具，例如BI工具、ETL工具等等，都支持PostgreSQL JDBC Driver，所以这意味着Hologres天生就有了广泛的工具兼容性和强大的生态，实现从数据处理到数据的可视化分析完整大数据生态闭环。在线服务优化Hologres作为HSAP服务与分析一体化的最佳落地实践，除了具备处理分析型query的能力外，还具备十分强大的在线服务能力，例如，KV点查与向量检索。在KV点查场景中，Holgres通过SQL接口可以轻松稳定地支持百万级的QPS吞吐与极低的延时。在向量检索场景，用户同样可以通过SQL的方式来实现向量数据的导入、向量索引的构建、查询等操作，无需额外转换就能查询，性能经过实际业务的测试也相比其他产品更优。此外，一些非分析型的query通过合理的建表、配合上Hologres强大的索引能力，也同样可以完美适用serving场景。五、数仓架构升级基于Hologres，多个业务场景也完成了架构升级，极大的简化了业务架构的复杂度，如下图所示：总结Hologres作为新一代云原生实时数仓，在今年阿里巴巴双11最核心的数据业务场景，连同实时计算Flink首次落地流批一体，并在稳定性、性能等方面经受住考验，实现商业全链路实时化，毫秒级的海量数据处理能力，为商家和消费者带来了更加智能的消费体验。随着业务的发展和技术的演进，Hologres也将持续优化核心技术竞争力，真正实现服务和分析一体化的美好愿望，为更多用户持续赋能。另，我们将会持续推出以上核心技术的专题解读，敬请关注！作者简介：金晓军（花名仙隐），阿里巴巴资深技术专家，大数据领域从业10年，现从事Hologres设计与研发工作。技术揭秘持续更新中：2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘：首次揭秘云原生Hologres存储引擎Hologres揭秘：Hologres高效率分布式查询引擎Hologres揭秘：高性能原生加速MaxCompute核心原理Hologers揭秘：优化COPY，批量导入性能提升5倍+Hologres揭秘：如何支持超高QPS在线服务（点查）场景Hologres揭秘：从双11看实时数仓Hologres高可用设计与实践Hologres揭秘：Hologres如何支持超大规模部署与运维Hologres揭秘：湖仓一体，Hologres加速云数据湖DLF技术原理解析Hologres揭秘：高性能写入与更新原理解析