最近，在网上读到了几个有趣的帖子，谈论在线分析处理  (OLAP) 的概念有多么古老，星型模型、多维分析和 cube 有多么过时。他们对企业中需要构建、维护和访问大数据平台的每个人夸下海口:使用他们的新款黑科技，你不再需要对数据进行建模，你可以抛弃 ETL，无论数据存储哪里，查询都可以即时得到结果。听起来简直美好得匪夷所思。

IT 是一个喜欢新鲜事物的行业，从不缺少值得学习和令人兴奋的新东西。坚持"老派"技术感觉一点都不酷。然而最近，我的朋友圈被一个帖子刷屏了，"SQL 是我在十多年的职业生涯中学到的最好的技能"引发了大量共鸣。可SQL早于1986年(按IT纪元大概是几百万年前吧)就首次成为ANSI 标准，一点都不新潮酷炫。

我记得多年前 NoSQL 风潮初起，我团队里的一些工程师同事都跃跃欲试：“写了这么多年SQL，终于可以换换口味了！”。不久之后发现现实很骨感，有人开始说哎呀不是“去SQL”（NoSQL）啦，而是“不仅仅用 SQL”(Not Only SQL)，又过了一阵，出现了“新SQL”（NewSQL)，大家又开始以支持SQL为卖点。

一个技术在 Gartner 的 HyperCycle上通过了所谓的"膨胀期望高峰"阶段后，人们终会意识到在新技术带来更多可能性之外，基于经典理论、经过实际验证、拥有众多拥趸的技术和方法可以是多么长青，能够继续为用户提供最佳价值。

如今，任何数据平台技术，如果它不能提供一个标准SQL接口，都不能声称自己是完整的(说的就是你，Druid)。

信息管理的现状

历史不会重演，但会雷同。同样的情况发生在了"数据湖"概念上，它承诺提供广泛的数据收集功能，以满足您的所有数据需求。这听起来很简单，你可以随时前来，只要带着你的收集数据用的“水杯”,在“数据湖”中获取一瓢“数据水”，以满足你对洞察的渴望。然而，未经过滤的水会让人生病，深不见底的湖水会淹没那些不会游泳的人。

未建模和不受管治的数据平台对每个人都是危险的。数据湖绝非一无是处，它在数据生态圈中占有重要的位置，但它不是银弹，不会自然而然地满足对大数据的所有需求。为了兑现申请IT预算时天花乱坠的诺言满足业务对于大数据的期望，我们需要克服几重障碍，其中之一就是确保最终用户从当今无处不在的数据海洋中能够简单而迅速地获得真正的价值。

评估其他大数据分析工具和技术

大多数人在处理大数据时都会经历类似的痛苦，比如海量数据查询速度慢、由于对稀缺系统资源的争用而导致的低并发，以及为了满足不同的数据需求而必须维护的异构系统，一般是历史遗留系统和新系统的混合体。

人们想出不同的办法来解决这些痛点，一些方法明显带有IT行业求"新"求"酷"的倾向。人们看不起"老派"的技术方案，如OLAP、cube和多维分析，认为它们已经廉颇老矣，就像MapReduce 出现时认为SQL将被抛弃的看法一样。但新技术就必然更好吗？

什么是OLAP？

近年才进入大数据和商业智能领域的朋友们可能已经不太熟悉 OLAP 一词，在此处先明确一下它的定义作为讨论的基础。

OLAP (在线分析处理的缩写) 是一种用于快速回答涉及多个维度的分析查询的方法。它通过将大型(有时是单独的)数据集聚合到称为OLAP  Cube（数据立方体）的多维数据库中来实现此目标。此OLAP Cube 经过优化，以便于分析，并可对来自不同角度的数据进行 "切片和分割"，从而获得优化的查询体验。

多年来，这种方法在商业智能分析中发挥了关键作用，尤其是在大数据方面。实践已经证明，采用数据聚合和预计算 OLAP 和 OLAP  Cube，能够避免困扰现代BI 工具和复杂大数据基础架构的一大基本难题：漫长的计算时间和缓慢的查询速度。如果您对现代大数据 OLAP 分析将是什么样子感到好奇，请查看我们关于该主题的最新文章: 

比较OLAP分析与其他现代方法

在我们深入了解 OLAP 技术方案为何仍然如此有价值之前，让我们就物理、数学和业务的一些基本定律达成一致:

• 内存速度更快，而且越来越便宜，但它无法与磁盘存储相比，它仍然是一种相对昂贵和稀缺的资源，即便在拥有闪存盘的今天。

• 对于具有不同性能/价格比的不同存储空间，始终会有一个权衡。在所有地方只使用最快(gui)的存储在商业上绝对不划算。

• 扫描更多数据将花费更长的时间/更多的资源。

• 网络吞吐量始终有一个上限。

• 如果乘数增长，乘积就会呈指数级增长。

• 大数据的博伊尔定律: 无论你的集群有多大，数据都会填满整个空间。

现在，让我们看看不同的方法是如何试图解决大数据的痛点，分析为什么它们还是无法彻底解决这些痛点:

内存引擎: 

将中间结果放入内存中，希望后续查询会复用它。这基于两点基本假设: 1) 因为内存速度快，所以查询速度快，2)类似缓存的机制可以通过复用以前的结果来加速类似的查询。但就像上面的基本规律所决定的，内存是有限的。缓存中间结果很容易导致内存不足（OOM）的出错，当查询过于天马行空时，缓存命中率很低，保质期很短。那么聪明如你应该想到，在一个较便宜较少限制的空间里，比如磁盘上，"物化"保留其中的一些结果，实际上某些声称自己是内存引擎的技术也正是这么干的。如果这样做，那基本上已经相当于在用这种方式做一些建模和OLAP了，只是没有定义或更改该模型的便利。

