首先，定义给出，OLTP（on-line transaction process）联机事务处理，OLAP(on-line analytic process)联机分析处理。前者用于业务处理，强调系统的快速、稳定、以及一致性。后者用于企业分析处理，强调业务的表达以及分析交互性，后者的数据通常来源与前者。
他们的产生要追溯到蛮久之前了，最开始阶段，约莫60年代时，是只有OLTP的，发展到了90年代，93年的时候，跟现在很多企业以及能认识到的一样，关系数据库之父E.F.CODE认为OLTP已满足不了企业的数据查询分析统计等需求，提出了多维数据库多维分析的概念，他发表了OLAP的12项准则，由此OLAP的概念便慢慢被行业接受开来。
对应到我们现在的BI项目里，OLTP系统通常会指的是我们的各个业务系统，用户在其中每天进行着重复的操作，单据录入，档案维护，使得企业业务运营正常展开，OLAP系统可指我们的多维数据库，亦可以意指我们的BI系统，具体情况下会有不同意思。强调的是用于分析的系统，用于监控企业运用，发现问题，分析问题。
OLAP又可分为MOLAP、ROLAP、HOLAP，MOLAP存定义存聚合数，ROLAP通常存定义不存聚合（有时也有聚合表），HOLAP介于上述两者之间。
大概10年前的时候,MOLAP是很流行的，大部分项目中都要配置OLAP数据库，即多维数据库，那些年将BI的技术定义为三大块：数据仓库、OLAP、数据挖掘，也是这个情况了。十年河东十年河西，果然，现在很多企业都放弃了MOLAP，转向ROLAP产品了，这一状况，也与现在硬件的升级，内存等资源的性价比更合理有关。现在的主流产品，BIEE、BO、COGNOS的FM，都是类ROLAP的，微软SSAS、ORACEL收购的HYPERION的ESSBASE(不知还有无，以前真的很火），COGNOS TR，SAP BW等，都以MOLAP为基础的。至于现在新出现的Qlikview，设计为在内存中进行关联组合查询，就有点不太好归类了。

如果把商场比作战场，那么，BI其实就是一种情报分析工作。。对敌方的战略部署、武器装备如果了如指掌的话，那么我们就能在战场上立于能够俯视全局的战略制高点的位置。时下是大数据时代，如果依然沿用老式的报表堆积式的分析方法，虽然也能应付一些问题，但是如果战场上已经有人使用了BI。那么，杂乱无章的报表攻略就像在用烟花火箭筒对抗卫星定位导弹系统群，吓人还成，真刀真枪比拼起来可想而知其后果，所以古语有云：欲善其工，先利其器！不过，虽然Bi工作能分析很多事儿，是一个利器，却也仅仅是一个棋子，需要明智的布局才能尽情发挥其作用。。。所以也是需要领导们的得力群策才能得到立竿见影运筹帷幄的效果。

首先，“传统”这个词，是蛮有意思的，传统是相对的。
本来BI就是不断演化的，今日的“主流”，极有可能变成明日的“传统”。
譬如当年我们做OLAP的时候，感觉ROLAP和MOLAP，最开始Rolap是主流，然后Molap出现了，通过预计算用空间换取时间，一时风行；然后再过一阵，硬件性能发展了，Molap又有些没落转而流行Rolap了。是不是有些像是十年河东十年河西的样子。
 
关于敏捷BI ，我觉得是从敏捷开发这一概念中演化而来的。
敏捷BI更像是一种方法 ，与你列存储、分布式、基于什么架构无关的。这种方法强调需求的迭代，快速迭代，先出来一些东西，然后看看行不行，OK的话继续深化，有问题的话则完善修改，不行的话放弃也损失不大。一个主题的弄完再进行引入另外一块。
这与Kimball的数据集市建设方法论，是非常相似的。也与多年前我们常说BI项目的“整体规规划、分步实施”、“螺旋式上升”是契合的。
传统敏捷方法里的一些概念，如“轻文档”这个在敏捷BI中就需要慎重了。另外，原型图的做法也是一个好的手段。
还有一点，如果你是走Inmon的路子，搞EDW，那么敏捷还不一定好用。
因此 ，敏捷BI是为了更好的交付项目的一种方法论上的尝试。大部分工具都可以来承载以此种方式交付项目，但是有些老牌BI工具层次过多实现较慢，会影响到敏捷的效率。
 
而 探索式BI ，这个概念并不是一个全球范围内很同行说法，但是事实上确实会有很多类似的体会。
个人认为， 探索式BI，更像是在阐明一种态度 。
我们通过一定的方式，对业务进行分析，快速的试错，低成本的试错。这些方式可以是基于多维分析、或是基于即席查询，可以用Cube，也可以通过数据内在联系搭建语义层等来实现，这些方式之间有效率的差别。
探索式BI强调从业务角度出发，定位出问题所在原因，或是在你随意组合与拖拽中发现一些有意思或者是有启发的内容点。
从本质上来看，多维分析、即席查询、上钻下钻切片切块，这些经典的BI属于，用于探索，真的不算过时。
因此，探索式BI，是为了得到回答而不断尝试的一种态度。与工具有一定关系。工具能够支持前面所属的一些功能即可开始着手，只是支撑程度上可能会有差异。
 
在这之外，还会有些概念的，再介绍几点。
内存式BI ，这个也是近年来非常火的一个概念，以几款新兴的世界级的工具（具体可在Gartner象限图第一象限中找）为代表，掀起一阵小风暴。而这几年在国内也是颇为的火。
内存式BI，倒是实实在在有技术上的东西，它利用了当下内存成本的下降，将一定的基础数据加载到内存中去，再在用户查询的时候动态计算，返回结果，这是即时的计算，并非之前Schedule好数据并缓存下来的。与那些Rolap相比，数据直接在内存里计算，比在RDBMS里要快上很多。
当然，这些工具的内存式程度也会有纯内存式、半内存式乃至伪内存式。
因此，内存式BI，也可以算是BI上一类技术、一类工具吧。
 
还可以用一个概念去宣讲。那就是 全员BI 。这个概念指的是让企业各个层级的用户都能够动起来，使用BI系统，而且可以各取所需。说全员BI，主要的概念还是会以多维分析、即席查询类似概念，让一线执行层能够查询出数据、做些基础的分析，从繁重的汇总统计中释放出来。毕竟高层和中高层都是会有定制的应用的。想想，从上往下各个层级都能在BI系统中获益，全员BI，多么华丽丽。
 
好了，大概就聊到这儿，希望能对你有所帮助。

我来八一八吧。
OLAP，这个东西啊，他的出现有好些年头了，E.F.Codd都对OLAP好像有过12条定义，你有兴趣的话可以去看看。
OLAP是分ROLAP和MOLAP的，区别是ROLAP存汇总的定义不存数，而MOLAP存定义也存数了。
毫无疑问，ROLAP省空间，但是在机器性能不够好的时候会慢，而MOLAP费空间，但是速度会快一些（事实上，数据量太大的时候，两者都慢）。MOLAP走的是牺牲空间换取时间的路子。
因此呢，在OLAP发展的历程中，是十年河东十年河西再十年河东，最开始是ROLAP然后是火了MOLAP，然后现在机器性能上来之后又是ROLAP了。机器性能上来了，表现在HANA可以搞几个T的内存配置机器。而大数据平台下也有相应的OLAP方案了。
好了。你的问题
1、OLAP是为了大量数据的查询而生，这也不算错，不过我宁愿认为数据仓库系统或者决策支持系统（BI前身的术语）的出现，是做业务和做统计功能的分离的需要。好像也是E.F.Codd大神那么多年前提出来的，真的很多年。
OLAP的牛，在于它的多维，在于灵活的切片旋转上钻下钻。在于可以基于它让用户自己动起来。探索问题，定位原因。这个我以前有帖子说过，有空的话可以看看。 http://www.flybi.net/question/47
2、OLAP必然是基于数据仓库比较好。如果你做CUBE，MOLAP，则会基于数据仓库或者数据集市去加载CUBE。如果你用ROLAP，你最好基于数据仓库去建立语义层，譬如COGNOS的FM，BIEE和BO也有类似的层。
3、几十几百T的MOLAP，我估计一般服务器承载不了。或者ROLAP可以，毕竟你查询如果涉及到的数据量不大的时候应该还可以。
数据抽取没什么特别，制定好增量策略，没有谁会总是跑全量，因此你需要描述一下你的增量。
而且，并非业务系统里所有字段，所有表都是有必要进数仓的。
4、其他，也没太多了，其实OLAP理解了之后，真的很好学，也很好用，是BI里一个不过时的概念。多维的概念，理解了就好，非常的强大。曾经在一次，碰到客户一个高级总监，他一直说Root cause分析这些的，说到底，还是基于OLAP的多维分析再上钻下钻切片等。 现实世界很复杂，但是很多东西以多维的角度来理解，就发现会变简单很多。
 

可以查看一下附件内容，可以帮助你理解。

个人观点：
内存数据库的概念或者为什么要用内存数据库？ 因为内存数据库对于传统的存储方式来说数据直接存在内存中，内存的数据读写速度明显比从磁盘不断的拷贝要高出很多很多，性能得到极大的提升，所以它是以内存资源来换取数据处理的实时性的。
 
谈不上优劣势，因为要放在不同的场景下去考虑。在处理实时并发和处理场景下，内存数据库肯定有优势；但是作为大容量存储包括数据安全方面还是需要传统的磁盘式 OLTP 数据库。
 
比如说在断电或者宕机的情况下，内存数据库的风险就比传统的 OLTP 数据库要大很多。几乎像日常的事务系统，比如银行交易、医院信息、其它等大型事务系统它们的数据库肯定是采用的传统磁盘式数据库，即使用到内存数据库技术也一定需要有一套解决方案定期的将数据副本最终复制到磁盘系统。所以内存数据库更多的用在数据分析、报表系统，以大查询高聚集为主的分析应用的产品上。