snowflake数据仓库调研

auth:guochaoqun createtime:2021-06-18

【1】 SnowFlake 简介

【1.0】snowflake 的商业模式

“Snowflake是将基础软件的服务，从传统的To-B的销售，变成了如同快消品一般，通过云原生一改数据仓库积弊；

• 在过去，数据仓库的用户往往面临着投入过高、灵活度低下，还有运营维护困难等一系列问题。在夜间对大数据进行抓取、计算的用户，还需要为白天闲时的物理机器、软件成本支出一大笔不必要的开销。
• 在过去，数据仓库的用户面临重重问题，Snowflake商业模式上的创新，就是针对数据仓库的遗留痛点，利用其云端原生性的优势，采取计算、存储分离的架构，支持计算、存储节点单独扩展，为客户提供了灵活、细化的方案

【1.1】Snowflake的关键特点

纯粹的SaaS服务体验。用户不需要购买机器、雇佣数据库管理员或安装软件。用户要么已经在云中拥有数据，要么上传数据。然后，他们可以使用Snowflake的图形界面或ODBC等标准化接口立即操作和查询数据。与其他数据库即服务（DBaaS）产品不同，Snowflake的服务覆盖了整个用户体验。用户无需调优，无需物理设计，无需存储整理任务。

关系型。Snowflake几乎完整的支持了ANSI的SQL和ACID的事务。大部分的用户几乎无需改动或者很小的改动就能迁移已经存在的工作内容。

半结构化和schema-less。Snowflake提供了用于遍历、展平和嵌套半结构化数据的内置函数和SQL扩展，并支持JSON和Avro等流行格式。自动模式发现和列式存储使得对schema较少的半结构化数据的操作几乎与对普通关系数据的操作一样快，而无需用户额外的操作。

弹性。公有云平台几乎能够按需提供无限的计算和存储资源，存储和计算资源可以独立无缝地扩展，而不影响数据可用性或并发查询的性能。

高可用。Snowflake能够容忍节点，集群，甚至全部的数据中心失败。在软件和硬件更新的时候不会下线。

持续性。Snowflake的设计具有极高的持续性，可防止意外数据丢失：克隆、下线和跨区域备份。

经济节约。Snowflake具有很高的计算效率，所有的表数据都被压缩。用户只为他们实际使用的存储和计算资源付费。

安全。所有数据包括临时文件和网络流量都是端到端加密的。没有用户数据暴露在云平台上。此外，用户能够基于角色在SQL级别执行级别细粒度的访问控制。

【1.2】Snowflake主要功能

• 安全、治理和数据保护
• 标准和扩展 SQL 支持
• 工具和界面
• 连通248606性
• 数据导入导出
• 数据共享
• 数据库复制和故障转移

【2】SnowFlake的组织形式

三个架构层示意图

​

作为 SaaS，Snowflake 技术完全通过 Internet 与客户共享。它使用基于公共云的基础设施与客户联系。

这些服务通过RESTful接口进行通信，分为三个体系结构层：

• 云服务：系统的“大脑”。这一层是管理虚拟仓库、查询、事务和围绕虚拟仓库的所有元数据的服务的集合，包含数据库元信息、访问控制信息、加密密钥、使用情况统计等。
• 虚拟仓库VW：系统的“肌肉”。该层通过弹性的虚拟集群（称为虚拟仓库VW），查询处理。
• 数据存储：该层使用amazon s3（AWS S3就是一个网络传输文件的工具，可以理解为命令行操作的百度云盘）存储表数据和查询结果。

【2.0】云服务层

• 该组件负责监督和协调 Snowflake 提供的服务。通过这些服务，客户端可以对存储的数据执行任何操作。从登录到处理请求，这一层促进了各种活动。在其数据仓库结构的雪花图中，该组件将位于最顶部。该层下提供的服务包括：
  • 验证
  • 基础设施管理
  • 元数据管理
  • SQL编译
  • 查询处理和优化，事务管理器
  • 访问控制
  • 加密

