摘要: “万事皆项目”,这是为我们做PMP培训的姚老师当时说过的一句话,小到一个人在家里烧条鱼,大到国家举办奥运会,都可以以项目对待。做事要有章法,要有目标,事才能竟成。项目大小不同,对待方式也要不同。小事如烧鱼,时间管理、采购管理、质量管理、成本管理等可由你一人把握,虽说你在烧鱼时可能不曾想到这些管理,但它们却是真实存在的。要做一件多人参与的事,如装修房屋,必然要做好与相关人的沟通、采购好需要的资源、规划好做事的步骤等等,可能一位有能力的好领导也能将这些事情管理地井井有条。然而,要做凝聚数十数百甚至更多人智慧的大事,若是还没有这些先进的管理理论做支撑,那就很难做到人尽其才、物尽其用,那么离分崩离析也怕是不远了。 阅读全文
posted @ 2016-01-03 23:25 王安琪 阅读(2753) 评论(10) 推荐(1) 编辑
摘要: 在前篇博客里已经讲述了通过一个自定义 HBase Filter来获取数据的办法,在末尾指出此办法的性能是不能满足应用要求的,很显然对于如此成熟的HBase来说,高性能获取数据应该不是问题。下面首先简单介绍了搜索引擎的性能,然后详细说明了HBase与MySQL的性能对比,这里的数据都是经过实际的测试获得的。最后,给出了采用多线程批量从HBase中取数据的方案,此方案经过测试要比通过自定义Filter的方式性能高出很多。 阅读全文
posted @ 2015-01-23 22:33 王安琪 阅读(28611) 评论(5) 推荐(3) 编辑
摘要: 本篇是本人对Solr的使用进行的总结,具体包括使用DataImportHandler从数据库中近实时同步数据、测试Solr创建索引的性能、以及测试Solr的搜索效率等。 具体的搜索引擎概念、Solr搭建方法、数据库mysql使用方法,假设读者已有了基础。 阅读全文
posted @ 2014-05-21 21:20 王安琪 阅读(18013) 评论(21) 推荐(6) 编辑

@(hadoop)[Spark, MLlib, 数据挖掘, 关联规则, 算法]


〇、简介

经典的关联规则挖掘算法包括Apriori算法和FP-growth算法。Apriori算法多次扫描交易数据库,每次利用候选频繁集产生频繁集;而FP-growth则利用树形结构,无需产生候选频繁集而是直接得到频繁集,大大减少扫描交易数据库的次数,从而提高了算法的效率。但是apriori的算法扩展性较好,可以用于并行计算等领域。

关联规则的目的就是在一个数据集中找出项与项之间的关系,适用于在大数量的项集中发现关联共现的项。也被称为购物篮分析 (Market Basket analysis),因为“购物篮分析”很贴切的表达了适用该算法情景中的一个子集。

购物网站里你买了一个商品,旁边列出一系列买过该商品的人还买的其他商品,并且按置信度高低排序,一般会发现买手机的还会买充电器(买充电器的人不一定会买手机),买牙刷的还会买牙膏,这大概就是关联规则的用处。

基础环境:
CentOS-6.5
JDK-1.7
spark:spark-1.2.0+cdh5.3.6+379

一、Apriori算法

支持度(Support):定义为
$$supp(X) = \frac{包含X的记录数}{数据集记录总数}= P(X)=\frac{occur(X)}{count(D)}$$
置信度(Confidence): 定义为
$$ conf(X=>Y) = \frac{同时包含X和Y的记录数}{数据集中包含X的记录数}=P(Y|X)=\frac{P(X \cap Y)}{P(X)} = \frac{occur(X \cap Y)}{occur(X)}$$
FP-growth算法是Apriori算法的优化。

二、MLlib实现

spark-1.2.0 版本中Mliib的FPGrowthModel并没有generateAssociationRules(minConfidence)方法。因此要引用高版本的jar包,并在提交任务时指定才行。这是可以实现的。

Ⅰ、获取购买历史数据

下面共选取了6931条购买历史记录,作为关联规则挖掘的数据集。

1、产生源数据

我们可能需要使用类Mysql中的group_concat()来产生源数据。在Hive中的替代方案是concat_ws()。但若要连接的列是非string型,会报以下错误:Argument 2 of function CONCAT_WS must be "string or array<string>", but "array<bigint>" was found.。使用以下hiveSQL可以避免此问题:

SELECT concat_ws(',', collect_set(cast(item_id AS String))) AS items FROM ods_angel_useritem tb GROUP BY tb.user_id;

得到item1,item2,item3式数据结构。
数据结构如下所示:

