数字化转型的今天，京东物流业务呈现出复杂多变的特性，涉及众多场景、多元化渠道与日益增长的数据量。针对市场对于数据即时性和灵活性的迫切需求，京东物流推出了一站式敏捷 BI 解决方案，以应对分散且高并发的数据处理挑战。本次分享的是京东物流如何通过其一站式敏捷 BI 产品，实现数据的快速集成、即时分析及自服务报告，从而在激烈的市场竞争中赢得优势，进一步提升业务效率和决策质量。通过这些实践，我们将见证数据驱动的力量如何在京东物流的业务流程中展现，以及如何帮助企业在数字化的道路上更快前进。

业务背景

1. 业务背景

数据来源多

数据来源极为多样化，包括线上数据、线下数据，甚至是手工提报的数据。这种多元化的数据来源导致数据管理和分析过程十分复杂，尤其是在不同来源的数据需要被整合和分析时。由于来源的多样性，确保数据质量和一致性成为了一个挑战。

需求变化快

由于京东物流的业务覆盖范围广，员工众多，从总部到各个地区层级，每一个层级都可能产生独特的数据需求。这些需求经常变化，且每个层级都可能定义自己的数据指标或分析某些特定的数据细节。这种快速变化的需求环境要求数据系统必须具备高度的灵活性和快速响应能力。

做数耗时长

传统的数据处理方式，如员工手工在 Excel 中处理数据，导致数据处理时间长，效率低下。此外，数据处理的成本高，数据口径不一致等问题也随之产生。

2. 复杂的“中国式报表”

物流和传统企业中常见的中国式复杂报表带来的挑战如下：

受众多样性

各个层次、各种角色的成员都是报表的使用者，不同角色的用户关心的信息内容不同，样式不同，使用方式不同。

数据计算复杂

查询、分析条件复杂，且报表中往往存在复杂的统计运算，如 Sumif 函数、汇总、同比、环比、达成状态等。对于参数页面布局、参数控件类型等都有较高要求。

报表样式复杂

不追求图表式的直观可视化效果，而是体现信息的丰富度，因此在样式上使用了较多的数据透视、多层表头、不完全划分、分栏等，样式非常复杂。

多数据源

数据源分散，数据信息来自不同的业务系统，技术路线和数据结构都有很大差异。

治理难度大

需要从数据源、数据指标体系两方面入手，且业务多层级联动共同拉齐数据认知，为治理带来很大困难。

研发资源消耗大

面向分析场景需求个性化程度高、不固化、不明确，研发侧支持有资源瓶颈。

大数据技术挑战大

大数据量、实时在线交互分析、系统执行复杂度不确定、响应时间和用户体验很难预判保证。

3. 建设平台工具以解决实际业务问题

(1)业务场景的数据化挑战

监控与预警的需求：质量改善、工单处理、异常处理岗位对 KPI 达成与工单量变化的敏感度。

数据时效性：在考核、复盘、经营运营及责任追究等方面的高标准要求。

人力资源局限：现有支持体系难以满足众多一线员工的复杂需求。

(2)数据处理的现状与困境

繁琐的数据获取与处理：员工需从各自业务系统下载并处理数据，效率低下。

报表的生成与分享：数据分析后需制作报表，进而进行分享与下达，流程繁杂。

(3)UData：创新的解决方案

敏捷 BI 的引入：一个自助式、集成式的敏捷商业智能(BI)解决方案。

数据集成：集成各类指标与模型至数据地图，简化标准化数据源的获取。

自助式内容分析：为非专业人士提供易于操作的数据分析工具，减少对技术的依赖。

数据准备：简化数据之间的关联、筛选与聚合操作，提高工作效率。

中国式报表与在线 Excel 插件 A. 数据与报表的融合：通过插件将数据语言与在线 Excel 结合，顺应用户线下习惯。

办公协同系统的整合：报表生成后，通过推送、邮件、订阅等方式实现办公自动化，确保信息流畅传递。

4.产品方法论与解决方案

1. 产品规划第一步:产品价值主张

产品规划的第一步为确定产品的价值主张：强调任何产品都需从其价值主张出发，这是产品成功的基石。

(1)三个逻辑的概述

价值发现：识别目标用户群体，明确产品解决的具体场景及需求，并构建核心竞争力。

价值共创：探讨如何与合作伙伴共同创造价值，包括共创方案和流程机制的构建。

价值获取：确定价值落地的模式，包括衡量标准和方法。

