基于doris+es 搭建用户画像系统(待整理)

olap
画像 doris+es
1、过去画像也是es 好用不代表能用好,
画像场景,看里面人群数,符合某些条件的人群数有多少?统计级
select count() groupby xxx 语义. 重要不优雅,用户需要学习dsl。包一层平台可以解决

人群如果有1000万(有将近1千多万条数据,大概占用空间有 300G 左右),几百万,导出来就比较崩溃,es 怎么用接口,并发导出,分布式读,并发控制,es黑科技,平台复杂度较高。普通用户对于高级玩法做不到。

几十万,几十分钟很正常,用游标scoll来做,如果失败,需要重跑,几千万,上亿就跑不出来了

doris on es 实现,列存,本地优先扫描,不排序(es 本身会排序,节省了很多计算开销),性能解决了,并且可以直接写sql了,不用写dsl了,扩展性,用户可以直接写sql了。中台必要的能力

更新场景,doris 更新不好,提升查询性能,需要做很多预计算,预计算需要有规则的。分析场景,维度跟指标要定义好,可以通过维度可以把指标预计算出来,画像场景,主键或者叫维度,更新大量是指标,查的时候要根据指标去查,某个年龄,金额大于xxx的,某个地域是xxx的人群是多少个,属性来查询。doris需要索引,排序,查询速度非常快,因为会预聚合,更新的结果应不应该在结果集中,性能会掉的很厉害,但是更新满足不了,
es 通过docid就可以更新了,性能一般,但是好歹是支持的。并且不影响读取。

所以画像场景,es把更新搞定,doris把上层查询搞定,查询快,有sql接口.

画像场景key 就是uid,其他都是属性一直在更新。预计算,就是终端类型android ios,地市,我想看北京市下的ios的用户数总共有多少人,报名人数,这种就是根据维度,预聚合求和,
kylin是所有维度预计算变成kv查询,这样会有维度爆炸,存储成本很高,加维度不方便,无法实时
,doris可以实时更新维度 tables schema change,上线没有kylin那么快,不会是毫秒级别的,做不到kylin那种kv查询,全部用预计算,比如要算几千万uv,每天都要groupby,如果现查询,肯定做不到秒出,

doris 要源源不断的更新的,并且可以计算的很好。也有物化视图,功能米有ck那么丰富,用不到太高级的能力,加一个rollup上卷就搞定了,一个物化视图的子集
clickhouse是一坨数据扔进去,查询会非常快

k1 k2 k3(城市) 维度列,pv uv 指标求最大,最小值,求k1 k3 算pv uv 可以k1 k3 pv uv做一个上卷,直接可以命中rollup列
clichouse 物化视图是跑sql,定期跑sql,doris做的是实时的,不是微批的,写的时候就把预计合全做了。

doris 预计算会把结果存在一个独立的表中,对外是可见的,sql会自动路由到rollup表里,自动分析sql的,可以指定维度和指标做预计算,业务是知道哪些是常用列,

es—doris+es 数据是不用动的,doris把es当成一个外表,挂上去就可以了,实时可用,外表创建成功了,fe模块会跟es元数据信息拉取es原信息,shard信息会拉取过来,doris访问失败,基本上都是因为es某个节点失败了,运维排查一下就好了

dorisdb数据更新,es就不用了,es维护成本太高了,需要写两套不同的实现,写入es keyword,doris必须是varchar int就会有问题,sql就解析失败了,doris有date类型,datetime有可能有不兼容问题,会查不出来。

es 类型不敏感,类型对应不上就会很麻烦。现在客户是通过平台化统一了,做了对应关系。

最终一致性,事务要求也不高,从业务库过来变成日志流了,客户对doris熟悉,人和事都认识,文档技术大家都知道,有问题会有人快速响应。

clickhouse运维复杂,c++,很难运维

目前所有分析都用doris,字段变更也很常见,现在有平台,改完字段,可以直接掉doris接口,alter table接口,不影响业务,无感知的

系统要能把控,技术做不深入 做proxy 做一些屏蔽 做平台化建设。在平台化解决掉

教学和拉新,1、统计类,分析
拉新,投放 端上PV uv多少人+业务的指标 来源,维度列可以枚举出来的。直接用doris

doris+es
1、老业务,裸用es 迁移doris 有成本。
2、微批架构 lamada kappy flink读业务流写到两个es表,ods–dwd,跟业务侧比较近,上面写sql 5分钟调度一次,当前时间往前推5分钟,a表更新3行,跟b表进行更新,如果join到了,说明b表也有更新了,

flinksql跟doris语法不一样,开发环境也不同,dwd dws ad 全部都是doris sql
select xxxx into xxx表,5分钟调度一次

flink实时,多留Join很麻烦

选择标准,微批数据不能太多,如果数据太多,还是走离线回灌回去

flink更新数据量很大,用redis做维表,doris不适合

对于客户要求要计算时间较长的数据,从doris再同步到hive里面去一份,这样就可以了,短时查询用doris,长周期用hive查,一个指标出口复用,但是不同需求,不同语法是合理的,目前在跟投放合作,还没有大规模用起来

腾讯没有调度系统

airflow 运维工作,对客户没有价值,体量?

clickhouse 可以通过shuddingkey 让多个表相同数据到同一个节点吗?

【原创】几句话说清楚《HBASE Snapshot 恢复 restore 原理》

首先snapshot恢复 理论上是建立在数据文件(region,hfile,storefile)都已经导入到集群中了,只是把元数据更新成snapshot的时刻
其实特别简单
Hmaster处理meta元数据表,跟当前元数据的region比较,分为三种情况:
1、snapshot 有,当前也有:说明这部分数据后来有可能被更新过,宁可错杀100,绝不放过一个,所以,直接先从meta信息删除,然后再从snapshot恢复
2、snapshot 有,当前没有:说明这部分数据被归档了,当前已经不用了,重新将snapshot这部分写入meta信息
3、snapshot 没有,当前有:说明是snapshot后面加入的数据,直接从meta删除

Hmaster恢复Hfile数据文件,分为三种情况:
1、snapshot 有,当前也有:同名的,不做任何改动,因为Hfile一旦落盘,很少会发生改变
2、snapshot 有,当前没有:对于缺少的文件,直接对exportsnapshot拷贝到archive中的Hfile文件做引用
3、snapshot 没有,当前有:说明是snapshot后面加入的数据,转移到archive归档

Hmaster恢复Wal文件:
写入recovered.edits文件夹的相应region中,每个region一个线程,只写入跟snapshot相关的表region信息,RS会从这里进行恢复,几句话说清楚《hbase snapshot 原理》也提到了,恢复只会从snapshot的flushid进行恢复,之前的就不会重复操作了

对于regionserver

参考:https://cloud.tencent.com/developer/article/1047967

【原创】几句话说清楚《HBASE Snapshot 原理》

首先snapshot 理论上是用于做备份恢复的
1、恢复哪些内容?
答:snapshot 指定表,在线region和split之前的region

2、谁参与了snapshot
答:
hmastr,regionserver

