Hologres RoaringBitmap实践：千亿级画像数据秒级分析

于 2023-09-06 16:20:12 发布
阅读量1.2k 收藏 1
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Taobaojishu/article/details/132726727
版权

9e3bf02ece53be922832cd98de5fc831.gif

本文介绍了Hologres RoaringBitmap的功能，希望可以帮助更多的业务利用Hologres RoaringBitmap能力，实现更快更准的画像分析。

d7021dee1dbb05be0cc7ec25dcc3ad10.png

业务介绍

我们团队所在的用户运营平台技术团队是一支懂用户，技术驱动的年轻队伍，团队立足体系化打造业界领先的用户增长基础设施，以媒体外投平台、ABTest平台、用户运营平台为代表的基础设施赋能用户增长，日均处理数据量千亿规模、调用QPS千万级。

在用户规模达到一定量级的情况下，单一的运营策略对于用户的效果愈发有限，人群分析的能力，因此显得尤为重要，它能帮助我们发现潜在用户、找寻运营时机，为策略调整提供数据支持。技术平台在过去一直采用MaxCompute进行画像分析，中途尝试过直接通过Hologres加速查询，但由于数据量级太大，在画像分析的效率上仍然存在一定的问题。为了解决Hologres的加速查询效率问题，我们团队调研了Hologres的RoaringBitmap画像方案，并在技术平台落地，成功让3-5min的画像分析提升到10s左右，显著提升人群分析的效率，为业务决策提供快速的依据。通过本文我将会分享RoaringBitmap方案在技术平台画像分析的应用实践。

cabdd21a3b4e7d2bf6636765bb9629f4.png

Bitmap原理解释

▐  Bitmap数据结构

Bitmap是一种通过位（bit）来存储和操作数据的数据结构，具备高度的空间效率和计算效率。它在人群画像分析中，例如跟踪大型网站用户行为时，能够极大地节省存储空间，并提高处理速度。

原理描述：

  1. 用一个bit位来标记某个元素对应的Value，而Key即是该元素。

  2. 如果一个数存在，则将这个数对应bit设置为1，否则置为0。

如下图：有一堆用户id，其中用户id为3、4的用户是勇士球迷；如果用Bitmap表示的话，那么key是勇士球迷；value是Bit数组。那么最后用户id用Bitmap存储如下：

440d6347f14b60f8c886c156459e78be.png

Bitmap的详细原理如下图：

  1. 默认情况下每个用户都有自己对应的一个特征，比如user0对于特征0，user1对应特征1，等等；这种是常规的存储方式，如果这样存储，计算特征的时候一般要进行关联查询。

  2. 我们需要把对应关系转换为Bitmap形式，Key为特征，特征背后对应的是一个Bit数组，如果用户拥有这个特征，那么对应的数组位Bit置为1。  这样只要给一个特征，就可以知道有多少用户拥有这个特征，而不需要遍历所有数据。

  3. 当多个特征都通过Bitmap存储的时候，多个特征进行计算只需要通过位运算就可以，而不需要再关联查询，所以极大的提升了数据处理效率。

a876e80495092264b29b36b0a4e3cfb9.png

从以上原理图可以看出，Bitmap可以将数据转化为数组位存储，不仅可以节约存储空间，也可以进一步提高查询效率。

▐  RoaringBitmap

虽然Bitmap已经让数据的存储空间有了N倍的缩减，但Bitmap的问题在于，不管业务中实际有多少个元素，它必须包含元素的最大值个bit空间，如果元素的取值范围是0-10亿，那么就要有10个bit空间，如果元素的取值比较稀疏，例如10亿个值中只有极少数据满足需求，那么这样的稀糊数据会造成严重的空间浪费，且也会占用大量的内存计算，所以我们一般还需要对Bitmap进行压缩处理。

RoaringBitmap就是一种高效的Bitmap压缩算法，适合计算超高基维的数据，常用于去重、标签筛选、时间序列等计算中。Roaring Bitmap算法是将32位的INT类型数据划分为216个数据块（Chunk），每一个数据块对应整数的高16位，并使用一个容器（Container）来存放一个数值的低16位。RoaringBitmap将这些容器保存在一个动态数组中，作为一级索引。