• 高可用性：每个服务都被复制以实现高可用性和可扩展性。因此，单个服务节点的故障，可能导致某些正在运行的查询可能会失败（并透明地重新执行），但是不会导致数据丢失或可用性下降。
• 查询管理：基于CBO的查询优化器，相关统计信息在数据加载时自动维护；生成执行计划后分发给 VW 中的部分节点；执行查询时云服务会不断跟踪查询的状态、收集相关信息进行存储，最终可以在界面上查看与分析；
• 并发控制：通过快照隔离（Snapshot Isolation，SI）实现ACID事务；SI 是基于 MVCC 之上的；所以能够比较好的支持bulk delete/ delete/update column，以及极少量的随机update，通过mark delete的方式。
• 剪枝优化：
  • 简单来说就是维护数据分布信息，快速定位到所需要的数据实际的文件
  • 假设文件 f1 和 f2 在某个列x中分别包含值3..5和4..6。然后，如果查询有一个谓词，其中x>=6，我们就知道只需要访问f2
  • 详细描述：基于最小-最大值的修剪，也称为小物化聚合、区域映射和数据跳跃。系统维护给定数据块（记录集、文件、块等）的数据分布信息，特别是块内的最小值和最大值。根据查询谓词的不同，这些值可用于确定给定查询可能不需要给定的数据块。

【2.1】snowflake - 计算与存储分离

​

• 了解存储和计算分离。
  • 耦合：存储和计算由两个松耦合、独立可扩展的服务来处理。
  • 计算：是通过Snowflake的（专有的）shared-nothing引擎提供的。
  • 存储：是通过亚马逊S3提供的，其实任何类型的对象存储都可以（Azure 对象存储，Google云存储）。
  • 流量：为了减少计算节点和存储节点之间的网络流量，每个计算节点在本地磁盘上缓存了一些表的数据。
• 存储层：只负责存储数据
• 计算层：只负责计算
  • 每次计算的过程中，计算层的计算节点会先从存储层均匀的获得数据，然后在节点中完成计算
  • 在这个架构下可以自由的单独增减计算资源、存储空间
• 计算与存储分离的好处
  • 本地磁盘空间不用存储整个数据，这些数据可能非常大，而且大部分是冷数据（很少访问）。
  • 本地磁盘专门用于临时数据和缓存，两者都是热数据（建议使用高性能存储设备，如ssd）。因此，缓存了热数据，性能就接近甚至超过纯shared-nothing结构的性能。我们称这种新的体系结构为multi-cluster、 shared-data结构。

【2.2】计算层（虚拟仓库层,multi-cluster）

• Virtual Warehouse 概念

  • 虚拟仓库：虚拟仓库层由EC2实例集群组成。每个这样的集群通过一个称为虚拟仓库（VW）的抽象呈现给用户。

  • 每个虚拟仓库都是一个MPP（大规模并行处理）计算集群，该集群由Snowflake从云提供商分配的多个计算节点组成。

  • 在以VW为虚拟分布式集群，可以添加多个资源相同的 EC2实例 计算节点

    

• VW层弹性

  • 可以按照需求创建、销毁或者在任意时刻改变大小。创建或者销毁一个 VW 对数据库状态没有任何影响。

  • 当没有查询时候，用户可以关闭所有的VW资源（默认10分钟没有使用自动挂起，要使用时立马恢复）。

    

    multi-cluster，如下图，我们可以看到一个VW中 可以配置多个相同配置的集群，以此增加并发度；

    标准的策略：

    • 即发现有查询排队时，立即新增启动集群；

    • 执行几次后会判断是否可以将负载最少的集群上的负载分配到其他集群，而无需再次启动集群

    

• 每个查询只在一个VW上运行