731478,732986,733494
731353
732985,733487,730924
731138,731169
733850,733447
731509,730796,733487
731169,730924,731353
730900
733494,730900,731509
732991,732985,730796,731246,733850

2、构造JavaRDD

JavaRDD<List<String>> transactions = ...;

Ⅱ、过滤掉出现频率较低的数据

Java代码:

//设置频率(支持率)下限
FPGrowth fpg = new FPGrowth().setMinSupport(0.03).setNumPartitions(10);
FPGrowthModel<String> model = fpg.run(transactions);

List<FPGrowth.FreqItemset<String>> list_freqItem = model.freqItemsets().toJavaRDD().collect();
System.out.println("list_freqItem .size: " + list_freqItem .size());

for (FPGrowth.FreqItemset<String> itemset : list_freqItem) {
    System.out.println("[" + itemset.javaItems() + "], " + itemset.freq());
}

结果:

[[734902]], 275
[[733480]], 1051
[[734385]], 268
[[733151]], 895
[[733850]], 878
[[733850, 733480]], 339
[[733152]], 266
[[733230]], 243
[[731246]], 500
[[731246, 733480]], 233
[[734888]], 231
[[734894]], 483
[[733487]], 467
[[740697]], 222
[[733831]], 221
[[734900]], 333
[[731353]], 220
[[731169]], 311
[[730924]], 308
[[732985]], 212
[[732994]], 208
[[730900]], 291

$$\frac{208}{6931}=0.03001>0.03$$,6931是交易的订单数量,即数据源总条数。

可见,商品732994正好高于支持率下限。

Ⅲ、过滤掉可信度过低的判断

Java代码:

double minConfidence = 0.3; //置信下限
List<AssociationRules.Rule<String>> list_rule = model.generateAssociationRules(minConfidence).toJavaRDD().collect();
System.out.println("list_rule.size: " + list_rule.size());
for (AssociationRules.Rule<String> rule : list_rule) {
    System.out.println(
    rule.javaAntecedent() + " => " + rule.javaConsequent() + ", " + rule.confidence());
}

结果:

[733480] => [733850], 0.3225499524262607
[731246] => [733480], 0.466
[733850] => [733480], 0.38610478359908884
  1. $P(733850|733480)=\frac{occur(733850 \cap 733480)}{occur(733480)}=\frac{339}{1051}=0.3225499524262607$
  2. $P(733480|731246)=\frac{occur(733480 \cap 731246)}{occur(731246)}=\frac{233}{500}=0.466$
  3. $P(733480|733850)=\frac{occur(733850 \cap 733480)}{occur(733850)}=\frac{339}{878}=0.38610478359908884$

以上表明,用户在购买商品733480后往往还会购买商品733480,可信度为0.3225499524262607;用户在购买商品731246后往往还会购买商品731246,可信度为0.466;用户在购买商品733850后往往还会购买商品733480,可信度为0.38610478359908884。

三、提交任务

Ⅰ、Spark On Standalone

spark-submit --master spark://node190:7077 --class com.angel.mlib.FPGrowthTest --jars lib/hbase-client-0.98.6-cdh5.3.6.jar,lib/hbase-common-0.98.6-cdh5.3.6.jar,lib/hbase-protocol-0.98.6-cdh5.3.6.jar,lib/hbase-server-0.98.6-cdh5.3.6.jar,lib/htrace-core-2.04.jar,lib/zookeeper.jar,lib/spark-mllib_2.10-1.5.2.jar,lib/spark-core_2.10-1.5.2.jar spark-test-1.0.jar

Ⅱ、Spark On Yarn

spark-submit --master yarn-client --class com.angel.mlib.FPGrowthTest --jars lib/hbase-client-0.98.6-cdh5.3.6.jar,lib/hbase-common-0.98.6-cdh5.3.6.jar,lib/hbase-protocol-0.98.6-cdh5.3.6.jar,lib/hbase-server-0.98.6-cdh5.3.6.jar,lib/htrace-core-2.04.jar,lib/zookeeper.jar,lib/spark-mllib_2.10-1.5.2.jar,lib/spark-core_2.10-1.5.2.jar spark-test-1.0.jar

四、FPGrowth算法在现实中的应用调优

在实际情况中,真实的业务数据处处都是噪声。活用数据,设计有业务含义的特征体系,是构造鲁棒模型的基础!

具体的解决办法,我们可以多算法并用,这些将在后续的aitanjupt文章中详述。

五、综上所述

也就是说,“购买了该宝贝的人32%还购买了某某商品”就是使用商品关联规则挖掘实现的;还有一些捆绑销售,例如牙膏和牙刷一起卖,尿布和啤酒放在一起卖。