3、如何snapshot
hmaster 主要负责管控snapshot,
创建snapshot相关信息,比如,表信息,关联region的信息,以及region对应的server信息
hmaster会通过zk管控任务,通过三种目录,acquired、reached、abort;abort下有Regionserver(RS)信息,说明RS有执行snapshot失败的,直接退出snapshot
acquired,hmaster 创建snapshot信息(表,region信息),然后RS进行确认,确认成功,在该目录下创建自己的名字
reached,hmaster 确认acquired下RS都确认了,通知RS可以进行干活,每个RS干完活,会在该目录下创建自己的名字
abort,RS如果执行遇到问题,则在该路径下留下名字,然后Hmaster 取消整个snapshot流程

regionserver 负责具体在线region的信息采集
对memstore和WAL进行flush到相应的Hfile和Hlog中,其中,WAL Hlog要记录本次的flushID,restore_snapshot后,即便发生Hbase集群恢复,也只从该flushID恢复,更早的不会再恢复了
把Hfile 创建相应的映射到snapshot相应目录中,只有映射(空文件),这也是snapshot快的原因
把Hlog 文件放入该snapshot相应文件下

hmaster还负责split之前的region(已经不用的,父region)相关信息的snapshot,其实也是把相关信息留到snapshot下的目录下

hmaster 负责校验snapshot结果,确认snapshot目录信息,表信息是否正确,最主要的要确认需要snapshot的region信息是否还在

总结一下:

1

snapshot流程主要涉及3个步骤:

1. 加一把全局锁,此时不允许任何的数据写入更新以及删除

2. 将Memstore中的缓存数据flush到文件中(可选)

3. 为所有HFile文件分别新建引用指针,这些指针元数据就是snapshot

扩展思考:LSM类系统确实比较容易理解,那其他非LSM系统原地更新的存储系统如何实现snapshot呢?

参考:https://yq.aliyun.com/articles/60455?spm=a2c4e.11163080.searchblog.18.151a2ec1uNNVP8

如何从小白成长为 Apache Committer?

from:http://wuchong.me/blog/2019/02/12/how-to-become-apache-committer/

过去三年,我一直在为 Apache Flink 开源项目贡献,也在两年前成为了 Flink Committer。我在 Flink 社区成长的过程中受到过社区大神的很多指导,如今也有很多人在向我咨询如何能参与到开源社区中,如何能成为 Committer。这也是本文写作的初衷,希望能帮助更多人参与到开源社区中。

本文将以 Apache Flink 为例,介绍如何参与社区贡献,如何成为 Apache Committer。

我们先来了解下一个小白在 Apache 社区中的成长路线是什么样的。

Apache 社区的成长路线

Apache 软件基金会(Apache Software Foundation,ASF)在开源软件界大名鼎鼎。ASF 能保证旗下 200 多个项目的社区活动运转良好,得益于其独特的组织架构和良好的制度。

用户 (User): 通过使用社区的项目构建自己的业务架构的开发者都是Apache的用户。

贡献者 (Contributor): 帮助解答用户的问题,贡献代码或文档,在邮件列表中参与讨论设计和方案的都是 Contributor。

提交者 (Committer): 贡献多了以后,就有可能经过 PMC 的提议和投票,邀请你成为 Committer。成为 Committer 也就意味着正式加入 Apache了,不但拥有相应项目的写入权限还有 apache.org 的专属邮箱。成为 Committer 的一个福利是可以免费使用 JetBrains 家的全套付费产品,包括全宇宙最好用的 IntelliJ IDEA (这是笔者当初成为 Committer 的最大动力之一)。

PMC: Committer 再往上走就是 PMC,这个必须由现有 PMC 成员提名。PMC 主要负责保证开源项目的社区活动都能运转良好,包括 Roadmap 的制定,版本的发布,Committer 的提拔。

ASF Member 相当于是基金会的“股东”,有董事会选举的投票权,也可以参与董事会竞选。ASF Member 也有权利决定是否接受一个新项目,主要关注 Apache 基金会本身的发展。ASF Member 通常要从 Contributor, Committer 等这些角色起步,逐步通过行动证明自己后,才可能被接受成为ASF Member。

Apache 社区的成员分类,权限由低到高,像极了我们在公司的晋升路线,一步步往上走。

如何成为 Committer

成为 Apache Committer 并没有一个确切的标准,但是 Committer 的候选人一般都是长期活跃的贡献者。成为 Committer 并没有要求必须有巨大的架构改进贡献,或者多少行的代码贡献。贡献文档、参与邮件列表的讨论、帮助回答问题都是很重要的增加贡献,提升影响力的方式。

所以如何成为 Committer 的问题归根结底还是如何参与贡献,以及如何开始贡献的问题。

成为 Committer 的关键在于持之以恒。不同项目,项目所处的不同阶段,成为 Committer 的难度都不太一样,笔者之前也持续贡献了近一年才有幸成为了 Committer。但是只要能坚持,保持活跃,持续贡献,为项目做的贡献被大家认可后,成为 Committer 也只是时间问题了。

如何参与贡献

参与贡献 Apache 项目有许多途径,包括提Bug,提需求,参与讨论,贡献代码和文档等等。

  1. 订阅开发者邮件列表:dev@flink.apache.org。关注社区动向,参与设计和方案的讨论,大胆地提出你的想法!
  2. 订阅用户邮件列表:user@flink.apache.orguser-zh@flink.apache.org。帮助解答用户问题。
  3. 提Bug和提需求:Flink 使用 JIRA 来管理issue。打开 Flink JIRA 并登录,点击菜单栏中的红色 “Create“ 按钮,创建一个issue。
  4. 贡献代码:可以在 Flink JIRA 中寻找自己感兴趣的 issue,并提交一个 Pull Request(下文会介绍提交一个 PR 的全过程)。如果是新手,建议从 “starter” 标记的 issue 入手。笔者在 Flink 项目的第一个 issue 就是修复了打印日志中的错别字,非常适合于熟悉贡献流程,而且当天就 merge 了,成就感满满。当熟悉了流程之后,建议专注贡献某个模块(如 SQL, DataStream, Runtime),有利于积累影响力。
  5. 贡献文档:文档是一个项目很重要的部分,可以在 JIRA 中寻找并解决文档类的 issue。熟悉中英文的同学可以参与贡献中文翻译,可以搜索 “chinese-translation” 的 issue
  6. 代码审查:Flink 每天都会在 GitHub 上收到很多 Pull Request 。帮助 review 代码也是对社区很重要的贡献。
  7. 还有很多参与贡献的方式,比如帮助测试RC版本,写Flink相关的博客等等。

如何提交第一个 Pull Request

1. 订阅 dev 邮件列表

  1. 用自己的邮箱给 dev-subscribe@flink.apache.org 发送任意邮件。
  2. 收到官方确认邮件。
  3. 回复该邮件,内容随意,表示确认即可。
  4. 确认后,会收到一封欢迎邮件,表示订阅成功。

2. 在 dev 邮件列表中申请 JIRA Contributor 权限

