业务背景
应急溯源是数据安全的最后一道防线，当出现疑似数据泄露的事件时，必须第一时间展开全面准确的排查，并且快速的组织和同步排查的结果，才能为后续事件的妥善处置和报告争取最大空间。
针对疑似泄露的样本数据，和域内各种数据进行关联，确认样本数据是否为泄露的数据，分析泄露源(如生态商家等)，及时进行处置并提供答复口径。 过程中的挑战在于溯源需要扫描数据(如：网关日志、流量数据等)，数据规模在PB级别，查询时间分区往往也较多，超过30+。
业务痛点
业务调研中发现，流量溯源明细表以及OSS日志表的查询是应急溯源常用场景，经常会出现慢SQL，查询计算资源消耗大等痛点。现有的优化方案主要基于以下两个方式：
1、基于Hash cluster/Range cluster 进行聚簇：在等值查询时，将查询Key分为256～4096个桶，利用桶裁剪的能力减少查询数据量；
2、基于二级索引表加速：针对一个表存在多种查询诉求（如OSS日志表既需要按照Access_key又需要按照IP查询)，增加二级表将IP映射到hash key的方式，两层表均通过Hash cluster/Range cluster来查询加速。
两种方式各有其弊端，对于方式一，Cluster by的一两个字段查询表现较好，但无法提效其他字段查询效率；而二级索引表会消耗大量额外的存储空间, 每个二级索引表会占用几十TB到几百TB之间，带来额外的存储成本。
MaxCompute Bloomfilter index 介绍
布隆过滤器（Bloomfilter）是一种高效的概率型数据结构，MaxCompute 在11月最新版本中全新上线了Bloomfilter index 能力 文档链接，针对大规模数据点查场景，支持更细粒度的数据裁剪，减少查询过程中不必要的数据扫描，从而提高整体的查询效率和性能。
大规模点查场景
大规模点查是一种常见的数仓使用场景，通常会通过指定不定列的值对大量数据进行检索，得到条件匹配的结果。MaxCompute是一个EB级的数据仓库解决方案，存储了集团内外的海量数据。在MaxCompute上不仅仅运行了大量的ETL作业，也运行了不少点查任务如：
-
查询某个用户最近一周的外卖记录
-
查询最近一周新注册的用户在母婴类的查询记录
-
查询手机号为xxx的用户信息
以下是一个点查的典型例子：
在这些情况下用户都会有这样一个疑惑：我查询的目标数据只有几条，但是为什么在MaxCompute中却需要大量的资源，并且需要相当长的计算时间才能得到结果？这是因为在这些情况下虽然会有谓词下推到存储层做过滤，但是由于以下原因仍可能读大量数据及消耗大量资源以便找出符合条件的数据：
-
过滤依赖于文件中保存的列的min/max值，数据分散的情况下，谓词下推后过滤效果不佳，甚至无法过滤任何数据
-
仍需按照表或者分区的全量数据申请资源
当前聚簇方式的痛点
在MaxCompute中支持Hash Clustering和Range Clustering两种聚簇索引（Clustered Index）。这两种索引会把数据按照指定的字段（称为cluster key）分散到不同的桶里面，桶与桶之间没有数据重叠，并且桶内部也会根据指定的字段进行排序。在查询时，将Clustering Key作为过滤条件，这样可以快速排除掉不需要读取的分桶，在分桶内也可以过滤掉不需要读取的数据，加快查询速度。但是聚簇表在以下几方面仍有不足：
-
对于Hash聚簇表，只有当查询条件包含了所有的Clustering Key之后才能进行数据过滤；对于Range聚簇表，只有当查询条件中包含了Clustering Key的前缀过滤条件，并且按照Clustering Key的顺序从左到右进行匹配时，才能有较好的过滤效果，如果不包含前缀过滤条件则效果不佳。
-
如果查询条件不包含Clustering Key则没有过滤效果，因而对于查询无固定条件的表来说，聚簇表可能无效。
-
数据写入时需要按照指定的字段进行Shuffle，会导致成本增加，如果遇到个别倾斜的Key，会导致任务长尾。
MaxCompute Bloomfilter 能力优势
点查本质上是检索某一个元素是否存在于一个集合中。不同于数据库中的索引（如BTree、RTree等）用来具体定位到某一行记录，大数据下基于索引构建、维护代价的考虑，更多的是引入更轻量级的索引，而空间效率和查询效率都非常高的Bloomfilter很适合在点查场景进行文件的裁剪，在数据库以及数据湖技术中均广凡引入Bloomfilter index，以便支持更细粒度的数据或文件裁剪。
Bloomfilter index的本质就是对指定的列生成bloomfilter，然后存储起来，供系统来判断值是否会在对应的集合里命中。相对聚簇表，Bloomfilter index的优势如下：
-
高效，插入和查询操作的资源消耗都比普通索引低，能以极小的代价过滤无效数据；
-
在高基数、数据分布紧凑的场景下有很好的过滤效果；
-
扩展性高，可以对表的一列或者多列建立BF索引，且可以和聚簇索引配合使用，即可以对非Clustering Key建立Bloomfilter索引。
蚂蚁安全溯源最佳实践
测试环境
主要包含以下两张业务表：
1、大规模等值测试-流量溯源明细表：Tracing表的si_value列存放的是用户敏感值，比如手机号、id。溯源场景中存在泄露风险的数据也是敏感信息，通过Tracing表的si_value字段，就可以查到该敏感值所有访问记录。
2、热点值查询-OSS日志表：OSS日志表的Access_id是应用的访问key，一般AK泄露场景时会把某个Access_id的所有请求OSS的日志捞出来，然后分析AK是否被某个应用泄露。
使用示例
-- 1、建表
create table test_oss_backend_hi_1 like dwd_sec_evt_oss_backend_hi LIFECYCLE 180;
desc EXTENDED test_oss_backend_hi_1;
DROP TABLE ap_asec_ahunt_sys_dev.test_oss_backend_hi_1;-- 2、创建bloomfilter index
CREATE BLOOMFILTER INDEX access_id_idx
ON test_oss_backend_hi_1
FOR COLUMNS(access_id)
IDXPROPERTIES('fpp' = '0.00005', 'numitems'='100000000')
COMMENT 'access_id index'
;
SHOW INDEXES ON test_oss_backend_hi_1;-- 3、写入数据（需要放在创建索引之后运行）
INSERT OVERWRITE TABLE test_oss_backend_hi_1 PARTITION (dt = '20230424', hour = '10')
SELECT *
FROM dwd_sec_evt_oss_backend_hi
WHERE dt = '20230424'
AND hour = '10';-- 4、查一个热点key -- 1024
set odps.sql.enable.bloom.filter.index=true;
SELECT * from test_oss_backend_hi_1 where access_id = 'LTAIIQ3X1Mr1JAFd' and dt='20230424' and hour='10';
执行情况
在Logview中可以看到，inputs 部分test_oss_backend_hi_1_bf为Bloomfilter虚拟表，其中包含4096个记录数代表源表中包含4096个文件，3606471214 bytes为Bloomfilter 虚拟表大小。
Job1 M1过程从Bloomfilter虚拟表的4096个记录中筛选出891条记录，即经过Bloomfilter index过滤后，源表中仅有891个文件符合条件；随后将其作为Job2 M1的输入，这891个过滤出来的文件对应源表test_oss_backend_hi_1中的9500000 (13341193497 bytes)条记录，最终从这些记录中筛选出精准的1024条数据。
测试结果对比
方案1：源表 + 二级索引方案
方案2：源表 + Bloomfilter Index方案
测试结果表明：Bloomfilter index可以替代二级索引表，整体存储有45%+下降，Bloomfilter index在单热点值查询中计算耗时都是表现最佳的。
虽然Bloomfilter Index构建后会占用额外的存储空间，这部分计量按普通存储收费。从下表中可以看到改造到方案2后带来的整体存储和计算CU减少：
总结
MaxCompute 作为阿里自主研发的具有业界领先水平的分布式大数据处理平台, 尤其在集团内部得到广泛应用，支撑了多个BU的核心业务。 MaxCompute在致力于提升SQL语言的用户体验和表达能力的同时，也在持续进行性能优化，并推出更多的功能提高广大ODPS客户的生产力和生产效率。
在蚂蚁安全溯源的大规模点查场景，基于传统聚簇方式与二级索引方式，均无法很好的解决业务查询效率与成本问题，通过MaxCompute全新引入的轻量级Bloomfilter index能力，提供了更高的空间效率和查询效率，不仅降低了业务的查询耗时，也避免了构建二级索引带来的大量存储消耗，为业务限制降低了成本。
更多Bloomfilter Index使用说明详见官网产品文档：文档链接