Hadoop Mapreduce本地调试
http://blog.csdn.net/ymh198816/article/details/51169698

HBase数据模型解析和基本的表设计分析
http://blog.csdn.net/ymh198816/article/details/51244911
对rowkey使用md5并不是为了加密，rowkey是唯一索引，对索引加密之后如何做查询？实际使用中做索引的数值可能是有规律递增的，直接用这个做rowkey会使得新插入的大量数据很有可能被插入到同一个region上，而其他region空闲，这样读和写都产生了热点，影响读写效率。对rowkey使用md5或者其他hash做散列之后再和原来的rowkey组合作为实际的rowkey，这样在持续产生数据的时候rowkey会被散列到不同的region上，有效避免热点问题。总之就是使用md5或者其他方式进行hash散列，避免数据持续产生是插入同一个region。

Flume+Hadoop+Hive的离线分析系统基本架构
http://blog.csdn.net/ymh198816/article/details/51540715

Flume+Kafka+Storm+Redis实时分析系统基本架构
今天作者要在这里通过一个简单的电商网站订单实时分析系统和大家一起梳理一下大数据环境下的实时分析系统的架构模型。当然这个架构模型只是实时分析技术的一个简单的入门级架构，实际生产环境中的大数据实时分析技术还涉及到很多细节的处理, 比如使用Storm的ACK机制保证数据都能被正确处理, 集群的高可用架构, 消费数据时如何处理重复数据或者丢失数据等问题，根据不同的业务场景，对数据的可靠性要求以及系统的复杂度的要求也会不同。这篇文章的目的只是带大家入个门，让大家对实时分析技术有一个简单的认识，并和大家一起做学习交流。
文章的最后还有Troubleshooting，分享了作者在部署本文示例程序过程中所遇到的各种问题和解决方案。
1.系统基本架构

整个实时分析系统的架构就是先由电商系统的订单服务器产生订单日志, 然后使用Flume去监听订单日志，并实时把每一条日志信息抓取下来并存进Kafka消息系统中, 接着由Storm系统消费Kafka中的消息，同时消费记录由Zookeeper集群管理，这样即使Kafka宕机重启后也能找到上次的消费记录，接着从上次宕机点继续从Kafka的Broker中进行消费。但是由于存在先消费后记录日志或者先记录后消费的非原子操作，如果出现刚好消费完一条消息并还没将信息记录到Zookeeper的时候就宕机的类似问题，或多或少都会存在少量数据丢失或重复消费的问题, 其中一个解决方案就是Kafka的Broker和Zookeeper都部署在同一台机子上。接下来就是使用用户定义好的Storm Topology去进行日志信息的分析并输出到Redis缓存数据库中(也可以进行持久化)，最后用Web APP去读取Redis中分析后的订单信息并展示给用户。之所以在Flume和Storm中间加入一层Kafka消息系统，就是因为在高并发的条件下, 订单日志的数据会井喷式增长，如果Storm的消费速度(Storm的实时计算能力那是最快之一,但是也有例外, 而且据说现在Twitter的开源实时计算框架Heron比Storm还要快)慢于日志的产生速度，加上Flume自身的局限性，必然会导致大量数据滞后并丢失，所以加了Kafka消息系统作为数据缓冲区，而且Kafka是基于log File的消息系统，也就是说消息能够持久化在硬盘中，再加上其充分利用Linux的I/O特性,提供了可观的吞吐量。架构中使用Redis作为数据库也是因为在实时的环境下，Redis具有很高的读写速度。

2.业务背景

各大电商网站在合适的时间进行各种促销活动已是常态，在能为网站带来大量的流量和订单的同时，对于用户也有不小的让利，必然是大家伙儿喜闻乐见的。在促销活动期间，老板和运营希望能实时看到订单情况，老板开心，运营也能根据实时的订单数据调整运营策略，而让用户能实时看到网站的订单数据，也会勾起用户的购买欲。但是普通的离线计算系统已然不能满足在高并发环境下的实时计算要求，所以我们得使用专门实时计算系统,如:Storm, Heron, Spark Stream等,去满足类似的需求。
既然要分析订单数据，那必然在订单产生的时候要把订单信息记录在日志文件中。本文中，作者通过使用log4j2，以及结合自己之前开发电商系统的经验，写了一个订单日志生成模拟器，代码如下，能帮助大家随机产生订单日志。下面所展示的订单日志文件格式和数据就是我们本文中的分析目标，本文的案例中用来分析所有商家的订单总销售额并找出销售额钱20名的商家。

