了, 请教数据仓库技术可以解决,海量数据的查询效率有关问题吗

高分求教了, 请问数据仓库技术可以解决,海量数据的查询效率问题吗?
对数据仓库不甚了解,但是碰到了如下问题,不知道怎么解决.

大型电子商务平台,比如像阿里巴巴那样,达到几千万上亿的数据量,
1 浏览任何分类都能统计出所浏览的分类的数据量,它包含哪些下级分类,以及每个下级分类的数据量,
2 输入关键字查询的话,也能显示出那些包含关键字的分类,以及满足条件的数据量,
(注:它们的统计数据有时看起来不是很真实<实时>,但总的说来差别非常小.比如,经常看到类似这样的情况,某个分类的统计数据显示有123,但真正浏览页面查看时,只浏览到121条.)

在我们自己的设计中,采用常见的分类统计的查询语句(大致用这样的语句去查询:select ... from ... where ... group by ... order by ...),以及我们的硬件环境下,表数据量到100W时,查询速度就很难受了.已经做过了索引优化.

请问,像阿里巴巴那样很快的显示出统计数据,需要采用数据仓库技术吗?或者是别的技术?大至的情况如何?

[解决办法]


建议看一下数据仓库的原理。 所谓data warehouse或data mart 其实就是预先把这个交易数据记录提练成按不同维度的不同粒度的数据。这样当然就快了。

你的100W条交易记录，按照事先确定的方法，在数据仓库中可能也就几百条，或者几千条记录。
[解决办法]


数据仓库

数据仓库是一个面向主题的、集成的、不可更新的、随时间不断变化的数据集合，它用于支持企业或组织的决策分析处理。

数据仓库，英文名称为Data Warehouse，可简写为DW。
　　数据仓库之父Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

　　◆面向主题：操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。
　　◆集成的：数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
　　◆相对稳定的：数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
　　◆反映历史变化：数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。


从功能结构化分，数据仓库系统至少应该包含数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）三个关键部分。



[解决办法]


　　设计数据仓库的九个步骤
　　1)选择合适的主题（所要解决问题的领域） 
　　2)明确定义fact表 
　　3)确定和确认维 
　　4)choosing the facts 
　　5)计算并存储fact表中的衍生数据段 
　　6)roundingoutthedimensiontables 
　　7)choosingthedurationofthedatabase 
　　8)theneedtotrackslowlychangingdimensions 
　　9)确定查询优先级和查询模式。 

[解决办法]


1\我需要先明确,数据仓库技术能不能解决前面所提到的实际需求
-- 能。
2\如果能,我就往数据仓库方面深入,如果不能的话,我得寻找其他的解决方案
-- 如果只是为了这个，数据仓库就有些大材小用了。 你只要把常用的查询归纳一下，然后把这些记录每天自动的预处理一下。比如你的界面是有按商品名称查询。 则事先准备一张 
 商品名称，已销售数量 这样的表.这样当用户查询时，你只要直接从这张表中取数据就行了。
[解决办法]
针对你说的情况，数据仓库不能完全解决你的问题，但同时数据仓库是你解决这个问题的第一步。

也就是说，你需要
1、首先建立数据仓库，以用来数据清洗，同时保证大数据量查询的时候，不会影响业务数据库。
2、建立OLAP，也就是多维数据集，这个部分是将大量的合计和计算进行预先的加总，并且更改为多维度的存储模型，以实现从不同的维度快速的切入和展开。
3、建立终端展示平台，用来让最终使用者方便的查询和分析


其实说白了就是需要一个商业智能体系（也就是BI系统），所有大容量数据的机构，BI体系都是必不可少的系统，金融保险行业中，商业智能就是标配，随着其他行业的发展，现在各个行业都开始关注Bi系统了。感兴趣的话可以查查看这方面的资料
[解决办法]


如果查询都只是根据品名，分类来查。那就设计表

分类一，分类二，分类三， 数量
板鞋 鞋 成品鞋 871378
跑步鞋 鞋 成品鞋 646451
....

这样你的记录也就是商品最小分类的数量。每天，或每小时在后台利用程序更新一下。 而用户查的时候就快了。
[解决办法]
我可以肯定的说，商业智能可以解决你所说的需求，不过商业智能系统的成本比较高，是属于平台性的系统，架上商业智能体系后，还可以不断的扩充不同的应用在这个平台上。