Apache 项目都使用 JIRA 来管理 issue,认领 issue 需要 Contributor 权限。申请权限之前,先在 JIRA 注册一个账号。然后发邮件到 dev 邮件列表(dev@flink.apache.org)申请 Contributor 权限,邮件内容要带上 JIRA 账号 id。例如:

Hi,

I want to contribute to Apache Flink.
Would you please give me the contributor permission?
My JIRA ID is xxxx.

社区的PMC大佬们看到后会第一时间给你权限的。

3. 在 JIRA 中挑选 issue

申请到权限后,就可以在 JIRA 中认领 issue了,推荐从简单的开始做起。例如中文翻译的issue。认领的方式非常简单,在 issue 页面右侧 Assignee 处点击 “Assign to me”,如下图所示。

Tip: 如果感兴趣的 issue 已经被别人认领,但是 Assignee 迟迟没有开始开发。那么可以在 issue 下面友好地询问下是否有时间开发,是否介意重新认领该 issue。

4. 本地开发代码

认领了 issue 后建议尽快开始开发,本地的开发环境建议使用 IntelliJ IDEA。在开发过程中有几个注意点:

  • 分支开发。 从最新的 master 分支切出一个开发分支用于 issue 开发。
  • 单 PR 单改动。 不要在 PR 中混入不相关的改动,不做无关的代码优化,不做无关的代码格式化。如果真有必要,可以另开 JIRA 解决。
  • 保证新代码能被单元测试覆盖到。如果原本的测试用例,无法覆盖到,则需要自己编写对应的单元测试。

5. 创建 pull request

在提交之前,先更新 master 分支,并通过 git rebase -i master 命令,将自己的提交置顶(也可以通过 IDEA > VCS > Git > Rebase 可视化界面来做 rebase)。同时保证自己的提交信息中只有一个 commit,commit message 遵循规范格式。Commit 格式是 “[FLINK-XXX] [YYY] ZZZ”,其中 XXX 是 JIRA ID,YYY 是 component 名字,ZZZ 是 JIRA title。例如 [FLINK-5385] [core] Add a helper method to create Row object

要创建一个 pull request,需要将这个开发分支推到自己 fork 的 Flink 仓库中。并在 fork 仓库页面(https://github.com/<your-user-name>/flink)点击 “Compare & pull request” 或者 “New pull request” 按钮,开始创建一个 PR。确保 base 是 apache/flink master,head 是刚刚的开发分支。另外在编辑框中按提示提供尽可能丰富的PR描述,然后点击 “Create pull request”。

6. 解决 code review 反馈的问题和建议

提交 PR 后会收到修改建议,只需要为这些修改 追加commit 就行,commit message 随意。注意不要 rebase/squash commits。追加 commit 能方便地看出距离上次的改动,而 rebase/squash 会导致 reviewer 不得不从头到尾重新看一遍 diff。

7. Committer merge PR

当 PR 获得 Committer 的 +1 认可后,就可以等待被 merge 到主干分支了。merge 的工作会由 Committer 来完成,Committer 会将你的分支再次 rebase 到最新的master 之上,并将多个 commits 合并成一个,完善 commit 信息,做最后的测试检查,最后会 merge 到 master 。

此时在 Flink 仓库的 commit 历史中就能看到自己的提交信息了。恭喜你成为了 code contributor!

总结

在我看来,成为 Apache Committer 的小窍门有几点:

  1. 把项目看成自己的事情,自发地,有激情地去做贡献
  2. 保持活跃,持续贡献,耐心和平常心都很重要
  3. 专注一个模块,吃透该模块的源码和原理,成为某个模块的专家
  4. 提升个人的代码品位和质量,让他人信任你的代码
  5. 勇敢地在邮件列表中参与讨论

希望通过本文能让大家了解到,成为 Contributor 并没有想象中那么难,成为 Committer 也不是不可能,只要怀有开源的热情,找到自己感兴趣的项目,在开源贡献中成长,持之以恒,付出总会有回报的。

成为 Apache Committer 不仅仅是一种光环和荣誉,更多的是一种责任,代表着社区的信任,期盼着你能为社区做更多的贡献。所以成为 Committer 远不是终点,而是一个更高起点,毕竟 Committer 之上还有 PMC 呢 ;-)。

关注微信公众号 爱解决,更多大牛在线帮你解决问题

数据库智能运维探索与实践(转载)

从自动化到智能化运维过渡时,美团DBA团队进行了哪些思考、探索与实践?本文根据赵应钢在“第九届中国数据库技术大会”上的演讲内容整理而成,部分内容有更新。

背景

近些年,传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大,各种NewSQL系统上线使用,运维逐渐跟不上业务发展,各种矛盾暴露的更加明显。在业务的驱动下,美团点评DBA团队经历了从“人肉”运维到工具化、产品化、自助化、自动化的转型之旅,也开始了智能运维在数据库领域的思考和实践。

本文将介绍美团点评整个数据库平台的演进历史,以及我们当前的情况和面临的一些挑战,最后分享一下我们从自动化到智能化运维过渡时,所进行的思考、探索与实践。

数据库平台的演变

我们数据库平台的演进大概经历了五个大的阶段:

第一个是脚本化阶段,这个阶段,我们人少,集群少,服务流量也比较小,脚本化的模式足以支撑整个服务。

第二个是工具化阶段,我们把一些脚本包装成工具,围绕CMDB管理资产和服务,并完善了监控系统。这时,我们的工具箱也逐渐丰富起来,包括DDL变更工具、SQL Review工具、慢查询采集分析工具和备份闪回工具等等。

第三个是产品化阶段,工具化阶段可能还是单个的工具,但是在完成一些复杂操作时,就需要把这些工具组装起来形成一个产品。当然,并不是说这个产品一定要做成Web系统的形式,而是工具组装起来形成一套流程之后,就可以保证所有DBA的操作行为,对流程的理解以及对线上的影响都是一致的。我们会在易用性和安全性层面不断进行打磨。而工具产品化的主要受益者是DBA,其定位是提升运维服务的效率,减少事故的发生,并方便进行快速统一的迭代。

第四个是打造私有云平台阶段,随着美团点评业务的高速发展,仅靠十几、二十个DBA越来越难以满足业务发展的需要。所以我们就把某些日常操作开放授权,让开发人员自助去做,将DBA从繁琐的操作中解放出来。当时整个平台每天执行300多次改表操作;自助查询超过1万次;自助申请账号、授权并调整监控;自助定义敏感数据并授权给业务方管理员自助审批和管理;自定义业务的高峰和低峰时间段等等;自助下载、查询日志等等。

第五个是自动化阶段,对这个阶段的理解,其实是“仁者见仁,智者见智”。大多数人理解的自动化,只是通过Web平台来执行某些操作,但我们认为这只是半自动化,所谓的自动化应该是完全不需要人参与。目前,我们很多操作都还处于半自动化阶段,下一个阶段我们需要从半自动过渡到全自动。以MySQL系统为例,从运维角度看包括主从的高可用、服务过载的自我保护、容量自动诊断与评估以及集群的自动扩缩容等等。

