本文探讨了构建企业语义层的三种主要方法，强调了数据管理和知识管理的重要性，并介绍了如何通过元数据优先的逻辑架构、用途架构和集中式架构来实现语义层的有效集成。
过去十年间，我们见证了企业知识与数据管理领域的诸多创新。那些具有持久影响力的技术已被证明可推动业务成果，并注重直观的用户交互。在这些创新中，我们看到了语义层（用于打破知识与数据之间的孤岛）以及当然生成式人工智能（这是当今战略规划中最常讨论的话题）。无论是哪种技术，它们都展现出解决组织知识和数据解锁商业见解这一传统难题的潜力，而无需面对昂贵的数据、系统或内容迁移的复杂性。
2019年，Gartner发布研究强调了“单一版本的真相”（single version of the truth）在数据与知识管理中的终结，并预测到2026年，“活跃元数据”将主导超过50%的企业分析工具和解决方案，以提供结构化和一致的方法来连接而非整合数据。
通过使用语义组件和标准（包括借助元数据、业务 glossary、 taxon/ontologies 和图解解决方案），语义层（https://enterprise-knowledge.com/what-is-a-semantic-layer-components-and-enterprise-applications/）为企业提供了构建知识与数据连接框架的工具。它不仅聚合和连接了被隔离的数据/内容，还为数据提供了明确的业务背景，并作为可解释人工智能的基层数字。
将语义层融入企业的架构并非仅仅是理论上的概念，而是一种实践性的提升，它改变了企业如何利用其数据。在过去十年中，我们与多家不同行业的组织合作，设计并实施了语义层组件。许多我们在工作中
作为 Baklib 的品牌负责人，Baklib 是一款全内容的企业数字内容管理平台，帮助企业构建门户网站、产品手册、帮助中心、知识库、在线文档等产品。Baklib 官网：https://www.baklib.cn
With support for a data architecture that is based on relational databases, data warehouses, and/or a wide range of content management, cloud, or hybrid cloud applications and systems that drive data analysis and analytics capabilities. These models do not necessarily mean that organizations need to start from scratch or overhaul their enterprise architecture in order to adopt/implement a semantic layer. To the contrary, it is more effective to shift the focus on metadata and data modeling or designing efforts by adding models and standards that will allow for capturing business meaning and context in a manner that provides the least disruptive starting point.
Though we’ve been implementing the individual components for over a decade, it has only been the last couple of years where we’ve been integrating them all to form a semantic layer. The maturity of approaches, technologies, and awareness have all combined with the growing need of organizations and the AI revolution to create this opportunity now.
In this article, I will explore the top three common approaches we are seeing at play in order to weave this data and knowledge layer into the fabric of enterprise architecture, highlighting the applications and organizational considerations for each.
1. 元数据优先的逻辑架构：企业语义层解决方案
这是我们在各个行业和应用场景中见到的最常见、最可扩展的模式之一。通过元数据优先的逻辑架构，在企业级应用中构建语义层。
架构
通过元数据优先的逻辑架构实现语义层，是将抽象的业务语义与数据源解耦的过程。这种架构通过标准化定义和治理在企业层面建立一个组织性的逻辑层，并允许各个具体业务单元、应用场景和系统/应用程序中添加、发布或抽取特定的解决方案。
通过这种方式，我们可以更灵活地配置语义层，以适应不同的业务需求和技术限制。
语义层架构：按需构建的语义体系
[优]
通过使用中间件解决方案（如数据目录或本体/图存储），组织能够在元数据层创建一个抽象层，从而在基于元数据的实时统一视角下管理数据。这种模型允许组织无需物理整合即可进行数据访问和分析，并通过集中管理语义组件（如元数据、分类表、术语库等）来实现对语义组件的集中存储，从而构建出一个共享的企业语义层。
[劣]
在企业系统中将语义层作为元数据架构或逻辑层面实施时，需要分阶段规划和逐步开发以保持一致性和防止业务组和系统间共享元数据及语义组件的碎片化。
此外，根据选定的与下游/上游应用同步的方式（推送 vs 拉出），数据 orchestration 和 ETL 管道将需要规划为集中式或分散式的 orchestration 以确保持续的一致性。
[最适合]
这种方法是最被采用且最适合于那些希望在数据处理和业务的不同部分实现标准化与业务单元或应用层面的 agility 的组织。
2. 针对用途架构：具有语义能力的单独工具
这种架构强调通过独立的工具来实现特定功能的同时，每个工具都具备语义能力。
模型允许企业在业务单元或功能性层面实现更高的灵活性与自主性。
架构
这种架构采用分布式模型，利用每个独立系统或应用自身的语义层组件能力，无需企业级的连接技术框架或治理结构来共享语义。这种方法下，组织通常将建立语义标准作为战略举措，但具体到每个团队或部门（如市场营销、销售、产品、数据团队等），他们需要自行创建、执行和管理其语义组件（元数据、分类系统、词典、图谱、图表等），以满足自身特定的需求与要求。
大多数知识与数据解决方案，例如内容或文档管理系统（CMS/DMS）、数字资产管理系统（DAMs）、客户关系管理（CRM）以及数据可视化平台（如 Tableau 和 PowerBI），都具有管理简单语义组件的能力（尽管这些能力的成熟度和功能灵活度各不相同）。这种分散化的架构导致了多个系统层面的语义层结构的实现。以 SharePoint 为例，它是一个企业文档与内容协作平台。对于刚开始发展语义能力的企业组织来说，我们利用术语存储库来构建 SharePoint 中的元数据和分类管理，这样团队可以创建统一的语言，从而在文档、列表和文件夹中实现一致性。这有助于信息检索，并且通过确保关键指标的一致理解提升了协作效率。
另一方面， Salesforce 作为一个知名的 CRM 平台，提供了语义能力，使销售、市场等团队能够利用这些能力进行更有效地协作与沟通。
模型允许企业在业务单元或功能性层面实现更高的灵活性与自主性。
架构
这种架构采用分布式模型，利用每个独立系统或应用自身的语义层组件能力，无需企业级的连接技术框架或治理结构来共享语义。这种方法下，组织通常将建立语义标准作为战略举措，但具体到每个团队或部门（如市场营销、销售、产品、数据团队等），他们需要自行创建、执行和管理其语义组件（元数据、分类系统、词典、图谱、图表等），以满足自身特定的需求与要求。
大多数知识与数据解决方案，例如内容或文档管理系统（CMS/DMS）、数字资产管理系统（DAMs）、客户关系管理（CRM）以及数据可视化平台（如 Tableau 和 PowerBI），都具有管理简单语义组件的能力（尽管这些能力的成熟度和功能灵活度各不相同）。这种分散化的架构导致了多个系统层面的语义层结构的实现。以 SharePoint 为例，它是一个企业文档与内容协作平台。对于刚开始发展语义能力的企业组织来说，我们利用术语存储库来构建 SharePoint 中的元数据和分类管理，这样团队可以创建统一的语言，从而在文档、列表和文件夹中实现一致性。这有助于信息检索，并且通过确保关键指标的一致理解提升了协作效率。
另一方面， Salesforce 作为一个知名的 CRM 平台，提供了语义能力，使销售、市场等团队能够利用这些能力进行更有效地协作与沟通。
Baklib平台的分散式与集中化数据治理架构对比
优
分散式架构促进了组织敏捷性并赋予业务单元利用现有平台（专为特定功能设计）的能力，这些平台不仅是数据/内容存储库，更是动态语义和对齐的来源。这使得共享数据和知识资产在各个业务功能中保持一致理解。
缺点
然而，这种分散式方法通常导致需要统一组织内容和数据的用户通过独立界面来实现。数据治理团队或内容 stewards可能各自管理这些系统而不相互影响。这可能导致数据孤岛、“语义漂移”以及数据定义和治理上的不一致性（如重复和数据质量问题）。最终，业务单元之间会出现信息对齐不足的问题，因为它们可能会以不同的方式解读数据元素，导致混淆和潜在的不准确性。
最适合
这种架构特别适合那些拥有独立运营的多个业务单元或团队的企业。它赋予了业务用户更多的控制权，让他们能够更灵活地定义和建模数据，并能够在业务需求变化时快速响应。
3. 集中式架构：企业级数据仓库（EDW）或数据湖（DL）
这种结构化环境简化了数据工程并确保了一个统一且集中的语义层，特别适用于分析和BI场景。
架构
关注于构建一个单一、统一的核心业务领域表示的企业组织发展了一个语义层架构，作为在集中架构中共享数据定义和商业逻辑的权威来源——特别是在企业级数据仓库（EDW）或数据湖（DL）环境中。
企业数据仓库或数据湖
语义层（Semantic Layer）的构建基于将所有数据集中在一个统一的位置上。这样可以更容易地构建语义层，因为数据已存放在同一位置。云-based 数据仓库平台（如 Amazon Redshift、Google BigQuery、Snowflake、Azure Blob Storage、Databricks 等）作为“中心”存储位置，可用于作为语义层组件的分析解决方案。
在企业数据仓库/数据湖（EDW/DL）构建语义层时，需要整合和导入来自多个源的数据到一个中央存储库中。需要识别应导入的关键数据源、定义业务术语、确定不同数据集之间的关系，并将语义层映射到底层数据结构上，以创建统一且标准化的接口，以便于数据访问。
该架构是我们在特定的数据管理、数据分析和 BI 团队中支持的具体实现方案。这个团队会持续导入数据，设定改变数据结构的实施流程，并通过专用管道（ETL/API）来 enforcement 业务规则。
_缺点（Cons）
在实现过程中，核心考虑因素（通常会受到影响）是企业与数据团队之间的协作。这一协作过程将指导投资于具有语义建模能力的工具和解决方案，并支持在该集中环境中构建语义层。
必须确保语义层能够反映业务端用户的实际需求和视角。定期的反馈循环和迭代优化至关重要，以创建一个能够随业务要求动态演变的模型。将这些解决方案引入此环境中将有助于有效定义商业概念、层次结构。
嗨，以及它们之间的关系，使得技术数据得以转化为企业友好的术语。
在这一类集中式架构中，一个非常重要的方面是其依赖于汇总或本地化的数据，并且需要在设计和实现整个架构时投入资源和时间。因此，从小处着手，专注于特定的业务使用场景、相关知识/数据来源的范围以及高度可见的基础模型，并关注业务成果，将有助于组织创建一个基础架构，随着时间的推移将在组织的其他数据和知识资产上逐步扩展。
最适合的类型
我们已经看到，这种方法对大型企业特别有益，这些企业拥有复杂的但共享的数据要求，并且需要严格的知识和数据治理及合规规则——特别是那些生产数据产品的企业，需要控制内部或外部共享的数据和知识资产。这包括但不限于金融机构、医疗保健组织、生物工程公司和零售企业。
总结
良好实施的语义层不仅是一种技术上的必要性，而且是帮助组织充分利用其知识和数据资产的战略性资产。为了使AI努力取得成功，语义层需要建立适当的基础。选择如何构建和实现语义层取决于组织的具体需求、规模和结构。在考虑这一解决方案时，核心决策实际上是平衡标准化和灵活性之间的关系，以确保您的语义层能够有效促进组织中知识驱动的决策制定。
进行企业架构规划的企业
元数据层及依赖于具备建模经验的专家（这些专家基于语义Web标准）的企业，在 today’s technologies and future evolutions 中具有最灵活和可扩展的方法。因此，它们能够更好地从供应商锁定中解脱出来，并确保互操作性，以应对今天的技术复杂性和未来的发展。
在启动语义层项目时，如果缺乏坚实的技术架构和实施计划，许多组织可能会遇到意外投资或失败的风险。如果您想了解其他企业如何实现规模增长，或者有具体问题，请阅读我们的案例研究，或联系我们将竭诚为您服务。
注意： 请确保所有链接均已验证有效！
资讯