订单日志生成程序：
使用log4j2将日志信息写入文件中，每小时滚动一次日志文件

agent.sinks.target.topic = bigdata

agent.sinks.target.brokerList=localhost:9092
agent.sinks.target.requiredAcks=1
agent.sinks.target.batchSize=100
agent.sinks.target.channel = memorychannel

这里需要注意的是,在日志服务器端的Flume agent中我们配置了一个interceptors，这个是用来为Flume Event(Flume Event就是拉取到的一行行的日志信息)的头部添加key为“topic”的K-V键值对，这样这条抓取到的日志信息就会根据topic的值去到Kafka中指定的topic消息池中，当然还可以为Flume Event额外配置一个key为“Key”的键值对，Kafka Sink会根据key“Key”的值将这条日志信息下沉到不同的Kafka分片上，否则就是随机分配。在Kafka集群端的Flume配置里，有几个重要的参数需要注意，“topic”是指定抓取到的日志信息下沉到Kafka哪一个topic池中，如果之前Flume发送端为Flume Event添加了带有topic的头信息，则这里可以不用配置；brokerList就是配置Kafka集群的主机地址和端口；requireAcks=1是配置当下沉到Kafka的消息储存到特定partition的leader中成功后就返回确认消息，requireAcks=0是不需要确认消息成功写入Kafka中，requireAcks=-1是指不光需要确认消息被写入partition的leander中，还要确认完成该条消息的所有备份；batchSize配置每次下沉多少条消息，每次下沉的数量越多延迟也高。
4.Kafka消息系统

这一部分我们将谈谈Kafka的配置和使用，Kafka在我们的系统中实际上就相当于起到一个数据缓冲池的作用, 有点类似于ActiveQ的消息队列和Redis这样的缓存区的作用，但是更可靠，因为是基于log File的消息系统，数据不容易丢失，以及能记录数据的消费位置并且用户还可以自定义消息消费的起始位置，这就使得重复消费消息也可以得以实现，而且同时具有队列和发布订阅两种消息消费模式，十分灵活，并且与Storm的契合度很高，充分利用Linux系统的I/O提高读写速度等等。另一个要提的方面就是Kafka的Consumer是pull-based模型的，而Flume是push-based模型。push-based模型是尽可能大的消费数据，但是当生产者速度大于消费者时数据会被覆盖。而pull-based模型可以缓解这个压力，消费速度可以慢于生产速度，有空余时再拉取那些没拉取到的数据。

Kafka是一个分布式的高吞吐量的消息系统，同时兼有点对点和发布订阅两种消息消费模式。Kafka主要由Producer，Consumer和Broker组成。Kafka中引入了一个叫“topic”的概念，用来管理不同种类的消息，不同类别的消息会记录在到其对应的topic池中，而这些进入到topic中的消息会被Kafka写入磁盘的log文件中进行持久化处理。Kafka会把消息写入磁盘的log file中进行持久化对于每一个topic里的消息log文件，Kafka都会对其进行分片处理，而每一个消息都会顺序写入中log分片中，并且被标上“offset”的标量来代表这条消息在这个分片中的顺序，并且这些写入的消息无论是内容还是顺序都是不可变的。所以Kafka和其它消息队列系统的一个区别就是它能做到分片中的消息是能顺序被消费的，但是要做到全局有序还是有局限性的，除非整个topic只有一个log分片。并且无论消息是否有被消费，这条消息会一直保存在log文件中，当留存时间足够长到配置文件中指定的retention的时间后，这条消息才会被删除以释放空间。对于每一个Kafka的Consumer，它们唯一要存的Kafka相关的元数据就是这个“offset”值，记录着Consumer在分片上消费到了哪一个位置。通常Kafka是使用Zookeeper来为每一个Consumer保存它们的offset信息，所以在启动Kafka之前需要有一个Zookeeper集群;而且Kafka默认采用的是先记录offset再读取数据的策略，这种策略会存在少量数据丢失的可能。不过用户可以灵活设置Consumer的“offset”的位置，在加上消息记录在log文件中，所以是可以重复消费消息的。log的分片和它们的备份会分散保存在集群的服务器上，对于每一个partition，在集群上都会有一台这个partition存在的服务器作为leader，而这个partitionpartition的其它备份所在的服务器做为follower，leader负责处理关于这个partition的所有请求，而follower负责这个partition的其它备份的同步工作，当leader服务器宕机时，其中一个follower服务器就会被选举为新的leader。