在 RoaringBitmap 中，容器（Container）是用于存储整数的数据结构，主要有三种类型：数组容器（Array Container）、位图容器（Bitmap Container）和运行长度编码容器（Run Container）。下面引用至RoaringBitmap的官方介绍，详情可以参考官网：https://roaringbitmap.org/

  1. 数组容器（Array Container）：这种容器使用一个数组来存储整数，适用于稀疏数据的情况，即数据之间的间隔较大。例如，如果一个容器内的整数数量小于4096，就使用数组容器来存储，因为在这种情况下，使用数组容器比使用位图容器更节省空间。

  2. 位图容器（Bitmap Container）：位图容器使用一个长度为65536的位数组（bit array）来存储数据，适用于稠密数据的情况，即数据之间的间隔较小。例如，如果一个容器内的整数数量大于4096，就使用位图容器来存储，因为在这种情况下，使用位图容器比使用数组容器更节省空间。

  3. 运行长度编码容器（Run Container）：运行长度编码（Run-length Encoding，RLE）是一种简单的数据压缩算法，适用于连续重复数据的情况。在 Roaring Bitmap 中，如果一系列连续的整数都存在于位图中，那么可以使用一个运行长度编码容器来存储这些连续的整数的起始值和长度，从而节省空间。

RoaringBitmap 根据实际的数据情况，动态地选择最适合的容器类型，从而实现了既高效的数据存储，又快速的数据查询。在做位图计算（AND、OR、XOR）时，RoaringBitmap提供了相应的算法来高效地实现在多个容器之间的运算，使得RoaringBitmap无论在存储和计算性能上都表现优秀。详细的实现原理图如下：

54eae2cd08453a4d6b60717f0e3e572c.png

在实际的使用中一般使用RoaringBitmap来，并且官方也提供了对应的Java库地址，可以直接拿来使用。

4bb1abd4c2bc4e2de7a3e63129744d91.png

技术平台基于RoaringBitmap的画像分析使用实践

技术用户画像分析是对一个或多个指定用户群，通过可视化的方式，可以多维、立体的展示用户群的画像信息，让运营更好的理解人群，实现人群细分及对个性化运营策略的制定提供能力支撑；在进行数据分析时，更加便捷的获得人群的特征信息，从而更好的进行定量的分析。

业务画像分析流程：

  1. 默认情况下平台有业务的所有标签在MaxCompute中存储，同时也会存储一份Bitmap的标签索引数据，再标签数据更新时构建。

  2. 业务可以使用标签和其他用户相关的数据圈选人群，人群圈选完成后，也会对其构建一份Bitmap索引数据。

  3. 圈选完人群后，就会进行画像分析，如果标签和人群都有Bitmap索引数据，就会通过Bitmap进行分析

5ca37ff4f1ad34f2b912c1bb45e0356f.png

▐  方案对比

技术平台早期画像分析主要依赖于MaxCompute执行SQL，但这种方式耗时较长，对于需要实时洞察分析的业务场景，分析需要更加快速看到结果，高延迟无法满足业务需求。之前尝试通过将数据导入Hologres进行加速，然而由于数据量庞大，Hologres的执行耗时仍然超过3分钟。

在前期，根据业务需求我们也在技术上做了一些调研。从技术方案角度看，一些可以实现的画像分析的方案和其缺点：

方案名称

缺点

MaxCompute进行查询

MaxCompute的任务执行耗时较长，并且是异步的，无法满足实时查询的需求。

Hologres JSONB

Hologres有JSONB列存方案，可以通过列式存储优化查询效率，但是因为业务还是有join，仍然是N^2的关联查询，大数据量的情况下查询效率相比Bitmap仍然有一定的不足。

ClickHouse

成本较高，在阿里集团内的应用场景较少，实践少。

而Hologres原生支持RoaringBitmap数据结构，特别适合大数据量级下的交并差运算，并且在画像分析的场景天然适合，因此我们最后选择了RoaringBitmap方案。虽然RoaringBitmap会带来额外的处理和优化步骤、索引构建过程，这可能会带来一定的初期成本上升。然而，在我们的场景中，数据更新不是那么频繁，数据量级也在可控范围内，因此这一成本上升在可接受范围。而且使用RoaringBitmap带来的效率提升非常明显，最终还是选择使用这一方案进行标签和人群加速。