现状和面临的挑战

下图是我们平台的现状,以关系数据库RDS平台为例,其中集成了很多管理的功能,例如主从的高可用、MGW的管理、DNS的变更、备份系统、升级流程、流量分配和切换系统、账号管理、数据归档、服务与资产的流转系统等等。

而且我们按照逻辑对平台设计进行了划分,例如以用户维度划分的RDS自助平台,DBA管理平台和测试环境管理平台;以功能维度划分的运维、运营和监控;以存储类型为维度划分的关系型数据库MySQL、分布式KV缓存、分布式KV存储,以及正在建设中的NewSQL数据库平台等等。未来,我们希望打造成“MySQL+NoSQL+NewSQL,存储+缓存的一站式服务平台”。

挑战一:RootCause定位难

即便我们打造了一个很强大的平台,但还是发现有很多问题难以搞定。第一个就是故障定位,如果是简单的故障,我们有类似天网、雷达这样的系统去发现和定位。但是如果故障发生在数据库内部,那就需要专业的数据库知识,去定位和查明到底是什么原因导致了故障。

通常来讲,故障的轨迹是一个链,但也可能是一个“多米诺骨牌”的连环。可能因为一些原因导致SQL执行变慢,引起连接数的增长,进而导致业务超时,而业务超时又会引发业务不断重试,结果会产生更多的问题。当我们收到一个报警时,可能已经过了30秒甚至更长时间,DBA再去查看时,已经错过了最佳的事故处理时机。所以,我们要在故障发生之后,制定一些应对策略,例如快速切换主库、自动屏蔽下线问题从库等等。除此之外,还有一个比较难的问题,就是如何避免相似的故障再次出现。

挑战二:人力和发展困境

第二个挑战是人力和发展的困境,当服务流量成倍增长时,其成本并不是以相同的速度对应增长的。当业务逻辑越来越复杂时,每增加一块钱的营收,其后面对应的数据库QPS可能是2倍甚至5倍,业务逻辑越复杂,服务支撑的难度越大。另外,传统的关系型数据库在容量、延时、响应时间以及数据量等方面很容易达到瓶颈,这就需要我们不断拆分集群,同时开发诉求也多种多样,当我们尝试使用平台化的思想去解决问题时,还要充分思考如何满足研发人员多样化的需求。

人力困境这一问题,从DBA的角度来说,时间被严重的碎片化,自身的成长就会遇到瓶颈,比如经常会做一些枯燥的重复操作;另外,业务咨询量暴增,尽管我们已经在尝试平台化的方法,但是还是跟不上业务发展的速度。还有一个就是专业的DBA越来越匮乏,越来越贵,关键是根本招聘不到人手。

在这种背景下,我们必须去思考:如何突破困局?如何朝着智能化转型?传统运维苦在哪里?智能化运维又能解决哪些问题?

首先从故障产生的原因来说,传统运维是故障触发,而智能运维是隐患驱动。换句话来说,智能运维不用报警,通过看报表就能知道可能要出事了,能够把故障消灭在“萌芽”阶段;第二,传统运维是被动接受,而智能运维是主动出击。但主动出击不一定是通过DBA去做,可能是系统或者机器人操作;第三,传统运维是由DBA发起和解决的,而智能运维是系统发起、RD自助;第四,传统运维属于“人肉救火”,而智能运维属于“智能决策执行”;最后一点,传统运维需要DBA亲临事故现场,而智能运维DBA只需要“隐身幕后”。

从自动化到智能化

那么,如何从半自动化过渡到自动化,进而发展到智能化运维呢?在这个过程中,我们会面临哪些痛点呢?

我们的目标是为整个公司的业务系统提供高效、稳定、快速的存储服务,这也是DBA存在的价值。业务并不关心后面是MySQL还是NoSQL,只关心数据是否没丢,服务是否可用,出了问题之后多长时间能够恢复等等。所以我们尽可能做到把这些东西对开发人员透明化,提供稳定高效快速的服务。而站在公司的角度,就是在有限的资源下,提升效率,降低成本,尽可能长远地解决问题。

上图是传统运维和智能运维的特点分析,左边属于传统运维,右边属于智能运维。传统运维在采集这一块做的不够,所以它没有太多的数据可供参考,其分析和预警能力是比较弱的。而智能运维刚好是反过来,重采集,很多功夫都在平时做了,包括分析、预警和执行,智能分析并推送关键报表。

而我们的目标,是让智能运维中的“报警+分析+执行”的比重占据的越来越少。

决策执行如何去做呢?我们都知道,预警重要但不紧急,但报警是紧急且重要的,如果你不能够及时去处理的话,事态可能会扩大,甚至会给公司带来直接的经济损失。

预警通常代表我们已经定位了一个问题,它的决策思路是非常清晰的,可以使用基于规则或AI的方式去解决,相对难度更小一些。而报警依赖于现场的链路分析,变量多、路径长,所以决策难,间接导致任何决策的风险可能都变大。所以说我们的策略就是全面的采集数据,然后增多预警,率先实现预警发现和处理的智能化。就像我们既有步枪,也有手枪和刺刀,能远距离解决敌人的,就尽量不要短兵相接、肉搏上阵。

数据采集,从数据库角度来说,我们产生的数据分成四块,Global Status、Variable,Processlist、InnoDB Status,Slow、Error、General Log和Binlog;从应用侧来说,包含端到端成功率、响应时间95线、99线、错误日志和吞吐量;从系统层面,支持秒级采样、操作系统各项指标;从变更侧来看,包含集群拓扑调整、在线DDL、DML变更、DB平台操作日志和应用端发布记录等等。

数据分析,首先是围绕集群分析,接着是实例、库,最后是表,其中每个对象都可以在多项指标上同比和环比,具体对比项可参考上图。

通过上面的步骤,我们基本可以获得数据库的画像,并且帮助我们从整体上做资源规划和服务治理。例如,有些集群实例数特别多且有继续增加的趋势,那么服务器需要scale up;读增加迅猛,读写比变大,那么应考虑存储KV化;利用率和分布情况会影响到服务器采购和预算制定;哪几类报警最多,就专项治理,各个击破。

从局部来说,我们根据分析到的一些数据,可以做一个集群的健康体检,例如数据库的某些指标是否超标、如何做调整等等。

数据库预警,通过分析去发现隐患,把报警转化为预警。上图是我们实际情况下的报警统计分析结果,其中主从延迟占比最大。假设load.1minPerCPU比较高,我们怎么去解决?那么,可能需要采购CPU单核性能更高的机器,而不是采用更多的核心。再比如说磁盘空间,当我们发现3T的磁盘空间普遍不够时,我们下次可以采购6T或更大空间的磁盘。

针对空间预警问题,什么时候需要拆分集群?MySQL数据库里,拆分或迁移数据库,花费的时间可能会很久。所以需要评估当前集群,按目前的增长速度还能支撑多长时间,进而反推何时要开始拆分、扩容等操作。