(2)价值发现

用户需求的深入分析：通过监控3万多数据业务人员的日常行为，揭示其重复性使用 Excel 等工具的频繁性和模式。

系统化建设的不足：指出目前数据体系化建设的不足，以及数据标准化沉淀的限制。

(3)价值共创的策略

建立多元异构查询支持：强调需要支持多样化的数据查询和交互式数据获取。

降低技术门槛：目标是打造一个低门槛、自助式、交互式的工具，特别强调点选式的操作和在线化的 Excel 功能。

业务层共建：与业务部门共建数据集，提高数据标准化程度，并通过重点项目共建和数据分析师培养专项计划提升整体数据理解和应用能力。

(4)价值获取与效果衡量

衡量指标的设定：通过覆盖度、渗透率和工作时长节省等指标衡量产品上线后的效果。

实验观测：运用 AB 实验等方法观测业务数据分析的效率和效果。

2. UData 一站式敏捷 BI 产品架构

构筑商业智能产品架构的过程中，我们面临的挑战源自业务系统的多样性及数据库类型的复杂性。为了应对这一挑战，联邦查询技术被引入以实现跨数据源的统一查询，这不仅强化了数据处理的能力，而且增强了系统的灵活性和响应速度。在此基础上，数据管理的角色显得尤为重要，它要求我们能够清晰地识别并定位标准化的数据集，确保数据的准确性和可靠性。

进一步地，数据的准备、分析和系统共享被强调为系统内特别核心的能力。这些能力不仅加强了数据的实用性，也为后续的决策提供了坚实的支持。

此外，利用商业智能工具和沉淀的标准化数据资产，通过开放 API 支持其他系统调用内部数据，这一策略极大地提高了整体架构的效率和灵活性。

总体而言，在构建商业智能产品时，必须认真考虑和实施跨数据源查询、数据管理以及数据服务等关键功能，以确保系统的强大、可靠和高效。

3. Udata 1.0-产品特性

(1)快速集成多样数据资源：该平台能够迅速融合各类数据资源，突破了传统数据处理的局限性，为用户提供了一个全面而综合的数据视图。

(2)简化数据配置：转变了常规的数据处理方式，用户无需撰写复杂的 SQL 语句，而是通过直观的点选式界面进行数据配置，大幅降低了技术门槛，提高了操作的便捷性。

(3)数据加速与联邦查询支持：软件底层采用了先进的查询引擎，支持联邦查询，这意味着即使数据分散在不同的系统和平台上，也能实现快速、高效的数据检索和处理。

(4)类 Excel 的操作简化

线上数据选择与创建：用户可以在线选择并创建自己的数据集，简化了数据处理步骤。

配置在线复杂报表：在数据集基础上，用户能够配置类似于中国式的复杂报表，这些报表既轻量级又易于操作，适应了用户对灵活性和复杂性的双重需求。

(5)轻量级访问与快速集成

工具提供了轻量级的访问方式，使用户能够迅速而方便地处理和分析数据。

支持快速集成到包括办公系统、业务应用系统和电子邮件等在内的各种平台，增强了其实用性和广泛的应用范围。

一些不足

系统稳定性问题

随着 1.0 版本在更广泛领域的应用，系统稳定性成为一个显著的问题，影响了用户体验和操作的连贯性。

性能问题

数据处理的效率和速度是评估系统性能的关键指标，性能瓶颈会导致做数耗时长，进而影响决策速度和业务流程。

应用性问题

随着需求的快速变化和数据来源的多样化，系统需要灵活适应不断变化的环境和需求，应用性的不足可能会限制系统的广泛应用和扩展 Spark 完成历史数据的回补。

基于用户价值公式思考产品优化空间

当前系统的挑战主要为以下几大方面：

系统稳定性：在广泛应用过程中，系统稳定性常常受到挑战，影响了用户的连续使用体验。

系统性能：频繁出现的性能问题减缓了数据处理速度，影响了整体效率。

易用性问题：随着用户规模的提升，用户需求多种多样，系统的易用性和产品体验暴露出一些问题，影响了其广泛应用的可能性。

优化策略与方法论：

用户价值公式：提出了一种评估产品价值的公式，即新体验减去旧体验和迁移成本后的剩余价值，以此作为优化的基础。

旧体验与新体验的对比：分析用户的旧体验，如手工操作 Excel 的熟悉性与稳定性，以及新体验所带来的自助式分析和自动化更新的便利性。

