京东数据架构解析：供应链效率提升与决策优化策略_

导读本文介绍了数据编织在数据分析与治理中的应用。

分享内容概览：

1. 数据分析与治理面临的挑战

2. 数据编织理念在指标平台中的落地

3.数据分析与治理技术详解与实战案例

4. 当前进展与未来展望

5. 问答环节

分享嘉宾｜梅焕京东数据架构师

编辑整理｜王红雨

内容校对｜李瑶

出品社区｜DataFun

数据分析与治理面临的挑战

1.数据分析与治理面临的挑战

企业中不同角色在数据分析和治理上面临着不同的挑战。

【业务视角】

看数难（质量）：数据孤岛普遍存在，各数据产品间的同名不同义和同义不同名现象频发，导致业务人员难以获取一致且可靠的数据视图，增加了理解和使用难度，阻碍高效决策。
提需久（效率）：需求从提出到实现的过程冗长繁琐，包含多个环节，人工介入过多，严重影响数据分析和决策效率。

【研发视角】

口径不一、运维成本高：指标口径分散于多种数据源，修改指标前需全面梳理，复杂度高，维护成本大。功能上线后常遭遇数据一致性问题，需反复核查与调试，消耗大量运维资源。
人力资源不足：专业数据团队规模有限，难以满足全方位需求。

【组织视角】

存储冗余：数据重复存储现象普遍，缺乏有效整合机制，加重了存储负担，尤以基础信息字段为甚。
计算冗余：跨 BG 和 BU 的商品交易数据引发的重复计算问题凸显，虽欲削减却碍于数据链路与业务紧密相连，难以操作。计算冗余难以根除，还进一步挤压有限的资源空间。
无序的数据增长：这是数据治理的巨大障碍。本质上，熵增原理映射出人的自然倾向——倾向于轻松状态，如无人约束时，私人物品易杂乱无章。同样，若无视计算与存储成本，数据开发者可能为每项业务创建专用的 APP 表，导致数仓内星型、雪花型模型混杂。数据爆炸式增长叠加重复计算/存储，不断恶化治理环境，威胁线上业务稳定性。

2. 数据分析与治理目标

我们的目标是将传统数据处理方式升级至指标中台模式，旨在革新数据计算与加工流程。

解决“看数难”

业务语言：构建指标定义体系，采用 4W（Who, What, Where, When）+ How + 裁剪口径的业务化表达，确保不同人员定义相同指标时遵循同一标准，避免多义性。
唯一资产表认证：业务语言背后，每个指标需技术负责人实现，绑定唯一资产表，保障数据输出一致性（5W2H 验证）。
元素被定义及生产：系统识别业务语言中的各项参数，如裁剪口径下的维度、操作符、值，自动匹配资产表字段，实现指标自动化生产，无缝对接业务和技术两端。

应对“人力短缺”

指标服务平台赋能不同角色，缓解人力压力：

逻辑资产层：释放数据资产管理人力，优化数据仓储效率。
自动化生产：基于标准数仓表，提供一键加速服务，节省数据加速人力。
自动化服务：依据引擎特性，自动化处理加速数据，提高查询速度，降低延迟，同时减轻数据服务团队负担。
全链路系统化：释放数据测试人力。

管控“数据无序增长”

业务视角的数据治理：业务方有权停用无效看板或指标，借助平台全链路元数据追踪，一次性下线关联实体，避免遗留问题。
智能运维与调度：依赖生产消费日志，实现系统级智能优化，动态调整资源分配，预防计算与存储冗余，提升整体效能。

数据编织在指标平台中的落地

接下来探讨数据编织概念及其在指标平台中的应用。

数据编织是一种架构模式，旨在使可信数据能够通过一个公共层从所有相关数据源传送给所有相关数据使用者，从而能以高效的方式整合不同数据源。

实现数据编织，第一个核心技术焦点为数据虚拟化，指标服务平台通过逻辑表与逻辑资产构筑业务和技术沟通的桥梁。然而，仅此不足以满足业务方多元化的数据使用需求，因为他们还需知晓数据的具体应用情境，例如 QPS（Query Per Second）与 DPU（Data Processing Unit）。为此，就需要第二个关键技术——智能加速。智能加速依托数据虚拟化，将可信数据源引入公共层，同时赋予智能加速的能力，以适应各类引擎需求，无论离线批量处理还是实时查询，都能游刃有余，确保用户体验一致无差别。至此，看似已覆盖大部分需求，但仍存一大隐忧——数据治理挑战。

