成功部署 AI 智能体（Agentic AI）绝非易事。我们从实践中总结了宝贵经验，告诉你如何把这件事做对。 AI 智能体革命已经开启一年，一个教训也愈发清晰：想把它做好，必须下苦功。 通过 AI 智能体实现企业转型，有望带来前所未有的生产力提升。虽然有些公司已经尝到了甜头，但更多企业却发现，他们的投入迟迟不见回报。在某些情况下，他们甚至不得不“开倒车”——在智能体搞砸的地方，重新把人招回来。 这些磕磕绊绊是任何新技术发展过程中的必经之路，我们在其他技术创新中也见过类似的模式。为了总结早期的经验教训，我们最近深入研究了麦肯锡内部主导的 50 多个 AI 智能体项目，以及市场上的几十个其他案例。我们将分析结果提炼为六条经验，希望能帮助领导者们成功地从 AI 智能体中捕获价值。 1. 重要的不是智能体，而是整体流程 要想用 AI 智能体创造商业价值，就必须改变工作流程。然而，很多公司常常过度关注智能体本身或某个工具。这必然导致一个结果：造出了看起来很酷的智能体，却无法真正改善整体工作流，最终价值寥寥。 那些致力于从根本上 重构整个工作流程 的项目，更有可能取得成功。所谓工作流程，指的是涉及人员、流程和技术的所有环节。 理解智能体如何在每个环节中提供帮助，才是通往价值的正确路径。人类员工依然是工作的核心，但人类员工将拥有新的智能体、工具和自动化系统来辅助他们。 重新设计工作流程的一个重要起点，是梳理现有流程并找出用户的核心痛点。 这一步至关重要，它能帮助我们设计出真正减少重复劳动、让智能体与人类高效协作的系统。这种协作可以通过学习循环和反馈机制实现，形成一个自我强化的闭环。智能体用得越多，就会变得越聪明、越契合业务需求。 以一家另类法律服务提供商为例，该公司正致力于合同审查流程的现代化。他们所处领域的法律推理在不断演变，新的判例法、司法管辖区的细微差异以及政策解读层出不穷，这使得将专业知识固化为代码变得极具挑战。 为了适应这种天然的变化，团队设计的智能体系统可以在工作流程中不断学习。例如，用户在文档编辑器中的每一次修改都会被记录和分类。这为工程师和数据科学家提供了丰富的反馈流，他们可以利用这些反馈来“教导”智能体，调整提示词（prompt）逻辑，并丰富知识库。久而久之，智能体便能将新的专业知识内化。 关注流程而非智能体本身，能让团队在恰当的节点部署最合适的技术。这在重构复杂的多步骤工作流时尤其重要。例如，保险公司通常有庞大的调查流程（如理赔处理和承保），每一步都涉及不同类型的活动和认知任务。公司可以通过周密部署，将基于规则的系统、分析型 AI、生成式 AI 和 AI 智能体等多种技术巧妙地组合起来，并用一个统一的编排框架（如开源的 AutoGen、CrewAI 和 LangGraph）来支撑。在这种模式下，智能体扮演着编排者和整合者的角色，调用各种工具，并将其他系统的输出整合到自己的上下文中。它们就像“胶水”，将整个工作流程粘合在一起，用更少的人工干预，交付真正的成果。 复杂的工作流程应该为每个任务选择最佳工具。 2. 智能体并非万能解药 AI 智能体（AI Agent）功能强大，但并非所有任务都适合用它来解决。很多时候，领导者们没有仔细审视需要完成的工作，也没有思考智能体是否是最佳选择。 为了避免投资浪费或不必要的复杂性，企业领导者可以像组建一支高绩效团队那样来评估智能体的角色。关键问题是：“需要完成的工作是什么？每个潜在的团队成员——或者说智能体——各自有什么天赋，如何协同工作以实现目标？” 许多业务问题完全可以用更简单的自动化方法解决，比如基于规则的自动化、预测性分析或简单的大语言模型（LLM）提示，这些方法通常比开箱即用的智能体更可靠。 在匆忙上马智能体方案之前，领导者应该先评估任务的性质。具体来说，就是要明确：这个流程的标准化程度应该有多高？需要处理多大的变数？哪些部分最适合交给智能体来做？ 从某种程度上说，这些问题很直观。例如，变化少、标准化程度高的工作流程，如投资者开户或监管信息披露，通常受到严格管控，遵循可预测的逻辑。在这种情况下，使用基于非确定性的大语言模型（LLM）的智能体，可能弊大于利，只会增加复杂性和不确定性。 相比之下，变化大、标准化程度低的工作流程，则能从智能体中获益匪-浅。例如，一家金融服务公司部署了智能体来提取复杂的财务信息，大大减少了人工验证的需求，并简化了工作流程。这些任务需要信息聚合、交叉验证和合规性分析——而这些正是智能体大显身手的领域。 最重要的一点是，不要陷入“用或不用智能体”的二元思维。有些智能体擅长完成特定任务，有些能帮助人类更好地工作，而在许多情况下，其他技术可能才是更合适的选择。关键在于，要弄清楚哪种工具或智能体最适合哪项任务，人类如何与它们最有效地协作，以及如何将人、智能体和工具组合起来，以实现最大产出。 3. 别制造“AI垃圾”：重视评估，建立用户信任 在部署 AI 智能体时，团队最常遇到的陷阱之一是：系统在演示（Demo）中看起来惊艳全场，但实际负责这项工作的用户却被它搞得头疼不已。 我们经常听到用户抱怨“AI 垃圾”（AI Slop），即智能体输出的低质量内容。用户很快就会对智能体失去信任，导致采用率极低。自动化带来的任何效率提升，都很容易被信任的丧失和质量的下降所抵消。 这个反复出现的问题给我们带来了一个来之不易的教训：公司应该像培养员工一样，大力投入智能体的开发。 正如一位企业领导者所说：“引入一个智能体，更像是招聘一位新员工，而不是部署一套软件。” 智能体应该有明确的岗位职责，需要“入职培训”，并获得持续的反馈，这样它们才能不断进步，变得更有效率。 开发高效的智能体是一项极具挑战性的工作。它需要利用领域专家的知识来创建评估体系（evals），并将最佳实践以足够精细的粒度固化下来。这种固化过程既是智能体的“培训手册”，也是它的“绩效测试”，确保其表现符合预期。 这些最佳实践可能存在于标准操作流程（SOP）中，也可能只是专家们心照不宣的默会知识。在固化这些实践时，关键是要关注那些区分顶尖员工与普通员工的核心要素。对于销售代表来说，这可能包括他们如何引导对话、处理异议以及匹配客户的沟通风格。 至关重要的是，专家必须持续参与，长期测试智能体的表现。在这个领域，绝不能“上线就完事”。这种对评估的承诺，要求专家们亲手为给定的输入，标注出期望的（甚至不期望的）输出。对于复杂的智能体，这样的标注有时可能需要成千上万条。通过这种方式，团队可以评估智能体的准确率，并进行必要的修正。 一家全球性银行在改造其“了解你的客户”（Know-Your-Customer）和信贷风险分析流程时，就深刻贯彻了这一方法。每当智能体对合规性的建议与人类的判断不符时，团队就会找出逻辑上的差距，优化决策标准，然后重新进行测试。 例如，在某个案例中，智能体最初的分析过于笼统。团队提供了这一反馈，然后开发并部署了额外的智能体，以确保分析的深度能提供恰当粒度的有用见解。他们使用的一种方法是，连续多次追问智能体“为什么”。这种方法确保了智能体的优异表现，也使得人类员工更愿意接受它的输出结果。 4. 盯紧每个环节，而不只是最终结果 当只与少数几个 AI 智能体打交道时，审查它们的工作、发现错误还相对容易。但当公司推广成百上千个智能体时，这项任务就变得极具挑战性。更糟糕的是，许多公司只追踪最终结果。因此，一旦出错——而随着规模化，出错是必然的——就很难准确找出问题到底出在哪里。 智能体的表现应该在工作流的每一步都得到验证。 将监控和评估嵌入到工作流程中，可以让团队及早发现错误，优化逻辑，并持续改进性能，即使在智能体部署后也是如此。 例如，在某个文档审查流程中，一家另类法律服务提供商的产品团队观察到，当系统遇到一批新案件时，准确率突然下降。但由于他们在构建智能体工作流时，内置了可观测性工具来追踪流程的每一步，团队迅速定位了问题所在：某些用户群体提交的数据质量较低，导致了错误的解读和糟糕的下游推荐。 基于这一洞察，团队改进了数据收集实践，向上游相关方提供了文档格式化指南，并调整了系统的解析逻辑。智能体的性能很快就恢复了。 5. 能复用就别重复造轮子 在急于推进 AI 智能体的过程中，公司常常为每个识别出的任务都创建一个独立的智能体。这会导致严重的冗余和浪费，因为许多不同的任务实际上共享着大量相同的动作（例如，数据导入、信息提取、搜索和分析），同一个智能体本可以完成。 决定在构建可复用智能体上投入多少资源（而不是只做一个执行单一任务的智能体），类似于一个经典的 IT 架构问题：公司既要快速构建，又不能锁定那些会限制未来能力的选择。如何找到这种平衡，往往需要大量的判断和分析。 一个好的起点是识别那些重复出现的任务。公司可以开发能够轻松在不同工作流中复用的智能体和智能体组件，并让开发者可以方便地调用它们。这包括开发一套集中的[2]、经过验证的服务（如 LLM 可观测性工具或预先批准的提示词）和资产（如应用模式、可复用代码和培训材料），并确保它们易于查找和使用。将这些能力整合到一个统一的平台至关重要。根据我们的经验，这几乎可以减少 30% 到 50% 的非必要重复工作。 6. 人类依然不可或缺，但角色正在改变 随着 AI 智能体的不断普及，关于人类将扮演何种角色的问题引发了广泛焦虑——一方面是对工作保障的担忧，另一方面是对生产力提升的过高期望。这导致了关于人类在当今许多工作岗位中角色的巨大分歧。 需要明确的是：智能体将能完成大量工作，但人类仍将是劳动力中不可或缺的一部分 ，尽管智能体和人类所做工作的类型都会随着时间而改变。例如，人类需要监督模型的准确性、确保合规性、运用判断力以及处理边缘案例。正如我们前面讨论的，智能体并非总是最佳答案，因此人类与机器学习（ML）等其他工具的配合仍然是必需的。然而，在某个特定工作流中所需的人员数量，很可能会在经过智能体改造后发生变化，并且通常会减少。企业领导者必须像管理任何变革项目一样，来管理这些转型，并深思熟虑地分配培训和评估智能体所需的工作。 我们经验中的另一大教训是，公司应有意识地重新设计工作，让人员和智能体能够良好协作。 如果缺乏这种关注，即使最先进的智能体项目也可能面临“静默失败”、错误累积和用户抵制。 以前面提到的那家另类法律服务提供商为例，他们希望在法律分析工作流中使用智能体。在设计流程时，团队花时间确定了在何处、何时以及如何整合人类的输入。例如，智能体能够以极高的准确率整理核心索赔项和金额，但考虑到这些信息对整个案件的核心重要性，律师必须进行复核和批准。 同样，智能体能够为案件推荐工作方案，但考虑到决策的重要性，人类不仅要审查，还要调整建议。智能体还被编程来高亮显示边缘案例和异常情况，帮助律师形成更全面的看法。而在流程的最后，仍然需要有人用自己的执照和资历来签署文件，为法律决定承担责任。 这种人机协作设计的一个重要部分，是开发简洁的可视化用户界面，让人们能轻松地与智能体互动。例如，一家财险公司开发了交互式视觉元素（如边界框、高亮和自动滚动），帮助审查员快速验证 AI 生成的摘要。当人们点击某条见解时，应用程序会直接滚动到正确的页面并高亮显示相应的文本。这种对用户体验的关注节省了时间，减少了反复猜测，并建立了对系统的信心，最终带来了接近 95% 的用户接受度。 AI 智能体的世界正在飞速发展，我们可以预见未来将学到更多。但除非公司在推进智能体项目时，从思想上和实践上都抱持着学习的心态，否则他们很可能会重蹈覆辙，减慢自己的发展步伐。 作者：Lareina Yee, Michael Chui, Roger Roberts 来源（公众号）：CDO之家