一般的消息系统分为两种模式，一种是点对点的消费模式，也就是queuing模式，另一种是发布订阅模式，也就是publish-subscribe模式，而Kafka引入了一个Consumer Group的概念，使得其能兼有两种模式。在Kafka中，每一个consumer都会标明自己属于哪个consumer group，每个topic的消息都会分发给每一个subscribe了这个topic的所有consumer group中的一个consumer实例。所以当所有的consumers都在同一个consumer group中，那么就像queuing的消息系统，一个message一次只被一个consumer消费。如果每一个consumer都有不同consumer group，那么就像public-subscribe消息系统一样，一个消息分发给所有的consumer实例。对于普通的消息队列系统，可能存在多个consumer去同时消费message，虽然message是有序地分发出去的，但是由于网络延迟的时候到达不同的consumer的时间不是顺序的，这时就失去了顺序性，解决方案是只用一个consumer去消费message，但显然不太合适。而对于Kafka来说，一个partiton只分发给每一个consumer group中的一个consumer实例，也就是说这个partition只有一个consumer实例在消费，所以可以保证在一个partition内部数据的处理是有序的，不同之处就在于Kafka内部对消息进行了分片处理，虽然看上去也是单consumer的做法，但是分片机制保证了并发消费。如果要做到全局有序，那么整个topic中的消息只有一个分片，并且每一个consumer group中只能有一个consumer实例。这实际上就是彻底牺牲了消息消费时的并发度。

Kafka的配置和部署十分简单
1. 首先启动Zookeeper集群，Kafka需要Zookeeper集群来帮助记录每一个Consumer的offset
2. 为集群上的每一台Kafka服务器单独配置配置文件，比如我们需要设置有两个节点的Kafka集群，那么节点1和节点2的最基本的配置如下：

config/server-1.properties:
broker.id=1
listeners=PLAINTEXT://:9093
log.dir=export/data/kafka
zookeeper.connect=localhost:2181

config/server-2.properties:
broker.id=2
listeners=PLAINTEXT://:9093
log.dir=/export/data/kafka
zookeeper.connect=localhost:2181
broker.id是kafka集群上每一个节点的单独标识，不能重复;listeners可以理解为每一个节点上Kafka进程要监听的端口，使用默认的就行; log.dir是Kafka的log文件(记录消息的log file)存放目录; zookeeper.connect就是Zookeeper的URI地址和端口。
3. 配置完上面的配置文件后，只要分别在节点上输入下面命令启动Kafka进程就可以使用了

bin/kafka-server-start.sh config/server-1.properties &
…
bin/kafka-server-start.sh config/server-2.properties &
…
5.Storm实时计算框架
接下来开始介绍本篇文章要使用的实时计算框架Storm。Strom是一个非常快的实时计算框架，至于快到什么程度呢？官网首页给出的数据是每一个Storm集群上的节点每一秒能处理一百万条数据。相比Hadoop的“Mapreduce”计算框架，Storm使用的是”Topology”；Mapreduce程序在计算完成后最终会停下来，而Topology则是会永远运行下去除非你显式地使用“kill -9 XXX”命令停掉它。和大多数的集群系统一样，Storm集群也存在着Master节点和Worker节点，在Master节点上运行的一个守护进程叫“Nimbus”，类似于Hadoop的“JobTracker”的功能，负责集群中计算程序的分发，任务的分发，监控任务和工作节点的运行情况等；Worker节点上运行的守护进程叫“Supervisor”，负责接收Nimbus分发的任务并运行，每一个Worker上都会运行着Topology程序的一部分，而一个Topology程序的运行就是由集群上多个Worker一起协同工作的。值得注意的是Nimubs和Supervisor之间的协调工作也是通过Zookeeper来管理的，Nimbus和Supervisor自己本身在集群上都是无状态的，它们的状态都保存在Zookeeper上，所以任何节点的宕机和动态扩容都不会影响整个集群的工作运行，并支持fast-fail机制。

Storm有一个很重要的对数据的抽象概念，叫做“Stream”，我们姑且称之为数据流，数据流Stream就是由之间没有任何关系的松散的一个一个的数据元组“tuples”所组成的序列。要在Storm上做实时计算，首先你得有一个计算程序，这就是“Topology”，一个Topology程序由“Spout”和“Bolt”共同组成。Storm就是通过Topology程序将数据流Stream通过可靠(ACK机制)的分布式计算生成我们的目标数据流Stream，就比如说把婚恋网站上当日注册的所有用户信息数据流Stream通过Topology程序计算出月收入上万年龄在30岁以下的新的用户信息流Stream。在我们的文章中，Spout就是实现了特定接口的Java类，它相当于数据源，用于产生数据或者从外部接收数据；而Bolt就是实现了Storm Bolt接口的Java类，用于消费从Spout发送出来的数据流并实现用户自定义的数据处理逻辑；对于复杂的数据处理，可以定义多个连续的Bolt去协同处理。最后在程序中通过Spout和Bolt生成Topology对象并提交到Storm集群上执行。

