Data as a Service (DaaS) 架构与优势

数据湖以其原生格式保存大量数据。数据工程团队将原始数据清理并丰富为结构化数据，并在整个业务中使用它进行临时分析或由数据科学家用于机器学习目的。此外，这些数据流经不同的下游团队，转换并存储在其自己的基础架构中，并且根据业务需求在其之上构建各种应用程序。

尽管大多数关键性能指标和洞察力在应用程序中是通用的，但下游团队将数据存储在自己的基础架构中，他们必须遵循应用在源头上的同一组业务规则、治理和合规性才能满足所有必需的标准。这可能会导致采购、维护和遵循所有这些流程的额外成本和资源限制。

数据和流程始终在不断发展，任何更改，例如添加新数据资产或修改现有数据资产或更改业务规则，都应在所有团队之间进行沟通和实施。源团队必须确保更改的向后和向前兼容性，因为所有团队可能不会同时实施这些更改。它通常会延迟整个过程，因为我们必须支持旧版本，直到所有团队都坚持新的更改。

数据即服务 (DaaS) 通过利用软件即服务模型提供解决方案，并将数据和见解作为 API 提供。它利用自己的基础设施来处理大量数据，并以低延迟提供洞察力。它从特定软件环境或平台的成本中抽象出数据的使用，并集中数据的质量、安全性、合规性和治理。它提供了统一的方式来访问和控制数据。

让我们来看看数据即服务的好处

一致的业务规则

在组织中，数据管理员将拥有数据资产并负责数据治理并定义业务规则及其访问控制，这些规则适用于使用数据的所有其他团队。

让我们以其他团队使用的销售指标为例，相同的业务规则适用于维护数据一致性。如果销售报告结构发生任何更新，则所有这些团队都必须实施更改，并应始终与源团队保持同步。规则更常变化，它需要额外的努力和时间。

数据即服务将这些业务规则封装在 API 中并提供更好的治理，以便数据在应用程序中保持一致。它还提供有关底层业务规则和功能的详细信息，以根据应用程序要求添加更多规则。

减少数据复制和基础设施成本

大多数团队都执行从大数据系统到关系数据库（如 Azure SQL、MariaDB）的 ETL，以实现低延迟读取。它会导致跨团队的数据有多个副本，并且随着数据量的日益增加，它可能会对性能产生影响。此外，数据必须被索引以允许更快的读取，但它会减慢写入并影响 SLA。维护基础设施的成本是巨大的，如今的业务需求期望以更快的性能处理更多的数据，这通常会导致基础设施的升级，这需要付出努力和时间。

数据即服务减少了跨域的数据重复，并且可以以较低的基础架构成本进行操作。它运行在软件即服务之上，并根据每次使用付费提供数据和见解。随着微服务架构和基于容器的负载的出现，团队可以使用这些 API 并在应用程序中使用它。大多数云供应商还提供运行在 HTTP/2 上的存储 API，可用于临时分析。

加速响应和实时数据

数据即服务利用 Apache druid、clickhouse 等加速层来提供低延迟响应。它还利用分布式 SQL 查询引擎（如 Presto 或云数据仓库）进行临时分析。最终用户可以使用近实时数据，而无需等待在各种存储库中加载和丰富它们。它提供了一种处理大数据的方法，具有更好的性能。

数据资产开发

由于数据即服务集中了治理和合规性，数据管理员可以专注于从数据资产中创造价值并获得有助于业务发展的洞察力。除了维护元数据信息之外，在一处的用户文档通过与消费者的无缝集成提供了对数据的更好理解。它加快了将数据付诸行动的过程。

描述性分析到规范性分析

数据即服务不仅支持低延迟响应或临时分析，而且更灵活地进行规范分析。关键业务决策基于实时预测。欺诈扣除、销售预测、产品供应、产品定价等例子很多，而且都使用 API。现在大多数家庭都在使用虚拟助手、自然语言处理和物联网。数据流入不断增加，数据即服务提供处理数据和更快响应的能力，从而改善客户体验。

云原生

部署在 Microsoft Azure 等公共云上的云原生、容器化工作负载，谷歌云平台提供可靠、可扩展和可维护的 API。云原生应用程序倾向于通过水平扩展和在不需要时释放资源来保持各种负载条件下的性能。它支持构建容错系统，提供软件升级，保持资源的高可用性，提供可靠的灾难管理服务。它配备了用于故障排除和监控的必要工具，例如用于应用程序日志的 Splunk、用于应用程序性能监控的 Dynatrace 等，

移动和网络应用

数据即服务 API 可用于移动和 Web 应用程序，因为它将业务逻辑与表示层分离。由于数据缓存在加速层中，因此在更高负载和各种性能改进（例如仅响应用户请求的指标）时响应会更好，从而减少延迟并使其最适合移动应用程序。用于较小有效载荷的 JSON 格式可以灵活地支持不同的表示格式，并且可以轻松地与使用 D3.js 的库集成，Plotly 来构建仪表板。