针对慢查询的预警问题,我们会统计红黑榜,上图是统计数据,也有利用率和出轨率的数据。假设这是一个金融事业群的数据库,假设有业务需要访问且是直连,那么这时就会产生几个问题:第一个,有没有数据所有者的授权;第二个,如果不通过服务化方式或者接口,发生故障时,它可能会导致整个金融的数据库挂,如何进行降级?所以,我们会去统计出轨率跟慢查询,如果某数据库正被以一种非法的方式访问,那么我们就会扫描出来,再去进行服务治理。

从运维的层面来说,我们做了故障快速转移,包括自动生成配置文件,自动判断是否启用监控,切换后自动重写配置,以及从库可自动恢复上线等等。

报警自动处理,目前来说大部分的处理工作还是基于规则,在大背景下拟定规则,触发之后,按照满足的前提条件触发动作,随着库的规则定义的逐渐完善和丰富,可以逐步解决很多简单的问题,这部分就不再需要人的参与。

展望

未来我们还会做一个故障诊断平台,类似于“扁鹊”,实现日志的采集、入库和分析,同时提供接口,供全链路的故障定位和分析、服务化治理。

展望智能运维,应该是在自动化和智能化上交叠演进,在ABC(AI、Big Data、Cloud Computing)三个方向上深入融合。在数据库领域,NoSQL和SQL界限正变得模糊,软硬结合、存储计算分离架构也被越来越多的应用,智能运维正当其时,我们也面临更多新的挑战。我们的目标是,希望通过DB平台的不断建设加固,平台能自己发现问题,自动定位问题,并智能的解决问题。

作者简介

应钢,美团点评研究员,数据库专家。曾就职于百度、新浪、去哪儿网等,10年数据库自动化运维开发、数据库性能优化、大规模数据库集群技术保障和架构优化经验。精通主流的SQL与NoSQL系统,现专注于公司业务在NewSQL领域的创新和落地。

来自:https://tech.meituan.com/Intelligent_Operation_Practice_in_meituan.html

LruCache在美团DSP系统中的应用演进(转载)

背景

DSP系统是互联网广告需求方平台,用于承接媒体流量,投放广告。业务特点是并发度高,平均响应低(百毫秒)。

为了能够有效提高DSP系统的性能,美团平台引入了一种带有清退机制的缓存结构LruCache(Least Recently Used Cache),在目前的DSP系统中,使用LruCache + 键值存储数据库的机制将远端数据变为本地缓存数据,不仅能够降低平均获取信息的耗时,而且通过一定的清退机制,也可以维持服务内存占用在安全区间。

本文将会结合实际应用场景,阐述引入LruCache的原因,并会在高QPS下的挑战与解决方案等方面做详细深入的介绍,希望能对DSP感兴趣的同学有所启发。

LruCache简介

LruCache采用的缓存算法为LRU(Least Recently Used),即最近最少使用算法。这一算法的核心思想是当缓存数据达到预设上限后,会优先淘汰近期最少使用的缓存对象。

LruCache内部维护一个双向链表和一个映射表。链表按照使用顺序存储缓存数据,越早使用的数据越靠近链表尾部,越晚使用的数据越靠近链表头部;映射表通过Key-Value结构,提供高效的查找操作,通过键值可以判断某一数据是否缓存,如果缓存直接获取缓存数据所属的链表节点,进一步获取缓存数据。LruCache结构图如下所示,上半部分是双向链表,下半部分是映射表(不一定有序)。双向链表中value_1所处位置为链表头部,value_N所处位置为链表尾部。

LruCache 初始结构

LruCache读操作,通过键值在映射表中查找缓存数据是否存在。如果数据存在,则将缓存数据所处节点从链表中当前位置取出,移动到链表头部;如果不存在,则返回查找失败,等待新数据写入。下图为通过LruCache查找key_2后LruCache结构的变化。

LruCache 查找

LruCache没有达到预设上限情况下的写操作,直接将缓存数据加入到链表头部,同时将缓存数据键值与缓存数据所处的双链表节点作为键值对插入到映射表中。下图是LruCache预设上限大于N时,将数据M写入后的数据结构。

LruCache 未达预设上限,添加数据

LruCache达到预设上限情况下的写操作,首先将链表尾部的缓存数据在映射表中的键值对删除,并删除链表尾部数据,再将新的数据正常写入到缓存中。下图是LruCache预设上限为N时,将数据M写入后的数据结构。

LruCache 达预设上限,添加数据

线程安全的LruCache在读写操作中,全部使用锁做临界区保护,确保缓存使用是线程安全的。

LruCache在美团DSP系统的应用场景

在美团DSP系统中广泛应用键值存储数据库,例如使用Redis存储广告信息,服务可以通过广告ID获取广告信息。每次请求都从远端的键值存储数据库中获取广告信息,请求耗时非常长。随着业务发展,QPS呈现巨大的增长趋势,在这种高并发的应用场景下,将广告信息从远端键值存储数据库中迁移到本地以减少查询耗时是常见解决方案。另外服务本身的内存占用要稳定在一个安全的区间内。面对持续增长的广告信息,引入LruCache + 键值存储数据库的机制来达到提高系统性能,维持内存占用安全、稳定的目标。

LruCache + Redis机制的应用演进

在实际应用中,LruCache + Redis机制实践分别经历了引入LruCache、LruCache增加时效清退机制、HashLruCache满足高QPS应用场景以及零拷贝机制四个阶段。各阶段的测试机器是16核16G机器。

演进一:引入LruCache提高美团DSP系统性能

在较低QPS环境下,直接请求Redis获取广告信息,可以满足场景需求。但是随着单机QPS的增加,直接请求Redis获取广告信息,耗时也会增加,无法满足业务场景的需求。

引入LruCache,将远端存放于Redis的信息本地化存储。LruCache可以预设缓存上限,这个上限可以根据服务所在机器内存与服务本身内存占用来确定,确保增加LruCache后,服务本身内存占用在安全范围内;同时可以根据查询操作统计缓存数据在实际使用中的命中率。

下图是增加LruCache结构前后,且增加LruCache后命中率高于95%的情况下,针对持续增长的QPS得出的数据获取平均耗时(ms)对比图:

引入LruCache前后平均耗时

根据平均耗时图显示可以得出结论:

  1. QPS高于250后,直接请求Redis获取数据的平均耗时达到10ms以上,完全无法满足使用的需求。
  2. 增加LruCache结构后,耗时下降一个量级。从平均耗时角度看,QPS不高于500的情况下,耗时低于2ms。

下图是增加LruCache结构前后,且增加LruCache后命中率高于95%的情况下,针对持续增长的QPS得出的数据获取Top999耗时(ms)对比图:

引入LruCache前后tp999耗时

根据Top999耗时图可以得出以下结论:

  1. 增加LruCache结构后,Top999耗时比平均耗时增长一个数量级。
  2. 即使是较低的QPS下,使用LruCache结构的Top999耗时也是比较高的。

引入LruCache结构,在实际使用中,在一定的QPS范围内,确实可以有效减少数据获取的耗时。但是QPS超出一定范围后,平均耗时和Top999耗时都很高。所以LruCache在更高的QPS下性能还需要进一步优化。

