选择一个数据仓库平台的标准

原文作者：Yaniv Leven

原文地址：https://dzone.com/articles/criteria-for-selecting-a-data-warehouse-platform

在最近偶然看到的一篇文章中，我喜欢其中的一句话：

“一旦知道哪种部署选项最能满足您的项目需求，就可以简化在不同类型的数据仓库平台之间的选择，从而更快地做出选择。”

虽然这听起来有点夸大，但不要自欺欺人: 简化数据仓库的选择和数据仓库的选择很简单并不是一回事。

从目前可用的丰富数据中挖掘出可操作的见解，仍然令人难以置信，复杂而乏味。这就是为什么选择数据仓库平台时从一开始就必须做出正确选择。正如骑士在选择圣杯时告诉印第安那琼斯：“明智地选择”。无论是实施新的数据仓库解决方案还是扩展现有的数据仓库解决方案，您都需要选择最佳选项。

如果您正在扩展现有的数据仓库，那么您需要将当前的解决方案与竞争对手进行比较，以查看其他供应商是否提供了更相关的特性，或者在性能方面更好。如果你是第一次用户，你的选择就更加复杂了，因为你没有之前的经验来判断你的选择。

无论如何，神奇的事情发生在这个甜蜜的地方，其中成本，性能和简单性根据您的需求完美平衡。但请记住，正如大多数技术一样 - 您今天选择的任何内容都可能比您期望的更早过时，因此请务必在持续的基础上重新评估您的选择。

选择完美数据仓库的标准

虽然没有一个通用的“正确”答案，但对于每个特定的用例，都有更好和更差的选择。而且选择不好会导致很多损失。为了避免陷入不合适解决方案的痛苦，我建议使用以下标准评估数据仓库平台和供应商。

性能

首先，让我们把云与内部问题结合起来。许多公司错误地认为DWaaS（数据仓库即服务）在列表中应该较低，因为速度限制是由云访问造成的网络延迟造成的。这导致许多人错误地进行本地部署。事实上，从安全性到可扩展性以及更改节点类型的灵活性等许多问题在内部部署解决方案本质上并不理想。

对于大多数（尤其是中型用户）来说，利用领先的云数据仓库提供商可以实现卓越的性能和可用性。我真的相信，除非严格的规定要求禁止DWaaS选项，否则大多数公司在涉及其数据仓库和一般分析基础架构需求时都更愿意与云供应商合作。

但是，相信云解决方案不需要大量的内部调整和管理是一个常见的错误。曾经处理过云中数据管理的任何人都知道，所涉及的任务是复杂且持续的。这就是说，相对于预测解决方案，这就像在公园散步一样简单。

云供应商：Redshift居于领先地位

Panoply，Periscope Data和其他许多公司已经在不同的云技术之间进行了广泛的性能测试。在大多数情况下，AWS Redshift排在前列，但在某些类别中，Google BigQuery或Snowflake占了上风。

Panoply进行了性能基准测试，比较了Redshift和BigQuery。我们发现，与之前没有考虑到优化的结果相反，在合理优化的情况下，Redshift在11次使用案例中的9次胜出BigQuery。BigQuery仅表现出优越的性能的唯一例子就是大连接操作。

在调查了Redshift，Snowflake和BigQuery之后，Periscope的数据也宣称Redshift在价格和性能方面都是明显的赢家。他们发现Redshift是客户典型数据量实时查询速度的最佳选择。

可扩展性

对于大规模增长的公司而言，云中的基础架构可扩展性应该从成本，资源和简单性方面进行衡量。大多数基础设施云提供商提供了一种“简单”的方式来扩展您的群集，而有些则像Google BigQuery一样在后台无缝扩展。

在我看来，BigQuery最显着的优势在于无缝快速调整集群的大小，最高可达PB级。与Redshift不同，不需要不断跟踪和分析群集规模和增长，努力优化其规模以适应当前的数据集要求。但是，从Panoply和Periscope数据分析的角度来看，在集群适当优化时，与BigQuery相比，Redshift显示出极具竞争力的定价：

“每查询7美分，每位客户的成本大约为70美元。我们可以使用8节点dc1.large Redshift群集以更低的价格获得更快的速度，每个客户的价格为48美元/天，因此迁移到BigQuery对我们来说不会具有成本效益。“

此外，Redshift可扩展性使用户在增加内存和I / O容量等资源时可以提高性能。Panoply根据数据和查询的数量以及查询的复杂性无缝缩放Redshift用户的云足迹。它按需扩展集群，确保数据仓库性能与成本完美平衡。

