1. 数据虚拟化服务

1.1. 趋势

1.1.1. 与数据集相关联的多语言数据模型
- 1.1.1.1. 多语言持久化既适用于数据湖，也适用于应用程序事务型数据
1.1.2. 查询引擎和数据存储持久化的解耦允许不同的查询引擎对数据湖中持久化的数据运行查询
- 1.1.2.1. 通常，为不同的查询工作负载组合配置多个处理集群，选择合适的集群类型是关键
1.1.3. 对于越来越多的用例（如实时BI），需要实时关联数据湖的数据和应用程序中的数据
- 1.1.3.1. 随着洞察的生成变得越来越实时，有必要将数据湖中的历史数据与应用程序数据存储中的实时数据结合起来

1.2. 痛点

1.2.1. 由于数据持久化在数据湖中的多语言数据存储以及应用程序数据源中，编写查询时需要针对特定数据存储使用不同方言，因此形成了学习曲线
1.2.2. 需要将不同数据存储的数据合并到一个查询中。先聚合数据并将其转换为规范化形式，然后再进行查询的方法不能满足越来越多的实时分析需求
1.2.3. 选择合适的查询处理集群
- 1.2.3.1. 通过解耦架构，可以根据数据基数、查询类型等选择不同的查询引擎对数据执行查询

1.3. 理想情况下，对于关联的底层数据存储和集群相关的细节，数据虚拟化服务应该将其隐藏

1.3.1. 如果数据用户提交一个类似SQL的查询，服务会自动将查询在数据存储间进行联合查询，并根据数据存储的特定原语优化查询语句
1.3.2. 通过自动化处理特定数据存储的查询细节，可以减少数据用户查询作业的时间

1.4. 虚拟化的概念抽象了底层处理的细节，为用户提供了系统的单一逻辑视图

1.5. 在大数据时代，数据存储技术和处理引擎没有通用的解决方案，数据用户应该关注如何跨数据源查询数据

1.5.1. 应该能够将数据作为单个逻辑命名空间来访问和查询，而不用考虑底层数据持久化模型和查询引擎如何处理查询

2. 路线图

2.1. 查询虚拟化服务适用于数据的所有阶段（发现、准备、构建和操作阶段）

2.2. 探索数据源

2.2.1. 在发现阶段，访问驻留在应用程序多语言存储区、仓库和数据湖中的数据以理解和迭代所需的数据属性，可以进行理解和迭代
2.2.2. 跨多个孤岛查询和连接数据的能力也适用于操作阶段
2.2.3. 构建跨数据孤岛实时连接的模型或仪表盘非常重要
2.2.4. 如今，首先在数据湖中聚合数据，这对于实时需求来说可能不可行
2.2.5. 假设有一个逻辑数据库包含所有孤岛存储，数据用户就能够以单个命名空间的形式访问数据

2.3. 选择处理集群

2.3.1. 通过解耦查询引擎和数据持久化，同一数据可以使用不同的查询引擎运行在不同的查询集群上进行分析
2.3.2. 根据查询的属性选择合适的引擎需要一定的专业知识
2.3.3. 处理集群的选择还需要考虑负载均衡等动态属性，以及蓝绿部署等维护计划

3. 最小化查询耗时

3.1. 查询耗时是开发查询所花费时间的总和，包括跨多语言数据存储访问数据并选择处理环境来执行查询

3.2. 选择执行环境

3.2.1. 择执行环境涉及根据查询类型将查询路由到合适的处理集群
3.2.2. 需要跟踪现有环境及其属性清单、分析查询属性，并监控集群上的负载
3.2.3. 挑战在于跟踪集群清单、持续更新集群的当前状态以获得负载和可用性，以及在无需用户更改的情况下透明地路由请求

3.3. 制定多语言查询

3.3.1. 数据也可能驻留在数据湖中，以可能缺少模式或可能涉及嵌套或多个值的格式存储
3.3.2. 每种不同类型和风格的数据存储可能适合特定的用例，但是每种类型的数据存储都有自己的查询语言
3.3.3. 语言查询引擎、NewSQL和NoSQL数据存储提供半结构化的数据模式（通常基于JSON）和相应的查询语言
3.3.4. 由于缺乏正式的语法和语义、习惯性的语言结构，所以语法、语义和实际功能的巨大差异会带来问题—很难理解、比较和使用这些语言
3.3.5. 查询语言和数据存储格式之间存在紧密耦合
- 3.3.5.1. 如果需要将数据更改为其他格式或需要更改查询引擎，则必须更改应用程序和查询代码
- 3.3.5.2. 这将是提升数据使用的敏捷性和灵活性的一大障碍

3.4. 跨孤岛连接数据

3.4.1. 数据存储在多个多语言数据存储源中
3.4.2. 对于孤岛数据源的查询，首先需要在数据湖中聚合数据，如果考虑到实时性要求，这可能无法满足需求
3.4.3. 挑战是平衡应用程序数据存储上的负载与来自分析系统的流量
3.4.4. 传统查询优化器需要考虑基数和数据布局，这很难跨数据孤岛实现
3.4.5. 应用程序数据存储的数据会缓存成物化视图，以支持重复查询

4. 定义需求

4.1. 当前痛点分析