演进二:LruCache增加时效清退机制

在业务场景中,Redis中的广告数据有可能做修改。服务本身作为数据的使用方,无法感知到数据源的变化。当缓存的命中率较高或者部分数据在较长时间内多次命中,可能出现数据失效的情况。即数据源发生了变化,但服务无法及时更新数据。针对这一业务场景,增加了时效清退机制。

时效清退机制的组成部分有三点:设置缓存数据过期时间,缓存数据单元增加时间戳以及查询中的时效性判断。缓存数据单元将数据进入LruCache的时间戳与数据一起缓存下来。缓存过期时间表示缓存单元缓存的时间上限。查询中的时效性判断表示查询时的时间戳与缓存时间戳的差值超过缓存过期时间,则强制将此数据清空,重新请求Redis获取数据做缓存。

在查询中做时效性判断可以最低程度的减少时效判断对服务的中断。当LruCache预设上限较低时,定期做全量数据清理对于服务本身影响较小。但如果LruCache的预设上限非常高,则一次全量数据清理耗时可能达到秒级甚至分钟级,将严重阻断服务本身的运行。所以将时效性判断加入到查询中,只对单一的缓存单元做时效性判断,在服务性能和数据有效性之间做了折中,满足业务需求。

演进三:高QPS下HashLruCache的应用

LruCache引入美团DSP系统后,在一段时间内较好地支持了业务的发展。随着业务的迭代,单机QPS持续上升。在更高QPS下,LruCache的查询耗时有了明显的提高,逐渐无法适应低平响的业务场景。在这种情况下,引入了HashLruCache机制以解决这个问题。

LruCache在高QPS下的耗时增加原因分析:

线程安全的LruCache中有锁的存在。每次读写操作之前都有加锁操作,完成读写操作之后还有解锁操作。在低QPS下,锁竞争的耗时基本可以忽略;但是在高QPS下,大量的时间消耗在了等待锁的操作上,导致耗时增长。

HashLruCache适应高QPS场景:

针对大量的同步等待操作导致耗时增加的情况,解决方案就是尽量减小临界区。引入Hash机制,对全量数据做分片处理,在原有LruCache的基础上形成HashLruCache,以降低查询耗时。

HashLruCache引入某种哈希算法,将缓存数据分散到N个LruCache上。最简单的哈希算法即使用取模算法,将广告信息按照其ID取模,分散到N个LruCache上。查询时也按照相同的哈希算法,先获取数据可能存在的分片,然后再去对应的分片上查询数据。这样可以增加LruCache的读写操作的并行度,减小同步等待的耗时。

下图是使用16分片的HashLruCache结构前后,且命中率高于95%的情况下,针对持续增长的QPS得出的数据获取平均耗时(ms)对比图:

引入HashLruCache前后平均耗时

根据平均耗时图可以得出以下结论:

  1. 使用HashLruCache后,平均耗时减少将近一半,效果比较明显。
  2. 对比不使用HashLruCache的平均耗时可以发现,使用HashLruCache的平均耗时对QPS的增长不敏感,没有明显增长。

下图是使用16分片的HashLruCache结构前后,且命中率高于95%的情况下,针对持续增长的QPS得出的数据获取Top999耗时(ms)对比图:

引入HashLruCache前后tp999耗时

根据Top999耗时图可以得出以下结论:

  1. 使用HashLruCache后,Top999耗时减少为未使用时的三分之一左右,效果非常明显。
  2. 使用HashLruCache的Top999耗时随QPS增长明显比不使用的情况慢,相对来说对QPS的增长敏感度更低。

引入HashLruCache结构后,在实际使用中,平均耗时和Top999耗时都有非常明显的下降,效果非常显著。

HashLruCache分片数量确定:

根据以上分析,进一步提高HashLruCache性能的一个方法是确定最合理的分片数量,增加足够的并行度,减少同步等待消耗。所以分片数量可以与CPU数量一致。由于超线程技术的使用,可以将分片数量进一步提高,增加并行性。

下图是使用HashLruCache机制后,命中率高于95%,不同分片数量在不同QPS下得出的数据获取平均耗时(ms)对比图:

HashLruCache分片数量耗时

平均耗时图显示,在较高的QPS下,平均耗时并没有随着分片数量的增加而有明显的减少,基本维持稳定的状态。

下图是使用HashLruCache机制后,命中率高于95%,不同分片数量在不同QPS下得出的数据获取Top999耗时(ms)对比图:

HashLruCache分片tp99耗时

Top999耗时图显示,QPS为750时,分片数量从8增长到16再增长到24时,Top999耗时有一定的下降,并不显著;QPS为1000时,分片数量从8增长到16有明显下降,但是从16增长到24时,基本维持了稳定状态。明显与实际使用的机器CPU数量有较强的相关性。

HashLruCache机制在实际使用中,可以根据机器性能并结合实际场景的QPS来调节分片数量,以达到最好的性能。

演进四:零拷贝机制

线程安全的LruCache内部维护一套数据。对外提供数据时,将对应的数据完整拷贝一份提供给调用方使用。如果存放结构简单的数据,拷贝操作的代价非常小,这一机制不会成为性能瓶颈。但是美团DSP系统的应用场景中,LruCache中存放的数据结构非常复杂,单次的拷贝操作代价很大,导致这一机制变成了性能瓶颈。

理想的情况是LruCache对外仅仅提供数据地址,即数据指针。使用方在业务需要使用的地方通过数据指针获取数据。这样可以将复杂的数据拷贝操作变为简单的地址拷贝,大量减少拷贝操作的性能消耗,即数据的零拷贝机制。直接的零拷贝机制存在安全隐患,即由于LruCache中的时效清退机制,可能会出现某一数据已经过期被删除,但是使用方仍然通过持有失效的数据指针来获取该数据。

进一步分析可以确定,以上问题的核心是存放于LruCache的数据生命周期对于使用方不透明。解决这一问题的方案是为LruCache中存放的数据添加原子变量的引用计数。使用原子变量不仅确保了引用计数的线程安全,使得各个线程读取的引用计数一致,同时保证了并发状态最小的同步性能开销。不论是LruCache中还是使用方,每次获取数据指针时,即将引用计数加1;同理,不再持有数据指针时,引用计数减1。当引用计数为0时,说明数据没有被任何使用方使用,且数据已经过期从LruCache中被删除。这时删除数据的操作是安全的。

下图是使零拷贝机制后,命中率高于95%,不同QPS下得出的数据获取平均耗时(ms)对比图:

HashLruCache分片数量耗时

平均耗时图显示,使用零拷贝机制后,平均耗时下降幅度超过60%,效果非常显著。

下图是使零拷贝机制后,命中率高于95%,不同QPS下得出的数据获取Top999耗时(ms)对比图:

HashLruCache分片数量耗时