tuples是Storm的数据模型,，由值和其所对应的field所组成，比如说在Spout或Bolt中定义了发出的元组的field为：(name,age,gender)，那么从这个Spout或Bolt中发出的数据流的每一个元组值就类似于(”刘建涛”,25,”男”)。在Storm中还有一个Stream Group的概念，它用来决定从Spout或或或Bolt组件中发出的tuples接下来应该传到哪一个组件中或者更准确地说在程序里设置某个组件应该接收来自哪一个组件的tuples; 并且在Storm中提供了多个用于数据流分组的机制，比如说shuffleGrouping，用来将当前组件产生的tuples随机分发到下一个组件中，或者 fieldsGrouping，根据tuples的field值来决定当前组件产生的tuples应该分发到哪一个组件中。

另一部分需要了解的就是Storm中tasks和workers的概念。每一个worker都是一个运行在物理机器上的JVM进程，每个worker中又运行着多个task线程，这些task线程可能是Spout任务也可能是Bolt任务，由Nimbus根据RoundRobin负载均衡策略来分配，而至于在整个Topology程序里要起几个Spout线程或Bolt线程，也就是tasks，由用户在程序中设置并发度来决定。

Storm集群的配置文件如下：
Storm的配置文件在项目的conf目录下，也就是:conf/storm.yaml

# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

##### These MUST be filled in for a storm configuration

storm.zookeeper.servers:
- “ymhHadoop”
- “ymhHadoop2”
- “ymhHadoop3”

storm.local.dir: “/export/data/storm/workdir”

nimbus.host: “ymhHadoop”

supervisor.slots.ports:
-6700
-6701
-6702
-6703

storm.zookeeper.servers自然就是用来配置我们熟悉的Zookeeper集群中各个节点的URI地址和端口的
storm.local.dir 是用来配置storm节点相关文件的存储目录的，每一个storm集群的节点在本地服务器上都要有一个目录存储少量的和该节点有关的一些信息。记得要开发这个目录的读写权限哦
nimbus.host 自然就是用来指定nimbus服务器的URI的
supervisor.slots.ports 这个是用来配置supervisor服务器启动的worker所监听的端口，每一个worker就是一个物理的JVM进程。

上面这些是基本配置，并且要严格按照上面的格式来，少一个空格都会报错。
接下来就是将配置文件拷贝到集群的各个机器上，然后在分别在nimbus和supervisor机器上通过bin/stormnimbus和bin/storm nimbus 和 bin/storm supervisor命令来启动集群上的机子。最后在nimbus上通过$bin/storm UI 命令可以启动Storm提供的UI界面，功能十分强大，可以监控集群上各个节点的运行状态，提交Topology任务，监控Topology任务的运行情况等。这个UI界面可以通过http://{nimbus host}:8080的地址访问到。
6.Redis数据库

Redis是一个基于内存的多种数据结构的存储工具，经常有人说Redis是一个基于key-value数据结构的缓存数据库，这种说法必然是不准确的，Key-Value只是其中的一种数据结构的实现，Redis支持Strings，hashes，lists，sets，sorted sets等多种常见的数据结构，并提供了功能强大的范围查询，以及提供了INCR，INCRBY,DECR,DECRBY等多种原子命令操作，保证在并发的环境下不会出现脏数据。虽然Redis是基于内存的数据库，但也提供了多种硬盘持久化策略，比如说RDB策略，用来将某个时间点的Redis的数据快照存储在硬盘中，或者是AOF策略，将每一个Redis操作命令都不可变的顺序记录在log文件中，恢复数据时就将log文件中的所有命令顺序执行一遍等等。Redis不光可以作为网站热点数据的缓存服务器，还可以用来做数据库，或者消息队列服务器的broker等。在本文中选择Redis作为订单分析结果的存储工具，一方面是其灵活的数据结构和强大的数据操作命令，另一方面就是在大数据的实时计算环境下，需要Redis这样的具备高速I/O的数据库。