大规模并行处理 (MPP): 

分而治之。在较小的数据块上并行执行操作。这是一个非常靠谱的策略，Hadoop也是基于类似的基本概念，但它受到另一套基本规则的限制。当数据必须通过网络在集群系统中移动时，或者当多个用户在同一系统上同时执行各自单独的操作时，并发性会受到影响，所有人都会变慢。更糟糕的是，相似的查询会对相同的详细原始数据集进行重复搬运和扫描，浪费大量的系统资源。聪明如你又会想到，为什么不预先扫描和汇总这些类似查询的结果，之后的查询只需重用结果，省得反复扫描原始数据？答对了！这不就是OLAP嘛！

数据虚拟化: 

同样，另一个热门想法。如果能够实现，那会是你终极理想的数据平台，但引用纽约一家顶级银行的首席技术官的话说，至今这类技术"没有一个管用的"。问题在于系统并不总是能够从这里那里只获取小的聚合数据集，并将它们组合在虚拟层上。跨数据存储移动海量数据的性能也会非常低。

异构系统: 

从数据湖中提取数据，然后将其加载到基于关系型数据库（RDBMS）的数据仓库中进行分析（一大原因是RDBMS的SQL支持更全面更强大）。很多公司都在这样做，尤其是那些在采用Hadoop 和其他大数据技术之前就拥有传统数据仓库，遗留系统尾大不掉的公司。这种方案会带来额外的ETL 和高昂的维护成本，更有甚者，由于某些数据集太大而只能存在数据湖中，有些公司会额外增加ETL流程，从关系型数据库中获取数据又返回加载到数据湖中，以便和这些数据集整合。这种一团乱麻的双向ETL简直是数据运维团队的噩梦。

这些方法除了本身的一些短板外，他们都有一个共同的挑战: 数据治理。其中一些方法可以很容易地上手，并且无需建模，快速上生产系统，但如果用户定义自己的查询和指标，而没有人控制逻辑的一致性，则事情很快就会失控。

在一个机动性很强的创业公司环境中，一般有一两个专门的"数据服务员"向首席执行官和其他高管提供各种即席定制报告，对业务和KPI定义都在摸索状态。在这种业务敏捷性高优先级的环境中，一种灵活易上手的技术方案可以在初期提供很大的价值。但是，一旦有多个业务线和多个数据分析师时，无数据治理的潜在成本可能会对业务造成致命影响。

未来属于极速大数据OLAP分析

为什么 OLAP 分析在大数据时代仍然老当益壮、价值非凡？就像 SQL 一样，它基于一个坚实的理论，随着时间的推移，它已经被证明是通用的，在需求增加时，这个概念仍旧成立。人们真正抱怨的是老一代的OLAP 技术实现，如Cognos。这些老一代的技术实现需要严格的从头开始手动建模，Cube的大小极大限制了大数据背景下的使用场景，动辄成百上千新旧不一的Cube需要繁重的运维，架构无法纵向扩展、无法满足大数据量下构建、查询和并发的性能要求。

 Apache Kylin OLAP 架构

然而，像开源 Apache Kylin 及其商业版Kyligence这样的技术将经过验证的经典OLAP 理论和新的大数据和AI 技术相结合，创建了OLAP v2.0，成熟概念焕然新生。这种现代的OLAP引擎仍然建模，只是现在模型由AI自我学习和维护。它能够在单个Cube 中实现PB级数据横向扩展并支持数百个维度的组合，并利用底层大数据 MPP 系统的并行高性能来增量构建 Cube。更好的是，Kyligence引入了一个统一的语义层，用于组织模型和元数据，以支持企业级数据治理和单元格级数据安全。

我前面提到的其他方法都在大数据生态系统中占有一席之地，并且非常好地服务于一些应用场景，特别是在相对小的数据集上分析高度未定义的场景时。你可以将这些解决办法理解为"论次付费"模式，初始使用成本低，之后用得越多成本越高；而 OLAP 是“一口价”模式，一次投入（建模构建）后续使用基本免费，与使用量无关。对于任何拥有中大型数据量和超过十几个的数据用户的企业来说，“一口价”的总成本实际上更低。

由于您的数据预计只会增长，"论次付费"的方式会由于使用量的增长和逐渐上涨而非摊薄的“单价”导致更多的成本，且不论那些隐形的成本（如割裂的指标和延滞的决策带来的成本）。

本文的目的并不是想让大家在大数据的世界里避免新的或 "热门"的解决方案和方法，而一定倾向于成熟和经过测试的技术。事实上，尝试新事物往往是发现更好的解决方案的唯一途径。但于此同时，历史总是螺旋上升的，经典的理论和方法，在新环境下一样可以焕然新生，并证明自己的价值和普适性。

关于作者

顾全，数据平台资深从业者，Kyligence北美市场副总裁。

今天数据社收到了Kylin社区邮寄的5周年礼物，真是惊喜，感谢社区~

进群方式：请加微信（微信号：dataclub_bigdata），回复：加群，通过审核会拉你进群。

(备注：行业-职位-城市)

福利时刻

01. 后台回复「数据」,即可领取大数据经典资料。

02. 后台回复「转型」,即可传统数据仓库转型大数据必学资料。

03. 后台回复「加群」,或添加一哥微信ID：dataclub_bigdata  拉您入群（大数据|数仓|分析）或领取资料。

！关注不迷路~ 各种福利、资源定期分享！

你点的每个在看，我都认真当成了喜欢