新体验中的挑战：识别新体验中存在的问题，如数据稳定性和同步的及时性问题，以及用户面临的迁移成本。

具体应对策略为：

改善数据稳定性：采取措施解决数据丢失和同步问题，提高数据稳定性。

降低迁移成本：通过简化操作和提供培训，降低用户的学习成本，使迁移过程更加平滑。

增强系统性能和应用性：优化系统架构，提高性能，扩展应用范围以适应不断变化的用户需求。

产品逻辑梳理

(1)数据处理链路的核心组成

数据源的多样性：强调了数据源包含实时与离线数据，以及明细层与汇总层数据，其中明细层数据量庞大，而汇总层数据经过聚合后较小。

数据集与数据源的区分：讨论了数据集作为数据处理和管理的结果，它代表了加工处理后的数据结果集，这有助于提高可视化的效率。

(2)数据集的构建方式与分析能力

构建数据集的多样方式：包括点选式操作生成 SQL，直接编写 SQL，以及问答式的自然语言处理技术。

数据分析能力：探讨了提供的分析能力，包括不同类型的数据报告和报告来源，以及系统易用性的考量。

(3)系统优化的逻辑与方法

产品和系统逻辑接入的标准：讨论了优化新版本系统时考虑的产品与系统逻辑接入的标准和方式。

数据准备与校验：强调了数据准备过程中的校验工作的重要性。

架构梳理与模块界定：强调了对系统架构、模块边界以及前后台关系的重新梳理和界定，以确保 BI 产品的稳定性和高效性。

7. Udata 产品升级

(1)稳定性提升

①稳定性专项的实施

问题收集与记录：系统地记录和识别用户报告的 bug 和问题，如系统打不开或数据不一致等，以便于后续分析。

高频问题识别：通过持续记录，识别频繁出现的问题，然后进行分类，以了解哪些类型的问题是经常发生的及其影响范围。

②分类与复盘

问题分类：将识别的问题进行分类，为进一步的分析和解决提供清晰的方向。

定期复盘：定期回顾问题，深入挖掘根本原因，并基于这些原因制定解决策略。

③监测指标的定义与优化措施

监测指标定义：定义关键的监测指标，如故障率和可用性，包括数据问题、共享问题和操作问题等，这有助于更准确地监控和评估系统稳定性。

性能优化：识别和解决导致查询失败的底层引擎问题，以及相关的性能问题，确保系统的稳定运行。

(2)性能提升

①性能问题及其对用户体验的影响

性能问题的表现：用户在尝试打开报表时经常遭遇长时间的加载延迟，有时甚至无法加载完成，这种延时和不确定性严重影响了用户的体验。

问题的重要性：强调性能问题不仅是一个技术问题，而且对用户体验有显著影响，需要被优先解决。

②性能优化策略

性能诊断：通过性能诊断，识别导致报表加载缓慢的原因，可能是数据接入问题、复杂的 SQL 查询，或不必要的数据引入等。

数据物化策略：实施数据物化，将大表拆分为小表，减小查询的数据量级，从而提高查询效率。

缓存策略：引入主动和被动缓存，基于历史访问行为优化缓存命中率，进一步提升查询效率。

③数据报表的分类与管理

分级和分类：对数据报表进行分类和分级，明确每个报表的服务场景和性能要求，实现精细化管理。

发布时的约束：在数据报表发布时增加边界约束，确保每个报表在发布前都能满足既定的性能标准。

④综合优化视角

技术与运营结合：强调性能优化不仅涉及技术问题，也包括产品运营的思路及用户的引导和约束。

用户教育：提倡对用户进行教育，使其更加理解如何有效地利用系统，编写高效的 SQL，减轻系统负担。

⑤数据集创建后的性能评估

评分机制：在数据集创建完成后，系统将基于性能和效率等关键指标对其进行评分，以确保每个数据集都符合既定的标准。

优化建议提供：对于评分不高或有改进空间的数据集，系统会提出具体的优化建议，指导用户如何改进数据集的性能和效率。

基于 StarRocks 的引擎升级带来极致查询性能

①性能优化的核心引擎与合作

核心引擎选择：采用基于 StarRocks 的核心引擎进行性能优化，并与社区进行战略合作，为优化提供技术支持。

StarRocks 的优化特性：介绍 StarRocks 支持的向量化执行，物化视图加速查询和 CBO 优化等特性，以及通过这些特性实现的性能提升。

②算子聚合下推优化