在本文的例子中，作者使用Sorted Sets数据结构来存储各个商家的总订单销售额，Sorted Sets数据结构由Key, Score，element value三部分组成，Set的数据结构保证同一个key中的元素值不会重复，而在Sorted Sets结构中是通过 Score来为元素值排序，这很自然地就能将各个商家的总订单销售额设置为Score，然后商家名称为element value，这样就能根据总订单销售额来为商家排序。在Storm程序中，我们通过Jedis API来调用Redis的
$ZINCRBY KEY INCREMENT MEMBER
的命令来统计商家总销售额, ZINCRBY是一个原子命令，能保证在Storm的并发计算的环境下，正确地增加某个商家的Score的值，也就是它们的订单总销售额。而对于两个商家同名这种情况应该在业务系统中去避免而不应该由我们的数据分析层来处理。最后提一个小trips，就是如果所有商家的Score都设置成相同的分数，那么Redis就会默认使用商家名的字母字典序来排序。
7.Kafka+Storm+Redis的整合

当数据被Flume拉取进Kafka消息系统中，我们就可以使用Storm来进行消费，Redis来对结果进行存储。Storm对Kafka有很好的兼容性，我们可以通过Kafka Spout来从Kafka中获取数据；在Bolt处理完数据后，通过Jedis API在程序中将数据存储在Redis数据库中。

下面就是Kafka Spout和创建Topology的程序代码:

BrokerHosts hosts = new ZkHosts(“ymhHadoop:2181,ymhHadoop2:2181,ymhHadoop3:2181”);
zkHosts是用来指定Zookeeper集群的节点的URI和端口，而Zookeeper集群是用来记录Spout对Kafka消息消费的offset位置

spoutConfig.scheme = new SchemeAsMultiScheme(new StringScheme());
主要是用来将Spout从Kafka拉取来的byte[]数组格式的数据转化为Storm的tuples

package com.guludada.ordersanalysis;

import java.util.UUID;

import backtype.storm.Config;
import backtype.storm.LocalCluster;
import backtype.storm.StormSubmitter;
import backtype.storm.generated.AlreadyAliveException;
import backtype.storm.generated.InvalidTopologyException;
import backtype.storm.spout.SchemeAsMultiScheme;
import backtype.storm.topology.TopologyBuilder;
import backtype.storm.tuple.Fields;
import storm.kafka.Broker;
import storm.kafka.BrokerHosts;
import storm.kafka.KafkaSpout;
import storm.kafka.SpoutConfig;
import storm.kafka.StaticHosts;
import storm.kafka.StringScheme;
import storm.kafka.ZkHosts;
import storm.kafka.trident.GlobalPartitionInformation;