面对业务快速迭代，被动式治理显然力不从心，仅在资源无限的理想状态下，前述方案可行，而现实则不然。为此，必须引入主动数据治理，这就需要依托于主动元数据，即通过生产消费血缘，提供智能退化与编排能力。

三项关键技术相互支撑，共同构建指标服务平台的强大能力，以满足多元化需求。在后文中将对其进行详细介绍。

整体架构如下图所示，也是围绕以上三个关键词设计的。

数据分析与治理技术详解与实战案例

1.数据虚拟化

围绕数据虚拟化这一核心概念，京东零售指标服务平台通过逻辑表与逻辑资产搭建起业务与技术沟通的桥梁，实现数据处理的高效与灵活。

（1）逻辑表

逻辑表作为数据虚拟化的基石，其构成从不同角度解读呈现多样化特征。从业务视角观察，逻辑表聚焦于所支持的指标、维度与修饰，形成一套系统可识别并应用于指标生产的业务语言。从技术视角审视，逻辑表强调其所依赖的物理模型，无论是经 5W2H 认证的数仓模型或是源自逻辑模型的二次处理结果，逻辑表兼容多种数据源形式，支持任意 SQL 片段与 JOIN 操作，确保业务需求与技术实现的无缝衔接。

完成逻辑表定义后，平台引入了一系列加速策略，包括介质加速、计算加速与智能加速，以提升数据分析效能。每种加速策略生成相应的逻辑表实现版本，对外表现为抽象层级，用户无须深入了解，只需专注业务需求。这一设计有效简化了用户界面，降低了学习成本，使得技术细节对终端用户透明，同时确保了数据服务功能的完整发挥，后续章节将详细介绍智能寻址等高级特性。

（2）逻辑资产

除了逻辑表，指标服务平台还引入了逻辑资产概念，以增强平台灵活性与响应性。逻辑资产相比物理资产，最大特色在于其“无需物化”的性质，即在满足业务需求的同时，不必实际转化为物理存储。当前平台支持多种类型的逻辑资产，如基于衍生指标构建的复合指标，无需单独物化即可实现数学运算；复合维度，基于基础维度二次处理而成，同样免于物化，但能满足业务查询要求；修饰包，处理修饰间 AND/OR 关系，无需额外物理存储；以及逻辑模型，允许对物理模型进行任意组合，最终输出逻辑列及其字段类型信息，极大地提高了存储效率。未来逻辑资产的种类还将继续扩充，以适应更多业务场景的需求。

通过逻辑表与逻辑资产的创新运用，京东零售指标服务平台成功构建了一个集业务友好、技术先进于一体的现代化数据处理框架，为海量数据时代的企业运营提供了强有力的支持。

2.智能加速

接下来通过实际案例来深度剖析逻辑表的实际应用过程，揭示用户如何配置逻辑表以及平台内部的工作原理。

（1）指标配置化生产过程

用户操作逻辑表分为三阶段：基础信息设置、逻辑层配置与加速策略定制。

基础信息：绑定物理表

首先，用户需指定逻辑表关联的物理表，通常为 5W2H 认证的资产物理表，如示例中的事实表与维表。事实表承载核心交易记录，而维表则补充扩展维度信息。通过定义关联字段，实现两表间的无缝链接。

逻辑层配置：映射业务语言

随后，配置逻辑层，将物理字段转化成业务术语。如 deptid 字段，标记为部门维度；isDeal 字段代表是否成交，供后期过滤条件使用；基于 ordered 字段创建指标，设定聚合方式（求和/去重），实现业务需求的精准映射。

定制加速策略：性能优化

最后，用户需规划加速策略，涉及加速类型、目标数据源、库表选择与生命周期管理。此外，还需配置调度信息，如账户队列及调度规则，确保数据服务的顺畅运行。

平台解析：从用户配置到技术执行

用户完成上述配置后，系统会进行技术语言翻译，将用户配置的业务逻辑翻译成技术指令。以指标“通用域交易成交订单数量”为例，系统捕捉其中的“成交”关键字，自动关联此前绑定的成交修饰 isDeal 字段，实现场景特定的裁剪处理，确保数据生产准确无误。