随着数字政府建设的深入推进，横纵向各部门、各信息系统之间长期存在的“信息孤岛”、“数据烟囱”以及重复建设等问题，已成为制约政务服务效能提升和数据要素价值释放的关键瓶颈。本文旨在系统性地探讨如何通过构建新一代一体化数据共享交换平台，有效破除部门间的信息壁垒，显著降低数据共享的技术与制度门槛，构筑一条高...

引言 在本系列前面的文章中，我们分别介绍了《什么是数据中台》和《为什么数据治理是持续性的？》 也为大家介绍了龙石数据“理采存管用”的数据治理方法论。 不少读者反馈，对“数据仓库”这个词还不太清楚：它和数据中台到底是什么关系？数据中台既然覆盖“理采存管用”，那数据仓库又在其中扮演什么角色？ 在深入探讨“理”（梳理）和“采”（采集）之前，我们可以先把“存”（存储）这个环节讨论一下。 数据中台和数据仓库的区别与联系 数据仓库为什么需要分层 业界常用的分层思路有哪些 龙石数据在实战中总结的分层模型是怎样的 一、数据中台 vs 数据仓库 数据中台：是一个承载“理采存管用”全流程的“工具与管理平台” ，核心是让数据能力可复用、可服务化。 数据仓库：是中台体系中负责 “存”的 “数据地基”。 它们的关系是： 数据经过中台的治理（理）和采集（采）后，存入数据仓库；再通过中台的调度和管理（管），最终以服务形式（用）支撑业务应用。 通俗来讲，数据中台操作数据，负责把数据治好。数据仓库存储数据，负责把数据存好。 二、数据仓库为什么一定要分层？ 数据仓库的命名源于“仓库”的概念，其设计核心在于解决数据管理中的混乱与低效问题。若将原始数据、加工数据及应用数据混杂存储于单一存储层，将导致数据定位困难、管理复杂、查询性能低下。数据仓库分层设计正是为应对这一挑战，通过结构化组织实现数据的高效治理与利用，数据仓库有以下优点： 结构清晰：像“俄罗斯套娃”一样，采用分层架构（如ODS、DWD、DWS、ADS），每层职责单一，将复杂数据流程简化为可管理的模块化处理，复杂问题简单化。 数据复用：沉淀公共指标和宽表，避免“重复造轮子”，极大提升下游开发效率。 任务解耦：复杂任务拆成多个步骤，便于运维和重跑，一层失败不影响全局。 查询加速：空间换时间，通过预处理和汇总，让上层应用（AI用数、BI、大屏）查询更快。 水平扩展：多数数仓基于分布式架构支持弹性扩容，无缝适配数据量增长场景，确保系统在高负载下保持高性能与高可用性。 三、业界主流的分层思路 3.1 经典两大流派 Inmon（自顶向下）： 主张先建企业级数据仓库（EDW），再建数据集市。 Kimball（自底向上） 主张先围绕业务过程建数据集市，再通过一致性维度整合成企业视图。 Inmon（自顶向下）就像先建一个巨型中央仓库，把所有货物标准化后，再分发给各部门小店； 而Kimball（自底向上）则像先为各部门开专业零售店，但使用统一的商品编码和会员体系，让这些店能轻松连锁成一个大超市。 前者强调整合与统一，后者追求速度与实用。现代数据平台通常结合两者思想。 3.2 当前共识：五层模型 融合了经典思想，互联网和大厂普遍采用五层结构： ODS（贴源层） 贴源层顾名思义是从源头粘贴数据，同城使用数据集成工具（ETL），将源头业务系统数据进行归集，保持数据的原貌，不做任何修改，隔离源头业务系统，不影响原系统的运行。 DWD（明细层） 当原始业务数据进入ODS层时，会对数据进行标准、治理的检查，将问题数据进行清洗、转换、去重、标准化等动作，实现数据的自优化。 DWS（服务层） DWS服务层，更多地贴近业务场景，在DWD明细层的基础上进行汇总加工和聚合计算，例如将事实表中的聚合度量值和维度表中的数据进行汇总聚合，借助DIM公共维度层的不同维度，计算分析出多维度的业务信息。 ADS（应用层） ADS层为数据产品、报表和分析服务提供可直接使用的数据，支撑业务决策的数据应用和报表分析。 DIM（维度层） DIM贯穿于ODS、DWD、DWS、ADS，确保各层数据计算中维度的一致性和准确性。提供通用的维度属性，常见的维度包括，时间维度：年、季度、月、日、时等；空间维度：物理位置、网络地址等。 五层结构相互独立又协同工作，形成高效的数据处理与分析体系，支持智能化的业务应用。 数据流向：ODS → DWD → DWS → ADS DIM 贯穿所有层次，确保维度一致性 这种架构兼顾高内聚、低耦合的数据仓库建设思路，但对团队建模能力要求较高，不少中小企业在落地时感到吃力。 四、龙石数据的实战分层模型 如果说 3.2 的五层模型是学院派，龙石数据的数仓分层就是实战派。龙石数据中台目前支持多种常见数仓，也对信创数据库（如达梦、人大金仓）做了良好适配。无论底层选Doris、StarRocks还是PostgreSQL，都将分层思想内嵌到平台中，提出一套更实战、易用、低门槛的分层模型： SRC（来源层） → ODS（贴源层） → DW（治理层） → ADS（应用层） → DS（共享层） 4.1 设计思路：让数据好管好用 1. 可行性与易用性 架构不是为了“炫技”，而是为了更快更好地实施和使用。考虑到数据工作未来会引入更多业务人员，以及“中国式速度”的要求，我们的模型必须“开箱即懂”。 2. 强化“理采”与“用”的映射： 将「SRC-来源层」纳入： 明确映射“理采存管用”中的“理”和“采”的起点，方便从源头理解数据。 将「DS-共享层」纳入： 明确映射“用”的出口，让数据提供者和消费者清晰知道“数据成品”在哪。 3. 降低“存”与“管”的门槛： 弱化DW细化分层： 将业界DWD（明细）和DWS（汇总）合并简化为「DW-治理层」。 解耦DIM维度层： 将「DIM-维度」的管理从数仓ETL中剥离，交由龙石中台的“数据标准、数据清洗”模块进行维护。 让实施人员无需精通复杂的Kimball建模，大幅降低数据工作的门槛。 4. 确保规范（前提）： 简化不等于随意。没有规范的敏捷是“灾难”。龙石模型通过中台工具将规范（如标准、质量等）“嵌入”到数据的归集、清洗、共享流程中，确保“简化”后的数据质量。 4.2 龙石五层模型详解 第 0 层：SRC（来源层） 逻辑层，不存实际数据。作用是梳理数据资产，比如“CRM系统-客户表”，这是数据治理的起点。 第 1 层：ODS（贴源层） 物理层，把源系统数据原样同步过来，只做轻微格式处理，不做业务加工。作用是可回溯、解耦业务库压力。 第 2 层：DW（治理层） 核心层，融合了明细和汇总功能。在这里执行数据清洗、标准化、关联和轻度汇总，产出可信、可复用的数据。 第 3 层：ADS（应用层） 面向具体业务场景做深度加工，比如大屏数据、报表数据、算法样本等。DW 层保持稳定，ADS 层灵活响应需求。 第 4 层：DS（共享层） 逻辑层，将 ADS 的数据包装成 API 或数据目录，供业务系统或人员直接调用。使用者无需关心数据存在哪里。 五、龙石数据的实战分层模型 数据中台是平台，数据仓库是地基。分层是为了让数据更清晰、可复用、易治理。 业界有 Inmon、Kimball 等经典思路，也有通用的五层模型，但对实施能力要求高。龙石数据在此基础上，提出更注重实战的五层模型（SRC/ODS/DW/ADS/DS），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。龙石数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。