我给你举个例子看看商业智能应用后的效果（这个效果是在建立数据仓库和OLAP之后，使用前端展示工具的效果）：
(见鬼的CSDN不让我传图片，用开心网上的相册吧)
上图左边的树形结构就是统计分析中的不同统计角度



上图表示出，通过拖拽，将统计的数据和统计的角度分别拉到报表中去，注意，由于有OLAP的支持，各种统计角度可以灵活的组合出你需要的报表



而你说的千变万化的条件的查询，对于商业智能体系来说，不过是最基本的功能（如上图），由于是经过多维化的处理，查询的速度肯定是可以符合用户的要求，不过也是有条件的，如果用户查询的是非常明细的数据，查询的速度也会相应的变慢，这个要看具体的项目使用具体的解决办法

------解决方案--------------------

探讨

谢谢,费心了.
接楼上问,那么商业智能分析的结果,程序通过什么方法能获取,也是sql语句吗?

[解决办法]

探讨

另外,为什么大家都在说商业智能来单纯用于解决我说的这类问题太浪废了?

这些,对于sqlserver2005/2008来说的话,不是自带的分析工具就能实现了吗?还需要别的什么软/硬条件?

[解决办法]

探讨

引用:

也就是说，如果想完全免费试用微软商业智能体系的话（前提是有买SQLServer，或者干脆是D版），也是可能的：
数据仓库：SQLServer数据库引擎
ETL： SQLServer IntergrationService
OLAP: SQLServer AnalysisService
前端： 使用ReportingService+浏览器(IE)



asp/asp.net/jsp/phpz这些脚本语言,能直接执行MDX语句,获取结果吗?

[解决办法]
面对变化的统计口径，仅采用匹配查询或模糊查询是无法做到的。因此可以这样认为出查询结果前，厂商提供了一个搜索引擎来分析用户输入的查询条件，确定选择那些数据库字段来执行此次查询。暂就称为命中概率问题吧，这种统计可能不精确，仅有参考价值。所以如果仅仅靠有限的几个人是不太能在短期内完成的。
[解决办法]
呵呵，我也来说说。


我们现在做的项目也称为商业智能，但是不是严格意义上的商业智能，是个半吊子的东西。
不过可能有一点是共通的，就是数据量大，当然，比阿里巴巴要查很远。而且没有阿里巴巴那样24小时运营。
数据是TB级的，日增量大概在10G。随便一个（逻辑上的一个）业务表的数据都是在亿条级别的。

引用

大型电子商务平台,比如像阿里巴巴那样,达到几千万上亿的数据量,
1 浏览任何分类都能统计出所浏览的分类的数据量,它包含哪些下级分类,以及每个下级分类的数据量,
2 输入关键字查询的话,也能显示出那些包含关键字的分类,以及满足条件的数据量,
(注:它们的统计数据有时看起来不是很真实 <实时>,但总的说来差别非常小.比如,经常看到类似这样的情况,某个分类的统计数据显示有123,但真正浏览页面查看时,只浏览到121条.)

[解决办法]
这个问题，去问问 http://www.dbanotes.net/ ，看看他是不是心情好能仔细回答一下，呵呵。
不过重点的问题要是6楼及下面的那些，1楼的太泛泛了。
[解决办法]
这个数据仓库肯定是需要的,但不仅仅是它.他还需要一套查询分析分类算法,它不是简单的group by,即使数据仓库内容一样,用各个商务站点的搜索引擎得到的结果也不一样,因此如何实现查询分析分类算法是关键,而且这个随着时间的推移,是需要不断完善的.
[解决办法]
这个不是数据仓库，或者数据库能直接去解决的问题。这是一个机器+人工的过程。 
首先，程序会对输入的关键字进行分词，比如说 "运动鞋"，分成 "运动"和"鞋"，然后再分别去查关键字。 
这是一个机器分拣的过程，而这之后，应该会有个人工的过程。去进一步鉴定，比如你看到 
钥匙配饰(274) 球服、球裤(251)，这两个应该不会出现在鞋子里面把？这里面更关键的应该是算法。 
"运动"和"鞋"从字面上无论如何也关联不到上面两个类别，于是，这个应该是其他类别（上级类别，上级类别的关联类别，或者是人工权重）关联出来的。
[解决办法]
我简单再总结一下，当然，相比我在19楼的说法，并没有新的建议。