• VW查询处理

  • 每个用户可以在任何给定的时间运行多个VW，而每个VW又可以运行多个并发查询。每个VW都可以访问相同的共享表(共享存储)，而无需物理复制数据。
  • 在查询非常复杂，需要并行计算的情况下，可以通过增加VW中的计算节点（Compute）来对单个查询并行分流计算
  • 在高并发的时候，可以构建多个 VW 来进行请求分流处理；（或一个 VW 下 多个 cluster 来应对高并发）
  • VW之间互相独立，所以资源也独立且性能互不影响；

【2.3】存储层（shared-data）

使用的亚马逊 S3 云盘，共享存储，可以无限扩容；

AWS S3就是一个网络传输文件的工具，可以理解为命令行操作的百度云盘

存储

• 列存储压缩列：数据加载到Snowflake后，Snowflake会将数据重组为内部优化的压缩列式格式，然后存到云；

• 向量化执行：（简单理解为就是消除程序循环的优化）与MapReduce（分布式计算）相比，Snowflake避免了中间结果的物化。相反，数据是以pipeline方式处理的，每次以列成批处理几千行。这种方法由VectorWise（最初是MonetDB/X100）首创，这能节省了I/O并大大提高了缓存效率。

• 基于push的执行：（简单理解为列筛选、条件过滤等操作在更接近存放数据的层面完成）关系运算符将结果推送到其下游运算符，而不是等待这些运算符拉取数据（经典的火山式模型）。Push-based提高了缓存效率，因为他消除了循环中的控制逻辑。它还使Snowflake能够高效地处理DAG形式的计划，而不仅仅是树的结构，从而可能更好的采用共享和管道化的方式利用中间结果。

• 数据组织形式：Snowflake管理着如何存储此数据的所有方面-Snowflake处理数据的组织，文件大小，结构，压缩，元数据，统计信息以及其他方面的数据。Snowflake存储的数据对象不直接可见，客户也无法访问；它们只能通过使用Snowflake运行的SQL查询操作进行访问。

从业务角度来说

1. 共享和集成数据：共享的无限存储意味着用户可以共享和集成所有数据，这是数据仓库的核心原则之一。
2. 弹性和隔离性：同时，用户受益于私有计算资源，避免了不同工作和组织的干扰，这也是数据集市的原因之一。这种弹性和隔离使得一些新的使用策略成为可能。

从性能、形式角度来说

• 劣势：与本地存储相比，S3虽然具有更高的访问延迟，每个I/O请求都有更高的CPU开销，特别是在使用HTTPS连接的情况下。
• 优势：
  • S3是一个对象存储，具有一个相对简单的基于HTTP的PUT/GET/DELETE接口。对象（即文件）只能完全写入。甚至不可能将数据附加到文件的末尾(append)。
  • 文件的确切大小需要在PUT请求中前就确定。并且，S3支持对部分（范围）文件的GET请求。
  • 当本地磁盘空间耗尽时，它还使用S3存储由查询（例如，大量连接）生成的临时数据，以及大型查询结果、排序等。将temp数据溢出到S3，系统可以计算任意大的查询，而不会出现内存不足或磁盘不足的错误。
  • 表被水平划分成large，immutable文件，等同于传统数据库的block或者page；
  • 这些属性对Snowflake的表文件格式和并发控制方案有很大的影响，后面【3.3会讲到】具体使用什么方案

【2.4】持续可用性

Snowflake在体系结构的所有级别上都能容忍单个和相关的节点故障

​ 一般情况下一个 AZ（Amazon availability zones），由多个相邻 Data Center 组成

以AZ 为运行单位：

1. 外部接口请求
2. loader balancer负责负载均衡，平衡请求的服务到不同 数据中心的 VW中去
3. 云服务做验证、过滤、分析等
4. VW实际处理数据

• Snowflake的数据存储层
• 
  • 使用的是 Amazon S3，它是跨地区的多个数据中心进行复制（一般2个以上），在Amazon术语中称为“可用性区域”（Amazon availability zones）或AZ
  • 跨AZ的复制允许S3处理完整的AZ故障，并保证99.99%的数据可用性和99.999999999%的持久性。