一、开篇 上周，业务总监在会议上拍桌子：“为什么销售额是负数？这数据太假了！” 我点开系统日志——他用ChatSQL问：“最近三个月销售额情况。” 系统返回了1000行“销售额”字段，其中70%是负数。 真相是：他连“销售额”这个指标在数据库里叫什么都没搞清。 这场景太常见了。说清楚自己要什么数据的人，永远不用ChatSQL；用ChatSQL的人，往往连自己要什么都说不清。 今天，我就撕开智能问数的遮羞布，告诉大家为什么90%的企业在智能问数上踩了大坑。 二、Text2SQL Text2SQL的致命伤：表元数据≠理解需求 很多厂商吹嘘“自然语言转SQL”，本质是用表元数据拼凑SQL，而不是理解业务逻辑。 ✅ 为什么表元数据是基础？ 数据库表结构（字段名、关联关系）是Text2SQL的“地图” 没有这张地图，AI就像盲人摸象 ❌ 但为什么它失效？ 因为业务人员说的“销售额”，在数据库里可能是： sales_amount（财务系统） revenue（电商系统） order_total（ERP系统） 而AI只能根据表名猜——猜错了，就是负数！ 📌 业内真相：ChatSQL的准确率=表元数据的完整性×用户描述的清晰度 两者缺一，结果必崩。 三、ChatSQL 谁在用ChatSQL？谁在骂ChatSQL？ 用户类型 代表场景 为什么用ChatSQL 结果 专业数据人 “查2023Q4华东区订单量” 他们直接写SQL，效率高 从不碰ChatSQL 模糊需求业务人 “看看最近销售情况” 说不清要什么，只能问 得到一堆错误数据 技术决策者 “让业务自己查数据” 以为ChatSQL能解决一切 误判数据，决策失误 >>延伸：AI + 数仓AI 不会取代数仓，但会增强数仓：•自动化建模、SQL 生成•智能调度优化•自然语言查询（NLQ） 这也是我见过最讽刺的场景： CTO要求“用ChatSQL赋能全员”，结果业务部门每天问：“为什么我的销售额是负数？” 这不是技术问题，是认知问题。 四、语义层，不是ChatSQL的升级版 破局关键：语义层，不是ChatSQL的升级版 很多厂商还在做“NL2SQL”，但真正的破局点在语义层（Semantic Layer）。 为什么语义层是核心？ 传统NL2SQL 语义层方案 依赖物理表结构 抽象业务语义（销售额=收入-退款） 一个指标多个口径 统一指标定义（全公司只用1个“销售额”） 业务变化需重写SQL 业务规则变更，语义层改1处，全链路生效 数据孤岛，口径混乱 跨部门数据一致，无歧义 🌟 语义层的本质：把“业务语言”翻译成“数据语言”的中枢 例如： 业务说“销售额” → 语义层映射到revenue - refunds → 生成精准SQL 这才是智能问数的正确打开方式： 用户问“销售额” → 语义层解析业务含义 → 生成SQL → 返回数据 五、别再盲目上ChatSQL 给企业的血泪建议：别再盲目上ChatSQL ❌ 你正在踩的坑： 以为ChatSQL=自助分析 → 实际是“自助造错” 用宽表+NL2SQL → 业务一变，IT就重排期 把指标库当摆设 → 业务人员依然用“销售额”“订单量”等模糊词 ✅ 我的实战建议： 先建语义层，再上ChatSQL → 用指标平台（如 数势科技SwiftMetrics，Aloudata CAN）定义“销售额”“用户活跃度”等业务指标，统一口径。 让业务人员参与语义定义 → 业务部门自己写“销售额=收入-退款”，比IT猜100次都准。 ChatSQL只做最后一公里 → 业务人员问“Q3销售额”，语义层自动转成SELECT SUM(revenue - refunds) FROM sales WHERE quarter=3。 💡 我的铁律： “没有语义层的ChatSQL，是数据灾难的加速器，不是解决方案。” 六、结语 智能问数的终极目标👇 智能问数不是“让AI替你写SQL”，而是让业务人员真正理解数据。 对专业DE：语义层解放了你的时间，让你专注数仓建设与数据治理，而不是救火。 对业务人员：不再需要问“销售额是什么”，而是直接问“Q3销售额对比Q2如何？” 对企业：从“数据孤岛”走向“数据统一认知”，决策效率提升10倍。 记住： 说清楚需求的人，永远不需要ChatSQL； 用ChatSQL的人，永远说不清需求。 破局的关键，不是让AI更聪明，而是让业务更懂自己。 范老师重申： “我见过太多企业花百万买ChatSQL，结果数据还是错的。 真正的智能问数，是让业务人员先学会‘说清楚’， 而不是让AI去‘猜清楚’。” 来源（公众号）：数据仓库与Python大数据

智能体人工智能正在颠覆大数据范式，它要求我们主动将数据引入专门的智能计算平台，而不是反过来。这种转变从根本上改变了我们对数据建模和存储的固有认知，因为低级机器学习（LLM）能够利用远小于传统机器学习的数据集进行上下文学习。因此，现代人工智能不断扩展的上下文窗口和工具调用能力正迅速使许多传统的ETL/ELT流程过时，迫使数据工程师彻底重新思考他们的整个方法。 造成这种混乱的原因是什么？ 造成这种转变的原因之一是人们使用数据的方式正在发生变化。 企业应用和仪表盘由软件工程师和数据科学家构建，旨在满足非技术用户的需求。反过来，业务分析师和最终用户则被动地接收这些内容。应用可能内置了一些交互功能，但这些交互都遵循僵化的、预先设定的工作流程。作为数据工程师，我们的工作是提供此类应用能够使用的数据格式。 从以“构建者”为中心的模式（技术用户创建应用程序）过渡到以“交互者”为中心的模式（非技术用户通过人工智能代理直接与数据交互）。 越来越多的非技术用户直接与数据交互。他们能够根据自身需求编写应用程序和工具。现有的SaaS应用程序不再局限于集成并排聊天界面，而是利用CopilotKit等框架更原生地嵌入自然语言交互。具有前瞻性的开发者并没有简单地重复僵化的工作流程，而是将AI代理嵌入到应用程序中，使代理能够以工具调用的形式访问后端API。 其次，重心正在转移。过去，数据量庞大，因此需要将计算资源部署到数据所在位置，以避免大量数据迁移。然而，如今前沿人工智能模型（LLM）才是重心所在，人工智能应用也围绕它们构建。 重心发生了转移，因此技术架构也随之翻转。与以往需要定制计算资源处理数据不同，智能体人工智能应用使用大型语言模型（LLM）作为推理引擎，能够理解用户意图、推理任务并调用工具执行操作。这一新应用浪潮旨在将用户意图直接转化为行动。 这两种动态变化如何影响数据工程师的工作？以下五个原则在准备用于人工智能的数据时需要牢记。 1. 重新思考 ETL/ELT：从规范化到上下文 如今，数据工程师投入大量精力进行数据规范化、创建清晰的数据模式并构建转换管道。其目标是使下游分析师和应用程序能够理解数据。 这并不意味着 ETL/ELT 就变得无关紧要，提供数据仍然至关重要。但您可以依靠代理来解释模式、理解关系，并处理各种格式的数据，而无需进行大量的预处理。 然而，仅仅在现有表上添加数据目录和 MCP 服务器，是对智能体技术能力的极大浪费。此外，这样做还会大大增加 AI 智能体的工作难度。为什么呢？ 人工智能代理能够理解上下文中的数据，它们不需要所有数据都预先规范化到僵化的模式中。事实上，随着表数量的增长，如今的代理很难正确解读数据并编写正确的 SQL 语句来连接所有数据。此外，随着数据切片数量的增加，冲突和歧义的概率也会增加。例如，两个表中可能都有“贷款金额”列。在一个表中，它可能代表借款人申请的金额，而在另一个表中，它可能代表贷款人实际发放的本金。数据结构越是经过处理、规范化和分散化，上下文信息就越难传递。 维护数据可用性工作流程，但要质疑每个规范化步骤是否仍然必要。代理人能否在适当的上下文中理解这些数据，而无需进行转换？委托人信息能否从原始条款清单或融资备忘录中摘录一段文字，解释该委托人将分期获得哪些款项，而不是仅仅用一个数字表示？ 避免只向 AI 代理开放非结构化数据的诱惑——虽然很容易对 PDF、电子邮件等进行处理，但组织中真正可操作的数据通常仍然是结构化数据。 2. 优先考虑数据整理而非数据收集 情境式学习使得内容整理比资料收集更为重要。 在大数据时代，目标是收集尽可能多的数据，因为你想在极其庞大的数据集上训练机器学习模型——更多的数据意味着更好的机器学习模型。 然而，人工智能代理的构建基于情境学习，即在提示中提供一两个示例。学习学习模型（LLM）可以有效地模仿这些示例，无论是遵循某种流程（思维链）还是遵循某种格式或风格（少样本学习）。随着情境学习的出现，示例的质量比数量更为重要。 你向代理展示的示例数据会影响它对所有类似数据的理解。你可能会创建一个示例库，并选择哪些示例用于特定类型的用户查询。随着数据管理的重要性日益凸显，作为数据工程师，构建以下工具变得至关重要： •找出最高质量的数据，例如完整、准确且具有代表性的数据样本。 •随着标准的演变，应定期更新这些示例。 •验证精心整理的数据是否确实能作为智能体学习的有效示例。 作为数据工程师，你需要赋能的关键角色之一是数据管理员。你需要支持的存储类型也会发生变化，包括图数据库和向量数据库。 3. 构建面向代理的基础设施：感知与行动 人工智能代理需要支持两种核心能力的基础设施：感知数据和根据数据采取行动。 并非所有数据格式都能被基于语言模型的智能体平等地访问。请考虑智能体解析、理解和提取数据格式含义的难易程度。能够保留语义含义且预处理需求极低的格式可以降低交互阻力。 AI 代理通过调用工具（包括函数、API 和服务）来执行操作，这些工具使它们能够处理数据。您的基础架构需要确保代理能够发现并使用这些工具。这意味着清晰的接口、完善的文档和可靠的执行。 从人工智能代理的角度审核您的数据访问模式和工具。一个自主系统需要了解哪些信息才能有效使用它们？哪些环节存在阻碍，导致运行不畅？ 4. 将代理工件作为一级数据进行管理 人工智能代理不仅会消耗数据，还会生成数据。事实上，你会发现，人工智能生成的内容将远远超过系统中“原始”数据的数量。 当智能体生成输出、做出决策、编写代码或记录其推理过程时，这些也变成了数据。 无论内容是由人工创建、从软件系统收集，还是由人工智能代理生成，都必须符合您所在行业的通用规范和法规。除了合规性之外，这些代理生成的数据对于调试、审计、训练未来的代理以及理解系统行为也具有价值。 对代理程序生成的数据应与其他数据一样严格对待： •存储代理输出系统 •保留决策日志和推理痕迹 •将代理生成的代码作为版本化工件进行管理 •确保这些数据可供分析和未来培训使用 这些工件将成为您数据生态系统的一部分。请据此设计存储和访问模式。 5. 将观察与训练联系起来 提升智能体性能的最快途径是实现可观测性和训练之间的闭环。人工智能智能体基础设施需要双向管道，将模型性能和可观测性与持续训练联系起来。 首先，你需要一个可观测性平台，它能够追踪数据质量指标，尤其重要的是，能够检测数据漂移（输入数据特征的变化）和概念漂移（输入和输出之间关系的变化）。同时，它还必须监控关键的模型性能指标，例如准确率、延迟和幻觉率。建立与预定义阈值关联的自动触发器。 您的可观测性平台也需要扩展，以纳入人工反馈。用户对生成内容所做的每一次修改都需要记录下来，并用于改进人工智能模型。 其次，你需要一个重训练流程，该流程会在收到监控系统触发的事件时自动激活。它必须完全自动化，负责提取最新版本的训练数据，启动模型重训练或微调任务，并对新训练的模型进行全面的评估和回归测试。在智能体时代，构建这种将性能监控直接连接到自动化部署的闭环系统，对于机器学习/数据工程师来说至关重要，两者之间的界限将日益模糊。 数据工程师的角色如何变化 这五大转变都围绕着一个共同的主题：从僵化、预设的工作流程转向灵活、情境感知的架构。现代代理的工具调用和反射能力使得僵化的 ETL/ELT 流水线不再那么重要。情境学习使得范例精选比详尽的范例收集更有价值。 数据工程的重要性并没有降低，而是发生了变化。过去十年构建数据基础设施的技能依然宝贵，但需要应用于不同的目标。我们不再需要预先设计每个工作流程，而是要创建一种环境，让代理能够自行设计工作流程。 来源（公众号）：数据驱动智能

