应该能够获得最大程度的洞察力，对吗？那么，要做到这一点，您需要完全访问所有相关数据。 分析 分析是将数据转化为见解的过程。有许多用例可以帮助企业做出更好的决策以实现其目标。这些目标通常包括提高客户满意度、增加收入和降低成本。 当 SaaS 提供商将分析嵌入到他们的应用程序中时，他们为用户提供的价值只会增加。毕竟，增强用户体验和客户满意度是留住客户的关键。 但是为什么没有更多的 SaaS 公司使用数据湖？ 为什么这么多人坚持使用极其昂贵的传统数据仓库？ 让我们弄清楚这一点。 什么是数据湖？ 数据湖是所有类型数据的原始、非结构化形式的中央存储。 与传统数据仓库不同，数据湖可以提取、存储和处理结构化、半结构化和非结构化数据。 根据 的说法，“数据仓库以结构化格式存储数据。它是用于分析和商业智能的预处理数据的中央存储库。另一方面，数据湖是原始数据和非结构化数据的中央存储库。您可以先存储数据，然后再处理。” AWS 数据湖的优势 数据湖是主要存储来自操作系统的原始数据的存储库。数据湖将大量数据保存为接近其原始格式。然后，我们以其他系统可以轻松使用的格式对数据进行分类和存储，成本低廉。 AWS 写道，数据湖非常适合以下分析： 机器学习/人工智能训练 数据科学家和分析师 探索性分析 数据发现 流媒体 运营/高级分析 大数据分析 数据分析 数据湖可扩展吗？ 是的。AWS 指出，数据湖“允许您存储任何规模的任何数据”。 数据湖可以处理不同类型的数据类型，例如结构化、半结构化和非结构化。这些通常来自： 数据库 文件 日志 社交媒体 数据湖存储有多灵活？ 治理套件和数据目录提供商 OvalEdge 。“数据湖可以存储来自不同来源的多结构数据。 描述了数据湖的多功能性 数据湖可以存储： 日志 XML 多媒体 传感器数据 二进制 社交数据 聊天 人员数据 OvalEdge 对此进行了扩展，以用于分析。他们表示，要求数据采用特定格式是一种障碍。“Hadoop 数据湖允许您不受模式限制，或者您可以为同一数据定义多个模式。简而言之，它使您能够将模式与数据分离，这对于分析非常有用。 使用数据湖的成本是多少？ 对于嵌入式分析用例来说，数据湖通常比数据仓库更具成本效益。 数据仓库成本（例如 Snowflake）通常会因并发查询而失控。SaaS 平台上的计算需求与内部分析功能不同。 成本也较低，因为： 数据湖的构建工作量较少 延迟极低 可以支持数据分析 由于不需要模式和过滤，存储成本相对于数据仓库来说可以更低。 什么是数据仓库？ 数据仓库是主要存储来自上游系统的经过转换、整理和建模的数据的数据存储。数据仓库使用结构化数据格式。 在我们的博客中，我们讨论了 在多租户分析方面的区别。数据工程师的角色包括将数据湖转变为数据仓库。这个过程类似于游泳的水豚如何适应其环境。然后，小水豚数据科学家就可以进行分析了。 数据工程师和软件工程师 数据仓库的优势 数据仓库针对结构化数据进行了优化 数据仓库使用结构化或关系数据格式来存储数据。 数据仓库还需要更多时间来构建，并且提供对原始数据的较少访问。但是，由于数据需要管理，因此它通常是更安全、更高效的数据分析场所。 正如 ，“数据湖和仓库都可以拥有无限的数据源。但是，数据仓库要求您先设计架构，然后才能保存数据。您只能将结构化数据加载到系统中。” AWS 所说 AWS 对此进行了扩展：“相反，数据湖没有这样的要求。它们可以存储非结构化和半结构化数据，例如 Web 服务器日志、点击流、社交媒体和传感器数据。” 适合单租户/内部分析 仓库中的结构化数据由于查询性能快，可帮助用户快速生成报告。这取决于数据量和计算资源分配。 Databricks ：“数据仓库可以快速轻松地分析从操作系统（如销售点系统、库存管理系统或营销或销售数据库）上传的业务数据。数据可能会经过操作数据存储，并需要进行数据清理以确保数据质量，然后才能在数据仓库中用于报告。” 写道 数据仓库的挑战 它们还没有做好多租户准备 大多数数据仓库存储大量数据，但通常不适用于多租户分析。 如果您使用数据仓库来支持多租户分析，那么正确的方法至关重要。Snowflake 和 Redshift 对于组织和存储数据非常有用。然而，在分析来自多个租户的数据时，它们可能会很困难。 用于多租户分析的数据仓库 。更不用说完全缺乏实现用户权限的语义层。 需要预先进行大量的建模和工程设计，从而导致成本大幅增加 缺乏多租户安全逻辑 保护多租户 SaaS 应用中的数据可能很困难。 尤其是在将图表直接连接到数据仓库时。 数据管理和治理需要定制开发的中间件。它以元表、用户访问控制和协调数据安全的语义层的形式存在。 连接到数据仓库需要构建另一个语义层。此组件将把前端 Web 应用程序的多租户逻辑转换回数据仓库逻辑。不幸的是，这个过程可能特别繁琐。 Snowflake 描述了三种用于设计多租户分析数据仓库的模式。他们 ，“就应用程序可以支持的租户数量而言，多租户表 (MTT) 是最具可扩展性的设计模式。 指出 这种方法支持拥有数百万租户的应用程序。它在 Snowflake 中具有更简单的架构。简单性很重要，因为对象蔓延使得管理无数对象随着时间的推移变得越来越困难。” 昂贵的计算成本 当数据仓库为您的多租户分析提供支持时，持续成本也会很高。 随着多租户平台的出现，每次查询费用的计算成本呈指数增长。 这对于 Snowflake 数据云来说尤其成问题。成本随着使用量的增加而上升是合乎逻辑的，就像公共云基础设施一样。不幸的是， 往往是指数级的，而不是与您的附加值成正比。[试用我们的 ] Snowflake 成本的上涨 Snowflake 成本优化计算器 可扩展性是另一个挑战 您的 SaaS 分析必须几乎立即可供所有人使用。 您不太可能有大量的空闲时间。当您的用户使用您的分析时，他们会获得更多价值。更多的使用应该等于更多的收入和客户保留。 SaaS 供应商 。 必须努力确保数据仓库能够随着租户的增加而顺利扩展 为什么数据湖更适合多租户 SaaS 应用程序中的嵌入式分析？ 从某些方面来看，数据湖是多租户 SaaS 应用中嵌入式分析的最佳选择。 1）多租户数据湖简化了应用程序的扩展 随着用户群的增长，将存储、计算和管理开销整合到共享基础设施中可以显著降低提供商和租户用户的成本。 然而，资源集群的规模正确非常重要。并发需求在 SaaS 租户群中是真实存在的。 数据湖还有利于租户数据隔离。由于租户访问同一个实例，严格的访问控制会阻止查看其他租户的数据。 2）处理多种数据格式 数据类型不断增加。SaaS 平台的产品负责人希望提供更好的分析，但他们的数据仓库常常阻碍他们。 数据湖开辟了分析选项。当使用半结构化数据时，MongoDB 等数据库更容易存储在数据湖中。 通过非结构化数据选项，您甚至可以为客户服务用例提供文本分析。 3）多租户的可扩展性 如果没有大量的开发工作，数据仓库就无法轻易地扩展为多租户。 要通过数据仓库实现多租户，您必须构建额外的基础设施。数据库和面向用户的应用程序之间存在逻辑流程，工程团队必须自行构建。 4）数据隔离和安全 数据仓库在多租户环境中面临行级安全性的难题。 每个数据仓库解决方案都需要额外的努力来确保租户级别的数据分离。这一挑战与用户级别的访问控制相结合。 5）成本优势 数据湖扩展起来更容易，所需的计算量也更少。这是我们 提供支持的重要原因。 使用 Elasticsearch 为多租户数据湖 数据流先驱 Confluent ：“数据湖在成本方面最高效，因为它以原始形式存储，而数据仓库在处理和准备要存储以供分析的数据时会占用更多的存储空间。” 写道 实施数据湖的挑战 1）专业资源 软件工程师不是数据工程师。 如果您正在构建，则需要一名数据工程师来正确扩展数据湖以进行 。扩展软件不同于扩展分析查询。 多租户分析 数据工程涉及创建系统来收集、存储和分析数据，尤其是大规模数据。数据工程师帮助组织收集和管理数据以获得有用的见解。他们还将数据转换为分析和机器学习的格式。 。当然，消除对数据工程师的需求可以降低成本并加快产品上市时间。 Qrvey 消除了对数据工程师的需求 2）与现有系统集成 为了分析来自多个来源的数据，SaaS 提供商必须构建独立的数据管道。 Qrvey 也消除了 这一问题。 数据收集的 使用 Qrvey 的 SaaS 公司不需要数据工程师的帮助来构建和启动分析。否则，团队最终会为每个来源构建单独的数据管道和 ETL 流程。 Qrvey 通过具有统一数据管道的交钥匙数据管理层解决了这一挑战，该管道提供： 单一 API 即可获取任意类型的数据 预建通用数据库和数据仓库的数据连接器 转换规则引擎 针对规模和安全要求进行优化的数据湖，必要时包括多租户 使用数据湖多租户分析的最佳实践 定义清晰的数据策略 任何寻求生成分析的组织都必须有一个数据策略。 是“一项长期计划，它定义了管理组织信息资产所需的技术、流程、人员和规则。” AWS 的定义 这往往比你想象的更具挑战性。 许多组织认为他们的数据是干净的，就像人们认为他们的智能手机是干净的一样。然而，两者都往往充满 ！ 细菌 数据清理是修复数据集内数据的过程。通常出现的问题是数据不正确、损坏、格式不正确或不完整。 合并多个数据源时，重复数据是一个特别令人担忧的问题。如果出现错误标记，问题就更严重了。实时数据的问题就更大了。 数据库可扩展性是另一个常常不乐观的领域。DesignGurus.io ：“水平扩展 SQL 数据库是一项复杂的任务，充满了技术障碍。” 写道 谁想要这个？ 实施数据安全和治理 SaaS 提供商可能会向用户授予控制某些功能访问权限的权限。为了收取附加模块的额外费用，控制访问权限是必要的。 在提供自助分析功能时，您的数据策略必须包括安全控制。 例如，大多数 SaaS 应用程序使用用户层来提供不同的功能。租户“管理员”可以查看所有数据。相反，较低层级的用户只能获得部分访问权限。这种差异意味着所有图表和图表构建器都必须尊重这些层级。 如果您的数据离开云环境，维护数据安全也会变得复杂且具有挑战性。当 BI 供应商要求您将数据发送到他们的云时，这会产生不必要的安全风险。 相比之下，使用 Qrvey 这样的自托管解决方案，您的数据永远不会离开您的云环境。您的分析可以完全在您的环境内运行，继承您已经实施的安全策略。这对于 SaaS 应用程序来说是最佳选择。它不仅使您的解决方案安全，而且安装、开发、测试和部署也更容易、更快捷。 Qrvey 知道分析始于数据 “分析”一词可能会让人联想到整齐地显示各种图表的彩色仪表板。 这就是最终的结果， 但一切都从数据开始。 因为我们知道分析始于数据，所以 Qrvey 专注于数据湖的使用。 我们专门为 SaaS 公司构建了一个嵌入式分析平台，用于多租户分析。目标是帮助软件产品团队在更短的时间内提供更好的分析，同时节省资金。 但它始于数据。 Qrvey 提供灵活的数据集成选项以满足各种需求。它既可以实时连接到现有数据库，也可以将数据导入其内置数据湖。 这种云数据湖方法可优化复杂分析查询的性能和成本效益。此外，系统会在提取过程中自动规范化数据，以便为多租户分析和报告做好准备。 Qrvey 支持与常见数据库和数据仓库的连接，如 Redshift、Snowflake、MongoDB、Postgres 等。 我们还提供用于实时数据推送的采集 API。它支持 和半结构化数据（如 。 JSON FHIR 数据） 此外，还可以从 S3 存储桶等云存储以及文档、文本和图像等非结构化数据中提取数据。 Qrvey 内置了数据转换功能，无需单独的 ETL 服务。有了 Qrvey，就不再需要专门的数据工程师了。 让我们向您展示我们如何帮助您在构建更少软件的同时为客户提供更多价值。
