作者|郑行涛(轩怒)
出品|阿里巴巴新零售淘系技术部
读者受益：
1、鹿班PICASSO实时合图引擎因何而生
2、实时合图引擎如何支撑每秒千万图像访问
3、实时合图引擎应用场景介绍
缘起
在个性化的公域触达和人货场的私域运营中，图片作为一个信息表达的载体，在过去一直是先生产，后消费。在这个生产-消费的过程中，存在两个循环:
商家与设计师的图片制作生产循环；
用户与商品的图片投放消费循环；
在生产侧，优秀的设计创意可以对用户注意力带来显著的提升，但由于缺乏标准化的生产机制，难以形成规模化的供给，更多的依靠作为个体的设计师的经验知识来优化生产供给。
在消费需求侧，相比于理解结构化的商品信息而言，机器去理解非结构化图片数据，在当下仍然有诸多的限定与不确定，同时由于无法干预生产，从而很难构建出一套正反馈机制，只能以量取胜。
我们希望能够利用新硬件与新软件的红利，构建生产与消费之间的数据新闭环，形成生产-消费双循环联动与共振。
基于以上出发点，我们在集团图片下行核心链路上构建起实时图像渲染服务，将原先面向存储的图片基础设施增加上面向理解生成的能力。
存储效率与设计能效双提升
营销图片的“千人千面”带来用户转化提升的与流量宏利的同时，给图片的存储成本与设计的生产能效上也带来了巨大的挑战。
在智能个性化算法大规模应用的今天，相同的商品在不同的“人货场”中有不同的展现需求。因“千人千面”普及而产生的大量设计脉络上大致相同仅局部元素不同的冗余图片，带来了存储成本与设计成本的爆炸性上涨。
如上图所示，同一套设计在不同年龄与性别的用户群体中展现的是配色与文案利益点的不同，而在不同尺寸的容器组件上又展现出图像分辨率的不同。
由此看来设计与个性化算法做笛卡尔积带来的图片数量的指数级别增加，若按照传统存储方式保存，财务成本是不可接受的；按照传统用人做图的生产模式，设计成本也非常高昂。
随着实时图像渲染服务的诞生，以上两个问题都迎刃而解。对于个性化算法产生的爆炸性的图片数据，仅需存储最原始的一份结构化设计，而实际展示的图片在访问时实时渲染生成，用高性能计算换取存储成本。
另一方面，实时渲染所存储的图像结构化的数据相较于二进制流数据更易于被设计端所理解。图像分元素控制更能感知用户对设计元素级的敏感性，从而更高效反哺智能化生产。
在大规模个性化算法应用下，实时图像渲染成为了精准控制图像元素级展现的必要条件，而只有做到了图像元素级的控制才能更好感知“人货场”的数据输入进行智能化表达，从而提升用户转换。
挑战
为完成面向理解图像基础设施的全新升级和进一步提升存储与设计效率的目标，我们做出了在集团图像下行核心链路上搭建个性化实时渲染服务的决定。
该服务的主要职责为每次用户访问图像资源时，将结构化的设计数据与个性化需求相匹配，实时渲染出图像返回给用户。实时图像渲染服务作为图片中心的基础设施服务，既要有设计增量效果又要满足高吞吐、高可用与低延迟(处理<100ms)，这些都给我们系统设计带来了巨大挑战。
▐ 高吞吐低延时
按照传统做法，用普通 CPU 机器渲染首焦的 banner 图片，至少需要 300ms 的延时，单机吞吐无法超过100QPS，这样的性能只能做到图片离线生产，无法支撑实时渲染。
为了满足高吞吐低时延的需求，我们引入了 FPGA 异构计算的架构，将图像编解码与图像融合烧写进 FPGA 板卡中，极大化的利用 PCIE 带宽及异构的优势，增加单机吞吐，降低单位延时。
目前在88Cores 2.5GHz / 340GB RAM双板卡4 VU9P FPGA 的异构机器上，用鹿班模版库历史数据作为压测标准（输出手淘上应用最广的 heic 格式的图像，平均7个图层，平均大小在800*800）最终能单机吞吐稳定到3000QPS，耗时控制在100ms内，相比普通 CPU 机器性能提升超30倍。
▐ 设计效果全支持
设计效果的丰富度与精细化程度很大程度上影响了图片的表达能力，进而影响图片的转化率。
为了完美还原渐变、描边、阴影、旋转等渲染效果，解决多语言、多字体带来的设计效果上的飞越，我们引入了 skia 渲染引擎，以上为渲染的示例图。skia 渲染引擎能在不影响硬件性能的情况下生成华丽的设计效果，满足视觉设计上的大部分需求。
▐ 缩放&质量&压缩后缀全支持
在手机淘宝与网页淘宝中，访问的所有图片链接都并不是图片的原始格式，而是经过对应后缀进行压缩的或更高压缩率编码的图片。
其中应用最广的高压缩率编码格式 HEIF ，编码的计算复杂度是 JPEG 编码的10倍以上，用普通的 CPU 机器来输出这种格式图片效率极低。
根据统计，每一份原图对应的不同后缀输出格式有 2400+ 种，TOP6 格式覆盖率 46%，TOP15 格式覆盖率仅达到 64%。可以看出在实际的图片应用场景中，所有访问都是带有后缀请求的。
我们支持了集团图片中心的所有缩放参数与格式参数（包括heic&webp输出）。由于在 FPGA 中操作，返回缩放与高压缩编码处理过的图片不增加耗时，保证生成的链接在全集团的端与页面上无差别适配。
▐ 异地多活与全球部署
在个性化场景下进行实时渲染，CDN 命中率不会很高，因此保证源站的稳定性就成了重中之重。如何避免因单地网络或存储集群不可用进而影响业务整体可用性，如何降低网络流量在垮地域中对穿都是亟须解决的问题。
为了响应集团国际化的需求，我们的服务必须在全球都有部署。实时渲染服务必须让存储和计算在一个机房内完成闭环，但又要考虑到数据垮地域复制的安全性。
实现细节
实时渲染服务架设在 CDN 与底层 OSS 存储之间，是一个重计算、低延时、高吞吐的分布式系统。
用户首次访问个性化图片会回源到实时渲染服务源站取图，此时我们会将渲染好的图片经过高压缩码率后吐还给 CDN；之后相同访问请求在更贴近用户的 CDN边缘节点上就能得到返回。
为满足国际化需求，实时渲染服务在全球多地均有部署，保证全球时延无差别。各地服务的存储数据都在本机房内流转，避免跨机房访问数据。每个地域服务的模块划分在下面大图中能够体现：
每个地域的流量服务入口都来自于 CDN 的回源请求，按照调用顺序依次经过个性化场景引擎、图片协议服务、资源管理服、渲染引擎、FPGA 图像处理引擎这五大模块。接下来会依次讲解关键技术。
▐ 基于 FPGA 的高吞吐低延时实时融合方案
基于智能算法，商品在不同“人货场”的个性化呈现，实质上是将不同的标签元素处理后生成不同的图片。以图层为单元定义合图结构，实现上采用图层依次处理的方案，如下图所示，即循环执行解码、预处理、合图，待合图完成后，再进行用户请求参数（包括分辨率、目标编码格式）的匹配。
图片处理方案实现
技术挑战与选型
传统的离线生产逻辑将图像合成后以图像格式存储在 OSS，下载端从 OSS 拉图后进行缩放、转码，而在新的实时图像渲染系统中，合图及目标格式的适配在同一个流程中完成，做到用户请求实时处理，支撑“人货场”的个性化表达。
复杂功能的实现带来的是计算量的增加，合图相比于传统的图像处理，单次请求单次合图请求输入图层数量多（线上平均6-7个图层），数据量大，在单次请求内完成多图层的处理，不论从资源占用，还是处理耗时，对服务端来说都存在很大的挑战。
进行9个图层的合成，使用软件方案处理，输出为850x850，吞吐及 RT 情况如下，对于 JPG 输出，从火焰图可以看到，CPU 主要消耗在解码、渲染等重计算处理上，如果使用软件方案来处理，要支撑30w QPS 的目标处理请求，需要 3750 台机器，成本无法接受，这种重计算逻辑的硬件化加速显得十分必要。
FPGA 由于其硬件并行加速能力和可编程特性，在传统通信领域和 IC 设计领域大放异彩，基于 line buffer 的实现，非常适用于滑窗插值、块匹配、MEMC 等图像处理算法的并行及流水线加速，借鉴图片中心在下行链路使用 FPGA 进行转码的经验与阿里云 AIS 合作，基于异构 FPGA 机器，将重计算的逻辑 offload 至 FPGA 来解决编解码及复杂图像处理问题。
FPGA 实现合图与编解码全流程
合图的输入流主要包括 PNG、JPG 及 bitmap 数据，对于 PNG 和 JPG 数据，需要先进行解码，针对不同的图层类型自适应选择解码器解码，对于JPG格式数据，FPGA 高性能解码方案在2019年双11时我们已经上线，对于 850x850 的图像，2ms即可完成解码，而软件 SIMD 加速版本 turbojpeg 需要10ms 左右。
由于 PNG 带有透明通道，可提升模板元素的呈现效果，设计上对 PNG 情有独钟，在解码端 PNG 的处理量也是最大的。
PNG 的压缩过程是完全无损的，压缩过的文件可以准确的还原出原图，可封装RGBA8888带透明的真彩色数据，并且是一种可扩展的封装格式，PNG 文件格式里面包含不同的区块(chunks)，各个区块带有不同类型的数据。典型的PNG数据包括四部分，而在此基础上，增加acTL（动画控制块）、fcTL（帧控制块）、fdAT（帧数据块）即为 APNG 动图格式。
IDAT 的压缩过程主要包括 Filter 和 deflate 两部分，Filter 即对像素做过滤，PNG 编码使用差分对原始像素数据进行 Filter ，该过程无任何压缩损失，并且完全可逆。
PNG 中的 Deflate 与 gzip、zlib 中的 deflate 原理一样，进行像素数据的无损压缩。最终我们与 AIS 合作将解压缩和 Filter 在 FPGA 中实现，大大加速的解码流程，提升吞吐并降低延时。
为支持丰富的图层表达，在图层预处理中实现多种图层缩放、裁剪、旋转、坐标适配逻辑，大大拓展图层元素的效果表现力。
合图本质为 alpha blending，即根据像素级透明度进行前后景的叠加，有大量像素级的乘加和操作，对于9个图层的叠加，最初直接采用像素操作方案，耗时40ms，后续使用 SIMD 加速，一个指令周期可进行64个像素点的操作，大大提升 CPU 的处理效率，最终在服务端，加速后9个图层的耗时控制在1个ms。
为支撑不同分辨率、不同质量、不同细节清晰度的请求，我们在服务端实现了大量的图像处理逻辑，包括各种各样的缩放操作（长边等比缩放、短边等比缩放、缩放裁剪、缩放不裁剪）、质量调整、锐化，最终输出调整后的结果。
手淘上目前常用的图片格式为 HEIC/WEBP，而 PC 上常用的格式为 JPG/WEBP ，为支撑淘系业务，需做到支持不同编码格式的输出。从压缩收益来看，HEIC>WEBP>JPG，高的压缩收益带来的是复杂度的提升，相比于 JPEG 编码只需要做中心化、DCT 变换、量化、熵编码，HEVC 帧内编码复杂度非常高（infra pred包括35个预测方向），是同等大小的 JPEG 编码复杂度的10倍以上。最终我们在硬件上支持 HEVC/JPG 编码，将软件 1000ms 耗时的处理降低到2-3ms。
经过 FPGA 硬件化加速，我们 HEIC/JPG 输出链路达到了3000 QPS 的吞吐，全流程的融合处理 RT 控制在40ms内，不加文字渲染合图结果如下，依次进行图层叠加，直至图层合并完成，再进行编码输出。
从优化后的火焰图可以看到，编解码等重计算逻辑基本都已 offload ，目前 FPGA 的资源平均利用率不到 30%，而 CPU 主要消耗在 Render 上，未来性能进一步的优化，主要在于 render（filter处理重计算）的卸载，这部分处理加速后，整机吞吐将会大大提升。
▐ 基于 skia 的 GPU 渲染
文字渲染业务上功能点主要考虑两个方面：排版、效果，排版指文字的水平/垂直排版、字号自适应缩放的计算，效果则围绕文字渐变、描边、阴影等常用的效果还原。
在技术上文本渲染不仅要支持高并发&低延迟，还要满足不同 os 端的跨平台特性，实时图像渲染支持 android、ios 下的文本渲染的集成，以解决端侧文字效果短板。
为什么选择 skia ？文字渲染有很多开源技术如 Skia、Cairo、Rusttype 等，以下是对部分文本渲染技术的分析：
从业务和技术出发点，skia/cario 都可以满足需求，考虑到鹿班当前渲染技术&编辑器基于 puppeteer，而 puppeteer 图形绘制是基于 skia，并且 skia 可集成 webassembly 利用 CanvasKit 在 web 端的渲染能力使得在技术架构上确保前后端的同构。基于 skia 的文字渲染流程如下：
字体匹配
实时图像渲染服务作为公私域全场景的图像基础设施，文字渲染最基本的要求不能出现下图(左一)的tofu问题，面对国际化多语言、不同 os 的字体引擎差别等问题，文字匹配在加载指定协议字体时会校验字符是否存在，不存在的字符会走统一的兜底接口，不同 os 端实现各自字体的管理逻辑。
布局计算
在图片设计中，文本的排版影响着整体布局的美观度，从简单的单行文字排版到多行文案排版、从水平排版到垂直排版、非 cjk 文字90°旋转垂直排版、字号缩放、自动换行等，在 html 中借助 css 布局样式可以很方便地实现以上布局排版，基于 skia 之上实现了自己的文本布局管理器。
上述文本布局单从文本角度上看，解决了文字元素域的布局问题，在业务中我们常遇见一些广告 banner 拓版需求，其本质也是对图片元素(位图、文本)进行重新布局排版问题，于是我们在此之上实现了拓版的布局自适应引擎。
拓版并不是简单的图片缩放，因为拓版的尺寸通常是非等比的(相对于原尺寸)，图片缩放只是处理位图尺寸等比缩放的一种方式，拓版强调的是位图元素等比、文本元素弹性的尺寸&坐标调整。
cpu/gpu文本绘制
skia 默认使用 cpu backend，我们分别在 cpu 和 gpu 场景下做了对比测试，在简单文本(无效果加持)图层渲染时，cpu 和 gpu 在性能上没有太大差别，甚至 cpu 还具有一定优势，虽然 gpu 在纯纹理绘制时具有很大优势，但在 readPixels 时 gpu 显存到 cpu 主存下的 io 处理很耗时，所以 gpu 加速用在复杂纹理(阴影、blur)处理或者批量图层渲染时优势才足够明显。
效果还原
效果还原其中效果指的是描边、渐变、阴影三种常见的文本设计效果，还原则对比的是设计师在 ps 的设计效果。skia 支持 stroke/gradient/shadow 底层 api 能力，但在表达 ps 效果上有些吃力更多地是见招拆招，如文字描边ps支持内描边、居中描边、外描边，skia 描边是没有类型区分的。
描边，skia 对描边的效果的支持需要绘制2层纹理叠加而成，叠加的顺序决定了描边的效果
渐变，文字渐变效果支持线性、径向两种，径向渐变较简单不在此赘述，这里简要说下线性渐变角度变化对于 start/end 两点坐标计算，参考示意图如下
阴影，文字阴影主要理解三个变量：dx/dy 阴影的偏移量，blur 阴影模糊半径，注：文字阴影效果对于cpu 绘制下的性能有很大影响
性能优化
在初期过程中，skia文本绘制区域是整个画布尺寸而一个文本图层区域相对于画布来讲小得多，全画布绘制使得内存开销更大数据传输也变得更加低效，在经过调整输出最小文本区域时性能提升不少。文字渲染默认返回png图片数据，火焰图中看出编码占用了5%cpu资源。将输出改为BGRA格式后性能有了30%的收益。通过增加字体缓存的方法，文字渲染性能同样获得了收益。
▐ 高可用架构和国际化部署
高可用架构
实时渲染作为直接面向 C 端的链路，对加载时长和稳定性的要求非常高，为降低加载时长、保证用户体验，采用 CDN 缓存 + 实时渲染源站 的二级分层架构：
在满足业务实时变化的诉求下，通过 CDN 缓存降低计算量，同时利用其分发网络来降低网络时延；
如果未命中 CDN 缓存，则直接请求源站并实时返回处理结果。
在个性化场景下，CDN 缓存命中率有限，因此，源站高可用成为整个链路的重中之重。因源站对网络、存储的强依赖，为避免单地网络或存储集群不可用影响业务整体可用性，实时图像渲染集群采用三地部署、异地多活模式：
渲染的原始数据在三地存储集群间异步复制，计算集群从本地存储集群读取所需数据；
当某地出现问题时，通过调整CDN回源策略实现异地容灾逃逸（秒级生效）；
考虑到存储集群作为一个有状态服务，单机不可用会造成请求成功率下跌，因此，针对单个请求使用跨地域容灾来保障整体成功率。
国际化部署
实时渲染作为基础服务，考虑到赋能 AE、Lazada 业务，进行了国际化部署；在国际化部署中，因实时图像渲染对加载时长、网络的要求较高，所以，必须让存储和计算在一个机房内完成闭环，整体架构如下图：
考虑到模板在电商业务中的复用性及其读多写少的业务特性，我们将设计师模板做了全球同步：3个分组、5个 Region；考虑到存储和复制成本，用于合图的商家数据 Native 化：只做分组内容灾、不做分组间同步。
▐ 基于设计领域知识的个性场景化引擎
相比文字，图片更容易吸引用户的注意力。但不同的人对图片的偏好是不一样的，如上右图所示，单就牛皮癣而言，不同年龄段、不同消费能力的用户会呈现明显的喜好差异。
此外，不同的导购链路和场景，用户对图片的注意力也可能产生差异。在主搜和首猜两大场景，我们通过深度测图产品，发现很多典型的 case ，同样的商品图片，仅有细微的设计差异，但在大数据的验证下，持续体现了完全不同的转化效率。由此可见，研究用户在图片上的注意力个性化，一定会给业务带来巨大的增量。
我们经过长期的业务积累，沉淀了一套基于设计领域知识的个性化引擎，结合专家知识+数据驱动，通过感知场景、人群、商品的特征，给出最合适的图片内容，实现图片效率的最优。
应用场景
▐ 手淘首焦
在手淘首焦商品个性化基础之上进行图片实时个性化投放，基于设计数据+用户注意力偏好构建图片优化生产模型，提高 banner 转化率。
▐ 主图打标
对商品主图增加官方的个性化模板，用智能算法填写符合用户画像的文案利益点，达到统一管控主图氛围的目的。做到公私域展现统一打通，首猜、搜索与详情展示图片实时渲染。
主图打标业务上要求在大促时候需要对图片进行指定氛围管控，利用实时图像渲染+CDN 缓存批量刷新，做到了双十一零点千万图片在同一时刻的氛围变化。
▐ 店铺
通过动态实时渲染技术与个性化推荐算法结合，支持了“千人千面”的店铺页设计，服务了近百万商家，日均曝光超千万次。
在于店铺的合作中开拓出长条形模版分片渲染的能力，适配手机上的内存淘汰策略，将长条形模版切分成多快渲染，使端上体验如丝般顺滑。
▐ lazada&AE 国际化输出
在与 Lazada、Ali Express 等国际站点的合作过程中，实时图像渲染服务不仅完成了全球化部署，还支持了全世界各地的多种语言以及不同国家的设计风格。
We are hiring
淘系技术部依托淘系丰富的业务形态和海量的用户，我们持续以技术驱动产品和商业创新，不断探索和衍生颠覆型互联网新技术，以更加智能、友好、普惠的科技深度重塑产业和用户体验，打造新商业。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入，让科技引领面向未来的商业创新和进步。
请投递简历至邮箱：jiuxian.tjo@alibaba-inc.com
关注【淘系技术】，一个有内容，有温度的微信公众号！
