Redshift入门


我们将数据导入到Redshift的节点上时，最好选择S3做为源。因为AWS在它上面做了很多工作，特别是并行加载，导入数据速度非常快。

但如果我们在S3的数据量非常大，比如上百个TB，则需要启动很多Compute Node，带来巨大的花费。Redshift还有Spectrum层，它其实是一个自动伸缩的EC2集群，帮助把数据从S3加载并做中间查询计算：

image-20221024212250305

附 schema on write模式介绍

不像Athena是schema on read模式，Redshift是schema on write模式

  • schema on write（写时模式）

​ 作用于数据源到数据汇聚存储之间，典型使用就是传统数据库。数据不管是在入库还是采用装载外部数据或者将一个查询的输出结果写入数据库或者是使用UPDATE语句，数据库存储对于在数据写入数据库时都需要对schema进行检查控制，对照模式进行检查，如果在加载时发现数据不符合模式，则被拒绝加载数据。

  • schema on read（读时模式）

​ 作用于数据汇聚存储到数据查询分析之间，数据先存储，然后在需要查询分析的时候再为数据设置schema，底层存储不会在数据加载时进行验证，而是在查询数据时进行。

两种模式对比

  • 业务角度分析
  1. 对于一个成熟的业务，已有模型足够涵盖所有的数据集，变化较少，则可以使用写时模型，提前定义好所有数据模型（数仓作用）；
  2. 对于一个新的或者探索性业务，由于业务需求不定，并且变动频繁，因此数据不适合绑定到预定的结构，则可以使用读时模式，快速迭代，尽快交付业务需求。
  • 数据质量对比
  1. 写时模式，会对存储的数据质量进行检查或檫除（ETL），确保数据在某个业务场景下明确定义的、精确的和可信的；
  2. 读时模式，因为数据没有受到严格的ETL和数据清理过程,也没有经过任何验证,该数据可能充斥着缺失或无效的数据,重复和一大堆其他问题，可能会导致不准确或不完整的查询结果。如果在on read的时候进行ETL，由于同样数据不同schema，则会导致重复工作。
  • 效率对比
  1. 写时模式倾向于读效率，因为数据存储在合适的地方，并做了类型安全和清理优化工作，通常更高效。但这是经过数据摄入时，繁琐的预处理为代价换来的；
  2. 读时模式更倾向于写效率，数据摄入不需要做其它处理，简单，快捷。但是就会导致on read时，解析和解释数据效率低下。
  • 功能与系统
  1. 写时模式更多用于对结构化数据的OLAP与OLTP，对应传统的数据库系统；
  2. 读时模式基于非结构化数据，需要存储更多的数据，海量的分析需求，快速的需求响应，与大数据系统不谋而和。

总结

  1. schema on read强调灵活自由，schema on write注重稳定和效率；
  2. schema on read与schema on write不是二者取一，而是相辅相成，互相协助；
  3. schema有其存在的意义，无论是结构化还是非结构数据分析挖掘，schema都是必须的过程

附 数仓在大数据生态中的定位

image-20221024211453043

从查询时间及扩展性上来看，NoSQL似乎是最佳选择，它既可以用partition来无限扩展容量，又能以近乎实时的查询时间来响应。但在大数据领域没有银弹，NoSQL牺牲的是查询语句的灵活性，以及业务一开始就要想好怎样查询NoSQL

相比之下，数仓虽然查询速度没有那么实时，但它在数据容量可扩展性及查询的灵活性上都不错