接着，系统对事实表与维表执行联接操作，重构数据流。这一过程将数据按需推送至预设引擎（Playhouse、HBase、Redis 或其他），由各自的数据服务组件负责后续查询请求的处理，实现性能优化与资源高效利用。

（2）智能物化&计算优化

尽管用户配置的逻辑表与加速策略足以应对多数常规分析需求，但在特殊场景下，特别是面临突发的大数据量冲击时，传统的手动配置显得捉襟见肘。因此，“智能物化”应运而生，旨在进一步降低使用门槛，通过自动化手段优化数据处理效率。

传统模式下，用户需明确选择加速类型（介质加速或预计算）及匹配的引擎，这对数据研发人员提出了较高的专业要求，不仅要熟悉不同引擎特性，还需掌握复杂的生命周期管理。为了突破这一瓶颈，智能物化技术登场，依据历史消费行为与内置规则，自动调整加速策略，从而将决策重点从“类型+引擎”转移到更具意义的性能指标（如 QPS、TP99）上。

设想一下，原本平稳运行的系统遭遇电商大促高峰，数据吞吐量激增，原本 500 毫秒响应时间骤然延长至两秒，严重影响用户体验。若缺乏智能物化，用户需自行诊断问题、询问专家并手动调整预计算策略，耗时费力。相反，智能物化机制能敏锐捕捉性能下降信号，基于消费数据变化趋势，自动触发向 HBase 引擎迁移的加速措施，即时恢复高效服务，无需人工干预。

智能物化不仅简化了用户操作，更实现了系统自我修复与优化升级，特别是在高负载环境下，其自主调节能力尤为突出，成为保障数据服务连续性与质量的关键一环。

让我们通过具体案例深入探讨智能物化如何优化数据处理流程。假设初始配置仅包含从 Hive 到 ClickHouse 的介质加速任务，在理想情况下，此任务于凌晨 5 点启动，仅需 8 分钟即可完成，消耗 15C 的计算资源。然而，若同步发起 Hive 到 HBase 的预计算加速，考虑到早高峰期间 Hive 资源紧张及复杂计算需求，预计耗时长达两小时，需投入 350C 资源方能于 7 点结束。

此时，智能物化展现出卓越的调度智慧。鉴于 ClickHouse 主要用于支撑在线查询，且清晨时段用户活跃度较低，系统充分利用 ClickHouse 空闲资源，于 5:08 分开始执行额外计算，仅需 20 分钟与 3C 资源便告完成。由此，原本单一的 Hive 至 HBase 加速路径被智能优化为 Hive 至 ClickHouse，继而从 ClickHouse 至 HBase 的双重路线。

如此一来，尽管用户初衷仅为 Hive 至 ClickHouse 的加速，智能物化却巧妙调整任务序列，最终形成了 Hive 至 ClickHouse，叠加 ClickHouse 至 HBase 的复合方案。结果是，系统在 CK 与 HBase 中各备一份数据副本，分别对应两种逻辑表实现——这一切对用户完全透明，他们仅需关注业务层面的指标、维度与修饰。

值得注意的是，智能物化过程中引入的物化类型（如明细或预计算）、支持时间范围、引擎选择（PlayCost/HBase 等）、分流策略与任务依赖等参数，虽不在原始逻辑表范畴之内，却是逻辑表实现不可或缺的部分。这些细化属性，尤其是物化类型与时间范围，对于确保数据时效性与准确性至关重要，同时也是智能寻址算法的核心参考，使系统能在繁复的数据网中迅速定位所需信息，实现高效数据交付。

总之，智能物化通过动态任务调整与资源优化，不仅提升了数据处理效率，更促进了数据服务的整体智能化，让系统能够在用户无感的状态下，实现数据的精准管理和高效利用。

（3）指标消费-寻址与编排

面对复杂的数据查询需求，通过智能寻址与编排连接用户需求与数据源，确保每一次数据访问都能得到高效且精准的响应。

首先要提供统一 DSL 语义，这一语言规范了所有数据产品的查询标准，涵盖五个关键要素：