本文将详细介绍五种重要的数据格式： •CSV •JSON •Parquet •Avro •ORC 在大数据时代，数据源之间的数据迁移和存储需要更具策略性的方法。如果没有优化的决策，通过 ETL 流程处理 TB 级数据可能会耗费大量时间和成本。本地部署系统虽然相对容易发现问题，但其基础设施不会自动适应新的情况，问题必须手动解决。 然而，在云端，资源可以自动扩展。虽然我们可能认为一切运行顺畅，但一些被忽略的小步骤却可能导致数万元的不必要成本。在我看来，根据项目需求选择合适的数据格式是大数据时代最关键的决策之一。 存储在 S3 中的物联网数据应该采用 CSV 格式还是 Parquet 格式？每周销售报告文件的最佳格式是什么？大小文件是否应该使用相同的格式？只有充分了解每种数据格式的特性，才能有效地做出这些决策。 近年来，某些格式——尤其是 Parquet 和 Avro——越来越受欢迎。尽管它们存在一些缺点，但它们的灵活性，尤其是在云环境中，极大地促进了它们的应用。在本文中，我将解释这些格式的特性、优势和劣势，并讨论哪种格式最适合特定场景。 一 CSV CSV是一种基于文本的表格数据格式，其中每一行代表一条记录。记录中的列或字段通常用分隔符（最常见的是逗号）分隔。第一行通常包含列名作为标题。CSV 格式被广泛支持，因此成为数据交换的热门选择。 1.编码 CSV 文件通常采用UTF-8编码，这样可以确保字符兼容性并使文件可压缩。 2.优势 •易于阅读： CSV 文件易于阅读和理解。 •通用性强： 几乎所有编程语言和工具都支持它。 •易于使用：可以手动生成、编辑和检查。 •兼容性：与电子表格和临时分析工具兼容。 3.缺点 •我认为，这种格式最大的缺点之一是它不存储元数据，不强制执行模式或数据类型，并且默认情况下将所有数据都视为文本。（例如，当使用其他工具读取 CSV 文件时，包含年龄等数值的列可能会被解释为整数，但这完全是一种解释，可能不正确，需要手动验证。否则，错误在所难免。） •由于其体积庞大且 I/O 速度慢，因此对于大型数据集来说效率低下。与 Parquet 格式相比，根据具体情况，它可能占用大约 10 倍的空间。 •CSV格式不适用于嵌套数据，这是由于CSV格式本身的设计缺陷造成的。例如，在更适合嵌套数据的格式（例如JSON）中，嵌套结构如下所示： { "user" : { "id" : 123 , "name" : "Alice" } , "actions" : [ { "type" : "click" , "time" : "2025-11-05T12:00Z" } ] } 相同的 CSV 数据必须以 JSON 字符串的形式表示在单个单元格中： user_id,user_name,actions 123,Alice,"[{""type"":""click"",""time"":""2025-11-05T12:00Z""}]""[{" "type" ":" "click" "," "time" ":" "2025-11-05T12:00Z" "}]" 这使得阅读、筛选和分析变得更加困难。 4.何时选择 CSV 格式 •适用于对人类可读性要求较高的中小型数据集。 •应用程序、分析师或团队之间轻松共享数据。 •不支持二进制或列式格式的系统或工具。 •快速原型制作或从电子表格（Excel、Google Sheets）导出。 二 JSON 多年来，JSON 一直是最流行的数据格式之一。它可以被视为一种通用语言，使不同的应用程序能够相互理解。其主要目的是促进 Web 服务和应用程序之间的数据交换。在 JSON 出现之前，XML 曾被广泛用于此目的，但它存在诸多缺陷。 XML格式非常冗长，难以阅读，尤其是在处理冗长且嵌套结构的情况下。它占用大量存储空间，解析XML文件会消耗大量的CPU和内存资源，因此不适合处理大数据。此外，XML的兼容性也有限，通常需要专门的库才能解析。 一个简单的 XML 结构示例： <user> <id> 1 </id> <name> Alice </name> <is_active> true </is_active> <address> <city> Berlin </city> <postal_code> 10115 </postal_code> </address> <hobbies> <hobby> music </hobby> <hobby> cycling </hobby> </hobbies> </user> JSON 随后应运而生，它是一种更简洁、更紧凑、人机可读且通用兼容的格式，极大地简化了跨语言数据交换。JSON以文本格式存储键值对数据。它支持嵌套和层级结构，能够自然地表示复杂且深度嵌套的数据。其通用性使其被广泛用于 API 数据传输和配置文件。 一个简单的JSON结构示例： { "id" : 1 , "name" : "Alice" , "is_active" : true , "address" : { "city" : "Berlin" , "postal_code" : "10115" } , "hobbies" : [ "music" , "cycling" ] } 1.编码 UTF-8 通常被使用，因为它既兼容 ASCII，又支持国际字符。由于采用了 UTF-8 编码，JSON 文件可以在不同的平台上无缝共享。 2.优势 •人类可读： JSON 文件是基于文本的，易于人类阅读。 •支持嵌套数据：可以自然地表示复杂和分层的数据结构。 •通用互操作性：几乎所有现代编程语言都支持。 •无模式灵活性：每条记录可以有不同的字段；不需要严格的模式。 •API友好： REST和GraphQL服务的标准格式。 3.缺点 •存储效率低下：每个记录中都重复出现键，这会增加大型数据集的大小。虽然它适用于消息传递，但并不适合大规模存储。 •不强制类型：数字、布尔值或空值均被视为文本；正确的类型由应用程序自行决定。这种缺乏强制的做法可能是一个缺点，尤其是在 ETL 流程中，新数据可能需要持续关注以避免类型错误。 •解析成本：与二进制格式相比，CPU 和 RAM 使用率更高，尤其是对于大文件而言。 •无元数据： JSON 中不包含最小值、最大值或空计数等信息。 •大文件处理：大文件需要流式传输或分块传输；一次性将整个文件加载到内存中是不切实际的。 4.何时选择 JSON •API 数据交换（REST/GraphQL）： JSON 非常适合在不同系统和编程语言之间传输数据。它为 Web 服务、微服务和移动应用程序提供了一种标准、快速且易于解析的格式。 •适用于快速原型设计和共享的中小型数据集：虽然 JSON 不是存储大型数据的最佳选择，但对于中小型数据集来说效果很好。 •人的可读性很重要：与 XML 或二进制格式相比，其基于文本的键值结构使得错误和缺失字段更容易识别和调试。 •嵌套和分层数据： JSON 自然地支持嵌套对象和数组，可以轻松地以清晰有序的方式表示复杂的结构，例如包含地址和订单的用户对象。 三 Parquet Parquet 是当今最流行的数据格式之一，专为Apache Hadoop 生态系统中的大数据分析而设计。它的主要目标是在高效存储大型数据集的同时，优化查询和分析性能。其最重要的特性是列式结构，这显著提升了查询和存储性能。从很多方面来看，Parquet 都可以被视为大数据时代的主流。 Parquet文件的结构 Parquet文件由三个主要层组成： Parquet 文件 •行组： Parquet 文件的一部分（例如，100 万行一组）。 •列块：行组中特定列的数据(e.g., user_id, age, country)。 💡注意：每一列（例如，country）并没有存储在整个文件的单个连续块中，而是作为每个行组中的单独列块存储。 行组允许并行读取和基于行的过滤（谓词下推），从而只读取必要的行块，降低 I/O 成本并提高读取性能。 1.编码 Parquet 格式以二进制列式结构存储数据。虽然 Parquet 中的文本数据可能使用 UTF-8 编码，但其效率并非源于编码本身，而是源于其他特性，我们将在下文讨论这些特性。 2.优势 （1）列式结构 采用列式结构可以显著提高 Parquet 格式的效率。其最大的优势在于，在大型查询中，系统只会读取所需的列，而忽略不必要的列。这不仅提高了I/O 性能，还降低了成本。 对基于行的格式（例如 CSV）和基于列的格式（例如 Parquet）的数据进行查询的方式如下： （2）基于行的查询（CSV） 在 CSV 文件中，所有行都以文本形式存储： 1，爱丽丝，30，美国，100 2，鲍勃，25，美国，200 3，卡罗尔，40，德国，150 4，戴夫，35，德国，300 5，伊芙，28，美国，250 查询： “美国客户总消费额”→ 仅需要列country和spend 因为 CSV 是基于行的，所以会读取和解析所有行，包括id、name、age。 I/O 成本： 5 行 × 5 列（读取整个文件）。 （3）列式查询（Parquet） 在 Parquet 格式中，列存储在单独的块中： 列ID：1、2、3、4、5 ； 列名称：Alice、Bob、Carol 、Dave 、Eve； 列年龄：30、25、40、35、28 ； 列国家/地区： US 、US、DE 、DE、US ； 列消费金额：100、200、150、300、250 •查询： “美国客户总支出”→ 仅读取country和spend列块。 •id、name 和 age 不会从磁盘读取，从而降低了 I/O 和 CPU 开销。 •列式格式结合字典编码、游程编码（RLE）和位打包（bit-packing）可减小文件体积并加速读取。 格式 ｜ 读取的数据 ｜I/O -----｜-------------｜------ CSV（行式）｜所有行 + 所有列｜高 Parquet（列式）｜仅 country 和 spend 的数据块｜低 （4）行组 行分组不仅按列划分数据，还按行划分数据，具体如下： •提高I/O 性能 •减少过多的随机磁盘访问 例如：一个文件有 3 个行组，每个行组有 50 万行： 如果我们只查询 ` idA` 和 ` ageB`，就不会访问 `C` name、country`D` 和 `D`salary中的 450 万行数据，从而节省大量资源。行组也可以并行读取，进一步提升性能。 如果我们需要的数据只在一个行组中，则跳过其他行组，从而节省高达 80-90% 的 I/O。 （5）字典编码 Parquet 的另一个效率提升之处在于字典编码。重复值存储在字典中，并通过索引进行引用，从而减少了高度重复数据的存储空间。 例子： 列：[美国, 美国, 德国,美国,德国, … ] 字典：{ 0 :美国, 1:德国} 编码列： [ 0 , 0 , 1 , 0 , 1 , … ] 如果我们有 10K 行：6K United States+ 4K Germany，我们存储索引而不是完整的字符串，最多可以节省约 90% 的空间。 原始文本（CSV）： 6,000 × 13 = 78,000字节4,000 × 7 = 28,000字节总计：106,000字节≈ 103.5 KB字典编码（Parquet ） 10,000行→ 2个类别→每行1字节（或至少1位）总编码：10,000字节≈ 9.8 KB （6）游程编码（RLE） RLE 对连续重复的值进行数值计数： 列： [ 0 , 0 , 0 , 1 , 1 , 2 , 2 , 2 , 2 ] RLE： [ (0 , 3 ) , (1 , 2 ) , (2 , 4 ) ] # 前三个值为 0 等 •数值使用最少位数。 例如：值为 0-3 的列只需要2 位而不是 32 位。（7）模式强制执行与元数据 Parquet 文件包含有关文件及其数据类型的元数据。 元数据存储模式和数据类型，以便下游消费者可以信任数据类型，而无需重新定义模式或依赖自动检测（自动检测容易出错）。 元数据还包括 Parquet 版本、创建者、写入工具（Spark、Pandas 等）、列最小值/最大值（启用谓词下推）、空值计数和值计数。 3.缺点 Parquet 格式不具备可读性：它是一种二进制格式；直接读取它只会显示原始二进制数据。需要使用专门的工具（例如 PyArrow、Pandas、Spark、DuckDB）来检查或处理数据。 小型数据集的写入开销：元数据、编码信息和字典表会使 Parquet 文件比小型 CSV 文件大得多。例如，一个包含几百行的 CSV 文件可能只有 10 KB，而相同数据的 Parquet 文件则可能需要 100 KB。 兼容性问题：并非所有系统或轻量级工具都直接支持 Parquet 格式，包括： •遗留系统 •基本电子表格或商业智能工具 •小型嵌入式或基于脚本的解决方案 •通常需要中间库（例如 Pandas、PyArrow、Spark）才能读取。 4.何时选择Parquet •大规模分析和大数据查询： Parquet 格式非常适合拥有数百万甚至数十亿行数据的数据集，尤其适用于对查询性能和 I/O 效率要求极高的情况。其列式结构允许仅读取必要的列，从而减少磁盘和内存使用量。 •嵌套或复杂的数据结构： Parquet 支持结构体、数组和映射等复杂数据类型，使其适用于分层或半结构化数据，而这些数据在 CSV 等基于行的格式中会显得很繁琐。 •云存储和成本效益：在云环境中，仅读取所需列可降低 I/O 和计算成本。Parquet 的压缩和编码特性可进一步减少存储占用。 •ETL管道和分析框架： Parquet可与Spark、Hive、Presto和DuckDB等大数据工具无缝集成。当数据将被多个下游分析系统使用时，它堪称完美之选。 •基于列值过滤场景：当查询涉及基于列值进行过滤时（例如，WHERE country = 'US'），Parquet 的行组和元数据允许跳过不相关的数据块，从而大幅提高查询速度。四 Avro Apache Avro 是 Apache Hadoop 生态系统中最古老、最成熟的数据格式之一。它由 Hadoop 的创建者 Doug Cutting 开发。其主要目的是解决数据可移植性和模式定义方面的不足。Avro基于行，与早期格式不同的是，它采用二进制而非文本格式。这使其更高效、更快速、更节省空间。 例如，考虑一个 10 位数： 1234567890 •在 CSV 或 JSON 格式中，每个数字都存储为一个字符（每个数字占用 1 个字节）： '1' → 00110001 '2' → 00110010 ... '0' → 00110000 •总计：10 字节。解析需要将每个字符转换回整数。 •在像 Avro 这样的二进制格式中，该数字以 int32（4 字节）形式存储，节省了约 6 个字节，并且允许直接内存访问而无需解析，从而显著提升了速度。 Avro 也像 Parquet 一样提供模式强制执行，这意味着模式存储在文件元数据中。 1.文件结构 Avro 文件由三个主要部分组成： Avro 文件 •头部：包含描述数据结构的“魔数”和模式定义（JSON 格式）。 •数据块：以压缩二进制形式存储实际数据。数据块支持并行处理；程序可以跳过不需要的数据块以加快访问速度。 •同步标记：充当断点，帮助在文件损坏时恢复数据。 编码 •Avro 以二进制格式存储数据，比 JSON 或 CSV 格式小得多。 •无需进行文本解析，因此CPU 使用率低。 2.优势 •模式演化与类型强制执行 •该模式嵌入在文件中，确保类型安全和向前/向后兼容性。 向后兼容性示例： 旧模式： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } ] } 旧数据（二进制表示，以 JSON 格式显示）： { "id" : 1 , "name" : "Alice" } { "id" : 2 , "name" : "Bob" } 新增模式，添加了字段（is_active）及其默认值true： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } , { "name" : "is_active" , "type" : "boolean" , "default" : true } ] } 使用新模式读取旧文件会产生以下结果： { "id" : 1 , "name" : "Alice" , "is_active" : true } { "id" : 2 , "name" : "Bob" , "is_active" : true } •旧数据不包含新字段，但Avro 会使用默认值填充该字段，从而确保向后兼容性。向前兼容性则以相反的方向实现。 紧凑二进制格式 •比文本格式小得多（大约是 JSON 大小的 10-20%），但比 Parquet 大。 快速序列化和反序列化 •序列化和反序列化数据时 CPU 使用率极低，使其成为Kafka、Flink 和 Spark Streaming 等实时系统的理想选择。 与语言无关 •模式在 JSON 中定义，数据是二进制的 → 可以轻松地在 Python、Java、Go、C++、Scala 等中使用。 非常适合流媒体播放 •基于行的结构意味着每个记录都是独立的，非常适合基于事件的处理（Kafka 主题、消息传递系统）。 3.缺点 人类无法阅读 二进制格式无法直接读取；需要 PyArrow、Avro 工具或 Spark 等工具进行检查。 基于行的结构 SELECT AVG(price)对于分析查询（例如，在大数据集上），列式格式（Parquet/ORC）效率较低。 读取模式所需 没有模式就无法读取数据。模式必须嵌入在文件中或可从外部获取。 压缩技术不如Parquet/ORC先进 行式存储限制了压缩效率；列式格式可以实现更好的存储空间缩减。 4.何时选择 Avro 流式传输和消息传递系统： Kafka、Flink、Pulsar 等，其中事件需要快速序列化。 模式管理和向后兼容性：跨版本自动模式演化。 类型安全：与 JSON 不同，Avro 强制执行数据类型。 适度的存储优化：比文本格式小，但不需要列式压缩。 高频 ETL 和微服务：适用于服务间数据流密集的系统。 五 ORC（优化行列式） ORC 是一种专为 Hadoop 生态系统开发的高性能列式二进制数据格式。它专为分析海量数据而设计，因此具有很高的查询效率和压缩率。它也像 Parquet 一样具有模式强制执行功能。 1.文件结构 ORC 文件包含三个主要部分： Postscript：数据以大块形式存储，每列都是独立的。也就是说，一个条带包含一组行的逐列数据。 Footer：包含所有架构、统计信息和条带位置。 Stripes：提供有关压缩、文件格式版本和页脚长度的信息。 下面我们通过一个例子来更清楚地理解这三个部分； 假设我们有一个客户表； ORC 文件 2.编码方法 ORC 的编码方式与 Parquet 非常相似；我们在此不再赘述。您可以在上面的 Parquet 部分阅读相关内容。不过，我们可以大致讨论三种基本方法； 字典编码：对于重复值，创建一个字典，并存储字典中的索引而不是数据本身。 游程编码（RLE）：连续相同的值用一个值及其重复次数表示。 位打包：对于数值，使用最少的位数，例如，对于 0 到 3 之间的值，只需 2 位就足够了。 3.优势 •高压缩比： ORC 具有很高的压缩比。这主要是因为数据是按列存储的，并且相似的数据是连续存储的。我们在 Parquet 部分已经提到过这一点，并指出这种方法称为游程编码 (Run-Length Encoding)。 •模式强制执行：与 Parquet 格式一样，ORC 也具有模式强制执行机制。我们前面已经讨论过它的重要性。 •快速分析： ORC 与 Parquet 类似，仅在需要时才访问数据，从而显著提升读取性能。更多详细信息，请参阅 Parquet 部分。 4.缺点 ORC的缺点与Parquet的缺点非常相似；简而言之，这些缺点包括： •不可读：由于 ORC 是二进制格式，因此无法浏览或读取。 •基于行的更新很困难：它专为追加或批量分析而设计，而非事务性的行级更新。它更侧重于分析，因此不适合行级更新。这是因为数据以列为单位存储在较大的数据块（条带或行组）中；更改单行需要重写所有相关的列数据块。 •小数据集的元数据开销：对于非常小的表，元数据和条带开销可能会使 ORC 比 CSV 或 Avro 更大。 •工具依赖性：某些轻量级工具或旧系统可能不支持 ORC 原生支持。 5.何时选择 ORC •对大型数据集进行分析查询： ORC 在读取密集型分析工作负载（如 Hive 或 Spark 中的聚合、过滤和连接）中表现出色。 •需要高压缩率：重复性或低基数数据集可受益于 ORC 的列式压缩。 •Hadoop 生态系统集成：与 Hive、Spark、Presto、Impala 或 HDFS/S3 存储配合使用时非常理想。 •谓词下推/更快的过滤： ORC 的条带级元数据可以高效地跳过不必要的数据。 •具有批量追加功能的稳定模式：非常适合追加密集型管道，但不太适合事务性行更新。 6.Parquet 与 ORC区别 这两种文件类型都是二进制、列式存储，并且在许多方面都使用非常相似的方法。然而，它们在某些方面也存在差异。首先，ORC 格式的优化更为激进。因此，在某些情况下，ORC 格式可以获得更好的压缩效果，并且由于其元数据更详细、更全面，因此也能提供更好的读取性能。 我们将在平台上使用的工具也很重要。ORC 主要面向 Hive 和 Hadoop，因此在这里速度可能更快；而 Parquet 在云端和异构系统中表现更佳，具有更强的平台兼容性和通用性。虽然这两种工具通常都适用于批量分析，但使用 ORC 添加少量数据或进行基于行的数据更改效率较低。Parquet 在这方面则更加灵活，可以根据具体情况用于此类操作。让我们简要比较一下这两种工具： 今天，我们介绍了大数据生态系统中的关键数据格式：CSV、JSON、Parquet、Avro 和 ORC。我们分析了它们的主要特性、优势、劣势以及各自最适用的场景，包括存储、性能、模式强制执行、压缩和兼容性等方面的考量。您可以在下方找到总结表。 来源（公众号）：数据驱动智能

