在this repository 中，其作者提到我们可以在Cassandra 或S3 中暂存OLAP 立方体：
一旦数据在 Redshift 中，我们的主要目标是让 BI 应用成为 能够连接到 Redshift 集群并进行一些分析。 BI 应用 可以直接连接到 Redshift 集群，也可以通过 数据以聚合形式存在的中间阶段 由 OLAP 多维数据集表示。
这怎么可能？那将如何运作？我错过了任何基本概念吗？据我了解OLAP 多维数据集是OLAP 数据库中存在的一种特殊数据结构。他可能是指存储在面向OLTP 的数据库中的dimensions 和facts 的特定预先计算组合，例如Cassandra？
【问题讨论】：
标签： amazon-web-services amazon-s3 cassandra etl olap
OLAP 的主要特点是：
而Redshift 可以做到这一点。
它的架构旨在解决OLAP 和BI 任务。见amazon-redshift-developer-guide
Amazon Redshift 专为在线分析处理 (OLAP) 和商业智能 (BI) 应用程序而设计，这些应用程序需要对大型数据集进行复杂查询。由于它满足了非常不同的需求，Amazon Redshift 使用的专用数据存储架构和查询执行引擎与 PostgreSQL 实施完全不同。例如，在线事务处理 (OLTP) 应用程序通常将数据存储在行中，而 Amazon Redshift 将数据存储在列中，使用专门的数据压缩编码来优化内存使用和磁盘 I/O。为了提高性能，省略了一些适合小规模 OLTP 处理的 PostgreSQL 特性，例如二级索引和高效的单行数据操作操作。
但是术语之间的界限很流畅。
正如Diana Shealy所说：
停止滥用 OLTP 作为 OLAP
市场上有很多关于 OLTP 和 OLAP 的混淆，而且由于商业 OLAP 的高昂价格，初创公司和预算有限的开发人员继续滥用 OLTP 数据库作为 OLAP 数据库。滥用分为两类：
- 一个通常带有应用层脚本的多分片 MySQL 数据库，用于执行历史事件数据分析。尽管这种设置非常常见，但它是进行分析的效率最低的方法之一。 MySQL 没有针对读取大量数据进行任何优化，并且它对分析函数的支持很弱。由于有多种选择，请避免使用这种“便宜”的解决方案，因为您最终会在其他地方付出代价。
- 使用 PostgreSQL 作为 OLAP 层。由于 Postgres 可靠的分析用户定义函数 (UDF)，这是比上述启动分析平台更合理的选择。此外，由于其 c-store 扩展，PostgreSQL 可以变成一个列式数据库，使其成为商业 OLAP 的经济实惠的替代品。
最后，如果您正在考虑从被滥用为 OLAP 的 OLTP 转移到像 Redshift 这样的“真正的”OLAP，我鼓励您学习如何使用 Redshift 的COPY Command，以便您可以开始在 Redshift 中查看您的数据。
这可能是由于Redshift 架构（列数据库）和分析功能，例如：
有关 Amazon Redshift 数据仓库系统架构的详细说明，请参阅 System and Architecture Overview。
（本文前面已经提到了一些链接）
我是否遗漏了任何基本概念？
我建议更多地依赖特定解决方案的技术细节，而不是营销术语。最后，实际任务不是通过软件命名或营销来解决的，而是通过它的真正功能来解决的。
在 DB 领域中真正重要的是考虑两个定理：
根据CAP定理的Iron triangle，可以选择三个DB架构组件中的两个点：
* 一致性
* 可用性
* 持久性
亚马逊的 Rick Houlihan 在choosing the DB archotecture 上发表了演讲。除了CAP theorem，他还提出了PIE theorem：
PIE 定理假设您可以在数据系统的三个理想特征中选择两个：
模式灵活性
效率
无限规模
而Redshift 位于PIE triangle 的PI 维度上
据我了解，OLAP 多维数据集是存在于 OLAP 数据库中的一种特殊数据结构。他可能是指存储在面向 OLTP 的数据库（如 Cassandra）中的特定预先计算的维度和事实组合？
OLAP 聚合数据结构和Redshift distribution styles 都针对一个目标：使查询更快。
列 DB、分布、并行查询和其他功能非常适合分析任务。
在 cmets 中，您询问 Cassandra 是否可以用作 OLAP 服务。
Cassandra 和S3 可以作为预先计算的维度聚合数据的存储。
【讨论】：