指标：定义了查询中所需的特定量化信息；
聚合条件：维度路径，用于数据切片，以便按类别细分；
筛选条件：设定查询限制，精确获取符合条件的数据项；
维度属性：附加于主维度之上，丰富数据描述，如商品颜色、尺码等；
数据组织：指明结果排序与分页方式。

以数据看板 A 为例，其请求包含部门等于“3C”维度下的数据，并涉及复合指标（用户成交贡献率、贡献率同比）与衍生指标（有效用户数、成交用户数）。统一 DSL 层将复合指标分解为基本单元，便于后续处理。

语义拆分后，就需要智能寻址与编排，由策略层、编排层与加速层共同构成，旨在实现数据请求的最优路径规划。

策略层：寻找最佳服务提供者

首要任务是确定哪项数据服务最适合响应特定指标查询。鉴于各类数据服务覆盖的指标范围各异，策略层需精确定位。

例如，用户数据服务专攻用户相关指标，交易数据服务则聚焦于交易领域。有时，同一指标会被多个数据服务覆盖，区别在于预计算程度的不同，如 HBase 侧重预计算，ClickHouse 则偏向明细数据，导致 QPS 表现差异明显。

策略制定需兼顾多种考量，如离在线转换策略、负载均衡等。以数据量大小为例，大量数据检索倾向于离线服务，小额快速查询则偏好在线实时服务。

编排层：优化查询执行路径

编排层专注于将请求细分为可并行执行的小单位，同时探寻合并机会减少冗余操作。以贡献率及其同比查询为例，编排层评估是否可在同一时间段内并行执行，进而提升效率。此外，当期查询与同期对比查询也可探索并行可能性，避免多次往返数据库。

加速层：挖掘引擎潜能

加速层致力于确保每次查询获得最优化执行。这包括但不限于引擎选择、利用引擎特性（如谓词上推、谓词下拉等）进行查询优化，以及缓存策略部署。通过精细调控，加速层最大限度地缩短响应时间，提升查询性能。

下面举一个引擎优选的实例。

用户在 10 月 4 日 6 时提出了一个查询成交金额的请求，最初仅有 ClickHouse 明细数据支持，随着数据量激增导致查询延迟增加，智能物化机制触发 Hive 至 HBase 的预计算任务，以缓解压力。然而，预计算任务 SLA 设为次日早晨 7 点，意味着当日查询仍需混合使用预计算与明细数据。假设进一步优化至 ClickHouse 至 HBase 路径，SLA 提前至 5 点 28 分，再次相同请求时，全部数据已预先计算完毕，查询效率显著提高。

（4）指标消费-服务优化

指标消费加速的第二个场景是服务优化，核心目标是大幅提升指标服务的效率与资源利用率，可实现 5 倍效能跃升，同时缩减列式存储占用。

假定查询需求为两项指标——3C 类别的订单数量和订单金额。在未优化状态下，通常做法是从同一基础表格提取数据，生成两个 SQL，各自计算后合并得出结果。

我们采取了一系列优化措施。首先，同源模型合并，基于两个指标源于同一数据模型的事实，系统在构建查询语句时，将它们整合成一个 SQL，显著降低了处理负担。

第二个优化是谓词下推，即在 SELECT 语句中嵌入的条件被下沉至子查询层面，促使子查询先行执行数据过滤，同时仅保留必需字段，而非加载整个数据集，极大地提升了数据检索速度。

第三项优化是属性跟随，旨在精简查询过程中的冗余步骤。具体而言，用户真正需求往往是商品 ID（sku_id）与其对应的中文名称（sku_name）。传统方法中，为呈现 sku_name，查询语句会连带加载该属性，无形中增加了计算成本。鉴于 sku_name 实为 sku_id 的一个属性，系统引入了专门的维度属性数据服务，负责补充缺失的 sku_name 信息，这意味着底层表格与 SQL 可以安全移除 sku_name 字段，既节省了存储空间，又加速了查询进程。

最后是优化复合维度。用户往往期望获取更细致的数据分类，如商品单价层级划分——高于 100 元归为“high_price_level”，反之则为“low_price_level”。以往，此类需求需通过物理表预处理，即将价格层级标签物化存储，再经 GROUP BY 操作筛选输出。然而，借助复合维度技术，这一繁琐过程得以简化。复合维度允许直接在物理表的价格字段上应用逻辑判断，即时生成所需层级，无需额外的物化步骤。这种方法几乎不影响查询性能，因其逻辑处理开销极低。这样，系统能实时响应用户对多层次数据的需求，还能显著降低存储成本。