数据处理链路：描述数据从消息队列到不同数据库和引擎的处理链路，以及在StarRocks查询时面临的挑战。

下推优化策略：实施算子聚合下推，将聚合和排序等操作下推到底层数据引擎(如CK、 MySQL)执行，减少 StarRocks 引擎的压力和网络带宽消耗。

③性能提升的实际效果

查询效率提升：通过优化，六张表的聚合关联查询时间从 30 秒降至 6 秒，显著提升了查询效率。

网络带宽优化：减少了数据在网络上的传输量，从而降低了网络带宽消耗。

(3)易用性提升

①易用性提升的重要性

1.0 版本的问题：指出前一版本因快速迭代而存在的问题，如系统高耦合、操作链路不清晰、设计复杂，以及展示形式单一。

2.0 版本的目标：明确了新版本的目标是提升易用性，降低用户的理解和操作门槛，让数据分析任务像协同办公文档一样简单。

②ERRC 方法的应用

移除(E)：识别并移除多余的无效概念和步骤，以减少用户学习成本和操作复杂性。

减少(R)：简化页面信息和操作步骤，去除冗余操作，使用户的操作更加直观和高效。

增加(R)：增强系统的性能诊断和校验，建立清晰的系统边界，提供驾驶舱功能等，以满足不同用户的场景需求。

创造(C)：创新数据探索能力，如引入问答式 DataGPT，以提供更高级的用户体验和分析能力。

③2.0 版本框架优化

低门槛目标：降低用户的理解和操作门槛，清晰可理解的系统概念，简洁的操作链路。

性能校验与诊断：在系统中增加性能的校验和诊断，确保系统稳定可靠。

场景区隔与功能增强：根据不同用户的使用场景提供区隔化的服务，同时增加驾驶舱等功能以提升系统的实用性和灵活性。

创新性能力：通过创新问答式数据探索能力，提高数据分析的效率和准确性。

④旧版菜单的问题

繁杂性：描述旧版菜单内容繁杂，各种功能杂陈在一起，导致用户难以快速找到所需功能。

用户体验：由于菜单的复杂性，用户在系统中的导航和任务完成过程变得不直观，影响了用户体验。

⑤新版本的导航优化

二级导航引入：提出在新版本中引入二级导航的方式，使结构更为清晰和直观。

内容合并与精简：对导航内容进行合并和精简，清楚地定义每部分的功能和定位，以便用户更容易理解和使用。

信息架构清晰：通过优化信息架构，确保用户在进入系统后能迅速、清晰地了解如何完成任务。

⑥基于席克定律的改造

