架构之争：数用一体VS数用分离，谁才是永远滴神-CSDN博客

编者荐语：

“数用一体”、“数用分离”有何差别？“数”、“用”两字具体怎么理解？架构选择两者优缺点?全网30万+粉丝的CSDN技术博主「不吃西红柿丶」前来解答，以smardaten平台为例深扒两者架构之差，上述所有问题全文干货解答，你离看懂只差这篇文章！

1 数用分离为什么不适合现代技术应用模式了？

🍎1.1 信息化前期阶段数用分离的价值

数用分离是很多公司数据与技术应用模式，把各种业务子系统的数据抽出来，放到一个数据平台上，然后在平台上把它治理好，同时再把这个平台开放出来，给业务系统去使用。把数据作为一个独立的一个单元去处理，跟应用不要那么紧耦合，它可以更好的去复用或者更好的去在各个地方共享。

过去信息化基础建设阶段，首先是要建设业务系统，保障业务实现线上化，因为数据量较少、业务变更频率低，这种模式是符合实际需求的。

但在这里面存在很多问题和门槛：

系统数据从哪来？如何治理好又回归到业务系统？这中间会有很多困境和实际面临的问题，比如需要协调很多厂家做对接，平台本身不懂业务时如何做治理？纯粹的通过数据属性的方式把数据治理好，其实很难的。即使在这个平台里面把它给治理好了，要谁来用？使用的一方怎么去用这个平台？怎么去开放？如何协调这几者之间的关系？

数字化加速的今天，现在的企业组织追求更高的效率，数据要能快速在业务中应用起来，所以数据要实现贯通、流程都拉通。在这种情况下，我们才有可能去实现数据驱动业务。

🍐1.2 数字化效率加快的背景下，数用一体或是新模式

弱化大数据平台建设过程，但是保留大数据平台本身，那么业务系统再去构建、改造、升级的时候，大数据平台能够把业务系统数据资产化这个过程，颗粒度变得越来越小一些，平台建设的门槛就会变得低一些。客户中间的需求发生变化，表结构都发生了很大的变化，然后系统能够快速的响应客户，沉淀下来的数据变成了资产能够再使用。

同时，应用系统本身产生的数据马上能进行资产化、快速利用，未来还可以用这些数据再进行开发更好的新的应用，循环往复这么去做。

沉淀的目的是为了再利用，如果沉淀下来的内容很难被利用，或者说需要独立去分割化管理，而不了解业务需求，其实就是浪费，浪费一台服务器。

要想存下的数据要能够被上面所接触，就要有一些很方便的方法和工具，让它更低门槛地方便我们去使用这个数据。那么可能是无代码组装工具，这是最快搭建业务场景的方式。这样，数据和业务会天然连接。有新的业务系统要做时，在这里继续组装，而不用改动数据平台或结构。达到一种数据与业务的平衡。

🍊1.3 数用分离与数用一体对比模式

具体看，数用一体和数用分离有何差别？

在传统产品的拼凑模式中，人力资源管理系统 HRM、企业资源管理系统 ERP、客户管理系统 CRM 系统等等，都是完全相互独立的，不可避免的将会带来以下坏处：

数据孤岛：不同子系统之间数据格式、标准、存储方式等存在差异，难以实现数据共享和交换，导致数据孤岛。
信息不一致：由于各个子系统之间信息孤立，可能会出现相同信息在多个子系统中存在且内容不一致的情况，导致信息不一致。
统计分析困难：由于数据无法共享和交换，企业难以对整体运营情况进行全面统计分析和评估。
效率低下：由于各个子系统之间缺乏协同配合，需要人工介入进行数据传递和处理，导致效率低下。
难以扩展：当企业需要引入新的子系统时，往往需要进行大量的接口开发和数据转换工作，增加了开发成本和时间成本。

数用一体架构不同于传统产品的拼凑模式，而是对各子系统进行集成化的管理建设，通过集成各个子系统并实现数据共享和交换，可以提高企业运营效率、降低管理成本，并为未来扩展打下良好基础。当有新的系统建设时，只需纳入版图即可。

其中，想要达到这样“数用一体”的效果，最关键的是，中间平台支持数据连贯性使用，业务上也需要有相对一致的数据结构与管理模式，这样才能沉淀一致的、可统一管理的数据，所以上层应用开发的模式和应用能力构建也是一致的。

就需要一套能让数据接入、存储、数据管理、分析和应用都能一体化完成的平台。

下面以数据驱动的企业级无代码软件平台smardaten为例，对数用一体展开讲解。

🍌2 smardaten 数用一体的架构

🍉2.1 smardaten 数用一体架构组件和特点

类似于传统的数据中台的概念中，数据是 all-in-one 中台。

smardaten 数用一体架构中包括3大块，数据管理模块、数据分析可视化模块和无代码应用开发模块。

数据底层管理模块一定程度上承担数据中台的作用，数据管理模块包括数据接入、数据清洗集成、数据血缘、数据质量、数据标准等等，完成了数据从产生到应用的全生命周期管理。简单来说，就是比中台的数据接入环节再往前走了一步，把数据产品管理起来；也往后走了一步，生成和分析报表访问等行为相关数据等。