根据Top999耗时图可以得出以下结论:

  1. 使用零拷贝后,Top999耗时降幅将近50%,效果非常明显。
  2. 在高QPS下,使用零拷贝机制的Top999耗时随QPS增长明显比不使用的情况慢,相对来说对QPS的增长敏感度更低。

引入零拷贝机制后,通过拷贝指针替换拷贝数据,大量降低了获取复杂业务数据的耗时,同时将临界区减小到最小。线程安全的原子变量自增与自减操作,目前在多个基础库中都有实现,例如C++11就提供了内置的整型原子变量,实现线程安全的自增与自减操作。

在HashLruCache中引入零拷贝机制,可以进一步有效降低平均耗时和Top999耗时,且在高QPS下对于稳定Top999耗时有非常好的效果。

总结

下图是一系列优化措施前后,命中率高于95%,不同QPS下得出的数据获取平均耗时(ms)对比图:

HashLruCache分片数量耗时

平均耗时图显示,优化后的平均耗时仅为优化前的20%以内,性能提升非常明显。优化后平均耗时对于QPS的增长敏感度更低,更好的支持了高QPS的业务场景。

下图是一系列优化措施前后,命中率高于95%,不同QPS下得出的数据获取Top999耗时(ms)对比图:

HashLruCache分片数量耗时

Top999耗时图显示,优化后的Top999耗时仅为优化前的20%以内,对于长尾请求的耗时有非常明显的降低。

LruCache是一个非常常见的数据结构。在美团DSP的高QPS业务场景下,发挥了重要的作用。为了符合业务需要,在原本的清退机制外,补充了时效性强制清退机制。随着业务的发展,针对更高QPS的业务场景,使用HashLruCache机制,降低缓存的查询耗时。针对不同的具体场景,在不同的QPS下,不断尝试更合理的分片数量,不断提高HashLruCache的查询性能。通过引用计数的方案,在HashLruCache中引入零拷贝机制,进一步大幅降低平均耗时和Top999耗时,更好的服务于业务场景的发展。

作者简介

王粲,2018年11月加入美团,任职美团高级工程师,负责美团DSP系统后端基础架构的研发工作。

崔涛,2015年6月加入美团,任职资深广告技术专家,期间一手指导并从0到1搭建美团DSP投放平台,具备丰富的大规模计算引擎的开发和性能优化经验。

霜霜,2015年6月加入美团,任职美团高级工程师,美团DSP系统后端基础架构与机器学习架构负责人,全面负责DSP业务广告召回和排序服务的架构设计与优化。文章来自:https://tech.meituan.com/lrucache_practice_dsp.html

AI技术在智能海报设计中的应用(转载)

背景

在视觉设计领域中,设计师们往往会因为一些简单需求付出相当多的时间,比如修改文案内容,设计简单的海报版式,针对不同机型、展位的多尺寸拓展等。这些工作需要耗费大量的时间、人力成本(5~6张/人日),但对设计师的进步成长起到的作用却非常有限。另一方面,精准营销是未来的大趋势,在大流量背景下,首页的海报资源展位需要展示“千人千面”的效果,这对海报的生产效率也提出了非常高的要求。所以,我们美团外卖技术团队尝试结合AI技术,来协助设计师避免这种低收益、高重复的任务,同时低成本、高效率、高质量地完成海报图片的生成。本文以Banner(横版海报)为例,介绍我们在海报设计AI技术结合方面所进行的一些探索和研究。

分析

什么是Banner的设计过程?我们尝试总结了对Banner设计的理解,Banner的设计过程是一系列的具备某种特征属性的素材图层的有序叠加过程。这里的特征属性既包括颜色、形状、纹理、主题等视觉属性,也包括位置、大小、贴边等空间属性。在这个过程中,哪些环节可以被机器算法所探索呢?文献[1]研究了如何调整图像的颜色分布,使杂志封面的视觉效果更加符合人眼的视觉特性;文献[2]以此为基础,引入了基于显著性识别的图像裁剪,并使用优化方法来解决布局问题。阿里巴巴的鹿班系统在去年双十一当天,生成1.7亿张Banner;京东内部也在孵化玲珑和莎士比亚系统,更加智能地设计文案和Banner。

图1 封面配色&布局设计[2]

在设计领域的一些子问题上,可以用算法来挖掘出数据背后的规律(如图1所示)。那么,能否构建一个完整的学习算法和处理系统,统一解决Banner设计中所有的子问题(配色、布局、搭配、生成)呢?

技术方案

素材图层是Banner的基础元素,其本身可以被特征化,同时组成Banner的若干元素间的叠加顺序可以被序列化,因此,算法实际是在学习“在什么时候,选择某种素材,放在哪里”。

图2 流程框架

如图2所示,为了解决这个问题,我们设计规划器、优化器、生成器来共同构建海报设计的学习与生产过程。其中:

  1. 规划器从数据中学习设计师对不同风格下的设计习惯与规律;
  2. 优化器基于美学质量和设计原则,对前者的输出结果做精细化调整;
  3. 最后,由生成器选取/生成素材并渲染成图;
  4. 素材库作为这三个环节的基础,负责素材管理素材标签化

素材库

如何提取素材图片的特征属性,这是比较典型的分类问题。在计算机视觉领域,传统方案是提取图像的颜色、梯度等低级语义特征[3],结合传统的分类器(LR、SVM等)来实现分类。近年来,基于深度学习的方法因为能表达更为复杂的语义特征,逐渐成为主流方法[4]。如图3所示我们提取传统的低级语义特征,以及基于CNN的高级语义特征,来共同完成素材特征属性提取

图3 素材库-特征提取

规划器

完成素材的数据化工作后,怎样学习Banner的设计过程?

作为一种生成模型,对抗生成网络(GAN)[5]在近年广为应用,其优势是可以端到端地训练图像生成模型,但在我们的应用场景下,GAN存在以下两个问题:

  1. GAN的过程更像是“黑盒”的过程:输入方面,虽然Conditional-GAN之类的方法可以实现某种程度有条件地可控生成,但对于Banner设计任务来说,其输入信息(文案、目标风格、主体信息)仍然过于复杂;
  2. 输出方面,GAN直接生成源数据(即图像),但非常缺乏解释性。我们需要的是更加直观、更有解释性的信息,比如素材的类型、颜色、轮廓、位置等。

在上文中有提到,Banner设计过程是素材图层依次叠加的过程。因此,我们可以用序列生成模型来拟合这个过程[6]。在建模过程中,我们把素材视作词汇(Word),海报视作句子(Sentence),词汇索引视为离散化的特征索引,素材叠加顺序就可以视为句子中的词顺序[7]。

图4 规划器-序列生成

图4是我们使用的序列生成模型,输入主体信息和目标风格,输出素材特征的序列。为了增强预测过程中多条路径结果的多样性,我们在监督性地训练每个时刻的输出之外,还引入了评估整个序列合理性的Object loss。如图5所示,借鉴SeqGAN的思想,Object loss可以由判别器来提供[8]。

图5 SeqGAN[8]

优化器

