达芬奇

达芬奇 - 基于"Serverless"的数据查询API框架

• 此文背景
• 我们要解决什么样的问题?
• 系统要求
• 系统设计
• • 访问控制列表及其使用
  • 过滤器以及其语法
  • Serverless 和 API Gateway
  • • Serverless 无服务器计算
    • API Gateway 云网关
  • Lambda 执行步骤
  • REP（报表接口组件）管理

此文背景

目前，诸多企业拥有各种软件业务系统，随即产生了大量的生产数据，但是这些数据却“散落”在不同的“地方”。如何将这些数据进行统一的管理，或者进行快速地查询以便深度挖掘数据的潜力是很多开发者面临的问题。因此，根据我们在数据平台工作的一些经验，提出一个基于”云原生“的构建数据查询API的框架，来解决一些这样的问题。

我们要解决什么样的问题?

1. 数据平台作为信息处理者，需要快速，有效地向用户提供相关的最新信息。
2. 但是，此信息存储在许多不同的数据存储库中。今天，我们的数据存储在Redshift和Snowflake等数据仓库，S3中的数据湖，NoSQL数据库以及我们的内部会计和ERP系统中，例如Salesforce和Intacct。我们还需要通过调用合作伙伴的外部API来访问数据。
3. 这些信息必须准确，尽可能最新，并易于呈现以方便消费。必须构建跨越这些不同系统的查询是一项艰巨的任务。此外，随着我​​们业务的发展，对新型数据查询和数据存储库的需求将继续增长。因此，我们的工程团队退后一步，问：“我们该怎么做才能减轻向用户提供有用数据所带来的开发痛苦？”这样，我们还能加快交付新类型数据报表的时间吗？ “报表”一词在这里被宽松地使用。它涵盖了用户或系统可能感兴趣的任何信息（查找分散的数据或聚合数据，交易流水数据或统计数据，或历史信息数据)
4. 另一个重要问题是数据安全性和隐私性。我们需要确保我们拥有适当的访问控制，以便用户只能看到被允许查看的信息。我们如何提出表达和执行这些访问控制规则的统一方法？

系统要求

我们很快意识到我们必须构建一个满足以下要求的系统：

1. 允许开发人员轻松贡献和支持新的报表查询接口（API）（在部署过程中产生最小的冲突）
2. 轻松添加新的数据源和数据仓库，并将数据从它们中提取并显示给用户
3. 使用通用语言创建和更新对数据的访问控制
4. 有一种统一的方式供用户表达查询过滤条件（无论数据是使用SQL或NoSQL的数据库）

我们构建的系统被称为“达芬奇”（DaVinci）（以纪念这位天才500周年诞辰），它是一项无所不包的服务，可实现信息检索（报表）API的创建，管理和执行。在此强调，它不是数据处理平台，因为它已经假设要检索的数据已先后由其他系统（例如ETL管道和其他数据处理应用程序）转换和管理。

系统设计

在设计达芬奇时，我们分析了数据报表API接口的“解剖”，并仔细查看了对应接口周围的元数据。有没有一种方法可以使接口的描述形式化，以便我们可以自动创建和维护接口，从而减轻开发人员的负担？答案是肯定的: 一个查询API接口始终具有以下特征：

• URL路径
• 所有可能的字段及其元数据（包括名称，类型和访问控制）的集合
• 要返回的默认字段
• 可返回的最大行数
• 访问控制（允许谁调用此接口？）
• 要返回的数据的检索逻辑（即数据获取器）
• 如果用户未指定，则应用的默认查询过滤器

于是，我们提出了JSON语法来定义报表接口的元数据，并将其称为报表接口组件（Reporting Endpoint Package: REP）。基本上看起来像这样：