结果表，可以这么说。
当然，实际层次可能要比这个复杂得很多。

这个表的设置，只是存储用户在实际保存时，所选用的分类的一个聚合。
这个阶段它并不需要关心，用户在实际过滤时选择了什么条件。这只是一个数据基础。
而无论用户选择了什么条件，数据都是依赖这个表出来的。
（当然，实际过程中，可能会为了查询便利，需要做一些冗余的字段）

这个表有了以后，就是一个怎么出的问题，也就是怎么根据用户的过滤条件出来。
之所以说商业智能之类也不能直接解决这个问题，也是从这里来的。
因为你的查询，不是一个简单的=或like，而是一个关联的。
这种关联，应该没有一个直接的（商业智能）工具可以直接做出来。
就像前面说的，分词是第一重，人工权重是第二重。或者还有其他的方法。

对于一个商用网站来说，分类纯依靠算法，应该是不可靠的。还要有一个人工确认和调整的过程。

差不多就这样了，再另外赠送个野路子，呵呵。

1：仍以“运动鞋”为例，分词是必须的。拆成“运动”和“鞋”，然后到我们的汇总表里找。
2：网站的一级和二级大类，应该是网站预设好的，我们找到“运动”和“鞋”相关的子类后
往上走一个级别，找到这些子类上的大类。然后随机取几个该大类中有的，但是不包含在我们已选出来的子类中的类别
然后组合出来呈现就可以了。
这样既有严格意义上查询出来的数据，又有没有直接关系，但是有好像有关系的数据
这样也给用户一种很酷的感觉，而且因为是近似类别的数据，所以也不会有大的偏差。

毕竟，就像你给的阿里巴巴的示例一样，它的那个，也不是绝对精确的，不是吗？呵呵。
而淘宝的例子，就简单的多了，他的关键字，主要是“鞋”。
这个在分词的时候会权重的，也就是说，“运动”和“鞋”，“鞋”的权重更大。所以出来的分类，以“鞋”为主。


而从这些角度来说，
如果你只是需要处理这一种业务逻辑的话。
用不着商业智能或者数据仓库，还是用数据库就能解决的，呵呵。
毕竟商业智能的东西，动辄也是百万级别了。
仅对这个问题来说，关键是想法和做法，而不是去用什么量级的产品。

就这样了，不炫，但应该还是相对实用的一种问题的解决方法。
[解决办法]
回复了半天，楼主还是回到原点了，呵呵。

海量数据，实时汇总是不太现实的，所以会有个抽取，汇总的过程。也就是你说的“预先”。
这个并不需要“预先知道”过滤条件，我们只是对现在数据中实际存在的类别汇总出来而已。
这个汇总出来的是数据基础，跟条件，没有任何关系。也不是所有可能的词都汇总，那没意义，而且基本上也做不到。



------解决方案--------------------

实时汇总，需要看什么层面的了，BI可以解决一部分
[解决办法]
数据仓库解决这个问题、得心应手啊
效率百倍、千倍、万倍于自己做GROUP BY，呵呵
[解决办法]
如果是解决海量数据快速和能够查询的问题，在不计成本的前提下，可以用teradata实现

这是我接触的最好办法，也是最贵的
[解决办法]

探讨

1\我需要先明确,数据仓库技术能不能解决前面所提到的实际需求
2\如果能,我就往数据仓库方面深入,如果不能的话,我得寻找其他的解决方案

请已经深入了解数据仓库的朋友,帮忙解答,先谢过了

[解决办法]
还是要硬件跟得上才行，我做过移动的项目，话单表都是好几亿条记录，检索一条记录加上并行度也就10来秒，还没有索引。

数据仓库里大都是没有索引的，基本上每日都要装载数据，加索引成本太高。

貌似有不少人不懂装懂啊，数据仓库其实也是数据库，也是普通的select语句，无非是是通过etl做了不同维度的转换罢了。
[解决办法]
硬件+cubes结构
[解决办法]
广义上的数据仓库设计好是完全可以的，像我上一个项目，几千万条记录，上千个字段，一般查记录简单的只需要三四十毫秒复杂的不超过20秒。

查看更多 下一篇