4.1.1. 数据虚拟化需求
- 4.1.1.1. 是否使用了多个查询引擎
- 4.1.1.2. 是否在数据湖或应用程序数据存储中使用多语言持久性
- 4.1.1.3. 是否需要使用跨事务性存储
4.1.2. 数据虚拟化的影响
- 4.1.2.1. 展示定义查询所花费的时间
- 4.1.2.2. 查询运行和优化所需的平均迭代次数
- 4.1.2.3. 不同多语言平台所需的专业知识
- 4.1.2.4. 件发生与分析之间时间差的平均处理延迟
4.1.3. 应用程序数据存储隔离的必要性
- 4.1.3.1. 应用程序存储的当前负载以及应用程序查询的速度减慢情况
- 4.1.3.2. 由于数据存储性能而导致的应用程序性能与现有SLA冲突
- 4.1.3.3. 应用程序数据的变化率
- 4.1.3.4. 对于应用程序数据存储饱和或数据快速变化的情况，可能无法实施数据虚拟化策略

4.2. 操作要求

4.2.1. 已部署技术的互操作性
- 4.2.1.1. 核心考虑因素是不同的数据模型和数据存储技术能够在数据湖和应用程序中将数据持久化
4.2.2. 可观测性工具
- 4.2.2.1. 数据虚拟化服务需要与现有的监控、告警和调试工具集成，以确保可用性、正确性和查询SLA
4.2.3. 速度和容量
- 4.2.3.1. 在设计数据虚拟化服务时，需要考虑要处理的并发查询的数量、处理的查询的复杂性以及可容忍的实时分析延迟

4.3. 功能性需求

4.3.1. 自动将查询路由到正确的集群，而无需任何客户端更改
4.3.2. 简化了对存储在多语言数据存储中结构化、半结构化和非结构化数据的查询方法
4.3.3. 联合查询支持连接驻留在数据湖中不同数据存储和应用程序微服务之间的数据
4.3.4. 可以限制推送到应用程序数据存储的查询数量

4.4. 非功能性需求

4.4.1. 可扩展性
- 4.4.1.1. 服务应该是可扩展的，以适应不断变化的环境，并且能够支持新的工具和框架
4.4.2. 成本
- 4.4.2.1. 虚拟化计算成本很高，降低成本至关重要
4.4.3. 可调试性
- 4.4.3.1. 在虚拟化服务上开发的查询应该易于监控和调试，以确保大规模运行的生产部署的正确性和性能优化

5. 实现模式

5.1. 自动查询路由模式

5.1.1. 简化为作业选择正确工具相关的任务
5.1.2. 这种模式隐藏了为查询选择正确的处理环境的复杂性
5.1.3. 目标是自动将查询路由至处理集群，数据用户只需提交作业到虚拟化服务
- 5.1.3.1. 这种模式是查询和可用的处理集群之间的匹配器
5.1.4. 数据虚拟化服务为每个提交的作业生成一个自定义运行脚本
5.1.5. 该模式的重点是在符合用户作业需求的集群上启动作业来完成用户的任务
5.1.6. Netflix的Genie
- 5.1.6.1. 允许数据用户以及各种系统（调度器、微服务、Python库等）提交作业，而不必真正了解集群本身
- 5.1.6.2. 旨在简化查询的路由
5.1.7. 随着查询处理配置的日益复杂，查询路由模式对于隐藏底层复杂性（尤其是在大规模场景中）变得越来越重要
5.1.8. 该模式的优点是透明路由，它兼容了静态配置和动态负载属性
5.1.9. 缺点是路由服务可能成为瓶颈或单一饱和点

5.2. 单个查询语言模式

5.2.1. 简化与在结构化、半结构化和非结构化数据上编写查询语句相关的学习曲线
5.2.2. 注重统一的查询语言和编程模型
5.2.3. 数据用户可以在不同数据存储的结构化、半结构化和非结构化数据中使用统一的方法
5.2.4. PartiQL
- 5.2.4.1. PartiQL是一种兼容SQL的查询语言，可以轻松高效地查询数据，无论数据存储在哪里或以何种格式存储
- 5.2.4.2. 具有最少的SQL扩展，可以对结构化、半结构化和嵌套数据集的组合进行直观的过滤、连接、聚合和窗口化
- 5.2.4.3. 不需要数据集上预定义模式，其语法和语义独立于数据格式，也就是说，查询语句在JSON、Parquet、ORC、CSV或其他格式的底层数据上是完全相同的
- 5.2.4.4. 查询是在一个全面的逻辑类型系统上操作的，这个系统可以映射到不同的底层格式
- 5.2.4.5. PartiQL的语法和语义并不与特定的底层数据存储绑定
- 5.2.4.6. 是一个干净、基础良好的查询语言，它非常接近SQL，并且可以处理嵌套数据和半结构化数据
- 5.2.4.7. PartiQL利用了数据库研究界的工作成果，即UCSD的SQL++
5.2.5. Apache Drill
- 5.2.5.1. 是SQL的直观扩展示例，可以轻松查询复杂数据
- 5.2.5.2. 特点是采用了JSON数据模型，可以对嵌套数据以及在现代应用程序和非关系型数据存储中常见的快速演变的结构进行查询
5.2.6. Apache Beam
- 5.2.6.1. 统一了批处理和流式处理
- 5.2.6.2. 是一个开源的统一模型，用于定义批处理和流式处理的数据并行处理管道
- 5.2.6.3. 分布式处理后端
  
  5.2.6.3.1. Apache Apex
  
  5.2.6.3.2. Apache Flink
  
  5.2.6.3.3. Apache Spark
  
  5.2.6.3.4. Google Cloud Dataflow