• Snowflake的云服务层也在多个AZ之间分布和复制
  • 如果一个节点发生故障，其他节点可以在不影响最终用户的情况下接管任务。
  • 云服务层的其余服务由多个AZ中的无状态节点组成，负载均衡器负责分发用户请求
  • 因此，单个节点故障甚至是完全的AZ故障都不会对系统范围造成影响，可能是对当前连接到故障节点的用户的一些失败查询。这些用户将被重定向到另一个节点进行下一次查询。
• 虚拟仓库（VW）并不分布在AZs中
  • 这个选择是出于性能考虑。高吞吐是分布式查询执行的关键，虚拟仓库VW中的机器/集群不跨可用区（AZ）,跨区需要网络I/O开销过大
  • 如果其中一个工作节点在查询执行期间失败，则查询会失败，但会透明地重新执行，要么立即替换该节点，要么暂时减少节点数。为了加速节点更换，Snowflake维护了一个小的备用节点池。（这些节点还用于快速VW配置。）

如果发生完全的AZ故障，那么在该AZ的给定VW上运行的所有查询都将失败

并且用户需要在不同的AZ中主动重新配置VW，由于完全的AZ故障是真正的灾难性和极为罕见的事件，我们今天接受这种部分系统不可用的情况，但希望在将来解决它。

【shared-nothing 与 shared-disk】

shared-nothing 形式

传统数仓：计算和存储耦合

​ shared-nothing 架构

优点：

1. 分布式存储与计算：每个节点都有存储与计算功能
2. 存储分布：数据横向且较为平均的分布在各个节点，每个节点在计算的时候都只需要处理位于自己节点上的数据即可；
3. 查询效率：理论上很快，降低了数据在节点之间传输的时间，数据处理的过程中也不会出现争抢计算机资源的情况；

缺点：

1. 数据量未必均匀：因为我们需要提前把数据分布到各个节点，而每个节点都只对自己拥有的数据负责

2. 异构工作负载：虽然硬件是同样的，但工作负载通常不是。对于大容量加载（高I/O带宽，轻计算）来说，理想的系统配置不适合复杂查询（低I/O带宽，重计算），反之亦然。因此，硬件配置需要在平均利用率较低的情况下进行权衡。

3. 节点关系变化：因为我们是需要提前把数据分布到各个节点，如果增加、删除节点，那么就要对数据分布进行重新洗牌（以便新节点可以发挥，或者删除节点后 其他节点接收过来后可以相对分布较为均匀，才不会使得性能和数据分布出现极大不均衡）这种数据量一大则会引起大量带宽占用以及其他资源占用；

4. 无法单独的增加计算资源和存储资源：

   害怕木板短筒：所谓木桶的短板，遇到后整个engine的性能下降到该短板机器的能力这也是为什么MPP架构不适合异构的机器，要求各节点配置一样。

   比如某节点的磁盘空间要满了，你想要扩容、大对象拆分，一般情况下是通过增加节点来进行数据重新平衡分片，来达到减缓整体集群磁盘空间使用率；那么新增的节点，必须要带有和现有节点相同CPU、内存等相关计算资源，如果资源不如线上节点，那么并行查询的时候它就是短板，查询结果要等它查完然后返回数据来整合，这就造成了等待，同时初衷是为了加磁盘，现在计算资源也要加这么多，这也导致了资源浪费；

5. 在线升级：虽然通过副本机制可以在一定程度上减轻节点关系变化更改的影响，但软件和硬件升级最终会影响系统中的每个节点。原则上是可能的，一个又一个节点在没有任何系统停机的情况下进行升级。但是由于所有节点都是紧密耦合的，并且都是同质的，这使得实现在线升级变得非常困难。

shared Disk 的优劣