2025年中央城市工作会议明确部署“坚持把城市作为有机生命体系统谋划”，为新时代城市发展贯穿系统性思维与生态化理念。在此背景下，国家发展改革委等部门印发《深化智慧城市发展 推进全域数字化转型行动计划》（以下简称《行动计划》），既是对中央城市工作会议精神的精准落地，更是数字中国战略在城市领域的深化拓展。作为城市生命体的“数字血脉”与“神经中枢”，全域数字化转型正重塑城市生长逻辑、治理范式与发展动能，推动现代化人民城市从“写意勾勒”迈向“工笔细描”。深入把握《行动计划》的理论内核与实践路径，需从数字化与城市生命体的共生关系、系统构建的协同生态、蓝图落地的实践突破三个维度，明晰其时代价值与深层逻辑。 一、共生共荣：数字化与城市生命体的本质联结 城市作为人口、产业、资源的聚合载体，绝非冰冷建筑的简单堆砌，而是具备自我调节、动态演化特征的有机生命体。《行动计划》的核心要义，在于以数字化为“血脉”与“神经”，激活城市生命体的感知、协同、进化能力，实现“人-城-境-业”的共生共荣。这种联结并非技术层面的简单叠加，而是对工业化时代城市发展规律的深度重塑。 （一）生命体视角：重构城市数字化本质认知 传统智慧城市建设多聚焦技术应用的单点突破，《行动计划》则将城市视为“有机生命体”，突出数字化转型的“全域性”与“系统性”。这一视角革新，意味着城市数字化不再是“给机器装芯片”，而是为城市生命体构建全域“循环系统”——通过数据要素流动，打通城市“资源代谢、要素配置、安全防控”等核心功能，实现从“物理集聚”到“数字协同”的质变。 正如人体需血液输送养分、神经传递信号，城市生命体的健康运行，同样需要数据作为“养分载体”、数字基础设施作为“传导网络”。《行动计划》提出的“设施联通、数据融通、平台互通、业务贯通”，本质是为城市生命体搭建“四通”循环体系，让数据像血液般渗透到城市治理、产业发展、民生服务的每一个“细胞”，让数字技术像神经般串联起城市运行的每一个“器官”。其中，城市信息模型（CIM）、国土空间信息模型（TIM）、建筑信息模型（BIM）的协同应用，以及实景三维中国数据的开发利用，更是为“四通”循环体系提供了空间维度的技术支撑，推动城市从“平面管理”向“立体治理”升级。 （二）互塑机制：构建人城境业数字协同新范式 城市生命体的核心是“人”，数字化转型的终极目标是让城市更宜居、更韧性、更有温度。《行动计划》通过“数智赋能治理”“数字美好生活”等行动，构建“城育人、人塑城”的互塑机制：一方面，城市通过数字化升级为市民提供更精准的服务（如高效处置“一件事”、高效办成“一件事”）、更安全的环境（如城市生命线监测预警），其中医疗电子处方流转、费用一站结算、诊疗数据共享、社会保障卡居民服务“一卡通”跨省通用等高频民生场景的落地，让服务精准度与便捷性显著提升；另一方面，市民通过数据反馈、场景参与（如民意速办、接诉即办、未诉先办）反向塑造城市生命体的数字化自修复能力，形成“需求-响应-迭代”的良性循环，而基层报表“一数一源”“统采共用”机制的建立，则进一步降低了市民与基层组织的数据填报负担，让参与渠道更畅通。 这种互塑不仅体现在人与城之间，更延伸至“境”与“业”：通过城市数字更新行动，推动基础设施数字化改造，让生态环境（境）治理更精细（如智慧环保监测）；通过数字经济赋能行动，以数据要素价值化实现“以城带产、以产促城”，让产业（业）成为城市生命体的“肌肉组织”，支撑城市持续生长。 （三）进化逻辑：实现城市治理能力质的跃升 城市生命体的核心特征是适应环境变化的进化能力。《行动计划》通过“城市智能中枢建设”“适数化改革”等部署，为城市生命体注入“学习能力”——通过数据沉淀形成的“城市知识图谱”、算法迭代构建的“决策模型”，让城市能够从历史数据中提炼规律、从实时数据中感知异常、从多元数据中预判趋势，实现从“事后处置”到“事前预防”的跨越。 正如超大特大城市率先建设的“智慧高效治理新体系”，本质是为城市生命体安装“智慧大脑”，通过“一网统管”实现对交通拥堵、环境污染、公共安全等“健康指标”的实时监测与动态调节；而“城市运行体征指标体系”的构建，则如同为城市建立“健康体检报告”，让治理者精准把握城市运行状态，推动治理从“经验决策”转向“数据决策”。 二、八网联动：六项行动构筑城市数字生态体系 《行动计划》部署的六项行动（智慧高效治理提升、数字美好生活、数字经济赋能、城市数字更新、数字化转型筑基、适数化改革创新），并非孤立割裂的任务清单，而是以数据流为纽带，构建起“设施网、数据网、业务网、知识网、创意网、产业网、民心网、安全防护网”八网联动的数字生态体系，为城市生命体提供全维度支撑。这一体系的核心，是打破“条块分割”的传统壁垒，实现“网网相连、网网赋能”。 （一）基础支撑网：筑牢城市生命体“骨骼”与“血脉” 城市生命体的正常运行，依赖强健的“骨骼”（基础设施）与畅通的“血脉”（数据流动）。《行动计划》通过“城市数字更新行动”“数字化转型筑基行动”，构建“设施网”与“数据网”协同支撑格局： 设施网以“物联、数联、智联”为目标，整合感知终端、算力网络、通信设施，如同为城市生命体打造“神经网络末梢”，实现对交通流量、管网状态、环境质量等细微变化的实时感知。例如，“城市数字基础设施”的集约建设，避免了“重复开挖”“系统孤岛”，让设施资源像骨骼般形成整体支撑；而低空数据基础设施的适度超前布局、智能化路侧基础设施与云控基础平台的建设，则进一步为低空经济、自动驾驶等新兴场景提供了设施保障，提升车路协同水平。 数据网通过“公共数据一本账”“数据产权制度探索”，推动数据跨部门、跨区域、跨层级流通，如同为城市生命体打通“血液循环系统”。《行动计划》提出的“数据要素价值化实现”，正是让数据从“沉睡资源”变为“流动养分”，通过“数据券、模型券”等创新工具，激活数据在民生服务、产业创新中的价值潜能。 （二）功能协同网：激活城市生命体“肌肉”与“大脑” 如果说基础支撑网是“硬件”，那么“业务网”与“知识网”则是城市生命体的“肌肉”（治理能力）与“大脑”（决策智慧）。《行动计划》通过“智慧高效治理提升行动”与“适数化改革创新行动”，推动治理能力与知识沉淀协同升级： 业务网以“一网统管”“高效处置一件事”为核心，打破部门壁垒，构建“监测预警-事件流转-指挥调度-闭环落实”全链条机制，如同为城市生命体训练“协同肌肉”，让交通管理、应急处置、民生服务等功能形成“联动反应”。例如，“数字化城市综合运行和治理中心”的建设，实现了城市运行、应急管理等系统的“多脑协同”，避免了“各自为战”的治理困境。 知识网依托“城市智能中枢”“模型即服务”生态，沉淀治理经验、产业规律、服务模式为可复用的算法模型，如同为城市生命体构建“记忆与学习系统”。《行动计划》提出的“超大特大城市率先落地一批先进可用、自主可控城市大模型”，正是让城市能够从海量数据中提炼知识，实现治理与服务的“智能迭代”。 （三）发展活力网：培育城市生命体“细胞”与“灵魂” 城市生命体的活力，源于“细胞更新”（产业创新）与“精神共鸣”（民心凝聚）。《行动计划》通过“数字经济赋能行动”“数字美好生活行动”，构建“产业网”“创意网”“民心网”协同发展格局： 产业网以“以城带产、以产促城”为路径，通过“数据创新型产业社区”“城市首试首用体验场”，推动数字技术与实体经济融合，如同为城市生命体培育“活力细胞”。例如“数字产业集群”的发展，既提升了产业竞争力，又为城市创造了就业机会，实现“产城共生”；而数据保险、数据信托等金融服务产品的探索，则进一步丰富了产业网的支撑工具，降低企业数据创新风险。 创意网鼓励“智创品质生活”“数字友好人居环境”，支持市民、企业、社会组织参与数字化场景创新，如同为城市生命体注入“创新基因”。《行动计划》提出的“城市首试首用体验场”，让市民从“被动接受服务”变为“主动参与创造”，催生了智慧养老、社区微治理等个性化场景。 民心网聚焦“高效办成一件事”“民意速办服务”，让市民感受到数字化带来的便利与温度，如同为城市生命体凝聚“精神共识”。智慧社区建设中提出的数字惠民服务生活圈、幸福邻里综合体，让民心在“数据血脉”的流动中更加凝聚；同时，针对老年人、儿童、残障人士等群体的公共空间与数字服务适老化、适幼化、无障碍改造，以及“一老一小”公共服务资源一站式集成，进一步让民心网覆盖更广泛群体，弥合数字鸿沟。 （四）安全防护网：守护城市生命体“免疫系统” 城市生命体的健康成长，离不开“免疫系统”的守护。《行动计划》通过“数字化转型筑基行动”中“筑牢数字化转型安全防线”的部署，构建“安全防护网”，为城市数字生态保驾护航：一方面，强化网络安全、数据安全防护能力，健全政务云网安全保障体系，实现城市数据基础设施的可信接入、安全互联、跨域管控、全栈防护；另一方面，推进数据安全治理，建立数据安全风险防控体系，强化数据分类分级保护与全生命周期安全管理，完善个人信息保护制度，压实政府、企业、社会组织等各类主体的安全责任，确保数据在流动与应用中“安全无虞”，为城市生命体的数字化进化提供稳定环境。 三、落地突破：从蓝图到实景的实践进阶 如果说2024年《关于深化智慧城市发展推进城市全域数字化转型的指导意见》是全域转型的“发令枪”，那么《行动计划》则是具体的“路线图”与“施工图”。推动蓝图落地，需把握目标锚定的阶段性特征、路径创新的关键突破、因地制宜的差异化推进，让城市生命体的数字化成长既见实效、亦具特色。 （一）目标锚定：2027年标杆引领与2035年远景展望的衔接 《行动计划》明确提出“到2027年建成50个以上全域数字化转型城市”，这一目标并非简单的数量指标，而是对城市生命体数字化成熟度的阶段性定义。转型城市的核心标志，在于形成“智慧高效治理、美好生活普惠、数字经济活跃、数字更新有序”的良性生态，具备可复制、可推广的转型经验；同时，超大特大城市需率先建成智慧高效治理新体系，落地一批先进可用、自主可控城市大模型，形成头部引领效应。 从长远看，《行动计划》还明确了“到2035年，涌现一批具有国际竞争力、全球影响力的现代化城市”的远景目标，与2027年阶段性目标形成“短期突破-长期跃升”的完整时间轴。从具体指标看，“高效处置一件事”覆盖城市运行重点事件，意味着城市治理的“响应速度”与“解决效能”大幅提升；“高效办成一件事”覆盖高频民生事项，标志着市民“获得感”的实质性增强；“自主可控城市大模型”落地，体现了城市“智慧大脑”的自主进化能力。这些指标共同构成城市生命体数字化成熟的“体检标准”，指引各地精准发力。 （二）路径创新：制度供给与主体协同的双轮驱动 从蓝图到实景，关键在于突破“制度壁垒”与“协同难题”。《行动计划》通过“适数化改革创新行动”，构建制度与技术双轮驱动的落地路径： 制度创新聚焦“流程再造”与“规则重构”，例如“加快城市运行管理服务平台体系建设，完善城市运行管理工作机制”“跨部门数据合作机制”“线下网格与线上网络联动协同机制”等城市综合治理机制，打破传统治理的“条块分割”，让城市生命体的“协同反应”更顺畅；同时，加快推进数据确权规则、数字权证应用、行政管理与政府采购等制度改革，为数据要素流通扫清制度障碍。“长效运营运维模式”则通过“用户满意度导向的运营预算与评价考核机制”，建立运营运维评价动态反馈和发布机制，强化评价结果运用，确保数字化建设“建得好、用得久、管得优”，避免“重建设轻运营”的短期行为。 主体协同强调“政府引导、市场主导、社会参与”，让多元主体像“细胞协作”一样形成合力。例如，“数据要素价值化”通过“数据即服务”“模型即服务”生态，吸引企业、科研机构参与数据开发，激活全社会创新活力；而“立体化运营体系”（涵盖数据运营、场景运营、设施运营）的建立，则进一步明确政府、企业、社会组织在运营中的权责分工，形成协同闭环。 （三）因地制宜：差异化发展塑造城市数字竞争力 城市生命体的魅力在于其独特性，数字化转型同样不能“千城一面”。《行动计划》鼓励各地立足资源禀赋、发展阶段，分类分级有序推进：超大特大城市可聚焦“智慧高效治理新体系”，利用人才与数据优势，在城市大模型、跨区域协同治理上率先突破；中小城市可侧重“数字基础设施补短板”与“特色场景创新”，例如结合农业优势发展智慧农业、依托文旅资源打造数字文旅场景；资源型城市可强化“数字赋能绿色发展”，通过智慧环保、碳足迹监测等场景，实现生态保护与经济发展的平衡。这种差异化发展，如同自然界中不同物种的“生态位分化”，让每座城市在数字中国的大生态中找准定位，形成“百舸争流、各具特色”的生动局面。 （四）组织保障：多方联动与能力建设的支撑 《行动计划》落地需强化“顶层统筹-基层落实-能力支撑”的全链条保障：在国家层面，由国家发展改革委数据局会同财政部、住房城乡建设部、自然资源部等部门加强工作指导，分类分级有序推进，强化部门协同与上下联动；在地方层面，支持各地建立高层级统筹推进机制，针对重大需求、重大场景、重大改革集中发力；同时，加大对数字化转型技术攻关、重大项目、试点试验的资金支持，强化数字化转型、数据合规、数据服务等专业人才队伍建设，并通过优秀实践与典型案例的提炼推广、深化国际交流合作，为各地提供经验借鉴与能力支撑，确保转型路径不偏、力度不减。 结语：迈向数字文明时代的现代化人民城市新图景 从“数字福州”的探索到“数字重庆”的实践，从“一网通办”的便民到“一网统管”的高效，我国城市数字化转型已走过十余年历程。《行动计划》的出台，标志着这一进程进入“系统重构、质效提升”的新阶段——不再是技术的简单叠加，而是城市生命体的“系统性重塑”；不再是单点的创新突破，而是全域生态的“整体性进化”。站在新的历史起点，推进全域数字化转型，需以系统思维呵护城市生命体的健康成长，以创新精神破解转型中的难点堵点，让数字化真正成为滋养城市、服务人民的“源头活水”，为中国式现代化注入澎湃的城市高质量发展动能。 作者： 中央财经大学政府管理学院城市管理系主任 王伟 来源（公众号）：北京数据