▐  核心流程

  1. 平台人员：筛选可加速的标签，然后配置在平台上，平台每天在标签数据更新完成后构建对应的标签Bitmap索引

  2. 小二同学：

  • 在圈人的时候，可以考虑勾选人群开启分析加速、或者核心空间会圈完之后会自动构建人群的Bitmap索引。

  • 在进行人群洞察分析的时候，点击画像分析，弹出可分析的标签，可进行加速的标签会标记🚀，然后运营可以勾选对应的标签进行分析，在1亿以下的规模，加速标签可在10秒内出结果。

技术平台：对平台小二筛选录入的标签进行构建Bitmap索引，人群构建Bitmap索引，画像分析的时候，执行RoaringBitmap的SQL查询操作。

▐  整体功能设计

应用功能分层描述

  1. 底层存储的是我们的各种明细数据和元数据，包括 标签的明细数据、人群的明细数据以及标签和人群是否加速的配置信息。 

  2. 中间部分是业务逻辑：通过调度任务，每日检查人群数据是否完成，标签数据是否完成，然后触发对应的加速流程；当触发对应的调度流程之后，走到右边的调度DAG任务，先构建MaxCompute Bitmap索引，然后将数据同步至Hologres，并在Hologres构建RoaringBitmap

  3. 最上面是Bitmap的应用场景：可以对有Bitmap索引的数据进行画像分析加速、模板分析加速、人群预估加速。

▐  数据模型设计

由于Hologres的RoaringBitmap相关函数只支持32位，而当前uid的设计是64位的数字，并且量级也比较大，因此需要对用户ID进行分桶设计。将uid拆为低位和桶号。借鉴阿里妈妈Dolphin引擎分桶设计经验，我们将uid直接通过位移拆分为level（高44位）以及normal_uid（低20位）, 通过将uid拆分，把相同level下的normal_uid放入同一个bitmap中即可实现人群的高度压缩，减少对数据的IO操作，加速后续的查询。

标签RoaringBitmap构建结果表预估：假设每个标签平均有10个标签值，每个表存储1000个标签，按照outside_default.png分桶，可以根据自己的业务进行计算。记录数 = (用户量  / 2^20) * (标签个数 * 标签值 )。因为记录通过分桶被极大的进行压缩，因此在Hologres的高性能查询支撑范围之内。

对于人群也是同理，数据量级会压缩 2^20倍，因此Hologres的查询效率也会提升。业务可以按照自己的量级进行分桶设计：业务应根据具体场景进行测试，确定每个桶的最佳用户数。一般桶的用户数越多，越耗费CU，速度可能有一定提升。

  • 分表策略

目前按照：用户属性rb表、人群rb表都分16个表；都是对16进行取余，然后落到对应的表上。

Hologres内表：

ee54573be2dbe7ab617e57d3535d5b43.png

Hologres外部表：

9ec58cc46a01e5c70c9d100febe2c2e1.png

  • 人群和标签表，新增字段

  1. 标记人群是否开启加速

  2. 是否加速完成

  3. 最近一次的加速日期

public class AccelerateConfigDTO {
    private Boolean isAccelerationCompleted;
    private Boolean isAccelerationEnabled;
    private String lastDs;
}
▐  关键的业务SQL

  • 在用Java提交MaxCompute任务的时候，记得设置如下参数

  1. sql.mapper.split.size默认 256M，mapper过程根据此大小进行任务数量计算。调整小容量小一点，会增大任务并发处理数量加快速度。增加速度，同时需要资源数量会增多。

  2. sql.submit.mode：改为script支持运行多条SQL

  • 尽量选择以下几种类型的数据构建Bitmap

可枚举标签构建Bitmap

尽量选择性别、年龄、城市这种类型的有限的字段值构建bitmap，里面的value类型比较简单。MaxCompute中分桶以及构建bitmap的SQL如下：

说明：Bitmap通过在MaxCompute中构建UDF实现，不再本文中做详细描述

--MaxCompute SQL
-- 创建表
CREATE TABLE IF NOT EXISTS 空间名.demo表名(
  field_value    STRING COMMENT '标签value值',
  bucket         BIGINT COMMENT '分桶',
  bitmap         BINARY COMMENT 'uid bitmap'
) COMMENT '用户基础属性标签bitmap'
    PARTITIONED BY