• shared disk
  • 缺点
    • 资源匮乏：可通过增加节点来提高并行处理的能力，但是存储器接口效率是瓶颈（磁盘争用）
    • 缓存效率低：shared-disk系统中的每台计算机都可能涉及整个数据集（因此需要缓存）。这降低了高速缓存的效率，因为高速缓存未命中的可能性更大。而shared-nothing每个机器只需要缓存它自己拥有的数据子集，因此缓存更加有效。
  • 优点：
    • 集成数据，只要有一台上层节点可用，则可以访问获取到所有数据

【3】中就说一说，snowflake是怎么优化解决 shared disk & shared nothing 的缺点，合理利用优点的；

【3】SnowFlake 性能优化

【3.1】snowFlake 对比传统数仓的性能

• 如【2.3】所说，使用了共享存储，那么共享存储 必定是没有 shared--nothing 把数据分布式存储在各个节点的盘下效率高

• snowFlake 解决了传统数仓的痛点，但这种形式也丧失了传统数仓 shared-nothing 的优点，无法分布式高效访问磁盘数据；

  可以说，这是它的缺点；但它有其他方式来解决这个问题；

【3.2】优化性能【计算层】=》loca caching （本地缓存）

• VW中的集群下的节点本地磁盘缓存：每个计算节点都会保存一份常用数据在本地硬盘上（文件头、文件中的列），这些数据就相当于 cache，根据 LRU 的算法来替换
• 一致性hash算法提高缓存命中与缓存留存：为了提高命中率并避免VW的工作节点之间对单个表文件进行冗余缓存，服务层会采用一致性 hash 的算法给每个节点分配任务。因此，访问同一表文件的后续查询或并发查询将在同一工作节点上执行。尽可能的增加数据的留存率，从而减少计算层与存储层的数据传输，从而达到加速的目的
• Snowflake中一致的hash是lazy的：当工作节点由于节点故障或VW调整大小（VW的大小改变包含CPU/内存/磁盘）而更改时，不会立即对数据进行shuffle(自动化平衡迁移)。
• Snowflake依赖LRU替换策略最终替换缓存内容。此解决方案将替换缓存内容的成本分摊到多个查询上，从而获得比立即缓存或纯shared-nothing系统更好的可用性，后者需要立即在节点之间shuffle大量表数据。它简化了系统，因为没有“降级”模式。
• 结果缓存： 保存 过去 24 小时内执行的每个查询的 结果。这些可跨虚拟仓库使用，因此返回给一个用户的查询结果可供系统上执行同一查询的任何其他用户使用，前提是基础数据未更改。
• 挂起VW会丢失缓存： 为什么VW默认设置是10分钟不操作自动挂起，很大原因是因为挂起VW会自动情况缓存，为了更好的应用缓存数据来提高效率，所以设置了10分钟为挂起阈值，以防过于短暂的闲置引起 VW 挂起，导致缓存被清理从而使得效率更低；

【3.2】性能优化【计算层】=》file stealing（数据倾斜处理）

• file stealing 解决数据倾斜
  • 数据/资源倾斜问题：由于虚拟化问题或网络争用，某些节点的执行速度可能比其他节点慢得多。
  • 文件窃取：在这点上，Snowflake在扫描文件的时候就处理了这个问题。每当工作进程完成对其输入文件集的扫描时，它就会从其对等进程请求其他文件，我们称之为文件窃取。
  • 窃取原理：当请求到达时，如果一个worker发现它的输入文件集合中还有许多文件要处理，这个时候又有其他worker请求帮助，这个worker将这个请求中他需要的查询的范围内的一个剩余文件的处理权力转移给其他worker。然后其他worker直接从S3下载文件，而不是从这个worker下载。这种设计确保了文件窃取不会给当前worker增加额外的处理负担。
  • 案例：如下图：
    • 在一个 VW 中，这里为了方便我们称呼左边node为 a，右边的为b；请求过来每个节点分配了3个文件扫描读取
    • a节点 比 b节点效率高很多，当 a节点已经处理完后，会对对等进程请求其他文件(这里就是 b进程)；
    • 这个时候假设 b节点还只是在处理第1个文件(如果已经是第3个了,那就不会偷操作了)，那么 a节点就从 b节点的扫描队列中 '偷' 走一个未处理的文件
    • 最终结果如下面第2副图；
  • 
  • 
  • 那么这种优化，就可以使得效率更高的计算节点能够去负责相对更高负载，而效率低的计算节点就负责相对较低的负载；