关联规则挖掘算法不只是能用在商品销售,使用它我们可以挖掘出更多的关联关系,比如我们可以挖掘出,温度、天气、性别等等与心情之间是否有关联关系,这是非常有意义的。

关联规则挖掘算法应用场景非常庞大,遥记多年前做的手机用户关联分析,那时尚未用到关联规则挖掘算法,用的是自己编写的类join算法,现在看起来,关联规则挖掘算法是再适合不过的了。

mllib

上面是mllib下所有的算法。
某一数据挖掘算法可以做某种特定的分析,也可以跨界使用,还可以联合应用,重要的是理解其思想以灵活运用。

幸福是有一颗感恩的心,健康的身体,称心的工作,一位深爱你的人,一帮信赖的朋友!
祝大家小年快乐!


作者 @王安琪
我的头像
http://www.cnblogs.com/wgp13x/
2016 年 02月 02日

posted @ 2016-02-02 10:55 王安琪 阅读(4938) 评论(0) 推荐(4) 编辑
摘要: Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的SQL查询功能,可以将SQL语句转换为MapReduce任务进行运行。 HBase(Hadoop Database),是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,只能通过Rowkey来取数据,无法进行SQL查询。 因此如果Hive可以从HBase中取数据,并结合Hive的SQL查询功能,便能做到较为复杂的SQL查询操作。 Impala对存储在HDFS、HBase的数据提供直接查询互动的SQL。除了像Hive使用相同的统一存储平台,Impala也使用相同的元数据,SQL语法(Hive SQL),ODBC驱动程序和用户界面(Hue Beeswax)。Impala还提供了一个熟悉的面向批量或实时查询和统一平台。达成目标:1、支持HBase多表联接查询等较复杂的SQL查询操作。 阅读全文
posted @ 2015-12-17 10:46 王安琪 阅读(4151) 评论(0) 推荐(3) 编辑
摘要: 本文先简单介绍了Sqoop和Hive\HBase,然后详细说明了Sqoop的使用方法,最后对当前大数据领域实践提出了自己的一些看法。 阅读全文
posted @ 2015-12-08 09:52 王安琪 阅读(34456) 评论(7) 推荐(6) 编辑
摘要: 管理、部署Hadoop集群需要工具,Cloudera Manager便是其一。本文先是简要对比了当前的类似工具,而后详细记录了以离线方式部署CDH集群的步骤。最后对“讲究”一词提出了自己的观点。 阅读全文
posted @ 2015-11-24 09:06 王安琪 阅读(4367) 评论(2) 推荐(3) 编辑
摘要: CSSDesk 使用Hive或Impala执行SQL语句,对存储在Elasticsearch中的数据操作使用Hive或Impala执行SQL语句,对存储在Elasticsearch中的数据操作Hive Impala Elasticsearch Hadoop SQL使用Hive或... 阅读全文
posted @ 2015-11-03 22:01 王安琪 阅读(2891) 评论(0) 推荐(0) 编辑
摘要: 我们的目标是:1. 支持Elasticsearch多表联接查询;2. 结合Elasticsearch搜索引擎提高SQL查询效率。Elasticsearch for Apache Hadoop能帮助我们实现这一目标吗?让我们拭目以待! 阅读全文
posted @ 2015-11-03 21:36 王安琪 阅读(9291) 评论(6) 推荐(3) 编辑
摘要: Deployment and Management of Hadoop clusters need tools, such as Cloudera Manager. In this article, I compare the tools briefly, and then record the step of deploying CDH cluster offline in detail. Finally, I expound the theory of 'handle delicately'. 阅读全文
posted @ 2015-10-22 21:56 王安琪 阅读(1001) 评论(0) 推荐(3) 编辑
摘要: 摘要:世上有三类书籍:1、介绍知识,2、阐述理论,3、工具书;世间也存在两类知识:1、技术,2、思想。以下是我在部署ElasticSearch集群时的经验总结,它们大体属于第一类知识“techknowledge(技术)”。但其中也穿插一些我个人的理解。敬请指正。 关键词:ElasticSearch, 搜索引擎, 集群, 大数据, Solr, 大数据 阅读全文
posted @ 2015-10-07 22:26 王安琪 阅读(9902) 评论(7) 推荐(6) 编辑
摘要: 如果没写单元测试,如若在branch中对之前代码重构的话,则没有移回trunck上的勇气,有了单元测试,全部运行通过后则有信心合并。互联网公司更是需要重视单元测试,因为版本迭代比较迅速。因此一个好的单元测试框架及一个好的项目质量管理非常重要。本文即是我对这些的心得体会。 阅读全文
posted @ 2015-09-01 17:08 王安琪 阅读(1896) 评论(8) 推荐(2) 编辑
点击右上角即可分享
微信分享提示