更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
据 QuestMobile 报告显示，挪动互联网曾经进入了下半场，在应用人数和应用时长方面曾经没有显著增长，互联网曾经流量趋于饱和。
作为广告投放次要阵地，因为互联网平台流量红利逐步消退，越来越多的广告企业和从业者开始摸索精细化营销的新门路，取代以往的全流量、粗放式的广告轰炸。精细化营销意味着要在数以亿计的人群中优选出那些最具后劲的指标受众，这无疑对提供根底引擎反对的数据仓库能力，提出了极大的技术挑战。
在人群圈选剖析中，分析师个别利用各种标签组合，挑选出最合适的人群，进而实现广告推送，达到精准投放的成果。但因为人群查问在不同标签组合下的后果集大小不同，在一次广告投放中，分析师须要通过屡次的逻辑调整，以取得 ” 最好 ” 的人群包。抖音团体领有宽泛的广告投放场景，在日常实际中，咱们发现以下痛点问题：
- 首先，数据预估。广告主须要对选定的人群组合进行预估，以便判断投放状况并确定投放估算。但广告平台用户越来越多，有的平台 DAU 达到上亿，使得人群包数据量过大，技术上只能采纳 1 /10 抽样存储，将导致 10% 误差。
- 其次，性能问题。为了保障人群圈选精准度，广告主往往会设定多样、简单的人群圈选条件，导致底层计算逻辑简单，比方单次计算可能蕴含几百，甚至上千个人群包。Hive 和 Elasticsearch 等计划在解决大数据量时，查问速度慢。如果研发人员查问某个广告主的所有用户，该计划须要扫描整个用户库，整个过程须要几分钟甚至几个小时，无奈满足广告主实时性要求。
- 最初，存储问题。Hive 和 Elasticsearch 等计划须要额定的索引构造，使得存储空间变大，导致成本增加。
在以往，研发团队通常应用两种计划来解决以上问题：
计划一：将每个人群包存储为一个 Array 类型的数据结构，每次查问须要从 Array 中找到某一个特定 ID。
计划二：应用一个表来存储用户 ID，在查问的时应用 In/Join 计算多个人群的交加。
通过外部长期应用教训，无论是计划一或计划二，都存在当数据量逐步增大，查问速度无奈满足实时剖析需要的问题。基于高性能、分布式特点，ClickHouse 能够满足大规模数据的剖析和查问需要，因而研发团队以开源 ClickHouse 为根底，研发出火山引擎云原生数据仓库 ByteHouse，并在其中定制一套解决模型——BitEngine，用于解决汇合的交并补计算在实时剖析场景中的性能晋升问题。
据介绍，BitEngine 是一个高效汇合数据处理模型，底层基于 MergeTree Family 存储引擎，并在此基础上引入了 BitMap64 类型，开发了系列相干运算函数。BitEngine 提供的 BitMap64 类型适宜表白具备特定关系的大量实体 ID 的汇合，将汇合的交并补运算转化为 bitmap 之间的交并补运算，从而达到远超一般查问的性能指标。
那么，BitEngine 如何利用在人群圈选场景中？举个例子，广告主需要为圈选出“人群包 A”和“人群包 B”的交加人群，实现广告精准投放。
人群包状况：
- 人群包 A = [10001, 20001，30001，40001，50001]，人群包 B = [10001, 20001，20002，20003，20004]
冀望后果：- 通过 BitEngine 计算 A &B = [10001, 20001]
首先，人群包依照肯定规定划分为多个区间，任意两个区间之间的人群包没有交加，由 BitEngine 保障数据的读取和计算是严格依照区间进行；其次，BitEngine 在数据读取时会为每一个文件构建一个读工作，由一个线程调度模块实现整个任务调度和读取；最初，BitEngine 实现所有两头后果计算后，依照后果的输入要求做一次数据合并，由此实现交加计算。已上线业务的测试表明，相比一般和 Array 或者用户表形式，BitEngine 在查问速度上有 10-50 倍晋升。
BitEngine 上线前后查问耗时监控
BitEngine 不仅仅在抖音团体海量广告投放场景中应用，目前更是集成在火山引擎云原生数据仓库 ByteHouse 中对外输入。火山引擎 ByteHouse 次要为用户提供极速剖析体验，可能撑持实时数据分析和海量数据离线剖析，具备便捷的弹性扩缩容能力，极致剖析性能和丰盛的企业级个性，目前曾经与中国地震台网核心、海王团体、莉莉丝游戏、极客邦科技等诸多行业企业达成单干，深度助力各个行业数字化转型。
点击跳转火山引擎 ByteHouse 理解更多