public class ordersAnalysisTopology {

private static String topicName = "ordersInfo";
private static String zkRoot = "/stormKafka/"+topicName;  public static void main(String[] args) {  BrokerHosts hosts = new ZkHosts("ymhHadoop:2181,ymhHadoop2:2181,ymhHadoop3:2181");  SpoutConfig spoutConfig = new SpoutConfig(hosts,topicName,zkRoot,UUID.randomUUID().toString());  spoutConfig.scheme = new SchemeAsMultiScheme(new StringScheme());  KafkaSpout kafkaSpout = new KafkaSpout(spoutConfig);  TopologyBuilder builder = new TopologyBuilder();          builder.setSpout("kafkaSpout",kafkaSpout);          builder.setBolt("merchantsSalesBolt", new merchantsSalesAnalysisBolt(), 2).shuffleGrouping("kafkaSpout");  Config conf = new Config();  conf.setDebug(true);  if(args != null && args.length > 0) {  conf.setNumWorkers(1);  try {  StormSubmitter.submitTopologyWithProgressBar(args[0], conf, builder.createTopology());  } catch (AlreadyAliveException e) {  // TODO Auto-generated catch block  e.printStackTrace();  } catch (InvalidTopologyException e) {  // TODO Auto-generated catch block  e.printStackTrace();  }  } else {  conf.setMaxSpoutPending(3);  LocalCluster cluster = new LocalCluster();  cluster.submitTopology("ordersAnalysis", conf, builder.createTopology());  }  }

}

下面是Bolt程序，主要是用来处理从Kafka拉取到的订单日志信息, 并计算出所有商家的总订单收入，然后使用Jedis API将计算结果存入到Redis数据库中。

package com.guludada.domain;

import java.util.ArrayList;
import java.util.Date;

public class ordersBean {

Date createTime = null;
String number = "";
String paymentNumber = "";
Date paymentDate = null;
String merchantName = "";
ArrayList<skusBean> skuGroup = null;
float totalPrice = 0;
float discount = 0;
float paymentPrice = 0;  public Date getCreateTime() {  return createTime;
}
public void setCreateTime(Date createTime) {  this.createTime = createTime;
}
public String getNumber() {  return number;
}
public void setNumber(String number) {  this.number = number;
}
public String getPaymentNumber() {  return paymentNumber;
}
public void setPaymentNumber(String paymentNumber) {  this.paymentNumber = paymentNumber;
}
public Date getPaymentDate() {  return paymentDate;
}
public void setPaymentDate(Date paymentDate) {  this.paymentDate = paymentDate;
}
public String getMerchantName() {  return merchantName;
}
public void setMerchantName(String merchantName) {  this.merchantName = merchantName;
}
public ArrayList<skusBean> getSkuGroup() {  return skuGroup;
}
public void setSkuGroup(ArrayList<skusBean> skuGroup) {  this.skuGroup = skuGroup;
}
public float getTotalPrice() {  return totalPrice;
}
public void setTotalPrice(float totalPrice) {  this.totalPrice = totalPrice;
}
public float getDiscount() {  return discount;
}
public void setDiscount(float discount) {  this.discount = discount;
}
public float getPaymentPrice() {  return paymentPrice;
}
public void setPaymentPrice(float paymentPrice) {  this.paymentPrice = paymentPrice;
}

}
本文例子中用不到skusbean，所以这里作者就没有写偷懒一下下

package com.guludada.domain;

public class skusBean {
………………
}

logInfoHandler用来过滤订单的日志信息，并保存到ordersBean和skusBean中，方便Bolt获取日志数据的各项属性进行处理

package com.guludada.common;

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

import com.guludada.domain.ordersBean;

public class logInfoHandler {

SimpleDateFormat sdf_final = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  public ordersBean getOrdersBean(String orderInfo) {  ordersBean order = new ordersBean();  //从日志信息中过滤出订单信息  Pattern orderPattern = Pattern.compile("orderNumber:.+");  Matcher orderMatcher = orderPattern.matcher(orderInfo);  if(orderMatcher.find()) {  String orderInfoStr = orderMatcher.group(0);  String[] orderInfoGroup = orderInfoStr.trim().split("\|");  //获取订单号  String orderNum = (orderInfoGroup[0].split(":"))[1].trim();  order.setNumber(orderNum);  //获取创建时间  String orderCreateTime = orderInfoGroup[1].trim().split(" ")[1] + " " + orderInfoGroup[1].trim().split(" ")[2];  try {  order.setCreateTime(sdf_final.parse(orderCreateTime));  } catch (ParseException e) {  // TODO Auto-generated catch block  e.printStackTrace();  }  //获取商家名称  String merchantName = (orderInfoGroup[4].split(":"))[1].trim();  order.setMerchantName(merchantName);  //获取订单总额  String orderPriceInfo = (orderInfoGroup[6].split("price:"))[1].trim();  String totalPrice = (orderPriceInfo.substring(2, orderPriceInfo.length()-3).trim().split(" "))[1];  order.setTotalPrice(Float.parseFloat(totalPrice));  return order;  } else {  return order;  }
}

}

package com.guludada.ordersanalysis;

import java.util.Map;

import com.guludada.common.logInfoHandler;
import com.guludada.domain.ordersBean;

import backtype.storm.task.OutputCollector;
import backtype.storm.task.TopologyContext;
import backtype.storm.topology.OutputFieldsDeclarer;
import backtype.storm.topology.base.BaseRichBolt;
import backtype.storm.tuple.Tuple;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class merchantsSalesAnalysisBolt extends BaseRichBolt {

private OutputCollector _collector;
logInfoHandler loginfohandler;
JedisPool pool;  public void execute(Tuple tuple) {  String orderInfo = tuple.getString(0);  ordersBean order = loginfohandler.getOrdersBean(orderInfo);  //store the salesByMerchant infomation into Redis  Jedis jedis = pool.getResource();  jedis.zincrby("orderAna:topSalesByMerchant", order.getTotalPrice(), order.getMerchantName());
}  public void prepare(Map arg0, TopologyContext arg1, OutputCollector collector) {  this._collector = collector;  this.loginfohandler = new logInfoHandler();  this.pool = new JedisPool(new JedisPoolConfig(), "ymhHadoop",6379,2 * 60000,"12345");  }  public void declareOutputFields(OutputFieldsDeclarer arg0) {  // TODO Auto-generated method stub  }

}

Topology项目的Maven配置文件


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  <modelVersion>4.0.0</modelVersion>  <groupId>com.guludada</groupId>  <artifactId>Storm_OrdersAnalysis</artifactId>  <packaging>war</packaging>  <version>0.0.1-SNAPSHOT</version>  <name>Storm_OrdersAnalysis Maven Webapp</name>  <url>http://maven.apache.org</url>  <dependencies>  <dependency>  <groupId>org.apache.storm</groupId>  <artifactId>storm-core</artifactId>  <version>0.9.6</version>  <scope>provided</scope>  </dependency>  <dependency>  <groupId>org.apache.storm</groupId>  <artifactId>storm-kafka</artifactId>  <version>0.9.6</version>  </dependency>  <dependency>  <groupId>org.apache.kafka</groupId>  <artifactId>kafka_2.10</artifactId>  <version>0.9.0.1</version>  <exclusions>  <exclusion>  <groupId>org.apache.zookeeper</groupId>  <artifactId>zookeeper</artifactId>  </exclusion>  <exclusion>  <groupId>log4j</groupId>  <artifactId>log4j</artifactId>  </exclusion>  <exclusion>  <groupId>org.slf4j</groupId>  <artifactId>slf4j-log4j12</artifactId>  </exclusion>  </exclusions>  </dependency>  <dependency>  <groupId>redis.clients</groupId>  <artifactId>jedis</artifactId>  <version>2.8.1</version>  </dependency>   </dependencies>  <build>  <finalName>Storm_OrdersAnalysis</finalName>  <plugins>  <plugin>  <artifactId>maven-assembly-plugin</artifactId>  <configuration>  <descriptorRefs>    <descriptorRef>jar-with-dependencies</descriptorRef>  </descriptorRefs>  <archive>  <manifest>  <mainClass>com.guludada.ordersanalysis.ordersAnalysisTopology</mainClass>  </manifest>  </archive>  </configuration>  </plugin>  </plugins>  </build>
</project>  maven配置文件中配置了一个官方推荐的maven-assembly-plugin插件，用来帮助用户方便地打包Topology程序的。只需要进入到项目的根路径，然后运行
$mvn assembly:assembly
命令就可以打包好Topology的jar包了。

8.整个项目的部署流程最后我带大家梳理一下整个项目的部署流程
1.  启动Zookeeper
2. 启动Kafka
3. 启动Flume将程序拉取到Kafka中
4. 启动Storm集群
5. 启动Redis服务端  通过命令
$ src/redis-server
6. 提交打包好的Topology程序到Storm集群中通过Storm UI 或者命令$storm jar path/to/allmycode.jar org.me.MyTopology arg1 arg2 arg3
7. 启动Redis的CLI客户端查看结果通过命令
$ src/redis-cli --raw
$  zrange key 0 -1 withscoresTroubleshooting
在使用maven同时导入storm-core, storm-kaka和kafka的依赖包的时候可能会出现jar包冲突导致无法初始化Log4jLoggerFactory，并无法启动Storm程序. 解决方法也很简单，按照红字提示，把多余的jar包移除就行了，通过在maven的pom文件中kafka的依赖设置部分加入下面的设置<exclusion><groupId>org.slf4j</groupId><artifactId>slf4j-log4j12</artifactId></exclusion>
第一次执行Storm建立Topology时，作者遇到了一个十分低级的问题，就是发现明明Kafka的topic里有数据，可是Storm程序怎么都无法读取到数据，后来才从下面的文章中明白了问题的所在 http://m.blog.csdn.net/article/details?id=18615761  原因就在于Topology第一次启动前还没有在zookeeper中的zkRoot创建offset信息，Storm取不到offset信息就会使用默认的offset，也就是log文件中从最后一个元素开始读取信息，所以之前在kafka中的数据都无法读出来。Storm启动后，再往broker中写数据，这些后写的数据就能正确被Storm处理。
当Storm的topology传到Nimbus的时候，或者说你的Storm程序刚开始启动的时候可能会报关于JedisPool是一个无法序列化的对象而导致的错误：java.lang.RuntimeException:java.io.NotSerializableException: redis.clients.jedis.JedisPool 解决方案就是将Bolt类中外部的JedisPool初始化代码放入Bolt的prepare()方法中，如本文的代码示例所示
在Storm启动并开始连接Redis的时候，会报出连接被拒绝，因为Redis运行在protect mode模式下的错误。这是因为Storm程序是远程连接Redis的服务器端，如果Redis服务器端没有设置密码的话是拒绝远程连接的。解决方法也十分简单，关闭protect mode模式(强烈不推荐),或者使用下面命令为Redis设置密码就可以了$config set requirepass 123
向Storm提交Topology以后, Supervisor端会一直报“Kill XXXX No Such process”的错误，多数原因是提交的topology没有正确被执行，而Storm的日记中不会显示topology程序里的错误。解决方法就是启动Storm UI, 通过这个Storm自带的UI界面查看topology的运行情况，并且程序中的错误也会在UI界面中显示出来，能方便地查看topology程序的错误。6.kafka使用的时候的小问题：当在一台机子上启动kafka producer客户端的时候，是无法在同一台机子上继续启动kafka的consumer客户端的,因为这两个进程可能占用的同一个端口，需要在另外一台机子上启动kafka consumer程序，这样就能看见正确的结果了
Flume+Spark+Hive+Spark SQL离线分析系统
http://blog.csdn.net/ymh198816/article/details/52014315
Cloudera简介和安装部署概述
http://blog.csdn.net/ymh198816/article/details/52423200

大数据架构方案总结-ljt（转载）相关推荐

大数据基础课03 阿里美团这些大厂都在用什么大数据架构？
首先,我想讲一个叫庖丁解牛的故事,想必你应该听过.庖丁从开始杀牛,到他的故事被写下,操刀十九年,杀了数千头牛.也正是由于丰富的实践经验,他总结出了解杀牛的方法论:依照牛生理上的天然结构,砍入牛体筋骨相 ...
作者：石在辉（1983-），男，中移（苏州）软件技术有限公司大数据产品部方案架构师。...
石在辉(1983-),男,中移(苏州)软件技术有限公司大数据产品部方案架构师,主要从事解决方案.战略规划.产品规划等工作.
常用的几种大数据架构剖析
https://insights.thoughtworks.cn/common-big-data-infrastructure/ 数据分析工作虽然隐藏在业务系统背后,但是具有非常重要的作用,数据分析的 ...
云原生大数据架构中实时计算维表和结果表的选型实践
简介: 随着互联网技术的日渐发展.数据规模的扩大与复杂的需求场景的产生,传统的大数据架构无法承载. 作者 | 志羽来源 | 阿里技术公众号一前言传统的大数据技术起源于 Google 三架马车 ...
数据湖 VS 数据仓库之争？阿里提出大数据架构新概念：湖仓一体
作者 |关涛.李睿博.孙莉莉.张良模.贾扬清(from 阿里云智能计算平台) 黄波.金玉梅.于茜.刘子正(from 新浪微博机器学习研发部) 编者按随着近几年数据湖概念的兴起,业界对于数据仓库和数据 ...
混合云模式助力斗鱼搭建混搭大数据架构
云栖号案例库:[点击查看更多上云案例] 不知道怎么上云?看云栖号案例库,了解不同行业不同发展阶段的上云方案,助力你上云决策! 案例背景 2019杭州云栖大会大数据企业级服务专场,由斗鱼大数据高级专家张 ...
大数据架构的典型方法和方式
版权声明:本文为半吊子子全栈工匠(wireless_com,同公众号)原创文章,未经允许不得转载. https://blog.csdn.net/wireless_com/article/details ...
WOT干货大放送：大数据架构发展趋势及探索实践分享
WOT大数据处理技术分会场,PingCAP CTO黄东旭.易观智库CTO郭炜.Mob开发者服务平台技术副总监林荣波.宜信技术研发中心高级架构师王东及商助科技(99Click)顾问总监郑泉五位讲师,分别 ...
系统架构师(java)和大数据架构师
架构师不是一个职业工种,而是一种能力,而且架构师也分很多种,不同领域的架构师是不一样的.比如互联网架构师和物联网架构师,没有什么可对比的. 架构要考虑什么 1.考虑系统能做什么,不能做什么,就是常说的 ...
大数据架构+Lamba+Kappa+Unifield
大数据架构+Lamba+Kappa+Unifield 前端+主数据服务(MDS)+后端 Tomcat HBase ElasticSearch Pig Oozie Node.js JQuery 数据分 ...

大数据架构方案总结-ljt（转载）

agent.sinks.target.topic = bigdata

##### These MUST be filled in for a storm configuration

大数据架构方案总结-ljt（转载）相关推荐

最新文章

热门文章