来源：数据驱动智能|作者：晓晓
本文经授权转载
作为一名数据专业人士，我目睹了过去15年数据利用和处理的发展。在此期间，出现了几个强大的概念和创新的数据架构，每个都有望解决现代数据管理日益复杂的问题。在这篇文章中，我们将批判性地审视最突出的趋势，探索它们的优势、劣势以及对数据架构未来的实际影响。
一
概述
数据格局已从一个小众焦点演变为现代企业运营的核心支柱。让我们花点时间反思一下这一演变。
企业数据：2010年，我曾使用一个1.5PB的数据仓库，当时，这个规模在大型科技公司之外还很罕见。时至今日，管理数十甚至数百PB的数据已成为大型企业的常态。Snowflake和Databricks等公司现在经常处理EB级的客户数据。我们看到了从面向批处理的数据到实时数据流的根本性转变，驱动力来自物联网设备和交易系统等各种来源。此外，数据的多样性呈爆炸式增长，要求我们处理从结构化表格数据到音频和视频等非结构化格式的所有内容。
存储：当时，存储速度慢且价格昂贵，通常仅限于通过SAN连接到EMC、HP或富士通等供应商的数据设备的大型数据库服务器。采购额外容量可能需要数月时间。如今，SSD已成为一种商品，几乎任何人都可以以极低的成本获得可扩展的按需对象存储。
网络：网络功能也有限；大多数后台网络都采用1G以太网，而10G和Infiniband则由于成本高昂而仅用于高性能集群。相比之下，当今的云基础设施通常采用40G和100G网络，从而大幅提高数据吞吐量和延迟。
计算：当时，SUN、富士通和惠普等供应商的大型SMP服务器主导着数据处理，集群计算仍处于起步阶段。海量数据仓库依赖于昂贵的MPP设备，例如Netezza、Vertica或Greenplum。然而，这种情况已不复存在，因为分布式计算的进步使可扩展、高性能计算资源的访问变得普遍化。
尽管取得了巨大的技术进步，但许多企业仍然面临着持续了十多年的挑战，只是现在规模更大了：
最高效、最可靠地向客户提供可信数据。整合来自不同来源的数据（在处理内部系统时已经是一项复杂的任务）在整合通过并购获得的系统时变得更加困难。有效地管理数据仍然是一个难以实现的目标，传统的数据治理模型往往被证明是不切实际的，并且在许多情况下成为瓶颈而不是推动因素。数据架构是指导正确构建复杂数据处理系统的学科。它曾经是一项相对简单的任务（通常涉及ETL工具和数据仓库的组合，并在Inmon或Kimball模型之间进行选择），但现在变得越来越复杂。那么，在当今复杂的环境中，我们可以依靠哪些框架和实践来指导我们？让我们探索最受欢迎的一个：
数据湖数据虚拟化现代数据仓库数据编织数据平台数据湖屋数据网格二
数据湖
“数据湖”一词由时任Pentaho首席技术官的JamesDixon于2011年提出。数据湖为来自各种来源的所有数据提供统一的存储库，使组织内任何人都可能需要分析这些数据，从而实现大规模分析。您可以将数据湖视为一个高度通用的文件系统，尽管它更像是一种设计模式，而不是数据架构。随着Apache Hadoop分布式文件系统(HDFS)等经济实惠且可扩展的存储解决方案的出现，这种模式越来越受欢迎。如今，更现代的实现将数据存储在基于云的分布式对象存储中，例如AmazonS3或AzureDataLakeStorage(ADLS)Gen2，构成了大多数大型数据平台的骨干。
集中存储的演变
虽然集中存储并非新鲜事物，但数据湖的关键创新在于将存储与计算分离开来。从历史上看，由于传统数据仓库的容量有限，公司会将大量数据以平面文件的形式卸载到EMCIsilon等网络附加存储(NAS)解决方案中。然而，分析这些数据需要先将其加载到关系数据库中。
相比之下，Hadoop从一开始就被设计用于直接从对象存储中处理大规模数据。最初，这是使用map-reduce框架完成的，后来，它通过更高级的工具（如Spark框架）和SQL引擎（如Hive和Presto）完成。虽然数据湖主要被视为一种存储解决方案，但人们总是隐含地认为，各种各样的工具都可以本地访问和处理其中的数据。
数据湖中的逻辑分区
数据湖中的数据通常被组织成几个逻辑区域或层，这种方法最近以“medallion”或“multi-hop”架构的形式流行起来。数据湖中的每个区域都旨在将具有相似生命周期、访问模式、质量和安全要求的数据分组。这些区域提供逻辑隔离，允许它们独立开发、实施和扩展。通过建立清晰、合乎逻辑的边界，区域促进了数据架构的长期发展，并且与供应商和产品无关。虽然可以根据特定需求定制区域，但它们通常被安排为在数据通过每一层时逐步改善数据的结构和质量。
最常见的区域包括：
登陆数据区：上游系统和原始数据区之间的可选中介，该区域有助于数据提取，同时保持数据完整性并限制业务用户的访问和转换。原始数据区：此区域专注于高效地提取数据而无需转换，以原始格式保存数据。它维护数据的多个版本，并限制业务用户访问以防止意外覆盖。合规（精选）数据区：原始数据在此区域转换为可信数据集，通常会删除或屏蔽敏感信息。它托管基础数据产品、自动执行转换、将数据保留在靠近其来源的位置、避免特定于业务的转换，并实施严格的数据保留策略。转换/服务数据区：此区域包含经过特定领域转换的业务和分析数据产品。数据使用业务语义进行组织，存储在优化的模型中，并根据不同的分析需求进行隔离。为了提高性能、访问控制和适应性，业务和分析数据产品区域可以物理或逻辑分离。
数据湖的优势
成本效率。与传统数据仓库相比，数据湖可节省大量成本，这主要是由于基于云的存储解决方案具有灵活性和可扩展性。弹性。现代云平台提供几乎无限的按需存储，无需进行广泛的容量规划和采购流程。这种弹性使组织能够轻松扩展其数据操作。模式灵活性。传统数据仓库通常会针对所有分析需求强加单一的规范模式，这对于除最小组织之外的任何组织来说都是不切实际的。相比之下，数据湖允许以源提供的任何形式存储原始数据，而无需对模式做出任何假设。数据消费者可以根据其特定用例来解释和构建数据。数据质量管理。确保传统数据仓库中的数据质量需要进行大量分析才能创建单一权威来源，这既不切实际，也不可取。湖中原始数据的不可变性，加上其持续可用性，使得数据湖可以轻松地进行重新处理，以纠正处理管道中的错误或支持新兴需求。挑战和注意事项
数据来源。数据湖中的每一块数据都必须有明确的来源，包括对源系统的可追溯性和数据创建时间。这对于维护数据完整性和促进审计至关重要。选择性原始数据访问。尽管原始数据很有价值，但应谨慎访问。数据运营团队可以在识别有价值的数据视图时创建数据集市，从而允许下游用户将这些数据集市视为特定上下文的权威来源。敏捷性约束。管理单一数据湖的集中式数据团队可能会限制组织敏捷性。将数据架构划分为不同的管道（提取、处理和服务）需要复杂的协调才能提供新的数据源或有效解决新的用例。数据是资产，而非产品。数据湖中的数据通常被视为资产而非产品，这通常导致缺乏正式的服务水平协议(SLA)或服务水平目标(SLO)。这可能导致确保数据的可靠性和可追溯性面临挑战。运营挑战。管道可观察性、事件管理和作业编排等跨职能能力通常不会作为核心组件集成到数据湖生态系统中。使用不同的技术可能会使创建一个具有凝聚力和运营稳健的数据湖系统变得具有挑战性，从而导致潜在的脆弱性。三
数据虚拟化/联合
数据虚拟化或联合创建了一个逻辑数据层，使应用程序能够检索和操作数据，而无需详细了解底层系统。它通常作为特定的虚拟化服务器实现。这种方法允许直接从源实时访问数据，无需移动或复制数据。这降低了出错的风险，并减少了管理未使用数据的工作量。重要的是，数据虚拟化不会强加单一的数据模型，而是管理统一的数据以确保集中的安全和治理。
数据虚拟化软件的功能
抽象：数据虚拟化抽象了从各种底层系统访问数据所涉及的复杂性。这包括抽象位置、存储结构、API、访问语言和存储技术等细节，使应用程序更容易与数据交互。虚拟化数据访问：此功能允许连接到各种数据源，包括数据库、数据仓库、云应用程序、大数据存储库甚至Excel文件，从而可以从公共逻辑访问点访问它们。转换和数据联合：数据虚拟化可以转换、重新格式化、提高数据质量、聚合信息并将相关数据组合成业务视图，无论其格式或来源如何。此功能对于为用户提供有意义的统一数据视图至关重要。实时数据传输：由于数据虚拟化实时连接到底层数据源，因此它向业务用户提供最新信息。这种实时访问是通过视图和数据服务提供的，由客户端应用程序或用户按需执行。数据虚拟化的好处
源系统保护。通过隔离关键源系统以防止用户和应用程序直接访问，数据虚拟化有助于防止意外的数据修改。实时数据访问。数据虚拟化无需额外的存储投资即可提高实时数据访问速度，从而使组织能够更有效地利用现有数据基础设施。优化查询处理。数据虚拟化允许将查询处理下推到数据源，而不是在中间层进行处理。这可以提高查询执行效率并减少虚拟化层的负载。自助数据访问。许多数据虚拟化系统允许最终用户通过自助服务创建虚拟数据库，无需大量IT参与即可直接访问源系统。集中治理和安全。数据虚拟化允许架构师在所有数据源上实施集中数据治理和安全策略，确保合规性并降低数据泄露的风险。开发资源效率。数据虚拟化的基于视图的方法简化了开发并减少了手动编码的需要，使开发人员可以专注于扩展和加快信息传递速度。数据虚拟化的挑战和缺点
对操作系统的影响。数据虚拟化可能会对操作系统的响应时间产生负面影响，特别是当虚拟化层没有充分扩展以处理意外的用户查询时。缺乏历史数据管理。数据虚拟化不适合记录历史快照，限制了其在关键历史数据分析场景中的实用性。变更管理的复杂性。共享同一虚拟化服务器的所有应用程序和用户都必须接受数据虚拟化层内所做的变更，这使变更管理变得复杂。与复杂分析查询不兼容。分析应用程序通常需要复杂的连接、表扫描和数据混排，这些通常与数据虚拟化支持的访问模式不兼容。特别是跨系统连接，很难有效执行。系统很难确定其执行计划的成本。让查询联合层准确预测不同底层系统中查询计划的成本几乎是不可能的。资源争用。具有不同执行配置文件的用户查询将争夺虚拟化服务器的有限资源，从而可能导致性能冲突和瓶颈。细粒度安全。对大量传输中的数据实施细粒度安全控制可能耗费大量资源。在许多情况下，数据分段的安全分区是一种更实用的方法，因为它可以缩小潜在的攻击面。计算与存储成本。尽管存储不再是一个重要问题，但计算仍然需要资源。在许多情况下，实现某些转换（预处理和存储数据）比每次即时执行它们的成本更低。高可用性问题。从高可用性角度来看，数据虚拟化代表单点故障，这对于严重依赖虚拟化数据持续访问的组织来说可能是一个重大风险。四
现代数据仓库
几十年来，传统数据仓库一直是业务分析的支柱，提供可靠的结构化数据管理。然而，它们往往面临成本、可扩展性和灵活性方面的挑战。数据湖的出现解决了其中一些限制，为各种数据类型提供了灵活且可扩展的存储解决方案。通过将关系数据仓库的业务价值和性能与数据湖的灵活性相结合，组织可以在现代数据架构中充分利用这两种技术的优势。
数据湖与数据仓库的集成
在这种现代架构中，数据湖有效地取代了数据仓库的传统暂存区以及经典的ETL流程。数据湖充当数据提取的中央枢纽，处理大规模数据转换，包括数据协调和数据产品的物化。然后，面向业务的数据集被发布到关系数据仓库中，通常以维度模型构建，以支持报告和商业智能(BI)功能。同时，数据湖可用于机器学习(ML)模型训练并支持高级分析。
虽然任何关系数据库都可以托管维度数据（PostgreSQL通常用于此目的），但现代关系数据仓库解决方案（例如Snowflake、Databricks、AzureSynapseAnalytics、GoogleBigQuery和AmazonRedshift）具有明显的优势。这些平台将存储与计算分离开来，提供与对象存储的有效集成，并在大数据量上提供卓越的性能。
现代数据仓库架构的好处
数据处理的多功能性：该架构可以有效地管理各种数据格式，包括结构化、非结构化和流数据。增强的报告和BI性能：现代数据仓库提供比数据湖中常见的SQL引擎更好的查询性能，并能与标准报告和BI工具更好地集成。弹性可扩展性：将存储和计算分离可实现弹性可扩展性，使架构能够无缝处理不断增长的数据量。实时分析：该架构支持实时数据分析，使企业能够根据最新的可用数据及时做出决策。改进的数据管道性能：现代数据管道和云原生ETL工具的性能明显优于传统ETL流程。灵活的数据建模：该架构支持灵活的数据建模，包括读取模式和模式演变，使组织能够适应不断变化的数据需求。成本效益：通过在数据湖中执行数据转换，组织可以降低与数据处理相关的成本。增强的数据安全性：该架构允许通过标准的基于角色的访问控制(RBAC)机制更好地控制数据安全。现代数据仓库架构的潜在缺点
复杂性增加：此架构的混合性质带来了额外的复杂性，需要协调多种技术。充分发挥此架构的潜力需要一套专业且多样化的技能，这可能导致招聘挑战、培训需求增加和维护成本增加。数据复制和管理：尽管存储成本相对较低，但跨数据湖和关系数据仓库管理数据可能具有挑战性。这种架构通常需要一定程度的数据复制，这可能会使数据治理和同步工作变得复杂。合规性挑战：系统的整体复杂性可能会带来合规性挑战，尤其是在需要PCIDSS或HIPAA等标准认证的环境中。确保架构的所有组件都符合监管要求可能很困难。五
数据编织
Gartner将数据编织定义为一种设计概念，它充当数据和连接流程的集成层（结构）。数据编织使用对现有、可发现和推断的元数据资产的持续分析来支持跨所有环境（包括混合和多云平台）的集成和可重用数据的设计、部署和利用。
数据编织的五大关键支柱
增强数据目录：数据结构必须收集和分析所有形式的元数据，利用AI/ML自动化来增强和维护全面的数据目录。富含语义的知识图谱：数据结构应创建和管理知识图谱，通过AI/ML算法实现对连接元数据的高级分析。这些知识图谱提供了对数据关系的语义理解，增强了数据的实用性和可访问性。元数据激活和推荐引擎：AI/ML辅助流程将被动元数据转换为主动元数据。然后利用这些主动元数据来推荐操作、优化数据使用并增强决策过程。数据准备和交付：强大的、由AI驱动的数据集成主干对于数据结构至关重要。该主干可确保高效地准备、清理和交付数据，从而支持实时分析和运营应用程序。编排和DataOps：数据结构必须在AI/ML的帮助下实现数据编排的自动化，简化数据操作（DataOps），并确保跨各种平台和环境的无缝数据流。数据结构与平台无关，这意味着它可以跨不同的部署平台、数据处理方法、数据交付方法、位置和架构样式运行。它抽象了管理不同数据环境的复杂性，促进了数据作为战略资产的使用。通过这样做，数据结构确保任何数据（无论其来源或平台如何）都可以有效地组合、访问、共享和管理。
实施数据编织的好处
增强的数据集成和连接：数据结构集成并连接组织的所有数据，实现无缝数据共享，并通过更明智的决策改善业务成果。加速自助数据发现：通过使可信数据易于访问，数据结构可以加速自助数据发现和分析，使数据消费者能够更快地获取见解。实时分析和洞察：使用数据结构优化数据生命周期有助于实现实时分析和洞察，从而实现更具响应能力和数据驱动的应用程序开发。降低数据管理成本：数据结构中的智能自动化减少了与数据管理任务相关的成本和工作量，例如数据质量改进、数据管理、数据分类和策略实施。自动编排和扩展：数据结构可自动执行工作负载编排、弹性扩展、自我调整和自我修复，确保作业已准备好处理任何环境和数据量。丰富的数据资产：数据结构自动链接发现的数据资产并用知识和语义丰富它们，帮助消费者更有效地查找、理解和使用数据。挑战和注意事项
技术成熟度：全面实现Gartner数据结构愿景所需的大部分技术仍处于起步阶段或尚未开发，这可能会限制全面数据结构解决方案的立即实施。元数据质量：数据结构的有效性在很大程度上取决于所收集元数据的质量。虽然在封闭系统内收集元数据相对简单，但集成来自不同供应商的不兼容系统的元数据可能极具挑战性。僵化的元数据模型：供应商提供的系统通常使用僵化的元数据模型，这些模型可能不够灵活，无法满足所有客户用例。解决这些限制可能需要昂贵的系统定制，在某些情况下，可能根本无法实现。监管限制：在监管严格的环境中，由于人工管理和监督要求，基于机器学习的推理可能不可接受。这可能会限制数据结构中采用人工智能/机器学习驱动的组件。知识获取的复杂性：构建和维护有用的知识图谱本质上很复杂，通常需要专业知识。在许多情况下，此过程无法完全自动化，需要大量人工干预和专业知识。六
数据中心/数据平台
数据中心或数据平台专注于集成数据并支持大规模高级分析。它提供了一套集成良好的领域无关服务，用于处理数据提取、集成、转换、管理和交付。主要目标是使组织能够高效地设计、开发、操作、管理、发布和使用能够带来商业价值的数据产品。该平台专为模块化、灵活性和成本效益而构建。然而，考虑到数据类型的多样性和特定的业务需求，构建一个一刀切的数据平台既具有挑战性，又成本高昂。相反，数据平台应该被视为一个概念蓝图，根据组织的要求，通过基于云的组件或本地服务实现。
现代数据平台的关键原则
数据即产品思维：摆脱孤立系统和单片数据湖，将数据视为产品。每个数据产品都是使用数据平台提供的与领域无关的功能开发的，与特定数据领域保持一致，并且必须遵守FAIR（可查找、可访问、可互操作和可重用）原则。这些数据产品还应发布SLA/SLO，并致力于“水平”端到端数据管理。以领域为中心的数据治理：从集中式转向联合式、以领域为中心的数据治理。这种方法利用环境可观察性等平台功能来促进利益相关者之间的沟通，并确保治理实践符合每个数据领域的特定需求。自助服务和通用服务：平台应提供自助服务功能和与领域无关的通用服务，如探索环境、数据资产目录、数据质量框架、流程编排、事件处理、本体和通用词汇管理、审计和监控、数据保护、通用数据处理框架以及对数据和开发操作的支持。渐进式开发：逐步构建平台，根据战略管理原则不断验证不断发展的架构。这种方法使平台能够有机发展，同时确保与长期目标保持一致。数据平台的核心模块
无论部署模型如何，每个数据平台都由五个关键的、松散耦合的模块组成：
存储：提供存储原始数据、处理数据和分析数据的基础架构，支持各种数据格式并确保可扩展性。典型的实现是使用数据湖作为存储层。但严格来说，这不是必需的。关系数据库或NoSQL数据库也可以用作存储。数据提取：处理来自各种来源的数据提取，确保及时可靠地捕获数据。数据转换：促进数据的清理、处理和丰富，为分析工具和应用程序的使用做好准备。数据服务：确保以高效、可访问的方式向用户和应用程序提供处理后的数据，通常通过API、仪表板或其他界面。通用补充服务：支持平台的整体运行，包括网络、计算以及安全、监控和治理等附加服务。功能齐全的数据平台的基本功能
开发框架：提供可重复使用的组件，抽象常用功能并与其他平台服务集成。这些框架应包括DevOps管道的标准模板，减少样板代码，简化新团队成员的入职流程，并简化数据提取和转换管道的开发。数据目录：管理技术和业务元数据，确保所有数据工件（原始数据、派生数据和数据产品）都在此目录中注册。目录应包括数据格式、模式、谱系、来源、敏感度分类、版本控制、SLA/SLO、质量属性、统计数据、分类法、保留、存档要求和所有权的详细描述。它还应支持数据产品发现和采样。事件处理和通知子系统：为异步、事件驱动的数据处理提供基础，实现环境可观察性、复杂事件处理、基于事件的调度和系统范围的通知分发。流程编排：支持复杂的流水线调度、作业依赖性跟踪、工作流设计、故障管理和作业重试，确保数据流程顺畅高效地运行。探索性环境：为数据科学家、数据工程师和数据运营团队提供自助服务环境，支持数据整理、发现、数据产品原型设计、ML模型训练和验证。审计和监控：实施统一的监控系统，提供实时平台健康检查、警报生成、操作仪表板、法规遵从性的访问审计、事后日志分析和活动跟踪。数据保护：与身份和访问管理(IAM)系统集成，保护数据免遭未经授权的访问。这包括管理一致的安全策略、数据标记化、加密和标记。数据质量和治理：提供数据质量分析、分析和政策合规性扫描的框架。系统应生成与质量相关的警报、支持治理工作流程并确保数据保持可靠和可信。本体和参考数据管理：实现跨领域数据标准化和协调，管理企业范围内的参考数据、本体和分类法。该平台应促进声明性属性验证、上下文和概念映射，并提供推理引擎和规则解析。构建综合数据平台的挑战
复杂性：在管理来自不同供应商的众多服务的同时，集成和适应特定业务流程的复杂性可能非常复杂。然而，迈向最先进平台的旅程并不需要从最先进的工具和系统开始。采用渐进式增长战略，明确关注最终目标，对于构建强大而高效的平台至关重要。成本：构建复杂的数据平台通常需要大量投资，通常高达数百万美元。只有当平台需要支持大规模运营时，这种前期投资才是合理的。确定具有最大潜在影响的领域并不断根据投资回报率(ROI)考虑因素调整决策至关重要。由于组织目标可能会随着时间的推移而发生变化，因此将平台开发锚定在进化架构和关注点分离等基本原则上至关重要。人员和变革管理：从传统的孤立IT运营过渡到与领域无关的服务和面向数据产品的方法可能非常艰巨。将组织变革管理周到地融入平台的增长轨迹是必不可少的。监控平台的采用情况并确保其在组织内得到有效利用也至关重要。与用户建立持续的反馈循环将确保平台根据他们的需求和期望发展。即使是最先进的平台，如果使用不当也会失败。优先考虑用户体验并提供全面的培训对于弥合差距至关重要。此外，数据平台格局正在迅速发展，新工具、框架和最佳实践不断涌现。保持平台最新并在不中断现有运营的情况下融入创新是一项挑战。七
数据湖屋
Data Lakehouse概念由Databricks团队提出，并由BillInmon在其著作《构建DataLakehouse》中进一步推广。如今，该理念已被数据管理领域的主要参与者广泛采用，包括微软、亚马逊、Dremio、Starburst等。DataLakehouse架构将数据湖的可扩展性和成本效益与传统上与数据仓库相关的分析基础设施相结合。这种混合方法允许更有效地读取、处理和理解数据，同时利用数据湖中通常使用的低成本存储解决方案。
数据湖屋的指导原则：
利用现有的数据湖基础设施：尽可能利用现有的数据湖基础设施，将数据存储在低成本存储选项上，例如AmazonS3、AzureBlobStorage或GoogleCloudStorage。数据应以CSV、Parquet和ORC等开放格式存储，以确保兼容性和灵活性。使用ACID事务确保数据一致性：使用DeltaLake或ApacheIceberg等技术通过ACID（原子性、一致性、隔离性、持久性）事务维护数据一致性，通常使用SQL进行管理。支持模式实施和演变：数据湖应该支持模式实施和演变，从而能够使用星型和雪花型模式等数据仓库模式架构。实施治理和审计机制：添加治理和审计功能，包括细粒度的基于角色的访问控制。确保可以通过各种API（Scala、Java、Python、SQL）执行数据操作，以遵守GDPR和CCPA等法规。将存储与计算分离：架构应允许存储和计算资源独立扩展，以容纳更多并发用户和更大的数据集，而不会降低性能。提供对数据的直接访问：为商业智能(BI)工具提供对原始、精选和汇总数据的直接访问。这可减少数据陈旧性、提高新鲜度、降低延迟，并最大限度地降低在湖和仓库中维护单独数据副本的成本。支持非SQL数据处理API：包括高效的非SQL声明性API，例如类似DataFrame的API，以允许数据科学家直接访问和处理大量数据，特别是对于使用R和Python库的机器学习实验。拥抱开放数据格式和API：支持开放数据格式和API，无需依赖专有引擎即可直接访问数据，从而避免供应商锁定并确保长期灵活性。实现数据流和在线分析：整合数据流和在线分析支持，无需单独的系统来处理实时数据应用程序。数据湖屋的挑战和局限性
DataLakehouse概念看起来更像是一种务实的努力，旨在规范现有的现状，而不是由连贯的问题分析支持的架构。由于它不是一个突破性的概念，因此采用的门槛很低，几乎所有供应商都声称要实现它。虽然这一概念已经获得了广泛的关注，但它也存在一些局限性，可能会阻碍其有效性：
以技术为中心：DataLakehouse方法主要侧重于技术解决方案，往往忽视人员和流程在数据管理中的重要性。有效的数据平台需要一种将技术与组织实践和文化相结合的整体方法。对数据孤岛和业务协调关注有限：虽然DataLakehouse强调数据可发现性，但它往往忽视打破数据孤岛和将数据资产与业务目标协调起来的挑战。它也没有充分关注数据生命周期、SLA（服务水平协议）和SLO（服务水平目标）。集中治理与敏捷性：DataLakehouse固有的集中治理和模式实施可能会阻碍组织敏捷性。随着业务的发展，快速适应至关重要，而僵化的治理结构可能会成为瓶颈。数据集成挑战解决不足：尽管DataLakehouse提供了大规模数据转换的技术能力，但它并没有完全解决数据集成的关键挑战，例如管理数据复杂性、元数据和上下文映射规则。这些是创建真正集成且可操作的数据平台的必要组件。八
数据网格
数据网格是数据管理中一个相对较新的概念，作为一种社会技术方法引入，用于在组织内部和跨组织环境中共享、访问和管理复杂、大规模的分析数据。据Gartner称，数据网格目前正处于预期膨胀的顶峰，突显了人们对其日益增长的兴趣和关注。值得注意的是，数据网格不是传统意义上的数据架构，而是组织处理数据所有权、管理和治理方式的范式转变。
数据网格带来的根本性转变
组织转变：数据网格提倡从传统上由专门团队管理的集中式数据所有权转变为分散式模型，在这种模型中，数据所有权和责任被推回到数据来源或最活跃使用的业务领域。架构转变：DataMesh不依赖单片数据仓库或数据湖，而是提出了一种分布式系统，通过标准化协议连接和访问数据。这种方法支持更具可扩展性和灵活性的数据架构。技术转变：在数据网格中，数据被视为一等公民，而不仅仅是运行管道代码的副产品。数据和维护数据的代码被视为可以独立发展的自主、活跃的单元。运营转变：数据治理从自上而下、大量人工干预的集中式模式转变为联合式模式。在此模式中，治理策略以计算方式嵌入到网格节点中，从而实现更加动态和可扩展的治理实践。价值体系转变：对数据的根本看法是从将数据视为需要收集的静态资产转变为将数据视为旨在服务和取悦用户的产品。数据网格的核心设计原则
面向领域的去中心化数据所有权：分析数据的所有权被分散到业务领域，让最接近数据的人来管理和共享数据。这一原则与领域驱动设计(DDD)相一致，并强调了领域专业知识在数据管理中的重要性。数据即产品：数据网格要求业务领域将其数据视为产品，抽象底层复杂性并确保其可发现、可理解、可寻址、可信赖、安全、可互操作、可访问和有价值。自助数据基础设施：该架构促进了自助数据基础设施，允许面向领域的团队管理整个数据生命周期，从获取到民主化，而无需过度依赖集中式IT团队。联合计算治理：数据网格中的治理是联合的，每个数据域团队负责其本地数据产品，同时遵守总体治理政策。这种方法可确保整个组织的数据可发现、安全、可信且可重复使用。
数据网格的好处
定制数据产品：数据网格能够提供满足特定业务需求的定制数据产品，将战略业务目标与动态的数据产品生态系统联系起来。通过去中心化实现可扩展性：通过去中心化所有权和利用特定领域的专业知识，DataMesh可以扩展数据产品的交付，并促进向数据产品思维的文化转变。提高敏捷性：通过分解单一的集中式架构并抽象复杂性，数据网格增强了组织敏捷性，从而能够更快地响应业务需求。灵活的治理模式：联合治理模式允许组织根据其独特需求定制治理实践，在地方自治和集中监督之间取得平衡。实现数据网格的挑战和注意事项
自2019年推出以来，数据网格就备受关注。从表面上看，数据网格解决了许多现有问题，并可以提供一些基本好处。然而，它仍然是一个相对较新的概念，尚未在现有市场产品中完全实现。到目前为止，它的市场渗透率为5%到20%，Gartner预测，在2023年炒作周期中，它将在达到生产力平台期之前过时。在实施数据网格之前，需要考虑一些因素。
人与文化的转变：
责任增加：DataMesh赋予领域团队重大责任，要求他们除了现有角色外，还拥有和管理数据产品。这可能会带来额外的负担，因此建立激励和支持结构对于确保成功采用至关重要。技能差距：领域团队可能缺乏有效设计和管理数据产品的专业知识。数据建模、生命周期管理、API创建、SLA/SLO和依赖管理方面的技能必不可少，但可能很少。需要进行适当的培训和角色调整来填补这些差距。分散的团队动态：优化跨职能团队（包括数据科学家、工程师和DevOps）的组成可能具有挑战性。将资源专门分配给领域团队可能成本高昂且效率低下，尤其是对于需求波动的领域。文化契合度：组织文化在决定去中心化决策的成功方面起着至关重要的作用。抵制变革或缺乏对基于域的自治的支持可能会阻碍数据网格的采用。流程和组织结构：
域边界和所有权：定义适当的域边界和所有权级别是实施数据网格最具挑战性的方面之一。该过程通常需要重新评估并可能重组组织，以使运营和分析功能与域所有权保持一致。治理与协作：所有利益相关者必须明确定义并接受治理模式、工作流程和KPI。联合治理模式对许多组织来说都是新事物，需要重新构想现有的结构和流程。必须改善领域之间的协作，以确保无缝集成和政策实施。变更管理：实施数据网格通常需要进行重大的组织变革。完善的变更管理流程对于指导过渡、缓解阻力和确保项目成功至关重要。技术和基础设施：
自助服务基础设施：在域级别构建自助服务数据基础设施需要复杂的数据平台功能，例如联合治理、数据沿袭、互操作性和云原生部署。这些功能仍在涌现，可能需要复杂的定制开发和较高的运营成熟度。遗留系统集成：将遗留操作系统集成到领域驱动设计中可能具有挑战性。过渡通常耗时且成本高昂，尤其是对于拥有大量遗留投资的组织而言。可计算策略的实现：数据网格依靠可计算策略进行数据发现和集成。然而，当前的工具并不完全支持这些功能，而且没有标准化的策略元数据编码和操作语义方法。开发用于上下文映射和域组合的复杂本体驱动系统是必要的，但这仍然是一个正在进行的研究领域。成本和复杂性：开发和维护数据网格架构可能成本高昂且复杂，尤其是在具有多样化和分布式数据需求的大型组织中。组织在走上这条道路之前必须仔细评估潜在的成本和收益。九
小结
1970年，埃德加·F·科德(EdgarF.Codd)发明了关系代数，这一概念有着坚实的理论基础，彻底改变了数据管理领域。这一突破推动了关系数据库的发展和SQL的出现，50多年来，SQL一直是数据处理的主导语言。
CJDate和HughDarwen等专家多年来一直认为，关系数据库理论上可以处理各种数据负载。然而，现有的关系数据库存在特定的缺点，而数据仓库方法可以有效解决这些缺点。数据仓库方法提供了一种实用的解决方案，即使它缺乏强大的理论基础，但至今仍然适用。
相比之下，现代数据架构（例如数据湖、数据中心和数据结构）通常缺乏统一的理论框架，无法有效应对当今一些最复杂的数据挑战。关于这些架构之间区别的讨论可能会变得过于学术化，让人想起中世纪关于抽象概念的辩论，例如针尖上能站多少个天使。这种情况凸显了对基本架构原则的需求，这些原则可以清楚地区分一种架构与另一种架构。尽管这些现代架构提供了有价值的工具，但仍然需要更激进、更基础的东西。
在我们等待数据架构的下一个重大突破时，在可预见的未来，一些指导原则可能会在所有数据架构中保持相关性和适用性：
存储与计算分离：在传统系统中，存储与执行引擎紧密耦合以优化性能。然而，这种模式从根本上限制了可扩展性。正如数据湖架构所见，存储与计算的分离将继续主导分析数据处理。像Snowflake和AWSAurora这样的关系系统已经采用了这种解耦，依靠可扩展的对象存储来实现灵活性和可扩展性。数据重复：从历史上看，由于存储成本高昂，数据处理工作侧重于优化数据布局和尽量减少数据重复。如今，存储成本低廉，允许组织无限期地保留原始数据并根据需要重新处理。保留多份数据副本（尤其是按不同的排序顺序）可以提高处理效率。然而，虽然存储成本已经降低，但数据管理仍然复杂且成本高昂。必须小心维护和保持这些额外副本同步。数据治理：数据治理实践，包括数据沿袭和出处、数据质量、数据保留和生命周期管理以及安全策略，必须作为任何成熟数据平台的首要任务实现自动化和集成。传统上，这些方面被视为事后考虑，阻碍了数据系统的灵活性和稳健性。强调数据治理对于维护现代数据平台的完整性和可靠性至关重要。数据作为产品：将数据视为产品可以实现访问民主化、提高质量并扩展数据管理实践。这种方法在大规模数据操作中特别有用，尽管对于较小规模的环境可能不太实用。然而，采用产品思维进行数据管理可以显著改善整个组织处理和利用数据的方式。基于人工智能的服务前景：尽管人工智能服务尚处于起步阶段，但它在简化和自动化数据分类、数据集成和高级数据分析等复杂任务方面具有巨大潜力。这些服务可以在解决当前数据架构面临的一些挑战方面发挥关键作用，提供管理和分析大规模数据的新方法。总而言之，虽然现代数据架构尚未充分发挥其潜力，但上述指导原则为构建和管理有效的数据系统提供了坚实的基础。随着技术的不断发展，这些原则将帮助组织应对数据管理的复杂性，并为该领域的下一波创新做好准备。
转自公众号：CIO俱乐部