(
  ds             STRING COMMENT '日期',
  label_id       STRING COMMENT '标签ID'
)
    LIFECYCLE 365
;


-- 插入数据
INSERT OVERWRITE TABLE 空间名.demo表名 PARTITION(ds='${bizdate}', label_id='${label_id}')
SELECT COALESCE(${label_field}, 'NULL') as field_value
     ,SHIFTRIGHT(CAST(COALESCE(${uidField}, '0') AS BIGINT), 20) as bucket
     ,ENCODE(mc_rb_build_agg(CAST(COALESCE(${uidField}, '0') as BIGINT) & 1048575), 'utf-8') as bitmap
FROM ${dataSource}.${dataTable}
WHERE ds=MAX_PT('${dataSource}.${dataTable}')
  AND CAST(COALESCE(${uidField}, '0') AS BIGINT) > 0
GROUP BY COALESCE(${label_field}, 'NULL'), SHIFTRIGHT(CAST(COALESCE(${uidField}, '0') AS BIGINT), 20)
;

人群数据构建Bitmap

因为人群只包含uid的明细，构建起来会比较简单，并且快速。如下是在MaxCompute中分桶以及构建Bitamp，Bitmap通过udf构建。

--MaxCompute SQl
CREATE TABLE IF NOT EXISTS 空间名.demo人群表名
(
  bucket          BIGINT COMMENT '分桶',
  bitmap          BINARY COMMENT 'uid bitmap',
  ds              STRING
)
    COMMENT '奥格圈人bitmap表'
    PARTITIONED BY
(
  crowd_id STRING
)
    LIFECYCLE 365;


INSERT OVERWRITE TABLE 空间名.demo人群表名 PARTITION(crowd_id='${crowd_id}')
SELECT SHIFTRIGHT(uid, 20) bucket
     ,ENCODE(mc_rb_build_agg(cast(uid as BIGINT ) & 1048575), 'utf-8') as bitmap
     ,ds
FROM crowdSourceDemo   -- 原始人群表
WHERE crowd_id = '${crowd_id}'
GROUP BY SHIFTRIGHT(cast(uid as BIGINT ), 20),ds
;

  • Bitmap标签数据同步Hologers

通过在Hologres中创建外表的方式将MaxCompute中的标签数据导入至Hologres。

--Hologres SQL
CREATE FOREIGN TABLE IF NOT EXISTS public.foreign_table(
  field_value TEXT,
  bucket INT8,
  bitmap BYTEA,
  ds TEXT,
  label_id TEXT
)
server odps_server
options(project_name '${projectName}', table_name 'foreign_table_${index}');


BEGIN;
CREATE TABLE IF NOT EXISTS public.holo_table(
  field_value TEXT,
  bucket INT8,
  bitmap roaringbitmap,
  ds TEXT,
  label_id TEXT,
  PRIMARY KEY (ds,label_id,bucket,field_value)
)
PARTITION BY LIST(ds);
call set_table_property('public.holo_table_${index}', 'distribution_key', 'field_value,bucket');
call set_table_property('public.holo_table_${index}', 'clustering_key', 'ds,label_id');
-- 表数据生命周期：365天
call set_table_property('public.holo_table_${index}', 'time_to_live_in_seconds', '31536000');
END;


--创建分区子表
CREATE TABLE IF NOT EXISTS "public".holo_table_${bizdate} PARTITION OF "public".holo_table_${index} FOR VALUES IN ('${bizdate}');


--数据写入至Hologres
INSERT INTO "public".holo_table_${bizdate}
SELECT field_value,
       bucket,
       bitmap,
       ds,
       label_id
FROM public.foreign_table_${index}
WHERE ds='${bizdate}' and label_id='${label_id}'
    ON CONFLICT(ds,label_id,bucket,field_value) DO UPDATE SET (field_value, bucket, bitmap, ds, label_id) = ROW (excluded.*)
;

  • Bitmap人群数据同步Hologres

通过在Hologres中创建外表的方式将MaxCompute中的人群数据导入至Hologres。