【3.3】性能优化【存储层】=》 Storage

• 所有表格文件在存储的时候，被横向切割成 N 块，然后每一块用列式存储文件块；

  • 文件拆分与压缩：表被水平地划分成大的、不可变的文件，这些文件相当于传统数据库系统中的块或页。在每个文件中，每个属性或列的值都被分组在一起并进行了大量压缩，这是一种普遍采取的方案

  • 标头(header)：每一个文件块/表文件都有一个 header 标头，其中包含文件中每列的偏移量 offset 以及其他元数据(metadata)

  • 根据header信息快速定位文件位置：这些 header 的相关信息被保存在服务层，当用户发送一个 query 请求，服务层会根据这个请求精确的指示出所需要的数据在存储层的位置，减少不必要的内容读取，以达到加速的目的；

  • 部分文件请求：因为S3允许对部分文件执行GET请求，所以查询只需要下载文件头和它们需要的列。

  • Metadata存储：例如目录(catalog)对象，table由哪些 s3 文件组成，统计，锁，事务日志保存在一个kv存储里面，这个kv存储作为Cloud Services layer一部分。

  • 

【4】snowflake优点与缺点详解

【4.1】最优价值优点

• 最大亮点：弹性

  • 独立性：最显着的一个是启动任意数量的虚拟仓库，每个虚拟仓库都有自己的 MPP 集群。这意味着用户可以在同一系统上运行无限数量的独立工作负载，而不会产生任何争用。
  • 纵向扩展：（解决大的复杂查询）每个仓库都可以动态的在一瞬间从一个小集群调整为一个庞大的集群。这为用户提供了高质量的性能，并能够根据工作负载全天调整大小。
  • 横向扩展：（multi-cluster架构解决高并发）横向扩展技术被用于部署一些相同大小节点的集群，以达到目标并发量，即：增加 VW 中的mpp集群的数量，而不是任务的大小或复杂性。
  • 按需计费：可以按需计费，使用的时候才计费，可以设置阈值自动挂起以省钱；如：设置5分钟没有操作就挂起；

• 数据共享

• SaaS体验

  • 分离计算和存储为您提供灵活性。它基本上可以说不需要 DBA 参与，因为它不需要任何性能调优。我们并没有真正进行任何性能调优，性能调优和 SQL 调优的全部负担都在 Snowflake 上。

  • 它的易用性非常好。我不需要增加任何用户，而且它的入门更容易。您只需加入用户，就完成了。有简单的 SQL 和 UI以及非常多的连接方式；人们可以轻松使用此解决方案。

• 时间旅行和复制功能

  • 时间旅行（time travel）：
    • 概述：就是保留指定时间内（最长90天）所有行版本；标准账户为 1 天；
    • 当文件被新版本删除时，它们将保留一段可配置的时间（当前最长为90天）。文件保留允许Snowflake非常高效地读取表的早期版本；也就是说可以保留90天内操作的所有版本，这让查询数据库变化、闪回等情况非常好用；
  • 复制（clone）：
    • 概述：有点类似于硬链接的概念，独立操作之后，引用的文件会不一样，元数据可能也会不一样；（因为它的存储特性是：任何操作都是新增文件，元数据重新标识引用，而不会通过删除文件的形式实现）
    • Snowflake还实现了一个我们称之为CLONE的功能，通过新的关键字CLONE来表示。CLONE表可以快速创建具有相同定义和内容的新表，而无需对表文件进行物理复制。CLONE操作只是复制源表的元数据。克隆完成后，两个表引用同一组文件，但此后可以独立修改这两个表。CLONE特性还支持整个schemas或数据库，这是非常高效的快照。在进行大量更新之前，或者在执行较为复杂的探索性数据分析时，快照是一种很好的做法。CLONE关键字甚至可以与AT和BEFORE组合使用，这样就可以在事后创建快照。