规划器预测素材的量化特征,为了确保最终成图符合美学标准,需要一个后处理的过程(图6)。我们用优化器来解决这个问题。从本质上讲,这是一个优化过程。通过和设计师们的沟通,我们设计了一些基于常规设计理念和美学标准的目标函数,动作集合包括移动、缩放、亮度调整等,结合优化方法,提升Banner的视觉效果。

图6 优化器

生成器

优化后的素材特征序列,通过生成器来渲染成图。如图7所示,对于素材库检索不到符合某种特征属性的素材的情况,我们设计了图像风格迁移的方法来实现图像特征迁移。这里的特征可以是颜色、形状、纹理等低级特征,也可以是某种语义化的视觉风格特征,对后者来说,可以将源图像的内容Content和目标图像的风格Style在某种特征空间(CNN中的某一层)里做融合,实现风格迁移[9,10]。

图7 素材生成

应用场景及功能拓展

“千人千面”的精准营销是未来营销策略的趋势,这对商品素材的丰富性提出了非常高的要求;从为商家赋能的角度来说,也需要为商家提供更多样的海报版式,这也要求系统具备海报风格的快速学习能力和拓展能力。对此,在常规设计风格的研究之外,我们从以下3个方面做了一些拓展研究。

主体图片加工

商品素材的丰富度与美学质量是精细化营销及海报美学质量非常重要的一环。其中最核心的要求是图像分割的能力[11,12]。以全卷积网络(FCN)为基础,如图8所示,我们采取以下几个在目标分割领域常见的技巧,来实现商品图片的目标分割:

  1. Encoder-Decoder结构
  2. 空洞卷积
  3. 多尺度特征融合
  4. Two-Stage微调网络

图8 图像语义分割&抠图(结构图部分参考DeepLab v3+[12])

这种基于语义分割方法的结果,在专业设计师人工评审质量的过程中,发现主体边缘有时会出现明显的锯齿感。经过分析,我们认为有以下两个原因:

  1. 语义分割模型把问题建模为一个“像素级分类过程”,每一个像素的类别都天然地被假设为“非此即彼”,大多数的Segmentation模型都采用Cross-Entropy作为损失函数;
  2. 因此,无论是从模型结构(CNN)还是从损失函数的角度来说,分割模型会更倾向于全局信息从而丢弃局部结构信息,导致只能得到边缘比较粗糙的分割结果。

为此,如图8所示,我们在图像分割的输出结果之外,结合了Image Matting方法:

  1. 对分割模型的输出结果做形态学变换,生成三值Trimap,分别表示前景区、背景区、未知区;
  2. 应用常规的Matting方法,比如Bayesian、Close-Form等,以原图像和Trimap图像为输入,输出前景图的Alpha通道;
  3. Matting可以使前景主体的边缘更加平滑,视觉质量更高(图9)。

图9 商品主体抠图

另外,基于图像美学质量评分模型,我们会优先选择质量分高的图片作为主体素材来源。对中低分的图片,未来可以考虑借鉴Cycle-GAN[13]的思想,设计基于半监督和GAN的图像增强网络,美化后再经过图像分割产生主体素材。

海报模板拓展

上述的常规设计风格的学习属于一种广义的设计风格,需要设计师先期投入很多精力做风格划分以及数据收集、处理。为了快速适配热点场景,我们借鉴图像检索技术(如图10所示),提取素材图片的CNN特征及颜色特征,使用欧式距离来度量素材相似度,这能节省人工打标签的成本,实现基于固定模板的自动拓展及生成(海报临摹)。

图10 素材图像检索与模板拓展

多分辨率拓展

在日常工作中,设计师在设计出Banner后,往往要花费很长时间对不同展位、不同版本、不同机型做多尺寸适配(如图11所示)。能否用算法来协助人工提效?在素材已经确定,并且相互的位置关系近乎确定的条件下做多分辨率适配,这本质上是一个优化问题,我们在上文布局优化器的基础上,增加元素的局部相对位置与全局绝对位置的拓扑关系作为目标函数。目前,系统支持在某个固定宽高比±30%范围内的任意分辨率适配,未来会进一步扩大适配范围。

图11 多分辨率拓展

总结

目前,我们的Banner智能设计系统为钻展(外卖首页广告位)、商家店铺装修等业务提供稳定的设计能力;素材加工等子能力也在为外卖、闪购等商品图片提供技术支持。后续我们会从扩展常规设计风格、语义相关的颜色及素材挖掘、自动解析数据、构建自评估学习闭环等方面继续研究,进一步提高算法的设计能力和适用性,尽可能协助设计师提高效率,降低高重复性工作的时间和经济成本。

参考文献

[1] A. Jahanian, J. Liu, D. Tretter, Q. Lin, E. O’Brien-Strain, S. Lee, N. Lyons, and J. P. Allebach. “Automatic Design of Colors for Magazine Covers”. In Proc. IS&T/SPIE Electronic Imaging, International Society for Optics and Photonics, 2013
[2] X. Y. Yang, T. Mei, Y. Q. Xu, Y. Rui, S. P. Li. “Automatic Generation of Visual-Textual Presentation Layout”. ACM Transactions on Multimedia Computing, Communications, and Applications, 2017
[3] David G. Lowe. “Distinctive Image Features from Scale-Invariant Keypoints”. International journal of computer vision, 2004
[4] Alex Krizhevsky, Ilya Sutskever, Geoffrey E. Hinton. “ImageNet Classification with Deep Convolutional Neural Networks”. NIPS, 2012
[5] I. Goodfellow, J. Pouget-Abadie, M. Mirza, B. Xu, D. Warde-Farley, S. Ozair, A. Courville, Y. Bengio. “Generative Adversarial Networks”. NIPS, 2014
[6] K. Kawakami. “Supervised Sequence Labelling with Recurrent Neural Networks”. Studies in Computational Intelligence, 2008
[7] T. Mikolov. “Statistical Language Models based on Neural Networks”. 2012
[8] L. Yu, W. Zhang, J. Wang, Y. Yu. “SeqGAN: Sequence Generative Adversarial Nets with Policy Gradient”. AAAI, 2017
[9] L.A. Gatys, A.S. Ecker, M. Bethge. “Image Style Transfer Using Convolutional Neural Networks”. CVPR, 2016
[10] Y. Li, M.Y. Liu, X. Li, M.H. Yang, J. Kautz. “A Closed-form Solution to Photorealistic Image Stylization”. ECCV, 2018
[11] J. Long, E. Shelhamer, T. Darrell. “Fully Convolutional Networks for Semantic Segmentation”. CVPR, 2015
[12] L.C. Chen, Y. Zhu, G. Papandreou, F. Schroff, H. Adam. “Encoder-Decoder with Atrous Separable Convolution for Semantic Image Segmentation”. ECCV, 2018
[13] J.Y. Zhu, T. Park, P. Isola, A. A. Efros. “Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks”. ICCV, 2017

作者简介

晓星,2017年6月加入美团,目前主要负责美团外卖图像内容挖掘、增强、生成方面的相关工作,致力于图像相关技术的积累及落地。

文章来自:https://tech.meituan.com/AI_in_Banner_Design.html