--Hologres SQL
CREATE FOREIGN TABLE IF NOT EXISTS public.foreign_crowd_table(
  bucket INT8,
  bitmap BYTEA,
  ds TEXT,
  crowd_id TEXT
)
server odps_server
options(project_name '${projectName}', table_name 'foreign_crowd_table_${index}');


BEGIN;
CREATE TABLE IF NOT EXISTS public.holo_crowd_table(
  bucket INT8,
  bitmap roaringbitmap,
  ds TEXT,
  crowd_id TEXT,
  PRIMARY KEY (ds,bucket,crowd_id)
)
    PARTITION BY LIST(crowd_id);
call set_table_property('public.holo_crowd_table_${index}', 'distribution_key', 'bucket');
call set_table_property('public.holo_crowd_table_${index}', 'clustering_key', 'ds,crowd_id');
-- 表数据生命周期：365天
call set_table_property('public.holo_crowd_table_${index}', 'time_to_live_in_seconds', '31536000');
END;


DROP TABLE IF EXISTS "public".holo_crowd_table_${crowd_id};
CREATE TABLE IF NOT EXISTS "public".holo_crowd_table_${index}_${crowd_id} PARTITION OF "public".holo_crowd_table_${index} FOR VALUES IN ('${crowd_id}');
INSERT INTO "public".holo_crowd_table_${index}_${crowd_id}
SELECT bucket,
       bitmap,
       ds,
       crowd_id
FROM public.foreign_crowd_table_${index}
where crowd_id='${crowd_id}'

  • 画像分析SQL

在Hologres中将进行画像分析。

--Hologres SQL
SELECT ${label_alias} as "${label_name}"
     ,sum(rb_and_cardinality(t1.bitmap, t2.bitmap)) as "人数"
FROM
    (
      SELECT  bucket
      ,bitmap
      FROM public.holo_crowd_table
      WHERE crowd_id='${crowd_id}'
    ) as t1
        JOIN
    (
      SELECT field_value
      ,bucket
      ,bitmap
      FROM public.holo_table
      WHERE ds= '${label_ds}'
      AND label_id = '${label_id}'
    ) as t2 on t1.bucket = t2.bucket
GROUP BY ${label_alias}

说明：label_alias最简单的方式是t2.field_value；直接取构建的结果用来展示，复杂的则是要在代码层面做个映射关系，不同分级的中文含义。

▐  方案的关键部分说明

  1. 用户识别码 (UID) 分桶设计：由于用户数量较大，决定在一个桶中放置多少用户变得尤为重要。业务应根据具体场景进行测试，确定每个桶的最佳用户数。一般桶的用户数越多，越耗费CU，速度可能有一定提升。

  2. 分析结果异步返回设计：虽然Bitmap加速后80%以上的场景都可以在10秒内返回，但对于可能产生大量桶的偏好类标签，可能会超过接口超时时长限制，因此需要设计一种有效的异步机制。如果初次查询未能返回结果，系统将返回相应的任务ID (taskid)。然后，通过taskid，交互侧可以进行轮询以获取结果。

  3. 构建任务调度设计：整个构建和同步过程都是耗时较长的任务，因此需要一个有效的调度机制。技术已经拥有一套基于有向无环图 (DAG) 的调度流程，在技术侧可以直接采用。

d9e7cd5e83ae0920513e37a0f312af65.jpeg

从3分钟到秒级，画像分析效率对比

基于Bitmap的画像分析，75%的的比例在10秒之内可以出结果，个别由于数量级过大(例如几十亿人群规模，以及一些复杂的标签) 会有一些长耗时的执行。

耗时

bitmap占比

ODPS占比

1~5s

22.30%

0%

5~10s

39.50%

0%

10~30s

25.00%

0%

30~60s

2.60%

9.10%

1~5m

6.60%

79.00%

5~10m

3.90%

9.90%

>10m

0%

2.10%

统计运营常用的10个标签，可以看到Bitmap的平均耗时对比maxCompute耗时缩短了至少2倍的时间，最高能提升20几倍的查询效率。

de3035a603c9e5eafdff742a23b25a96.png

ae49500c185b67a080545f30eafab5d5.jpeg

总结

通过Hologres RoaringBitmap的功能，我们技术平台实现了从原来的分钟级画像计算，到千亿级人群画像秒级分析体验，帮助业务查询效率提升几十倍，也进一步节约了计算资源。

