AI时代的 湖仓数据体系建设 刘岩 腾讯游戏数据技术负责人 腾讯游戏数据工程的挑战基于多智能体的需求构造AI驱动的湖仓资产体系可持续优化的工程平台系统演示 腾讯游戏数据工程 01的挑战 1.1腾讯游戏数据发展—紧跟业务发展,以业务需求为核心 腾讯游戏以休闲品类进入市场 外部大厂纷纷投身网游,腾讯游戏基于绕道休闲品类打造QQ系列游戏,深耕社交流量 2003~2007 游戏业务发展 以“代理+自研”后来居上 重启游戏代理,同步自主研发 率先完成“端改手”移动化,全面升级自研体系 2008~2014 产业链布局和全面出海 打造全品类矩阵,扶持游戏厂商,建立全球化发行平台,全面出海,推动电竞职业化、游戏IP化等 2015~Now 3.0技术驱动创新 对于数据资产集中管理的进一步加强,河图数 据治理平台全面升级 标准数据治理体系建设:以业务应用为导向,数据管理规范3.0发布 逐步开始接入实时技术:datamore投入应用, 决策对于数据时效性提出较高要求 架构升级 数据应用 数据治理 迁移到TDW数据 日志标准迭代推 数据治理处于萌 仓库,完成数据 进,移动互联网 芽阶段,数据资 的集中管理与统 数字化,精准分 产意识建立,数 一分析 析,用户画像、 据管理规范1.0 买量与增长分析 发布 游戏发展初期,缺乏统一标准,游戏数据孤岛。 业务持续扩张,数据驱动成为新的价值增长。 以数据驱动业务变革,安全合规与成本治理。 1.0基础功能完善阶段 从零起步 数据应用 数据治理 一切从简,快速 数据单位主要是 每年在游戏数量 启动,MySQL读 G,数据分散在 上翻翻,对接不 写分离、分库分 各个数据库,缺 同业务的游戏日 表 乏整体数据统计 志,标准难以统 一 数据平台演 进 2.0平台构建阶段 1.2游戏业务对数据的需求 现存游戏业务的数据挖掘/提取类需求数万个/年,数据挖掘是问题归因、分析决策、干预闭环的关键。 业务对数据需求数据产品和服务数据资产数据加工链路 经营分析 (可视化) 数百个看板 (框架+特性) 1%的数据表资产 离线计算+数仓 精细化运营 (数据挖掘) 数万个/年数据提取服务 基于明细数据动态分层 流式计算+湖仓一体 辅助决策 (预测) 数十个算法服务 特征和画像标签 湖仓一体 驱动业务 (干预) 数十个实时线上服务 特征和画像标签 流式计算+实时计算 1.3如何更好地服务业务? AI要解决的问题不是仅仅是写SQL,而是从业务需求到数据结果的各个环节,需要建立AI环境下的工程平台和资产体系。 确定数据分层 结果和想法验证 口径对齐 业务需求数据结果 14 需求理解 提交正式数据任务 使用LLM进行提效 对齐业务统计逻辑 持续运营 数据结果及提取逻辑 结果发送 找到细粒度的数据表 资产探查 资产体系 2 3 SQL代码实现SQL验证 计算加速 提交任务 与业务二次对齐逻辑 验证SQL准确性 基于多智能体的 02需求构造 2.1提示词(需求)的完备度与结果准确性 “好”提示词的特点: 完整的上下文解释 隐性知识 行业know-how 恰当的示例 逐步思考 明确的预期结果 《ThePromptReport:ASystematicSurveyofPromptingTechniques》https://arxiv.org/abs/2406.06608 统计: 2024.1.1-2024.2.2期间XX条件的玩家 每个自然周不同周活跃天数 玩家数 输出: 统计周、周活跃天数、玩家数 2.2基于“需求标准”的人与AI需求对齐 需求标准一个完备的SQL需求包括:“筛选”、“问题”、“结果”三段式提问,及“行业知识” 需求对齐通过需求Agent,匹配需求案例和行业知识,对进行需求整理与改写,改写成标准的需求格式 把复杂需求分解成简单的子需求,降低AI生成难度,通过工程化方式组合成最终结果,确保稳定可控的交付质量。 2.3根据复杂度进行需求分解 标准化 需求 是 看板资产 完全满足 是 库表资产 资产匹配与推荐 完全满足 <=4 复杂度估算 >=5 生成SQL 分解成子需求 知识资产特征资产库表资产 根据腾讯游戏内部实际应用统计: 1.需求复杂度小于等于4准确率>90%,5至7准确率>60%,大于等于8准确率<25%,复杂度大于等于15时正确率趋近于0 2.需求复杂度=Where个数+Join个数+Union个数+GroupBy个数 +OrderBy个数+Distinct个数+开窗/json等高阶函数个数 AI驱动的湖仓资产 03体系 3.1LLM在SQL生成的能力瓶颈 Spider是一个由11名耶鲁大学学生注释的大规模复杂、跨领域语义解析和文本到SQL数据集。它由10,181个问题和5,693个独特的复杂SQL查询组成,涉及200个数据库以及覆盖138个不同领域的多个表。https://github.com/taoyds/spider BIRD(BIgBenchforLaRge-scaleDatabaseGroundedText-to-SQLEvaluation)代表了一个开创性的跨域数据集,用 于检查广泛的数据库内容对文本到SQL解析的影响。BIRD包含超过12,751个独特的问题SQL对、95个大型数据 库,总大小为33.4GB。它还涵盖了区块链、曲棍球、医疗保健和教育等超过37个专业领域。 https://bird-bench.github.io/ 3.2如何提高SQL准确率? 通过资产建设覆盖所有需求?但真实的需求更复杂 示例: 统计:2024.10.1-10.7,游戏内各个玩法,按每天的参与率排名+次日留存排名+七日留存排名算一个总排名 排名逻辑:每个玩法在每天都有一个参与率、次留、七留的数值,先需要按照这三个数值排名,然后按照排名总和再order一下 库表资产 无法提前通过预处理,建设好资产 BIRD 数据集的 无法将知识提前补充到元数据中 挑元数据补充 战 SQL复杂,无法满足实时查询速度需求 SQL 优化引擎 3.3从经典数据中台到AI+湖仓中台 自上而下业务梳理 经典数据中台 自上而下 分层加工 用户分层使用数据 应用数据层ADS 汇总数据层DWS 明细数据层DWD 操作数据层ODS 业务 数据工程 数科 资产治理 资产覆盖率 资产覆盖率存在天花板资产建设滞后于业务需求 数据治理体系复杂边际收益低 非结构化资产标准缺失 数据集 AI + 按照最细粒度进行轻量加工 湖仓中台 语义资产 指标维度特征业务规则 语义层建模规范 资产自助交付 满足率 + 透明加速层 资产成本 运行效率 10% 生成新看板 根据特征生成新指标、维度 补充业务信息 生成特征 拆解指标、维 度至特征 无特征 生成新看板 根据特征生成指标、维度 拆解指标、维 度至特征 40% 已有特征 推荐已有看板 匹配已有指标 维度 50% 已有指标 按速度进行物化 &冷热策略 按维度组合建 逻辑视图 按特征识别指标 维度唯一 按热度进行物化 &冷热策略 按最小粒度建 逻辑视图 按来源识别最小粒度 特征库 + 实时链路数据接入 指标库 3.4构建“人和AI”都能理解的资产 建立从业务需求、行业知识、数据结构之间的资产纽带,通过领域模型进行沉淀和推荐,确保资产能被AI理解和使用 资产知识图谱 特征资产化沉淀 公共特征自动识别和转化 无歧义的传递复杂信息 热度分析特征聚类事前事后收敛群助手定期曝光 逻辑初始化-自动解析 临时号码包规则 特征初始化 框架初始化 AI用资产 资产推荐自助分析开放式问答 游戏历史SQL 通过大模型,结合SQL本身复杂度,自动识别出通用特征 日志表 资产 流程资产认证 基础资产 命名、注释、逻辑等开发标准校验,人能理解 优质资产 S指标唯一性、资产标签 、维度匹配等管理标准校 验,人和机器能理解 人用资产 资产检索手工提数任务开发 根据 ROI 迭代 优选 (存量) 中间表 资产 治推荐未通过,不 理转正为优选资产 评价模型 推荐准确率资产 超过80% 迭代建设的验证用例集 数据资产治理:资产下架(逻辑删除、物理删除…)、资产结构优化(指标资产新增、逻辑调整…)、资产质量提升(计算效率、稳定性、异常恢复…)治理 治理建议 治理评价 资产运营&效率工具 玩法域 活跃域 …… 辅助英雄出辅 助装明细 技能命中率 …… 双周流失用 户标签 …… …… 数据资产标准:开发标准(命名、字根、逻辑…)、管理标准(唯一性、标签…)、运营标准(热度、复用率、成本…) 3.5领域模型技术架构 服务场景 智能提数智能问答 资产治理 归因分析 …… 在线推理 Query理解 预处理Query分词 检索排序系统 L0粗排 L1精排 SFT 模型蒸馏 预训练 样本生成 推理加速 语义召回 图谱召回 文本召回 意图解析 模型部署 Query归一 Query分域Term分析 Server 接口 改写词库 标签索引 业务逻辑 资产热度 知识图谱 语义索引 文本索引 离线挖掘 监控告警 数据库表逻辑资产搜索日志反馈日志数据看板分析SOP 底层语料 Neo4j 微服务 vLLM DeepSpeed Pytorch Faiss ES Mysql 基础组件 3.6新一代AI资产基建-湖仓一体 通过湖仓一体的技术架构,最终数据分析直接使用明细数据(非传统结果数据)而不用考虑性能问题,配合实时链路接入,让业务人员可以使用实时明细数据做业务洞察分析。 用户的看板基于明细数据实时计算和汇总,能够支持进一步的数据挖掘和探索分析,快速洞察业务增长背后的深层次原因。 DA看板/探索分析 iData报表 分析自助化 实时表MySQL 离线表PG 资产表 仓(BE) StarRocks 湖(CN) 日志明细表 湖仓一体化 离线数据仓库 TDW 日志表-ODS TGArk预处理框架 时 间修复 维 度提取 倾 斜打散 ... 动 态分发 监 控对账 自 动修复 分冷,热,实时三级存储,满足实时与性能从低到高不同层级提速要求,可以将不同数据按时间或重要程度,分级提供最优性价比。 时序 数据 Druid 配置表 道具、渠道、地图、赛季、模式... 特性表 对局、组队、武器、活动、社交、行 为... 经分框架表 注册、活 跃、流水 结果表 中间表 资产实时化 链路实时化 减少原有开发过程中的数据重跑检验过程;数据源(资产)变化时看板自动更新,无需等待。 TDBankStorm TGlog日志采集 TGlog日志采集 原有架构 当前架构 3.7基于StarRocks构建湖仓一体解决方案 独立无状态的ComputeNode支持灵活的计算扩展。 存储层可以在对象存储上进行灵活的资源扩展。 智能应用 基于大模型的智能应用建 模 ComputeNode支持热存储(BE)和冷存储(对象存储)查询。 通过数据下沉机制,可以实现数据在冷热存储的转储 SuperSQL 与 JDBC开 发 计算加速 统一SQL访问分析层 缓存加速优化(Caching)资产推荐 数据仓库 虚拟数仓 弹性计算+计算资源隔离 (异步)物化视图 代价预估,CBO优化 存算分离 OLAPTable 数据湖 ExternalTable冷 分 冷热分层热 腾讯云对象存储(COS) COS加速优化层 冷热沉降 物化视图加速统计 3.8智能动态加速 资产粒度 API服务 粒度智能标识 数据集粒度标识 特征粒度标识 粒度治理 成本优化建议 粒度重复判断 粒度管理 粒度资产详情 粒度目录管理 资产粒度查询 资产热度查询 资产优化器 资产热度 资产速度 自动化触发物化 特征看板使用热度 粒度热度 执行物化 物化视图动态 变更 验证物化视图 创建物化视图 热度&速度治理 数据集/特征治理详情 数据集/特征待优化建议 优化策略制定 热度&速度总览 资产透明加速映射 数据集运行