曾经有一段时间，分析学是BI的同义词，BI是OLAP的同义词-在线分析处理。这个词的意思是与更常见的在线事务处理（OLTP）形成对比，并涉及创建多维“立方体”，而不是二维表。每个维度都是一个不同的类别，用于对数值数据进行下钻分析，称为度量。

现在你已经有了BI101的速成课程，看看像Tableau这样的众多分析产品，你就会发现维度和度量的范式是活生生的。OLAP从未消亡，即使它的底层技术发生了一些变化。

然而，OLAP一直困扰着它的可伸缩性。大多数OLAP服务器运行在单一的，尽管很强大的服务器上，这限制了可以实现的并行性，因此对数据量施加了事实上的限制。达到这些可伸缩性上限的客户可能会考虑使用大数据技术，比如Hadoop和Spark，但这些客户往往不采用OLAP用户所习惯的维度范式。

怎么办？嗯，一些供应商已经决定采用Hadoop和Spark，并利用它们作为平台，在这些平台上运行和构建大型OLAP立方体。供应商，即AtScale、Kyvos Insights和Arcadia Data，对一些企业的大数据采用模式进行了研究，并看到这一势头已经停滞。他们的做法是让这些企业的人员在他们感到舒适的OLAP环境中工作，同时利用他们的Hadoop集群。

AtScale的CEO大卫？马里亚尼（David Mariani）是微软几个最大的OLAP项目（在雅虎和Klout）的幕后主使。虽然他能够在微软的OLAP平台，SQLServerAnalysis Services（SSAS）做大的事情，但他确实克服了可伸缩性的限制，包括立方体重新处理时间长达一周。他创建一个更有弹性的OLAP平台的动机是非常明确的，所以他成立了AtScale。

三种方法AtScale立方体可以使BI客户端出现，就好像它们是SSAS立方体一样。所以兼容性较高..同时，当查询AtScale立方体的度量和维度时，AtScale生成相应的SQL查询，以从Hive和Spark SQL中的底层表中获取数据。从这个意义上说，AtScale在Hadoop中存储的表上实现了一种类型的ROLA P（关系OLAP）。

如果它是你想要的物理立方体，但你仍然想要Hadoop的分布式处理和存储，那么Kyvos Insights的产品可能会吸引你。它实现了一个持久的多维数据集，作为底层数据的维度缓存，以存储的聚合完成。立方体本身由多个“长方体”组成，Kyvos称之为“长方体”，每个立方体都存储在集群中的不同节点上。

如果你想要熟悉OLAP，而不需要显式地建模一个立方体（即）。在做任何分析之前，定义所有的措施和维度）？然后，您可以查看ArcadiaData，它允许您执行特定的分析，这些分析将生成派生结构-实际上是生成的立方体-引擎可以查询。然后，您可以将这些派生结构的设计细化为完整的立方体，并且始终可以用更传统的模型优先方法设计立方体。阿卡迪亚还提供了自己的可视化设施，而不是依靠使用其他BI工具作为前端。

目的地还是过渡期？这里有一系列的选项，其中任何一个必定会帮助那些为Hadoop的采用而挣扎的组织。但是，虽然这些技术确实有助于采用熟悉的OLAP方法进行分析，并使其克服其规模限制，但它们并没有引导客户在其本地“栖息地”使用Hadoop和Spark。

有些顾客可能认为这是件好事。其他人可能认为这些产品是一种过渡性技术，在一段时间内是有用的。在过渡期间，员工可以习惯使用非结构化数据，并在建模之前进行分析，而不是相反。还有一些客户可能希望以更“本土化”的方式与大数据公司合作。最重要的是用户获得的功能，企业获得的投资回报，以及他们两者产生的结果。

披露：我工作的公司Datameer提供了一个业务用户工具和平台，用于使用不使用OLAP隐喻的大数据。