更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
抖音依附本身举荐零碎为用户推送可能感兴趣的视频内容，其中趣味圈层是举荐的重要能力，通过了解外围用户的偏好特色，判断两者偏好的相似性，从而构建同类用户的趣味圈层，实现精准举荐。
以往的趣味圈层往往依赖繁多的维度或标签，比方内容类型、时长、天文特色等，难以揭示用户趣味的底层逻辑。例如，重庆美女小姐姐吃播视频、二次元古风舞蹈视频，外表上标签类型可能齐全不一样，但深度剖析后发现喜爱两个视频的是同一个类型的人，并把他们划分在同一个趣味圈层中。
要搭建这样一套趣味圈层平台，不仅须要算法策略，对底层数据存储架构也是一大挑战。抖音每日新增的数据量宏大、业务标签形形色色，更须要满足业务人员对简单查问的实时性诉求。之前技术团队采纳 MySQL 作为存储架构，作为一种行式存储的数据库，MySQL 对于大量数据的解决效率较低。如果要在 MySQL 上查问上亿级别的数据，可能须要更高配置的硬件，甚至可能须要采纳分片、读写拆散等策略来晋升性能，这将导致硬件老本显著进步。
因而，技术团队逐步将趣味平台基于 ByteHouse 进行重构。ByteHouse 是一款 OLAP 引擎，具备查问效率高的特点，在硬件需要上绝对较低，且具备良好的程度扩展性，如果数据量进一步增长，能够通过减少服务器数量来晋升解决能力。本文将从趣味圈层建设难点及构建计划等角度拆解如何基于 OLAP 引擎来搭建趣味圈层平台。
趣味圈层平台介绍
趣味圈层指兴趣爱好雷同的人组成的群体，趣味圈层能够从用户视角更深刻的了解短视频作者和内容，挖掘出该圈层作者外围用户群体的独特趣味点和典型偏好特色，作为划分作者的重要标签，利用在内容散发、垂类经营、数据分析、战略规划等场景中输入价值。趣味圈层以簇（cluster）的模式存在，通过机器模型聚类而成，每个簇蕴含一位种子作者及多位与之关联作者。
圈层生产流程：数仓的天级 Hive 表以定时工作的形式将 Hive 表内数据依照分区导入 RDS（MySQL）数据库，同时预计算脚本每天会定时将 RDS 内的数据按需写入缓存（如圈层信息等通用查问）或写回 RDS（如圈层的父节点信息等外围数据），生产流程胜利会标记在缓存代表今日数据无效，反之报警告诉相干负责人。
圈层查问流程：用户操作查问，前端发送查问场景数据申请，服务端接管到申请后读取相应的缓存、数据库表及分区，对数据进行组装，最终返回给用户。
次要问题
数据收缩
日更版本导致数据量级收缩，圈层根底信息表日增万级数据，圈层作者信息表日增百万数据，圈层用户信息表日增千万条左右数据，曾经达到 MySQL 秒级千万级查问的性能瓶颈。
查问效率已无奈满足需要，即便有缓存减速缩小联表查问，单表查问的效率在到 10s 以上，其中圈层了解（圈层用户信息表）进入页面的工夫超过 15s，肯定水平影响业务应用体验。之前做了很多包含索引优化、查问优化、缓存优化、表构造优化，然而单次对表更新列 / 新增批改索引的工夫曾经超过 2 天，优化老本也逐步升高。
历史架构过薄，难以承接较简单圈选能力
从现状来看，以后圈层架构简略且为辨别查问场景，与数据库间接交互且仅反对简略的同步查问，当业务须要较简单的泛化圈选条件时，须要用户在平台期待超过 15s。
从将来布局，目前以 RDS 为存储的同步查问架构已无奈反对须要关联多个表和特色的简单条件查问的业务场景。
业务特色收缩
标签特色收缩，以后圈层有越来越多的标签形容，因为不同业务方会通过不同视角了解圈层，如垂类标签 / 圈层关键词形容 / 圈层品质分类 / 圈层画风等，目前圈层信息实体特色达到几十种，预计圈层属性标签仍会收缩。
一站式圈选泛化指标作者诉求增多，以后作者只蕴含根底信息，业务方心愿基于圈层和其余根底作者特色，如粉丝数，作者品质，活跃度等以满足对作者的流量定向策略等需要，以满足简单条件多维度的筛选排序功能。
基于 ByteHouse 重构趣味圈层平台
RDS 作为行式数据库更适宜单点事务剖析工作显然不合乎以后平台诉求，咱们别离从查问场景、查问性能、存储老本、迁徙老本对存储选型。
查问场景
- 圈层信息由模型生产，按工夫分区批量导入，不存在长期导入，为 append only 场景。
- 圈层特色多，业务方依照诉求对和本身业务相干的特色进行筛选，列式存储比行式存储更适合。
- 圈层次要以剖析统计为主，不强需要事务处理，面向 OLAP 业务。
查问性能
- MySQL 对于多列简单的条件查问时，查问性能很难优化，须要通过强依赖 redis 缓存减速，否则平台性能不可用。
- 圈层场景通常限度在部分数据中聚合剖析，如计算圈层 id 位于汇合内的关键词频率统计，若该汇合范畴过大索引生效会被劣化为全表扫描。
具体场景测试
重构前后存储比照
| MySQL | ByteHouse |
|---|---|
| 关系型数据库，反对事务 | 分布式列数据库，反对最终事务 |
| 行存储模式，适宜尽量少的读取须要的行数据 | 列存储模式，且数据压缩比高，对大批量数据读取有着人造劣势 |
| 单过程多线程服务，单条业务申请查问无奈无效利用到多个 CPU 资源 | 多核并行 |
| 面向 OLTP 业务 | 面向 OLAP 业务 |
具体场景比照
数据管理信息查问场景：
利用工具剖析场景：
总结
综上能够看到，基于 ByteHouse 替换 MySQL 重构抖音趣味圈层平台后，不同几个典型场景的查问效率均匀晋升了 100 倍左右，大大晋升了用户体验。因为 ByteHouse 杰出的查问性能和良好的数据压缩比，中等资源的服务器就能很好的满足需要，这也升高了综合硬件老本。此外，ByteHouse 具备良好的程度扩大能力，如果数据量进一步增长，也能够便捷的通过减少服务器数量来晋升剖析能力。
点击跳转火山引擎 ByteHouse 理解更多