{"rep_name": "xxxx",  //组件名称"category": "xxxx",   //目录名称"display_name": "xxxxxx",  //显示名称（我们将它考虑前端展示使用）"description": "xxxxxxxx",  //此接口的描述"endpoint": "/sample-api", 

达芬奇

达芬奇 - 基于"Serverless"的数据查询API框架

• 此文背景
• 我们要解决什么样的问题?
• 系统要求
• 系统设计
• • 访问控制列表及其使用
  • 过滤器以及其语法
  • Serverless 和 API Gateway
  • • Serverless 无服务器计算
    • API Gateway 云网关
  • Lambda 执行步骤
  • REP（报表接口组件）管理

此文背景

目前，诸多企业拥有各种软件业务系统，随即产生了大量的生产数据，但是这些数据却“散落”在不同的“地方”。如何将这些数据进行统一的管理，或者进行快速地查询以便深度挖掘数据的潜力是很多开发者面临的问题。因此，根据我们在数据平台工作的一些经验，提出一个基于”云原生“的构建数据查询API的框架，来解决一些这样的问题。

我们要解决什么样的问题?

1. 数据平台作为信息处理者，需要快速，有效地向用户提供相关的最新信息。
2. 但是，此信息存储在许多不同的数据存储库中。今天，我们的数据存储在Redshift和Snowflake等数据仓库，S3中的数据湖，NoSQL数据库以及我们的内部会计和ERP系统中，例如Salesforce和Intacct。我们还需要通过调用合作伙伴的外部API来访问数据。
3. 这些信息必须准确，尽可能最新，并易于呈现以方便消费。必须构建跨越这些不同系统的查询是一项艰巨的任务。此外，随着我​​们业务的发展，对新型数据查询和数据存储库的需求将继续增长。因此，我们的工程团队退后一步，问：“我们该怎么做才能减轻向用户提供有用数据所带来的开发痛苦？”这样，我们还能加快交付新类型数据报表的时间吗？ “报表”一词在这里被宽松地使用。它涵盖了用户或系统可能感兴趣的任何信息（查找分散的数据或聚合数据，交易流水数据或统计数据，或历史信息数据)
4. 另一个重要问题是数据安全性和隐私性。我们需要确保我们拥有适当的访问控制，以便用户只能看到被允许查看的信息。我们如何提出表达和执行这些访问控制规则的统一方法？

系统要求

我们很快意识到我们必须构建一个满足以下要求的系统：

1. 允许开发人员轻松贡献和支持新的报表查询接口（API）（在部署过程中产生最小的冲突）
2. 轻松添加新的数据源和数据仓库，并将数据从它们中提取并显示给用户
3. 使用通用语言创建和更新对数据的访问控制
4. 有一种统一的方式供用户表达查询过滤条件（无论数据是使用SQL或NoSQL的数据库）

我们构建的系统被称为“达芬奇”（DaVinci）（以纪念这位天才500周年诞辰），它是一项无所不包的服务，可实现信息检索（报表）API的创建，管理和执行。在此强调，它不是数据处理平台，因为它已经假设要检索的数据已先后由其他系统（例如ETL管道和其他数据处理应用程序）转换和管理。

系统设计

在设计达芬奇时，我们分析了数据报表API接口的“解剖”，并仔细查看了对应接口周围的元数据。有没有一种方法可以使接口的描述形式化，以便我们可以自动创建和维护接口，从而减轻开发人员的负担？答案是肯定的: 一个查询API接口始终具有以下特征：

• URL路径
• 所有可能的字段及其元数据（包括名称，类型和访问控制）的集合
• 要返回的默认字段
• 可返回的最大行数
• 访问控制（允许谁调用此接口？）
• 要返回的数据的检索逻辑（即数据获取器）
• 如果用户未指定，则应用的默认查询过滤器

于是，我们提出了JSON语法来定义报表接口的元数据，并将其称为报表接口组件（Reporting Endpoint Package: REP）。基本上看起来像这样：

{"rep_name": "xxxx",  //组件名称"category": "xxxx",   //目录名称"display_name": "xxxxxx",  //显示名称（我们将它考虑前端展示使用）"description": "xxxxxxxx",  //此接口的描述"endpoint": "/sample-api",