也希望通过这篇文章的分享，帮助更多的业务利用Hologres RoaringBitmap能力，实现更快更准的画像分析。

9400522386e41e623f00ce7e2116033f.jpeg

团队介绍

大淘宝技术用户运营平台技术团队是一支最懂用户，技术驱动的年轻队伍，以用户为中心，通过技术创新提升用户全生命周期体验，持续为用户创造价值。

团队以创新为核心价值观之一，鼓励团队成员在工作中不断探索、实验和创新，以推动业界技术的进步和用户体验的提升。我们不仅关注当前业界领先的技术，更注重未来技术的预研和应用。团队成员会积极参与学术研究和技术社区，不断探索新的技术方向和解决方案。

团队立足体系化打造业界领先的用户增长基础设施，以媒体外投平台、ABTest平台、用户运营平台为代表的基础设施赋能阿里集团用户增长，日均处理数据量千亿规模、调用QPS千万级。在用户增长技术团队，我们提供“增长黑客”极客氛围和丰富的岗位选择，欢迎业界贤才加入。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

阿里巴巴淘系技术团队官网博客
关注
博客
淘系技术，实力为2019年双11而战！稳！
11-12 2万+
今年，双11走到了第11个年头，史无前例的，阿里经济体内有49支技术团队共同参与作战，也是第一次，双11的核心系统将100%跑在云上，这无疑让今年的双11技术作战充满了更大的挑战。正如2019年双11技术团长平畴（汤兴）说的“「善战者，无智名，无勇功」，这是我们技术人最高的境界”。我们一起捍卫了阿里技术人的荣耀，一个字 “稳”！年年双11，回回新玩法，“在吗，盖楼吗？”成为了好友聊天的日常，每天蹲...
博客
淘宝亿级图片素材调度与处理的工程实践
11-15 5
因为业务需要，笔者有幸参与设计和开发了涉及数十亿量级的图片素材调度、处理和索引使用的平台-产业AI素材库，在平台的建设落地过程中，踩了许多坑，也有了一些工程落地上的实践总结，希望分享给大家。导入实践总结素材库建设之初，涉及的图片素材单次导入不过百万，不过随着算法侧针对图片素材训练的模型的“胃口”急速增长，单次图片素材导入的需求直接突破到了数十亿级。在实践中发现，最开始完全借助于dataworks平...
博客
全面解析：从AI原理到模型演进及代码实践
11-13 602
本文从原理、模型演进到代码工程实践，全面探讨了人工智能领域的核心内容。通过深入浅出的讲解，笔者不仅介绍了神经网络的基本原理，还详细阐述了Transformer模型的实现机制及其在自然语言处理（NLP）中的应用。文章结合了实际案例和代码示例，旨在帮助读者理解AI技术的全貌，并能够在实际项目中应用这些知识。初探神经网络（原理）▐神经网络讨论ChatGPT前，需要从神经网络开始，看最简单的“鹦鹉学舍...
博客
2024年天猫双11四大技术亮点发布
11-12 724
第16年天猫双11刚刚落幕，在互联互通、品牌爆发、营商环境持续向好的大背景下，围绕“用户为先、AI驱动”的战略目标，技术持续保持突破与创新，给消费者带来更好的体验，帮助商家实现更好的经营。体验、稳定、效率，是技术先进性的锚点，是我们在双11中技术交付的首要责任，也是技术成功的核心标准。“丝般顺滑”，既要优化用户基础体验，也要带来体验大升级今年，手淘整体端基础体验优化进展明显，核心导购、交易链路...
博客
提升业财系统测试充分度的实践
11-08 1014
在软件测试领域，"测试充分度"一直是一个备受关注的难题。本文探讨了如何提升业财系统测试的充分度，以减少线上问题的发生。文中介绍了测试充分度的概念及其重要性，并提出了测试充分度的建模方法，包括测试场景的建模和用例设计模型等。认识测试充分度网上曾经统计过测试领域的“Top Hard Problems”，其中“测试充分度（Test Sufficiency）”高居榜首。软件测试行业发展到今天，测试充分度一...
博客
深入Java泛型及其设计原则
11-06 51
在日常开发中，必不可少的会使用到泛型，这个过程中经常会出现类似“为什么这样会编译报错？”，“为什么这个列表无法添加元素？”的问题，也会出现感叹Java的泛型限制太多了很难用的情况。为了更好的使用泛型，就需要更深的了解它，因此本文主要介绍泛型诞生的前世今生，特性，以及著名PECS原则的由来。泛型的诞生▐背景在没有泛型之前，必须使用Object编写适用于多种类型的代码，想想就令人头疼，并且非常的不...
博客
将淘宝直播间融入H5页面的技术探索
11-04 781
在数字化转型的浪潮中，如何将直播间无缝融入H5页面，成为提升用户体验和业务转化率的关键挑战之一。本文探讨了这一创新实践，通过技术解析和实际案例，展示了如何在H5页面上实现直播间的高效嵌入，不仅增强了用户的沉浸式体验，还显著提升了业务指标，为开发者提供了宝贵的参考和借鉴。背景先看图说话 —— 猜猜这是一个直播间还是一个H5 页面？认真审题的朋友，闭眼猜肯定猜到是 H5 页面。不认真审题的朋友，再...
博客
大模型技术在淘宝生鲜审核场景的应用
11-01 1035
随着多模态大模型技术的不断进步，大模型的应用范围得到了极大的扩展，其中较为重要的一个分支便是审核场景。现业务域内有较多场景需要人工进行凭证审核，这些审核工作不仅需要耗费较多的人力成本，效率上也有较大的提升空间。困境凭证审核工作主要有以下几项任务：1. 确定商品品种2. 确定商品是否存在某些质量问题（缺陷识别）3. 确认出现问题商品比例这些任务与商品类目强耦合，由于类目众多，且涉及到的商品质量问题更...
博客
OpenAI o1模型的前世今生
10-30 949
记得很久之前看过科幻作家阿西莫夫的一篇短篇小说《最后的问题》[1]，大概是讲根据热力学第二定律，宇宙作为一个独立的系统，会因为熵增而最后归于热寂。于是人类去询问最强大的人工智能AC宇宙的终极问题：如何逆转熵增。但直至人类灭亡，AC仍在思考答案。然后就是最精彩的部分，当然要粘原文：“经过了一亿兆年的运行虚耗，所有的恒星和星河，逐一地泯灭消亡。太空变得漆黑一片，黯然没有一丝亮光。人最后一丝的心灵与模融...
博客
QuickJS的垃圾回收算法
10-28 985
内存管理，对于C/C++选手来说，是个再熟悉不过的名词。malloc/free，new/delete，一旦使用不当，就会遇到mem leak，uaf，double free等等内存问题。但是对于其他高级语言例如JAVA，JS等，似乎从来不需要关心他们创建对象的死活，是这些语言可以违背计算机的规律么？当然不是，只是这些语言底层的编译器/虚拟机自动对内存进行了管理，我们一般称之为GC(garbage ...
博客
FlinkSQL之temporary join开发
10-25 1174
在实时开发中，双流join获取目标对应时刻的属性时，经常使用temporary join。笔者在流量升级的实时迭代中，需要让流量日志精准的匹配上浏览时间里对应的商品属性，使用temporary join开发过程中踩坑不少，将一些经验沉淀在此文中，供各位同学参考与交流。背景介绍关于实时flinkSQL的双流join的背景知识可以先阅读以下文章：https://www.51cto.com/articl...
博客
深入RAG：知识密集型NLP任务的解决方案
10-23 1375
在当今知识密集型任务日益增多的时代，如何有效地利用外部知识来增强语言模型的生成能力成为了一个重要的研究方向。RAG技术应运而生，通过从外部记忆源中检索相关信息，RAG不仅提高了模型生成的精准性和相关性，还解决了大型语言模型在数据隐私、实时数据处理和幻觉问题等方面的局限。本文将详细介绍RAG的工作原理、应用场景、限制及挑战，帮助读者更好地理解和应用这一前沿技术。什么是RAG?RAG（Retrieva...
博客
从DDD视角探讨代码复用的成本及效益
10-21 96
刚工作时，代码写得不太好，师兄每次 CR 代码，总是会指着屏幕里的一坨代码说 “把它抽成一个类或函数”；“为什么呢？写在一起不是挺好的吗？” 我反问道；师兄老道地回答 “为了方便复用”；我仿佛若有所得，回到工位上把那些很长的代码全部抽象成了类和函数，感觉今天又有所成长。但是随着工作经验的增加，我对此又产生了困惑。随着业务发展得越来越复杂，我当初写的那个类被大量复用，为了适应不同的场景，里面充满了 ...
博客
淘宝AI试衣素材高效写入IC实践
10-18 712
随着电商行业的快速发展，用户对于在线购物体验的要求也在不断提高。特别是在服装领域，用户希望能够更加直观地了解商品的实际穿着效果。为此，淘宝试衣项目应运而生，通过AI技术为用户提供个性化的试衣体验。本文将详细介绍淘宝试衣项目的背景、现状、合作场景以及技术实现，特别是如何通过定时任务驱动的试衣素材高效写入IC（商品中心）拓展结构，提升用户体验和转化率。背景▐现状服饰属于非标商品，用户无法直观的通过...
博客
动态量化：大模型在端侧CPU快速推理方案
10-16 1230
作为一款高性能的推理引擎框架，MNN高度关注Transformer模型在移动端的部署并持续探索优化大模型在端侧的推理方案。本文介绍权重量化的模型在MNN CPU后端的推理方案：动态量化。动态量化指在运行时对浮点型feature map数据进行8bit量化，然后与8bit/4bit的权重数据做矩阵乘法并将结果反量化为浮点类型输出。虽然动态量化方案设计的初衷是在移动端高效地推理LLM模型，但方案本身适...
博客
用你的手机/电脑运行文生图方案
10-14 1096
随着ChatGPT和Stable Diffusion的发布，最近一两年，生成式AI已经火爆全球，已然成为移动互联网后一个重要的“风口”。就图片/视频生成领域来说，Stable Diffusion模型发挥着极其重要的作用。由于Stable Diffusion模型参数量是10亿参数的大模型，通常业界都是运行部署在显卡上。但是随着量化、剪枝等模型压缩技术的进步，以及手机等终端设备的算力、带宽、内存持续...
博客
复用的双刃剑：软件工程里的悖论与挑战
10-11 114
在软件工程领域，复用与扩展性一直是开发者追求的目标，然而，这两者之间存在着天然的矛盾。本文探讨了复用的双面性——它既可能是提升效率的利器，也可能是引入复杂性和维护难题的根源。第二十二条军规我一直有一个疑惑，「Duplicated code fragment 10 lines long」这是IntelliJ IDEA中对重复代码的标记。我们从学习面向对象开始就被告诫，duplicated code ...
博客
大模型在问答领域的探索和实践
10-09 1147
随着大模型应用持续火热，应用门槛也越来越低，去年底开始我们利用少部分精力做了一些 AI 探索和实践，并完成了业务所在垂直领域答疑机器人产品的上线。这里主要从普通使用者的视角，把一边学习一边实践的过程记录下来，和大家一起学习交流。本文定位无门槛。本文受众主要是入门玩家，但对大模型感兴趣想做一些小工具，或者在平常的业务工作中希望使用大模型来提效的读者。背景当前大模型的应用还是处于比较初期的阶段，以物流...
博客
KLimiter自适应限流器
09-30 990
随着互联网业务的快速发展，系统架构日益复杂，对下游资源（如数据库）的保护成为系统稳定性的重要环节。传统的限流方式往往依赖于人为设定的固定阈值，难以应对动态变化的业务需求，容易造成资源浪费或系统过载。为此，本文介绍了KLimiter自适应限流器，它可以基于下游资源（如db）水位，对多个不同优先级的上游入口进行自适应调流。背景通常情况下，我们对下游资源（如db）的保护，是通过对上游接口限流进行的；多个...
博客
商家营销工具架构升级总结
09-27 1267
今年以来，商家营销工具业务需求井喷，需求数量多且耗时都比较长，技术侧面临很大的压力。因此这篇文章主要讨论营销工具前端要如何应对这样大规模的业务需求。问题拆解我们核心面对的问题主要如下：1.人力有限我们除了要支撑存量页面的日常迭代，还需要完成大量页面的新增，虽然有短期的人力支援，但总体还是捉襟见肘。2.如何保障交付质量和体验？商家营销工具核心的业务目标之一是体验优化，因此对前端交付页面的质量和体...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值