但与数据中台有最大的不同是，它不会与应用系统分开，不是各自独立的架构、技术模式，互相需要接口去对接。这3块是连通的，加上数据分析可视化模块，另外还有无代码应用开发模块。

你可以有多种理解，让无代码开发出的应用产生的数据直接存放在数据管理模块进行管理、导入数据分析可视化模块进行分析决策，反过来，你做好数据对接与管理、甚至也做好了一些业务数据分析，这时候，你可以搭建一个业务应用系统，数据资产也好、报表也好，可以直接导入去支撑业务。这么双向来回，数据与应用就是一体的。

🍓2.2 smardaten平台的“数”

smardaten平台中数据是贯穿整个使用过程的，若只从数据层面看，集数据连接、IoT设备采集、数据标准、数据质量、数据集成、数据安全、数据服务等比较全面的数据资产管理能力。

🍈2.2.1 数据接入

汇集来自不同来源的结构化和非结构化数据，并将其转换为可处理格式。

支持 30多种数据源的接入，包括一些关系型、非关系型数据库，主流国产化数据库，以及一些文件、媒体数据。

传统关系型数据库:Oracle、MySQL、SQLsever、DB2、Sybase…
非传统型数据库:InfluxDB、Redis、MongoDB、CouchDB…
图数据库:Neo4J、TigerGraph…
MPP 数据库:Greenplum、DorisDB、Clickhouse Hadoop 生态(数据源):HDFS、Hive、Hbase
国产数据库:GaussDB、达梦、金仓
文件数据:CSV、EXCEL、ACCESS、特定格式(TXT、log、 json)…
多媒体数据:视频、音频、图片… 其它数据:钉钉、企微、飞书、API…

另外，很特别的是，这里支持IoT物联网数据的连接，自带了8中预置接口协议，面向广泛的物联网终端，支持大多数物联网 IOT 终端感知设备的数据对接，满足物联网发展趋势下多场景下的数据实时/准实时采集需求。

🍒2.2.2 数据集成

支持快速数据清洗、计算处理，并且是拖拽式的，是一个比较全面的ETL工具，能够轻松实现数据快速抽取、清洗与加载。

内置海量算子：已预置30+数据处理组件，例如：过滤、连接、离散、格式化、类型转化等的，参数化实现数据处理操作。

跨数据源计算：支持跨数据库联合计算，无需数据迁移，加速数据处理。业务逻辑与物理引擎隔离，保证计算引擎平滑升级。

复杂算法：多算子组合配置，算法模型开发人员能够完成建模过程，屏蔽传统复杂的代码，实现建立快速、高质量全程可见的算法模型。也可以将相对应的处理流程封装为固定算子，开发领域算法，减少同类处理方式的反复构建。

🍑2.2.3 数据管理

数据目录管理：对数据分目录管理，支持计数、行数、最近更新时间、数据查询配置等，可添加变量和查看历史变动。

数据检索配置：可通过数据搜索和按钮配置等，快速实现数据查询条件配置，并配置不同数据展示形式。

血缘关系：支持数据处理过程的血缘查看，追溯数据演变与联合处理的数据链路，展示各阶段数据的更新时间、行数及状态信息。

数据安全维护：提供全方位的数据安全能力，包括数据加解密、数据隐私保护和数据溯源等。

🍍2.2.4 数据标准管理

按需求实现规范化术语描述和标准配置，确保数据符合行业规范要求，提供对数据标准进行完整性、规范性、一致性、准确性的规则内容和稽核脚本管理，支持逆向反射解析数据源中数据，在不影响用户原有信息化系统情况下实现元数据的抽取与管理。

🥝2.2.5 数据质量管理

以稽核任务包形式为主要载体，满足部门内数据治理小组按照数据标准维度，分批、分量的对部门内系统数据项开展数据治理工作。

根据稽核结果，系统自动输出质量统计报表，对稽核结果数据按照不同维度进行提炼统计，反映系统内目前数据总体质量水平。基于制定的数据标准，可以自动输出元数据的数据质量问题并以报告形式展现。

🥑2.2.6 数据服务

数据服务能力，主要体现在两个方面。一是服务编排和搜索配置，构建多场景灵活的数据共享能力。二是数据服务监控与日志分析，有效管理数据使用情况。

数据服务编排：数据服务场景下的交互动作编排，针对复杂交互接口可实现数据处理、变量控制等逻辑编排组合。

数据服务监控：对数据资产服务的使用排名、下载情况、API 调用等情况进行统计分析，对详细服务记录进行展示。

日志管理：对数据资产服务的类型、时间、操作类型等进行全面记录，可追溯查询数据使用全责。

🍅2.3 smardaten平台的“用”

数据管理能力有了，再看数据“用”的能力。在smardaten平台里面，主要包括数据分析与可视化，以及无代码应用开发。

2.3.1 数据分析与可视化

提供数据智能分析工具，支持复杂图表处理及数据字段钻取、标签、预警、变量、拆分、合并、统计等基础分析能力，同时具备图谱分析、时序分析、预测分析等智能分析能力。