利用上述四点优化，为数据生产链路和消费链路都带来了显著的性能提升。

3.主动元数据

Denodo 公司对主动元数据的定义为：使用历史经过适当处理和总结，便可作为传统元数据的自然延伸。在京东零售指标服务体系中，这一理论具体为，依托于动态的消费、生产元数据，自动物化、退化指标生产和消费链路，主动进行元数据的动态迭代。

具体而言，即便在用户无须介入的场景下，如促销活动引发查询响应时间从 500 毫秒延长至两秒，系统可通过主动元数据管理，智能分析并预测性能瓶颈，进而自主优化，例如通过增强预算分配、智能寻址等手段，将响应时间压缩回甚至优于原先水平，达至 100 毫秒级别。此举不仅显著改善用户体验，更在后台无声运转中，保持系统的活力与效率，体现主动元数据在维护数据健康生态方面的潜在价值。

主动元数据的技术架构概览揭示了其运作机制的核心组件及流程。架构设计中，元数据目录有静态与动态两大类型，涵盖了指标、维度、逻辑表、实现集群配置等一系列关键元素，辅以修饰符、维表等辅助信息，构成了丰富的元数据生态系统。这些数据首先在元数据中心接受自检，而后由指标服务平台内部各子系统汇总上传。

动态元数据的生成依赖于决策引擎与消费、生产链路的日志上报机制，详尽记录了生产活动的时间、实例选择、运行周期，以及消费端的指标调用频次、目标集群及时延情况。此外，集群资源的 CPU 和内存消耗也成为监测重点。这些动态反馈为决策引擎提供了智能物化、退化与编排决策的依据，同时消费数据的 Hive 存储促进了系统自我学习与优化循环。

为强化透明度与可用性，主动元数据方案还配备了消费生产链路的可视化工具，直观展现系统内外交互详情，助力数据分析人员洞察系统行为模式，优化资源配置与策略调整，确保数据流畅通无阻，提升整体服务质量和效率。

主动元数据治理巧妙运用全局视野与动态调节，特别在复杂数据处理方面成效卓著。从数据源头出发，即一张事实表加两张维度表的基础结构，系统捕捉到多个用户分别请求生产相似但实质关联的流量 PV 与 UV 指标，随即启动任务整合计划，消除冗余作业，大幅提升效率。

面对 27 个月历史数据的海量生产需求，初试用一个任务全包揽的策略遇挫，表现为频繁故障与资源紧绷。随后，采用按月分解任务的方式，均衡分布压力。期间，元数据管理系统担当重任，综合考量各项参数，包括任务量级、集群碎片状态和单碎片承载量，实现定制化优化。

另一重要能力是算力感知，在涉及多集群协作时表现突出。遇到某个集群负荷过载，系统能迅速转向轻载集群执行数据生产，再通过集群同步分享成果，既避开拥堵瓶颈，又能挖掘集群间协同潜力，全面提升系统效能。算力感知远不止监控集群概况，还精细至 CPU 和内存使用状况，确保资源分配准确及时。

下图是主动元数据生产消费血缘的全景展示，可以看到指标如何服务于哪些看板，还深度解析了指标生成路径，追溯至数据服务、ClickHouse 表、Hive 表，揭示了完整的血缘链路。

可视化工具有助于明确每个生产任务及其决策点在系统中的流动轨迹，便于快速定位故障原因，向用户提供详尽指引，确保数据流程透明可控。

当前进展与未来展望

1.当前进展

当前，服务平台在定义即生产链路上已广泛服务于五大业务群组，跨越十余个部门，需求覆盖率超 50%，并成功支持如黄金衍生品等高级数据产品。经受住了大促、跨晚、春晚等重大事件考验。

指标调用量已达千万级别，注册指标逾万，维度登记数千，配置化生产链路数量庞大。

指标复用率达 40%，效率提升 50%，自动化生产链路节省 20% 的离在线存储、计算资源。

2.未来规划

首要任务在于拓展业务场景，探索离线在线一体化分析、A/B 测试、个性化分析等领域；

其次，优化数据加速策略，深化 HBO、RBO 等能力；

