现场回顾。PPT 公众号回复 20210724 获取。
感谢您的关注 + 点赞 + 再看，对博主的肯定，会督促博主持续的输出更多的优质实战内容！！！
火山 abtest 引擎
问题
- 实时 abtest 的探索？以及一些应用场景？
有5分钟，1小时的指标，结合监控报警能力，可以在在某些效果很差的实验下进行及时止损。
其他情况下实时指标在 abtest 中的效果并不明显。
- abtest 自动化归因能力？
目前在探索中，结合老虎机算法。但是归因能力还是需要更多业务的输入，以及用户消费数据的特点。
展望
- 智能化：智能化归因，和算法进行集成
- 场景化：深入用户场景
- 被集成：深入集成到各个业务系统中
clickhouse
着重介绍了字节基于 RoaringBitMap 对于人群包圈定或者留存分析上面的优化应用。
人群包圈定流程
- 将画像维度下的 uid 集成到 bitmap 中
- 使用 bitmap 的各种 and，or 操作进行人群包圈定
流批数据质量管控
字节跳动数据质量监控平台的能力。包括实时、离线数据的 dqc 能力。
- 实时数据时效性监控从监控指标上面来分为延迟、乱序；从监控模块：任务，数据源，字节实现了哪些？以及是否有全链路的监控？
字节数据质量平台更多的是从数据源、数据表角度去监控数据表的数据时效、数据质量。
实时数据 dqc：目前主要是针对数据源角度，有延迟监控，没有乱序监控。但也只是针对单个的数据源有延迟、质量（和离线一直，包括实时数据空值等校验）监控，针对全链路，虽然目前建立了血缘数据，但是没有全链路监控。
针对任务角度的监控，全部都是集成在实时数据开发的 IDE 中，不属于 dqc 平台的范畴。博主理解实时 dqc 更靠近业务侧，而非实时数仓侧。
当用户配置好了实时数据质量监控规则之后（延迟配置方式其实就是在 dqc 平台中配置对应 kafka 的时间戳字段进行延迟监控），其会自动生产 flink sql 任务。当然这个 flink sql 任务也会遇到延迟等问题，所以字节团队也会对这种关键任务配置任务层面的报警。
离线数据 dqc：离线数据是会存在全链路的 dqc 数据质量以及产出时效监控。
- 实时数据 dqc 目前有调研过算法吗（毕竟算法会比强阈值监控报警准确度高）？
目前也有自研时序算法来处理流量高峰期的误报过多的情况，但是目前跑下来发现效果没那么好。
- 离线数据时效性监控保障是怎样做的？
在字节总共分为两部分，第一部分是基线，第二部分是产出死保协议。这两种工具产品形态是两天，底层能力都是一套。
基线：会逆推进行预警，这个预警目前是会有两套算法进按照历史执行情况进行预估，两套算法相辅相成可以更准确的预估产出时效。
产出死保协议：此工具的能力是和基线一致的，类似于对于重要任务让各个任务节点的 DE 签署一个产出时间协议，保障对应的数据必须在某个时间点进行产出。如果没有按照这个时间点产出，那么你懂的。
埋点流量治理大规模实践
主要介绍了埋点流量治理的整套方法论，包括治理规范、工具链。
拓扑重构：重复消费 kafka 的任务合并到一个任务中，减少 kafka consumer。
将拆流任务和埋点平台进行绑定：拆流任务其实就是一个 mapper 任务，只有 map，这个 map 任务负责清洗、拆流，任务可以做到热加载，rpc 热加载，拆流策略热加载，udf 热加载，可以做到不重启任务就可以更改。
并且用户可以自定义产出数据类型（json、protobuf 等）、schema，任务会将热加载 schema 配置，动态生成 sink schema 代码，热 load 后写出。针对客户端埋点延迟上报的情况，可以自定义配置上报时间以及策略。但是目前针对埋点丢失、重复、上报延迟也没有更好的方式去解决，只能是在客户端添加一些重试策略。