席克定律(Hick's Law)：引入席克定律，说明面对过多选择时，用户做出决策的时间增长。

菜单优化：根据用户的使用习惯和流程对菜单进行重新排列，减少或隐藏非常用功能，以减少用户的选择负担和干扰，加快反应时间。

⑦数据准备的操作优化

旧版本的操作复杂性：指出旧版本在数据准备环节存在许多步骤和冗余概念，导致用户理解和操作门槛高。

新版本的简化流程：新版本将数据准备的操作从 11 步精简至 6 步，大幅提升了用户理解和处理数据的效率。

⑧应用菲茨定律(Fitts’ Law)优化用户操作

菲茨定律概念：引入菲茨定律，解释目标越大且越近，用户到达的速度越快，出错几率越低。

改造点：基于菲茨定律，缩短用户到达路径，提供更合理的引导流程，减少用户的操作步骤，提高用户转化和操作效率。

⑨提升用户体验的综合策略

精简操作步骤：通过减少操作步骤和去除冗余概念，简化用户的操作流程，降低理解门槛。

优化引导流程：改进用户的引导流程，确保用户可以更直观、更快速地完成任务，提升整体用户体验。

⑩旧版本数据准备界面的问题

集成度过高：指出旧版本的数据准备页面集成了选择数据集、管理和创建操作，导致页面复杂且难以理解。

缺乏用户引导：操作过程中缺少必要的引导，使用户在完成任务时感到困惑和不便。

⑪新版本交互体验优化

操作与反馈分离：新版本中，数据集的操作与结果反馈被清晰地分离，确保用户可以立即得到操作反馈。

明确的操作指示：在界面上清楚地列出可进行的操作，增加用户在操作过程中的清晰度和方向性。

⑫泰斯勒定律的应用

复杂度守恒概念：引入泰斯勒定律，解释系统中固有复杂性的存在，并强调其无法被完全消除，只能通过设计进行转移和平衡。

复杂度转移改造：为了提升用户体验，将系统的固有复杂度从用户侧转移到研发侧，通过后端复杂的处理来为前端用户提供简洁明了的操作体验。

应用实践案例

1. 实现业务报表的线上化、数据更新自动化

(1)应用效果概述

系统线上化：介绍了通过 UData 系统实现报表线上化，替代了以前频繁且耗时的手工制作过程。

实时更新：强调了一次性设置后的长期效益，报表可以实时更新，显著提升数据处理效率。

(2)《618 大促小时战报》效率提升案例

优化前状况：每天手工制作报表 10 次，每次需耗时 30 分钟，仅能提供整点数据。

优化后成果：通过 UData 线上制作一次，耗时 1 小时，报表永久有效且实时更新。

效率对比：通过线上化和自动化处理，实现了 80% 的工作效率提升。

(3)省区日常运营监控效率提升案例

优化前状况：每天手工制作报表 1 次，每次需耗时 2 小时。

优化后成果：通过 UData 线上制作一次，耗时 2 小时，但报表永久有效，无需重复制作。

效率对比：通过自动化和长期有效性，实现了 96% 的工作效率提升。

2. 典型案例

(1)项目概述与目标

项目持续期：介绍了项目实施了半年多时间，目标是通过数据处理优化分拣员的工作效率。

优化目标：明确项目旨在降低分拣员在数据处理上的时长，并提升其有效工作时间。

(2)成效展示

数据处理时长的降低：报告在半年的时间里，分拣员在数据处理上的时长下降了 37%，显示出数据产品优化的显著效果。

有效工作时长的提升：同时，分拣员的有效工作时间实现了持续上升，其中在半年期间有效工作时长上升了 10%，反映出工作效率的整体提升。

(3)分析与结论

效率提升分析：分析发现数据产品优化导致分拣员数据处理时间减少，使他们能够更多地投入到实际工作中，从而提升了整体工作效率。

综合效益：强调了通过精细化的数据管理和流程优化，项目不仅提升了个体工作效率，也为整体操作流程带来了效率提升。

3. 升级规划：ABI 能力进阶

(1)数据资产平台与 ABI 能力进阶

问答式报表能力：介绍了未来 ABI(问答式商业智能)能力的进阶，即通过问答式交互返回报表和数据趋势，简化数据获取过程。

移动端应用：强调了在数据资产平台上结合 DataGPT 和 AIGC 技术，使用户能够在移动端轻松获取所需数据。

(2)数据资产集约管理

管理组成：描述数据资产集约管理包含知识库、标准指标体系和实时数仓模型，形成一个全面的数据管理体系。

DataGPT 作为释放窗口：将 DataGPT 作为数据资产价值释放的轻量化窗口，使用自然语言作为查询门槛，使所有员工都能轻松进行数据查询。

(3)大模型 AIGC 的作用

业务与技术语言转化：大模型 AIGC 为业务语言和技术语言的相互转化提供能力支持，使非技术人员也能通过自然语言获取复杂数。

助力数据普惠化：通过这种能力加持，推进数据的普惠化，使数据查询和分析不再局限于数据科学家或技术人员。

04

Q&A

Q1：我想详细了解您提到的基于问答形式获取数据源码的方法，以及您正在开发的 data GPT 是如何运作的。

A1：我们所提的是通过问答方式创建数据集，而非直接获取数据源。传统上，构建数据集主要有两种方法：一是基于配置的拖拉拽方式，二是编写 SQL 语句。我们现在正尝试通过问答形式来构建数据集。具体而言，用户可以用自然语言告诉系统他们需要哪种类型的数据集，以及数据集应包含哪些信息。系统将根据用户的描述生成所需的数据集。这一过程的核心是 NLP(自然语言处理)技术，它能够将自然语言指令转换为 SQL 语句，从而建立相应的数据集。

Q2：如果我想查询特定年份的某项指标或数据情况，系统是否能自动生成相关报告和结果展示?具体实现方式是怎样的?

A2：目前，我们正在探索两种方案。第一种方案是结合大模型来实现。在这种方法中，我们将数据资产指标的定义以及一些语义信息输入模型，以帮助模型更好地理解例如京东物流的数据资产，包括表格的元数据等。当你提出问题时，它可以通过 SQL 返回结果。但是，这个方法的问题在于，有时候回答的准确率可能不高，特别是在数据底层质量不高的情况下，对数据的理解可能会有误差，导致生成的 SQL 可能不太准确。这需要一个持续优化和调整的过程。我们目前正在尝试优化这种方法，但只限于小范围的数据资产。

第二种方案是采用配置化的方法。这种方法不依赖于大模型，而是依赖于一个后台的数据模型配置策略。你只需要指定相关表格，只要查询范围在这个表格或其支持范围内，系统就能顺利地将查询转换成 SQL 并返回结果。这种方法比较直接和稳定，但如果基于大模型，则需要持续的运维和调整，因为大模型需要不断地接收相关领域的数据以提高其准确性。最重要的是，系统能否理解用户用业务语言提出的问题，并将其转换成数据语言的过程。

Q3：我希望未来的 BI(商业智能)工具可以更加敏捷，用户无需编写脚本或 SQL，只需要输入一段话，系统就能理解并生成报表或图表。这是否可行?

A3：这确实是一个很好的想法，目前行业内已有多方探索这一方向。一些产品已经初步实现了这一功能，它们通过部署大型 AI 模型并向其提供相关的指标数据来进行训练，使其能够根据用户输入生成基本的报表。此外，许多第三方创业公司也在尝试相关技术。然而，大部分尚未利用大模型，因为完全依赖大模型来解决这一问题是相当困难的。虽然当前有一定的进展，但实现用户简单输入即可生成复杂报表和图表的目标，还需要更多的技术突破和创新。

Q4：我想了解一下异构数据源融合的问题。我目前所在的公司使用的互联互通工具并不好用，我想知道如何在一个脚本中实现异构数据源的简单融合?

A4：确实，技术上是有可能实现异构数据源融合的，但实际业务场景中很少需要在一个 SQL 中同时关联例如 ES(Elasticsearch)表和 MySQL 表。虽然理论上这种技术是存在的，但成本相对较高。我之前提到的 Starrocks 引擎可以查询 Hive 数据，甚至直接连接 HDFS，其查询速度比许多其他工具更快。它也可以查询 MySQL 和 ES。但它并不支持同一次查询中同时跨库关联查询这些数据源。实际上，这种需求并不常见，也不需要花费太多时间去优化或实现。如果你们公司确实有大量异构数据源的融合需求，可能需要先从数据治理方面入手，找到更有效的方法和工具来解决这个问题。

Q5：您好，老师。我注意到您将报表制作成在线 Excel 格式。我想了解制作这种 Excel 功能的研发成本是否很高?因为它包含了许多复杂的功能和函数。同时，实际制作这个在线 Excel 的成本控制如何?

A5：是的，我们确实将报表制作成了在线 Excel 格式。不过，我们并没有自己从头开始研发这些复杂的功能和函数，而是主要通过集成一些第三方插件来实现的。因此，实际投入是可控的，成本并不会特别高。我们购买了第三方的插件，并在此基础上将其与我们的前端链路相结合。这样做的主要目的是模仿 Excel 的效果，同时确保工具的使用门槛对用户来说更低，让他们能够更容易地操作和理解。

Q6：在数据产品领域，我们面临哪些常见问题和挑战?特别是关于 BI 工具和数据跨库问题。

A6：这里主要有两个问题。首先，关于 BI 工具，我们的定位是针对两种不同的场景。京东内部已经有一些类似于 Tableau 的 BI 工具，它们适合总部的分析师和 BI 工程师使用，但对于一线工作人员来说，这些工具过于复杂，因为至少需要一定的数据库操作和 SQL 知识。因此，我们针对两种不同的用户群体有不同的解决方案。

其次，关于数据跨库的问题，我认为在数据建设上应该采用体系化的方法。所有业务系统都是分散和多样化的。我们需要从业务系统中集中数据，建立一个数据部门或数据中心。首先是数据融合：将 OLTP(在线事务处理)转换为 OLAP(在线分析处理)，在数仓中集成数据后进行分析应用。理论上，我们应该将所有数据统一入仓，在数仓里分层建模，然后有标准化的口径沉淀，再接入 BI 系统。这是最合理的链路。

我有两个建议：第一个是标准化数据。从数仓定义好，尽可能全面地接入 BI 工具，以便它可以灵活地支持业务需求和变化。第二个建议是让 BI 工具支持更多类似于低代码可视化的组件，这样业务方可以更灵活、丰富地搭建页面，提高可视化能力。这样的整体解决方案，包括嵌入式组件，可以嵌入到他们自己的业务系统中，减少将数据接过去处理后再定制页面的成本。