第三，增强主动治理，引入智能生命周期管理，完善 CBO 能力，强化主动元数据治理；

最后，持续改进用户体验，打造更加友好高效的服务界面，利用大模型助力用户智能数据分析。

以上就是本次分享的内容，谢谢大家。

问答环节

Q1：在逻辑层，每次计算后的结果会被缓存吗？缓存多久？

A1：逻辑表中主要是分为三个部分：1. 业务语义层，即代表该逻辑表支持的指标、维度等信息；2. 物理模型层：如离线数仓场景下的 Hive 表，以及逻辑模型（比如 Hive 视图）；3. 加速层，即可以配置针对于不同数分场景下的加速策略（如 tp99 要求高的和 tp99 要求低的，其可以配置不同的数据加速策略以使用不同的成本满足不同的业务诉求）；我理解上述问题主要涉及到的是第三部分，先回答数据加速结果不是存储到缓存中（这里的缓存主要指的是数据服务链路使用的缓存，比如 Redis、服务内存等），而是实际沉淀到 OLAP 层（或者 KV 数据库），以不同的生命周期将数据沉淀下来（当然这部分数据也可以配合数据服务的缓存一起使用）。这个生命周期在不同场景下的时间是不同的，但是核心的设计原则是：用空间去换时间时，不能存在无效的空间浪费（计算和存储）。比如在电商场景中，往往有大促周期的说法，对于数分场景而言，某个指标（如成交金额），在非大促周期内的 tp99 可以是 2s，但是在大促周期的 tp99 需要在 500ms 以内，这种就可以通过在同一个逻辑表内设置两个加速策略去完成，大促时间段可以配置成预计算策略，且生命周期为大促时间段，其余非大促时间段的为明细数据。当然实际场景肯定比该场景更加复杂，但是核心原则还是上述的原则。

Q2：如何保障在同一时间周期维度下的指标数据，在业务方于不同时间点抽取时，数据仍保持稳定，不受变动？平台是否有相应规则主动监测此类型的问题？

A2：针对第一个问题，即如何保证数据一致性，在离线场景下，指标服务平台通过限定指标定义必须源自单一逻辑资产表的方式，有效避免了数据变动问题。这意味着，只要上游数据未经历重刷，不论何时查询，数据都将始终保持一致，因为所有指标产出均直接关联至这张核心表，确保了“定义即生产”的原则得到贯彻执行。虽然数据加速措施可能会带来性能表现上的差异，但在质量层面则不存在问题。即便面对相同长期请求，系统响应快慢有别，却不会造成数据品质的参差，归功于始终依据同一张资产表进行处理。

在上述原则下，我们还遇到了一些数据质量的问题，主要遇到两种情况：1. 数据不准导致的历史数据的回刷，主要集中在离线场景；2. 数据延迟导致的结果变化，只要体现在实时、准实时场景。

针对上述第一种情况，其本质上还是【数据不准系统如何发现的问题】，目前指标服务中采用的核心原则是：默认用户知道准确的数据应该长什么样（即一个指标的技术负责人，能知道指标的数据在什么情况下是不对的），为此，指标服务平台目前提供了指标巡检的能力，可以让用户为不同的指标*维度路径*时间周期去配置预期值，并辅以一些规则，如不为 0、数据范围、同比环比等。但是在这期间也发现了一些问题，如每年的京东促销活动、天气变化等都会影响到指标的数据，这部分的内容目前无法被监测，就会导致巡检的准确率问题。所以目前指标服务平台也在积极建设这块元数据能力。此外，指标的定义与生产都在指标服务平台，那么平台是否有能力识别其业务语义并进行指标的结果验证？（如预测能力，数理统计相关能力），目前指标服平台也在积极探索中。

针对上述第二种情况，这块本质上数据其实没有问题，所以核心还是在于产品级的预期控制。指标服务平台与集团内的 BDP 系统有元信息层面的打通，具备离线、准实时任务的 SLA 信息，将这部分内容与端上用户的产品体验结合，可以在一定程度上减少用户的使用体验。

Q3：京东零售在数据服务领域的改造升级，对其他企业而言，学习门槛和实施成本如何评估？

