
Hadoop家族 整个Hadoop家族由以下几个子项目组成: Hadoop Common: Hadoop体系最底层的一个模块,为Hadoop各子项目提供各 种工具,如:配置文件和日志操作等。 HDFS: 是Hadoop应用程序中主要的分布式储存系统, HDFS集群包含了一个NameNode(主节点),这个节点负责管理所有文件系统的元数据及存储了真实数据的DataNode(数据节点,可以有很多)。HDFS针对海量数据所设计,所以相比传统文件系统在大批量小文件上的优化,HDFS优化的则是对小批量大型文件的访问和存储。 MapReduce: 是一个软件框架,用以轻松编写处理海量(TB级)数据的并行应用程序,以可靠和容错的方式连接大型集群中上万个节点(商用硬件)。 Hive: Apache Hive是Hadoop的一个数据仓库系统,促进了数据的综述(将结构化的数据文件映射为一张数据库表)、即席查询以及存储在Hadoop兼容系统中的大型数据集分析。Hive提供完整的SQL查询功能——HiveQL语言,同时当使用这个语言表达一个逻辑变得低效和繁琐时,HiveQL还允许传统的Map/Reduce程序员使用自己定制的Mapper和Reducer。hive类似CloudBase,基于hadoop分布式计算平台上的提供data warehouse的sql功能的一套软件。使得存储在hadoop里面的海量数据 的汇总,即席查询简单化。 Pig: Apache Pig是一个用于大型数据集分析的平台,它包含了一个用于数据分析应用的高级语言以及评估这些应用的基础设施。Pig应用的闪光特性在于它们的结构经得起大量的并行,也就是说让它们支撑起非常大的数据集。Pig的基础设施层包含了产生Map-Reduce任务的编译器。Pig的语言层当前包含了一个原生语言——Pig Latin,开发的初衷是易于编程和保证可扩展性。 Pig是SQL-like语言,是在MapReduce上构建的一种高级查询语言,把一些运算编译进MapReduce模型的Map和Reduce中,并且用户可以定义自己的功能。Yahoo网格运算部门开发的又一个克隆Google的项目Sawzall。 HBase: Apache HBase是Hadoop数据库,一个分布式、可扩展的大数据存储。它提供了大数据集上随机和实时的读/写访问,并针对了商用服务器集群上的大型表格做出优化——上百亿行,上千万列。其核心是Google Bigtable论文的开源实现,分布式列式存储。就像Bigtable利用GFS(Google File System)提供的分布式数据存储一样,它是Apache Hadoop在HDFS基础上提供的一个类Bigatable。 ZooKeeper: Zookeeper是Google的Chubby一个开源的实现。它是一个针对大型分布式系统的可靠协调系统,提供的功能包括:配置维护、名字服务、 分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。 Avro: Avro是doug cutting主持的RPC项目,有点类似Google的protobuf和Facebook的thrift。avro用来做以后hadoop的RPC,使hadoop的RPC模块通信速度更快、数据结构更紧凑。 Sqoop: Sqoop是一个用来将Hadoop和关系型数据库中的数据相互转移的工具,可以将一个关系型数据库中数据导入Hadoop的HDFS中,也可以将HDFS中数据导入关系型数据库中。 Mahout: Apache Mahout是个可扩展的机器学习和数据挖掘库,当前Mahout支持主要的4个用例: 推荐挖掘:搜集用户动作并以此给用户推荐可能喜欢的事物。 聚集:收集文件并进行相关文件分组。 分类:从现有的分类文档中学习,寻找文档中的相似特征,并为无标签的文档进行正确的归类。 频繁项集挖掘:将一组项分组,并识别哪些个别项会经常一起出现。 Cassandra: Apache Cassandra是一个高性能、可线性扩展、高有效性数据库,可以运行在商用硬件或云基础设施上打造完美的任务关键性数据平台。在横跨数据中心的复制中,Cassandra同类最佳,为用户提供更低的延时以及更可靠的灾难备份。通过log-structured update、反规范化和物化视图的强支持以及强大的内置缓存,Cassandra的数据模型提供了方便的二级索引(column indexe)。 Chukwa: Apache Chukwa是个开源的数据收集系统,用以监视大型分布系统。建立于HDFS和Map/Reduce框架之上,继承了Hadoop的可扩展性和稳定性。Chukwa同样包含了一个灵活和强大的工具包,用以显示、监视和分析结果,以保证数据的使用达到最佳效果。 Ambari: Apache Ambari是一个基于web的工具,用于配置、管理和监视Apache Hadoop集群,支持Hadoop HDFS,、Hadoop MapReduce、Hive、HCatalog,、HBase、ZooKeeper、Oozie、Pig和Sqoop。Ambari同样还提供了集群状况仪表盘,比如heatmaps和查看MapReduce、Pig、Hive应用程序的能力,以友好的用户界面对它们的性能特性进行诊断。 HCatalog Apache HCatalog是Hadoop建立数据的映射表和存储管理服务,它包括: 提供一个共享模式和数据类型机制。 提供一个抽象表,这样用户就不需要关注数据存储的方式和地址。 为类似Pig、MapReduce及Hive这些数据处理工具提供互操作性。 Chukwa: Chukwa是基于Hadoop的大集群监控系统,由yahoo贡献。 Cloudera Manager功能 cloudera manager有四大功能: (1)管理:对集群进行管理,如添加、删除节点等操作。 (2)监控:监控集群的健康情况,对设置的各种指标和系统运行情况进行全面监控。 (3)诊断:对集群出现的问题进行诊断,对出现的问题给出建议解决方案。 (4)集成:对hadoop的多组件进行整合。 示例,管理4集群: 管理的服务包括: Cloudera Manager架构 cloudera manager的核心是管理服务器,该服务器承载管理控制台的Web服务器和应用程序逻辑,并负责安装软件,配置,启动和停止服务,以及管理上的服务运行群集。 Cloudera Manager Server由以下几个部分组成: Agent:安装在每台主机上。该代理负责启动和停止的过程,拆包配置,触发装置和监控主机。 Management Service:由一组执行各种监控,警报和报告功能角色的服务。 Database:存储配置和监视信息。通常情况下,多个逻辑数据库在一个或多个数据库服务器上运行。例如,Cloudera的管理服务器和监控角色使用不同的逻辑数据库。 Cloudera Repository:软件由Cloudera 管理分布存储库。 Clients:是用于与服务器进行交互的接口: Admin Console - 基于Web的用户界面与管理员管理集群和Cloudera管理。 API - 与开发人员创建自定义的Cloudera Manager应用程序的API。
web访问日志 主要是指用户在访问某网站的时候产生的日志信息,采集方式包括前端Javascript埋码采集和后端服务器日志采集两种。 前端采集目前主要以javascript为主,收集用户数据。 后端服务器日志根据网站架构,一般以nginx和tomcat等加上业务日志的采集为主。 对于数据的权威和准确性而言,应该首先以后端服务器产生的数据为主,配合前端采集的数据来进行整体的分析和挖掘。 日志分析流程 日志分析流程如下: 数据采集:包括埋码和业务数据收集两种。 数据传输:包括实时和离线传输两种。 存储:建立统一的数据仓库。 分析和建模:数理统计和数据挖掘。 可视化展示:分析结果、挖掘结果及分析报告。 nginx样例数据 样例数据格式: 124.42.13.230 - - [18/Sep/2013:06:57:50 +0000] "GET /shoppingMall?ver=1.2.1 HTTP/1.1" 200 7200 "http://www.baidu.com.cn" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; BTRS101170; InfoPath.2; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727)" 格式分析: 1、访客ip地址:124.42.13.230 2、访客用户信息: - - 3、请求时间:[18/Sep/2013:06:57:50 +0000] 4、请求方式:GET 5、请求的url:/shoppingMall?ver=1.10.2 6、请求所用协议:HTTP/1.1 7、响应码:200 8、返回的数据流量:7200 9、访客的来源url:http://www.baidu.com.cn 10、访客所用浏览器:Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; BTRS101170; InfoPath.2; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727) 对于这种数据,可以交叉组合,开成多维度的数据分析与挖掘。 web日志挖掘的目标 web日志挖掘的目标: 1、以改进站点设计为目标,根据挖掘到的用户频繁访问路径重新调整链接关系。 2、以分析网站性能为目标,统计出用户经常浏览的页面及访问时间等。 3、以理解用户意图为目标,根据这些信息对用户的请求做专门的定制,然后将页面返回给用户。 使用分为: 1、web结构挖掘。 2、web内容挖掘。 3、web使用挖掘。 web日志挖掘流程 分为数据收集、数据预处理、模式发现和模式分析几部分。 作者:skyme 联系方式: 邮箱【cloudskyme@163.com】 QQ【270800073】 本文版权归作者和云栖社区共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
单例模式介绍 单例模式是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例。 对于系统中的某些类来说,只有一个实例很重要,例如,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;一个系统只能有一个窗口管理器或文件系统;一个系统只能有一个计时工具或ID(序号)生成器。如在Windows中就只能打开一个任务管理器。如果不使用机制对窗口对象进行唯一化,将弹出多个窗口,如果这些窗口显示的内容完全一致,则是重复对象,浪费内存资源;如果这些窗口显示的内容不一致,则意味着在某一瞬间系统有多个状态,与实际不符,也会给用户带来误解,不知道哪一个才是真实的状态。因此有时确保系统中某个对象的唯一性即一个类只能有一个实例非常重要。 单例模式七种写法 第一种(懒汉,线程不安全) public class Singleton { private static Singleton instance; private Singleton (){} public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } } 不适合多线程。 第二种(懒汉,线程安全) public class Singleton { private static Singleton instance; private Singleton (){} public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } } 这种方式线程安全,但是效率很低。 第三种(饿汉) public class Singleton { private static Singleton instance = new Singleton(); private Singleton (){} public static Singleton getInstance() { return instance; } } 这种方式基于classloder机制避免了多线程的同步问题,不过,instance在类装载时就实例化,虽然导致类装载的原因有很多种,在单例模式中大多数都是调用getInstance方法, 但是也不能确定有其他的方式(或者其他的静态方法)导致类装载,这时候初始化instance显然没有达到lazy loading的效果。 第四种(饿汉,变种) public class Singleton { private Singleton instance = null; static { instance = new Singleton(); } private Singleton (){} public static Singleton getInstance() { return this.instance; } } 和第三种差不多,都是在类初始化即实例化instance。 第五种(静态内部类) public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } private Singleton (){} public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } } 这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程,它跟第三种和第四种方式不同的是(很细微的差别):第三种和第四种方式是只要Singleton类被装载了,那么instance就会被实例化(没有达到lazy loading效果),而这种方式是Singleton类被装载了,instance不一定被初始化。因为SingletonHolder类没有被主动使用,只有显示通过调用getInstance方法时,才会显示装载SingletonHolder类,从而实例化instance。想象一下,如果实例化instance很消耗资源,我想让他延迟加载,另外一方面,我不希望在Singleton类加载时就实例化,因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载,那么这个时候实例化instance显然是不合适的。这个时候,这种方式相比第三和第四种方式就显得很合理。 第六种(枚举) public enum Singleton { INSTANCE; public void whateverMethod() { } } 这种方式是Effective Java作者Josh Bloch 提倡的方式,它不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象,可谓是很坚强的壁垒啊,不过,个人认为由于1.5中才加入enum特性,用这种方式写不免让人感觉生疏,在实际工作中,我也很少看见有人这么写过。 第七种(双重校验锁) public class Singleton { private volatile static Singleton singleton; private Singleton (){} public static Singleton getSingleton() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } } 第二种的升级版,俗称双重检查锁定。 scala单例 单例模式就控制类实例的个数,通过伴生对象来访问类的实例就提供了控制实例个数的机会。一个简单示例: class Worker private{ def work() = println("I am the only worker!") } object Worker{ val worker = new Worker def GetWorkInstance() : Worker = { worker.work() worker } } object Job{ def main(args: Array[String]) { for (i <- 1 to 5) { Worker.GetWorkInstance(); } } } class Worker private声明了Worker的首构造函数是私有的,这样Worker的所有构造函数都不能直接被外部调用,因为所有从构造函数都会首先调用其他构造函数(可以是主构造函数,也可以是从构造函数),结果就是主构造函数是类的唯一入口点。 另一方面,Worker.GetWorkInstance();有点类似静态函数调用,但在Scala中这是不对的。Scala会隐式地调用apply来创建一个伴生对象的实例。Scala是一个纯粹的面向对象语言,不允许有任何破坏对象模型的机制存在,比如类的静态变量、函数等。 作者:skyme 联系方式: 邮箱【cloudskyme@163.com】 QQ【270800073】 本文版权归作者和云栖社区共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
什么是精细化运营 企业运营对于企业来说是非常重要的,因为良好的运营体系会让企业在市场宣传中轻松应对各种情况。当我们迈入数据时代的时候,企业在运营上相对应的也发生了改变,从最初的粗放式运营逐渐过渡到精细化运营。精细化运营就是能够充分了解企业的运营情况,做到知已知彼。 跟踪监测的点 主要包括以下部分: 模块的访问记录——对比新老用户的访问比,如果新用户的访问占比远远大于老用户的访问占比,那这个功能就是个鸡肋,因为基本上只有新用户在访问。(注册等新用户特性模块除外)。 模块的留存情况——我们知道一般情况下所谓的留存都是指用户有没有在一段时间后(天,周,月)持续的访问网站,而留存本身的意义也在于观察一段时间内用户的持续访问情况,但对于留存的观察,“访问网站”远远不及使用产品的核心功能,例如电商应用需要关注用户持续使用的是浏览商品、加入购物车或下订单功能等;对于图片社区,可能关注的就是用户浏览图片或者上传图片;而对一个社交应用来说可能关注的就是用户有没有持续的互动。对于内容类网站来说可能就是是否持续的阅读。 排序和模块展示的位置优化——在屏幕上的每一个位置都有不一样的转化率,所以如果很多可能吸引用户的功能放在不好的位置,也会导致用户流失。但目前对于很多模块的展示位置,或者类似于某块内容的分类排序,一般基于产品经理的原型设计或者运营编辑的经验判断。因此在产品发布之后,我们需要关注的是这些模块或者分类的持续访问情况,然后根据用户访问数据去优化排序,留存高的模块当然要放在好的位置,留存低的就要持续优化了。 路径优化——上面所述的点,关注的更多是持续访问的意义,也就是产品功能的长期价值。在产品使用过程中,有很多流程性的操作,比如: “阅读”——“分享” “注册”——“填写资料”——“注册成功” “浏览商品”——“加入购物车”——“下订单” 每一步操作背后都隐含着用户的交互,所以交互设计不合理、操作繁琐或隐蔽、产品有bug、性能不好都会造成用户的流失。 怎样与产品结合 那么数据分析到底该怎样和产品结合呢?其实等同于精益创业打磨一个最小化产品,然后利用数据衡量再规模推广一样,数据分析也是这样一个过程。我们需要一开始选取一部分的用户流量去测试我们的产品,当数据还行的时候,再应用到全市场,看看下面这个图: 逻辑是:确立目标,找到分析模型,然后利用分析方法进行分析,最后随着迭代的过程周而复始。 网站分析之热图 热图模式中间的热图区域显示的是,在选定的时间段和页面(而不只是热图中的当前可视区域)中,点击量在数据总量里前 1000 的元素里,有内容或有链接的元素。没有内容和链接的元素将会被过滤,以防止混淆元素的干扰。热图同时也是产品优化产品的重要手段之一,可以通过热力点击的区域来盾是否点击和喜好程度。 网站分析之留存 对预先设定的目标进行展示,比如次日留存等指标。留存分析包括:用户留存、产品功能留存、自定义留存。 用户留存:分析用户回访网站、App的留存情况,包括新用户和所有用户留存分析。通常情况下,用户在早期流失现象非常严重。产品需要让用户快速容易的体验到产品的价值。一旦用户发现产品对自己的价值,继续使用和探索产品新功能的概率就会增大很多。对比分析用户进行过的行为可以帮助您发现高留存率的行为,寻找行为与留存的相关性, 还可以通过维度、分群对比了解不同特征的新用户留存分布情况,并为您的决策提供数据支持。 产品功能留存: 分析用户对不同产品功能的使用粘性与活跃度。一般我们不仅需要关注整个网站/App的留存,还需要关注核心行为的留存率,比如重复购买的情况。对产品进行迭代时,我们还可以使用产品功能留存观测这个功能的留存率整体有没有提高;或者例如电商网站,发现用户对某一类商品购买的留存率很高,便可以采取相应的营销活动。 自定义留存:可自定义起始、回访行为,进行更多情景下的留存分析。 例如您想了解新用户多久才开始使用某个产品功能,您可以选择起始行为是任意行为,回访行为是点击这个功能的按钮,来观测新用户对这个功能使用时间的分布情况,寻找到合适的转化周期。您还可以通过维度对比与分群对比,进行更深度挖掘。 网站分析之转化 漏斗是衡量转化效果、进行转化分析的重要工具。这也是观察运营效果的重要手段之一,对于转化率不能达到阈值的情况,进行深入的分析,找到原因,对症下药。 网站分析之用户分群 用户分群是对用户根据一定的规则进行切分。可以使用基于分析或者业务结合的方法,也可以使用模型的方法,下图是使用RFM对数据进行切分的实例。
日志收集 日志收集包括服务器日志收集和埋码日志收集两种。 服务器日志主要是nginx、tomcat等产生的访问和业务日志。 埋码收集主要是某些服务器无法收集,需要在前端进行收集的数据。 收集流程 日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。 日志采集客户端,负责日志数据采集,定时写受写入Kafka队列; Kafka消息队列,负责日志数据的接收,存储和转发; 日志处理应用:订阅并消费kafka队列中的日志数据; 下面是一个应用的实例图 存储可以是Elasticsearch,对数据进行实时分析。 为什么kafka Kafka 是分布式发布-订阅消息系统。它最初由 LinkedIn 公司开发,使用 Scala语言编写,之后成为 Apache 项目的一部分。Kafka 是一个分布式的,可划分的,多订阅者,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。如果对时时性要求较高的话,可以使用这种方案。 它具备以下特点: 同时为发布和订阅提供高吞吐量。据了解,Kafka 每秒可以生产约 25 万消息(50 MB),每秒处理 55 万消息(110 MB)。 可进行持久化操作。将消息持久化到磁盘,因此可用于批量消费,例如 ETL,以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数据丢失。 分布式系统,易于向外扩展。所有的 producer、broker 和 consumer 都会有多个,均为分布式的。无需停机即可扩展机器。 消息被处理的状态是在 consumer 端维护,而不是由 server 端维护。当失败时能自动平衡。 支持 online 和 offline 的场景。 kafka的测试效果 下面是单机情况下的测试效果: kafka的核心概念 kafka中的核心概念如下: Producer 特指消息的生产者 Consumer 特指消息的消费者 Consumer Group 消费者组,可以并行消费Topic中partition的消息 Broker:缓存代理,Kafa 集群中的一台或多台服务器统称为 broker Topic:特指 Kafka 处理的消息源(feeds of messages)的不同分类。 Partition:Topic 物理上的分组,一个 topic 可以分为多个 partition,每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id(offset)。 Message:消息,是通信的基本单位,每个 producer 可以向一个 topic(主题)发布一些消息。 Producers:消息和数据生产者,向 Kafka 的一个 topic 发布消息的过程叫做 producers。 Consumers:消息和数据消费者,订阅 topics 并处理其发布的消息的过程叫做 consumers。 kafka的整体流程 kafka的整体流程: 数据通过flume在客户端进行代理,收集各种日志信息,整体模式使用生产者,消费者的模型。 producer可以根据配置设置发送的时间段。 broker中分为不同的topic,topic中又可以分为不同的partition,这个有点儿类似于数据库中的分区表,对于数据量大的情况下非常适合。 customer负责消费消息日志,如果需要时时消费,则可以使用storm或者spark streaming,如果离线消费,可以使用mapreduce。 kafka总结 kafka可以完全应用到不同的业务场景中,配合zookeeper,保证系统的高可用性。 作者:skyme 联系方式: 邮箱【cloudskyme@163.com】 QQ【270800073】 本文版权归作者和云栖社区共同所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。