另外，数据大屏设计引擎就比较厉害了，除了一般的二维数据信息展示布局，还支持三维场景开发，支持多种二三维GIS地图进行交互分析，更支持大型3D模型导入，通过无代码去构建数字孪生场景。当然也支持CSS自定义个性化的展示样式。

🍆2.3.2 无代码应用开发

无代码应用开发也是最直接的“用”的方式，市面上很多低、无代码平台，大体逻辑是一致的。包括常见的表单、业务流程构建、权限管理等。

不过在smardaten上面，也有一些明显差异，比如应用构建中仪表盘的构建，除了正常的拖拽图表组件，还可以把数据分析模块中已经做好的数据分析图表直接导入，甚至数据大屏也可以直接导入到应用页面中。

另外，像数据接入、数据集成、标准管理、质量管理、数据服务等这些数据类模块，都可以被独立组装到应用中。也就是说，可以按照客户需求重新组装轻量级数据中台、数据治理平台。

这是其他无代码平台不具备的，因为市面大多本身就没有这么多数据底层服务。

这也是为什么说smardaten是“数”、“用”一体，数据能力和业务应用是互相支撑、闭环的。

目前交付了很多行业级的数字化软件项目，因为平台本身没有行业属性，框架技术比较开放完整，适用于很多场景去做数字化业务综合能力构建。

🥒3 架构选择，没有最好，只有最适合

🥜3.1 从企业架构演进过程来看

回过头，我们看看这些年，企业架构的演变大体上分为几个阶段：

第一阶段：烟囱式建设

优势：

业务系统具备较完整的业务逻辑，适合相对通用、业务模式稳定的业务

劣势：

业务变化对系统的侵入性相对较高
能力沉淀和复用的工作容易被弱化
数据孤岛，数据难以被综合利用分

第二阶段：裙楼式建设

优势：

数据中台打通各个业务系统数据
业务逻辑与数据服务一定程度分离，业务变化对中台的侵入性相对较小

劣势：

数据中台大多只能用作数据提取，提取出来的数据只能用作经营分析，数据价值难以被充分利用

第三阶段：回廊式建设

优势：

业务和数据能力沉淀，业务应用与通用业务能力、数据能力分离，业务变化对中台的侵入性相对较小

劣势：

虽然有全局性的分层抽象规划，但其本质并不彻底，特别是对于易变的业务何和日新月异的技术体系而言，需要付出额外的治理成本和更新迭代成本

传统的烟囱式、孤岛式系统无疑已经是被公认为过时的信息化建设模式；而基于整体规划的平台化建设方案，以及近年来热门的数据中台和业务中台，虽然有了全局性的分层抽象规划，但其本质并不彻底，特别是对于易变的业务和日新月异的技术体系而言，需要付出额外的治理成本和更新迭代成本。

垂直式与烟囱式建设的对比：烟囱式建设是自下而上都采用相对独立的数据管理和技术框架体系的建设，而垂直式建设是在同一套数字化操作系统上专注面向垂直领域业务逻辑和能力组件的系统化建设。虽然两种建设模式都能够实现特定业务的系统建设，但如果想要实现业务系统间的集成、交互和协同，前者需要付出额外的集成化建设代价，并且系统集成本身又是一个新的难题，集成化的效果更加难以确定。

而垂直式建设，是一种位于多维度联通体系空间内的垂直业务系统建设模式，在这种模式下，前期不仅可以像传统烟囱式建设方式一样只专注于具体业务领域的构建，同时又能在构建过程中自动沉淀架构资产、数据资产、能力资产和应用资产，这些资产会在构建新的业务应用时开箱即用。

🥕3.2 smardaten 数用一体架构优缺点

从这个趋势看，smardaten是符合这个趋势的，甚至是比最新阶段还有一些变化，类似一种垂直式的架构，从业务构建和数据下沉管理的角度看，是纵向垂直的。而从数据资产、数据使用、业务能力模块的使用上看，又是横向统一的。

垂直式建设具备更多的良好特性，包括页面、组件、业务模型、数据资产的跨系统复用，业务流程的跨系统联通，角色权限的全局式管理。

不管横向还是纵向，数据和业务都是能持续积累和扩展，对业务的发展变化影响很小。

优点：

数据能力比较全面，数据以数据资产的形式进行统一管理并驱动上层应用的构建，通过平台构建的应用也会在运行过程中产生数据，沉淀为数据资产，这样也可以避免过去多个应用形成的数据孤岛。
平台包含数据、分析、应用开发、二次开发、集成等多方面的能力，相当于集成了数据中台、BI工具、低无代码开放平台等多种工具平台，适用于很多场景，对于要求不是特别高的客户，也节省了专项平台的重复性开发和管理工作。
平台整体上都是无代码、可视化的，使用上相对比较易上手。但由于功能多、甚至大量隐含功能，在使用上有一定的复杂度。从功能上看，很适合数据架构师、产品经理、数据分析师、实施交付人员去使用。
由于所有功能都在同一应用程序中实现，因此部署和维护非常容易。由于没有额外的网络通信开销，因此可以获得更高的性能。

缺点：