Panoply分析显示，使用BigQuery估算查询和数据量成本非常复杂。这导致不可预测的费用增加了用户对所涉及成本的不确定性，导致他们试图限制查询和数据量，所有这些都会对组织的数据分析能力产生负面影响。

这种成本计算的复杂性在Snowflake的捆绑CPU定价解决方案中得到了一些解决，但同样，提前预见您的查询需求是一个有待解决的挑战。

可靠性

云基础架构技术领域的领先者亚马逊，谷歌和微软通常都是可靠的，尤其是与内部部署选项相比，链中更多因素依赖于您。这就是说，无论供应商声誉如何，最近的AWS S3中断显示，即使是最好的供应商也可能会有糟糕的日子。您不仅需要考虑此类事件的发生频率（显然越少越好），而且还要看供应商如何快速彻底地对停机时间做出反应。

可靠和专业的支持是选择DWaaS平台时要考虑的主要标准之一。在我看来，没有一家供应商真正提供足够好的SLA来解决当今对精通数据的客户的按需支持需求。这个缺点是Panoply提供专用于每个帐户的数据架构师的原因之一; 一个负责照顾您真实数据需求的真人。

可用性，安全性和集成

随着数据的增长，数据源的数量增加，数据逻辑变得更加复杂，您还需要添加管理功能和功能，例如DBA生产力工具，监控实用程序，锁定方案和其他安全机制，远程维护功能，和用户退款功能到您的基础设施。随意更改数据类型和实施新表格和索引的能力有时可能是一个漫长的过程，事先考虑到这一点可以防止未来的痛苦。

在将数据注入到分析架构中时，评估要实现的方法类型非常重要。正确的摄取方法和错误的方法之间的差异可能是数据丢失和丰富数据之间的差异，以及组织良好的模式和数据沼泽之间的差异。

例如，Snowflake通过不同的虚拟仓库支持同时用户的查询。根据Periscope数据，你可以：

“......让您的隔夜ETL进程运行在更慢、更便宜的仓库资源上，然后在业务时间内通过更强大的仓库启用实时的临时查询。”

但是，随着Redshift规模和运营效率的提高，ETL可能被称为僵化和过时的范例。

这就是Panoply遵循ELT流程的原因，即所有原始数据都可即时实时获取，并且转换在查询时异步发生。这使得Panoply既是数据湖泊也是数据仓库，允许用户持续和实时访问其原始数据。这意味着他们可以实时迭代他们的转换，并且更新也立即应用于新插入的数据。最后，通过Panoply UI控制台还可以进行自定义的高级转换，只需几分钟即可完成设置和运行。

支持的数据类型

仔细考虑你的需求。多语言方法涉及多种数据平台类型。这些范围从关系数据库和分析数据库到NoSQL DBMS以及Spark和Hadoop等新平台。虽然这增加了复杂性，但它还为数据仓库用户提供了将历史BI与更具前瞻性的预测性分析和数据挖掘相结合的能力。从BI角度来看非常重要。

备份和恢复

BigQuery自动复制数据以确保其可用性和持久性。但是，由于灾难造成的数据完全丢失比快速，即时恢复特定表甚至特定记录的需要少。出于这两个目的，Redshift会自动将备份存储到S3，并允许您在过去90天内的任何时间点重新访问数据。在所有情况下，检索包括一系列可以使即时恢复成为繁琐冗长操作的操作。

由于Panoply采用Redshift技术，因此备份到S3是显而易见的，但我们更进一步。通过利用Panoply的修订历史记录表，用户可以跟踪他们数据仓库中任何数据库行的每一个变化，从而使分析师可以立即使用简单的SQL查询。这使得文件上传到S3和数据库提取冗余时，需要回到任何时间点，并迅速看到数据如何改变。

生态系统

保持共同的生​​态系统通常是有益的。对于兼顾灵活性和简单性的中型企业而言，通常值得与单一供应商合作，以便在不同平台上提供兼容的技术。

谷歌亚马逊和微软都有惊人的生态系统。这就是为什么您很少看到一家使用Redshift的公司与Google基础架构相结合的主要原因，以及为什么主要提供商花费了如此多的资金和努力试图将公司从当前提供商迁移到其生态系统。

关于数据仓库平台的基础性决策，应该清楚的是有很多可能的选择，而引入正确的平台确实为公司的信息文化设定了参数。祝你好运，并作出明智地选择！