在数字化转型的浪潮中，数据治理已从可选课题升级为企业核心战略。然而，众多企业在投入大量资源后，却难以准确回答一个根本性问题：我们的数据治理究竟成效如何？对于决策者而言，建立科学的评估体系不仅是管理需要，更是将数据治理从成本中心转向价值引擎的战略举措。本文旨在构建一套完整的数据治理成效评估框架，通过五...

城市是推进数字中国建设的核心载体，更是中国式现代化建设的主战场与动力源。近日，《深化智慧城市发展 推进全域数字化转型行动计划》（以下简称《行动计划》）正式发布，明确了推进城市全域数字化转型的思路与目标，并从六个方面系统规划了扎实推进转型的重点任务与具体举措，为城市数字化转型提供了行动指南。《行动计划》深入贯彻中央城市工作会议精神，深刻把握并主动适应我国城镇化和城市发展的形势变化，以数据赋能城市经济社会发展全局为核心理念，充分发挥数据要素在城市高质量发展中的协同优化、复用增效与融合创新作用，不仅为提升城市治理智能化精细化水平提供了清晰路径，更为满足人民群众美好生活需要注入了动能，为现代化人民城市建设提供了强大支撑。 一、聚焦三大核心领域全维度赋能城市发展 建设现代化人民城市具有深刻的理论内涵与实践意义。“人民城市”彰显了中国特色城市发展的本质属性，“现代化”则涵盖创新、宜居、美丽、韧性、文明、智慧等多元维度，是对城市发展质量与水平的综合性要求。《行动计划》锚定建设现代化人民城市的目标定位，坚持数据驱动、应用导向，聚焦城市智慧高效能治理、高品质生活、高质量发展三大核心领域，致力于全领域、全方位、全过程赋能城市经济社会发展。 一是以数据驱动城市高效能治理。当前我国城市工作重心正发生重大转变，亟需打破“重建设、轻治理”的传统思维与惯性做法，加大治理投入，推动城市向高水平运营、高效能治理转型。《行动计划》紧密结合治理需求，统筹发展与安全，提出实施城市智慧高效治理提升行动，围绕城市运行、安全风险、社会服务与治理等关键领域，明确了构建城市智慧高效治理体系、数智赋能城市应急安全保障、提升民意速办服务效能等重点举措。其中，深化“一网统管”建设，构建城市运行体征指标体系，建立数据赋能、分级协作、闭环落实的智慧高效治理机制；围绕城市风险早期预警、灾前防范、应急处置等关键环节强化数智赋能；在社会治理中深化数字化应用，提升社情民意实时感知与精准服务水平等举措，均有助于将风险防控深度嵌入城市管理系统，助力建设安全可靠的韧性城市，提升城市平急联动协同能力。 二是以数据创造高品质生活。人民群众对美好生活的向往是城市工作的出发点与落脚点，宜居则是践行人民城市理念的基本要求。《行动计划》提出开展数字美好生活行动，着力建设舒适便利的宜居城市。重点聚焦医疗、健康、教育、新就业群体服务管理等重点应用场景，推进智慧公共服务升级；打造数字赋能文旅、体育、数字消费等新型数字生活场景，推动人工智能在消费场景的深度应用，发展智创品质生活；精准识别老年人、儿童、残障人士等群体的服务需求，推动城乡数字基本公共服务均衡化，优化数字友好型人文环境。一系列举措紧扣民生所需、推动精准普惠，充分彰显了城市数字化转型的“温度”，生动诠释了“人民城市为人民”的发展理念。 三是以数据引领高质量发展。建设富有活力的创新城市，精心培育创新生态，在发展新质生产力上持续突破，是我国当前及今后一段时期城市工作的重点任务。《行动计划》立足城市内涵式发展的战略取向，统筹建设与治理关系，提出实施数字经济赋能行动，从发挥城市功能的角度推动经济高质量发展。在依托城市集聚优势、推进数据要素价值化实现“以城带产”的同时，更强调“以产促城”，利用数字技术推动城市功能改造，建设创新型产业社区、商务社区；依托产业园区促进传统产业、新兴产业、未来产业的科技创新成果落地转化；构建城市经济运行协同调度与监测体系，支持有条件的地区开展城市数字经济监测分析，为建设活力之城、机遇之城提供有力支撑。 二、聚焦存量提质增效推进城市数字更新 城市全域数字化转型需置于我国城镇化和城市发展的历史方位中审视。从我国新型工业化、城镇化进程来看，尽管城镇化仍有较大空间与潜力，但增速已整体趋稳，城市空间布局和基础设施建设已大体成型，多数城市建成区面积与开发强度已达较高水平，城市发展已难以延续外延式扩张态势。在我国城镇化从快速增长期转向稳定发展期、城市发展从大规模增量扩张转向存量提质增效为主的阶段，推动城市全域数字化转型必须以坚持城市内涵式发展为主线，以推进城市更新为重要抓手。 《行动计划》深刻把握我国城市发展阶段性特征，提出推动城市数字更新行动，注重通过盘活存量带动增量发展。一方面，优先解决安全与韧性问题，加快城市基础设施数字化更新改造。在风险高发区域有序实施城市泛在感知工程，运用人工智能等技术深化城市生命线安全工程建设，同时建立健全数字基础设施与市政基础设施同步规划、同步建设机制。另一方面，深化智慧社区建设，着力提升城市功能与品质。支持有条件的地区改造建设一批高品质智慧社区，完善社区嵌入式服务设施，按需配置、优化升级社区数字服务能力，发展智慧物业；打造数字惠民服务生活圈，建设涵盖一站式托育助老、亲子阅读、社区康养等服务的幸福邻里综合体，通过高品质生活空间的打造实现城市有机“新陈代谢”。 三、聚焦城市新“硬件”构建统筹集约数字底座 新时代以来，我国新型城镇化水平和城市发展能级不断提升，城市面貌发生历史性变化，城市功能实现历史性跃升，城市发展取得历史性成就，城市发展的传统“硬件”设施已达到较高水平，部分特大超大城市更是走在世界前列。但与此同时，面对新一轮科技革命和产业变革加速演进、人民群众需求日益升级的新形势，我国城市在数字基础设施建设方面仍有较大提升空间。 《行动计划》提出实施数字化转型筑基行动，强调大力推进城市数字基础设施建设，集约布局感知、网络、算力等基础设施，推进全国一体化算力网建设，在国家算力资源统筹规划下，推动跨区域多元异构算力资源的统筹管理与灵活调度；强化数据资源供给，积极探索数据产权归属认定、合规流通、权益分配等制度建设，建立动态更新的城市公共数据资源目录，逐步构建公共数据“一本账”；完善城市智能中枢，构建统一规划、统一架构、统一标准、统一运维的一体化中枢系统，加强城市数据汇聚治理与融合利用；高度重视数字化转型安全，强化网络安全、数据安全一体化防护能力。一系列具体行动围绕基础设施、数据资源、智能中枢、安全防护四个主要维度形成实施城市新“硬件”发展“路线图”，为现代化人民城市构筑了坚实的数字底座。 四、聚焦激发城市活力深化适数化改革 建设现代化人民城市，需要通过持续深化改革破解矛盾难题，加快培育壮大城市发展新动能。当前，许多城市的政策、标准体系形成于大规模扩张时期，而数字化领域的政策制度仍不健全，亟需破除数字化转型的制度性堵点，加快构建与城市发展新阶段、新目标、新任务相适应的政策制度体系，在适数化改革中实现突破。 《行动计划》坚持系统观念与问题导向，提出开展适数化改革创新行动。重点围绕城市治理需求推进适数化改革，依托城市智能中枢创新跨部门数据合作机制，构建线下网络与线上平台联动协同机制，开展有利于数字化转型的数据确权规则、数字权证应用、行政管理、政府采购等制度改革；针对城市运行效能提升，创新长效运营运维模式，探索建立以用户满意度等应用效果为导向的运营预算与评价考核机制；尤其注重发挥标准的基础性、引领性作用，推动形成涵盖数字底座、转型场景、运营运维等领域的标准规范体系，并围绕服务主体评价，制定城市全域数字化转型规划咨询、建设实施、运营运维三类服务主体评价标准，构建闭环管理体系。相关适数化改革既强调跨部门、跨层级、跨区域统筹协调，又注重鼓励和支持各城市因地制宜，差异化探索全域数字化转型之路，有助于持续激发城市活力，提升现代化人民城市建设的整体效能。 作者： 国务院发展研究中心公共管理与人力资源研究所综合研究室主任、研究员 赵峥 来源（公众号）：北京数据

在数字经济时代，数据已成为关键生产要素。然而，许多企业在推进数据驱动转型的过程中，普遍面临着“数据孤岛”的困境——数据分散在各个系统中，业务人员不知道有哪些数据、不知道数据在哪里、更不知道如何获取数据。数据资源目录的出现，正是为了解决这一核心痛点，它不仅是数据的“导航系统”，更是实现数据价值释放的重...