A3：京东零售内部正在经历的数据服务体系转型，旨在克服以往烟囱式开发架构带来的挑战。采取的是渐进式迁移策略，借助自主研发的数据服务平台，该平台具备承载历史版指标的功能，允许新旧体系间的平稳过渡。在迁移过程中，只需添加特定标签，即可无缝对接自动化生产流程，确保前后一致性，简化了调用方式变更的验证过程，配合自动化映射工具，确保迁移顺畅。

Q4：如何构建高效的共享模型，实现指标复用？如何监控服务质量？

A4：指标服务平台的宗旨之一就是：指标复用。即相同业务口径的数据应该由统一的模型给出独一份的计算口径，不同的业务方共享相同的指标口径以解决【对数难】的问题。还是以离线数仓为例，成交 GMV 指标的口径定义只能被一张 Hive 物理表定义，但是服务的业务方可以是多个，比如集团内的不同数据产品、BI 工具等，这里面数据的开放与共享主要涉及到两大问题：1. 权限；2. 资源。

1. 针对权限问题，主要集中于离线计算的库表权限，以及在线分析场景的指标权限。针对前者，京东在内部的大数据平台中已经有一套针对 ERP、生产账号、集市、库表的权限管控机制，目前指标服务是直接复用的。而对于后者，在指标消费时，指标服务平台有自己的一套数据权限管控机制。主要是调用方*指标*服务方粒度，可以简单理解为：调用方就是不同的页面、菜单；服务方就是不同的 OLAP 集群。

2.资源：资源层面也主要包含离线的计算资源以及在线分析的数据服务 OLAP 引擎资源。目前离线资源方面跟公司的大数据平台也是打通的，复用生产账号、队列、调度节点等资源管控机制。而针对后者，指标服务也提供调用方*指标*服务方级别的限流、熔断、缓存等措施，以保护服务方的资源使用。

关于如何监督服务质量：这块我理解主要还是需要回答指标的质量问题以及后续的数据治理问题。指标的质量当然也包含这个指标的数据服务的质量（比如 QPS 和 tp99），目前指标的质量主要集中在复用度以及服务质量：调用方、调用频次、tp99、QPS。如果我们发现某个指标的质量较差，那么就会触发指标下线的流程，在流程中会触发指标的全链路生产以及服务链路的资源释放（当然这么做的前提条件是指标服务平台的主动元数据的基础设施能力）。打通指标的生产和消费全链路血缘。实现一站式得数据治理。

Q5：逻辑层数据存储时间应如何设定？

A5：逻辑层的存储时间并非固定，而是根据数据的实际使用状况动态调整。在数据加工链路中，预计算策略生成的中间表（智能物化）将在完成数据校验后自动清理，确保资源高效利用。存储时长实质反映的是数据的有效期，直至消费完毕即按需清除，体现缓存性质，既加速数据处理，又保护任务执行连续性。

Q6：数据处理流程中，是否优先抽提至数据仓库再计算，若否，是否会干扰原有系统运行？

A6：目前指标服务的离线数仓场景都是会先抽取到数仓之后再计算的。实时链路目前指标加速部分尚未接入到指标服务平台，不过从数据计算的角度，原则上肯定也不会因为指标加速链路去影响到生产系统，可以通过 MQ+Flink 等技术架构去实现。具体这块的实现有些复杂，这里不做详细描述。

Q7：京东零售的数据仓库采用了何种框架结构？

A7：目前尚未做到湖仓一体：主要还是解决离线数仓的场景。但是数据湖提供的是统一的数据访问层，简化数据管理和分析（支持结构化与半结构化方式），其数据的元信息与离线数仓的较为类似，目前我们正在打通 POC 数据链路，通过将逻辑表（业务元数据）与统一的湖仓一体的技术元数据打通，解决数仓集市中的数据孤岛与数据整合问题。

是否是流批一体：目前在数据中台中数据资产的沉淀中，技术上使用了 Flink 等技术，但是目前指标服务平台主要还是解决的离线场景，对于实时场景的资产沉淀以及逻辑层与物理层如何打通目前还在建设中。可以知道的是目前像 JMQ 这种消息队列技术的非结构化数据以及离线数仓中的库表的结构化数据，其与指标服务平台逻辑层打通的技术实现方式是不同的，这块目前是否能借助上述湖仓一体以及引入更多 OLAP 引擎（如 Doris、StarRocks 等）还在进行技术探索中。

以上就是本次分享的内容，谢谢大家。