• 共享和协作 ：

  • 概述：类似于视图一样（只读），以类似角色的形式创建、授权，用户加入这个角色即可
  • 不会在帐户之间复制或传输实际数据。所有共享都是通过 Snowflake 独特的服务层和元数据存储完成的

• ETL

  • Saras Analytics 是 官方的 Snowflake ETL 合作伙伴。我们的产品 Daton 可以将来自各种数据源的数据无缝复制到 Snowflake，而您无需编写任何代码。Daton 拥有 100 多个连接到不同数据源的连接器，是将数据复制到 Snowflake 的最快、最简单的方法。
  • 自带的 Snowpipe 管道方式

• 半结构化数据处理schema-less

  • 以VARIANT，ARRAY，OBJECT拓展SQL类型

    VARIANT类型可以存储任何SQL中的类型（DATE VARCHAR等）
    VARIANT列可以用作连接键、分组键、排序键，这使得可用于ETL
    用户可以从 json、avro、xml格式转化为variant列

• 在线升级

  • 
  • 在线升级过程：

    • 升级的时候，首先部署新版本的服务，与老版本的服务并行，之前已经运行的请求，可以允许在之前的版本上运行完，一定所有的用户和请求在之前的版本上运行完，老版本的服务被终止和解散。

    • 上图显示了这样的一个2个版本的VW同时允许的状态，上面有2个版本的cloud service和virtual warehouse，他们各自选择不同的服务。

    • 这点非常重要，重要是能够支持快速迭代，但是对于传统数据库来讲非常难做到，因为传统的数据库都是有状态的，而snowflake的状态都保存在kv storage，所有他除了kv storage。

【4.2】缺点

• 过于云依赖：依赖于 Azure、AWS、GCS。每当这些云服务器之一发生独立中断时，支持就可能成为问题。

• 不支持地理空间数据：目前没有提供很多处理地理空间数据的选项。也许这在他们的计划中。

• 不支持非结构化数据：它目前没有支持非结构化数据的选项。也许他们很快就会添加。

• 连续加载数据限制：将数据从数据文件迁移到 Snowflake 文件时，有很多关于批量数据加载的支持和指导。如果需要连续加载，用户仅限于 Snowpipe。

【5】基本使用

databases

​

shares

​

数据集市(data marketplace)

​

​

VW

​

点进去可以看到使用情况时间分布

​

选中某个VW，调整大小、自动挂起策略、最大最小集群等等

​

查询历史记录(History)

preview App

​

（1）工作蒲

​

（2）仪表盘

​

​

可以创建各种报表，图标里面可以设置各类查询、报表样式等等

​

（3）数据

（4）计算

​

（5）账户

根据VW，可以查看账户在该VW的消费、存储等等

角色、账户 等等可以维护

安全方面的话，可以设定会话策略和网络策略

【6】结论

还是很好用的

【参考文档】

翻译参考文档：https://mp.weixin.qq.com/s/PgpTUs_B2Kg3T5klHEpFVw

官方文档参考：https://docs.snowflake.com/en/sql-reference.html

snowflake 缓存：https://www.analytics.today/blog/caching-in-snowflake-data-warehouse

snowflake 配置调优：https://database.51cto.com/art/201907/600428.htm

smp 与 mpp 概述：https://blog.csdn.net/ioteye/article/details/113452551

SQL 火山模型：https://zhuanlan.zhihu.com/p/219516250

SQL 向量化执行引擎：https://book.51cto.com/art/202103/652247.htm