2015年12月04日大数据分析背景、Hadoop架构及日志系统在Hadoop的应用与实现微信直播文字版记录
PS：由于本次分享文字几近超出2万字微信的上限，因此部分自由讨论内容没有出现在本篇微信文章中，大家可以点击最下方阅读原文查看全部完整版本。
下周微信直播主题：
1. 旅游行业如何根据不同的人群做精准的酒店推荐匹配。
2. 大数据技术在智慧旅游行业中如何应用？
3. 旅游行业数据收集、数据预处理、个性化推荐
Bob - 同程旅游大数据BI架构师
从C#到java， 从sql到BI，从cube到Hadoop，从Hadoop到nosql+mpp+storm。一路走来，只为心中的执着。
个人专栏：
博客专栏：
天天向上 - 人民日报媒体技术中心大数据研发工程师
7年工作经验，2年项目管理经验，曾就职于知名互联网公司担任软件经理，现就职于人民日报媒体技术中心担任大数据研发工程师，负责构建人民日报媒体数据平台构建与开发。
关注范围：分布式高性能并发处理,开源技术,大数据实现,数据可视化，数据分析与挖掘(算法与解决方案)
个人专栏：
博客专栏：
学院专栏：
主持人：欢迎我们两位嘉宾的到来，两位都在大数据方向有丰富的经验，很期待今天的分享，我们开始第一个话题的分享吧，我们来一起聊一下大数据产生的背景。 有请我们的嘉宾@同程吴文波 @天天向上
大家好，我是牟瑞（MuRui），这个姓读Mu，不读Mou，在天善的论坛里面是叫天天向上，目前是在人民日报媒体技术公司工作，非常感谢梁总和吕总给了我这次与大家交流学习的机会。
天善智能大数据交流群 : 225978231 加群请注明: 天善智能。
先说点政府层面的大数据分析背景。
现在大数据这次词在时下的热门程度，无需多说，在今年的9月5号，国务院总理李克强还特别印发了《促进大数据发展行动纲要》，系统部署了大数据发展的工作。
《纲要》的官网地址：
我挑了一点重要的分享一下。
《纲要》提出，要加强顶层设计和统筹协调，大力推动政府信息系统和公共数据互联开放共享，加快政府信息平台整合，消除信息孤岛，推进数据资源向社会开放，增强政府公信力，引导社会发展，服务公众企业；以企业为主体，营造宽松公平环境，加大大数据关键技术研发、产业发展和人才培养力度，着力推进数据汇集和发掘，深化大数据在各行业创新应用，促进大数据产业健康发展；
在纲要下发之前，大数据主要还是存在于民间，各大互联网行业做的比较好，那么在纲要下发之后，说明大数据行业已经作为一个产业，得到了政府的支持和认可，并在政策上予以扶持。
另外，贵阳大数据交易所于2015年4月15日，正式挂牌运营并完成首批大数据交易，贵阳大数据交易所完成的首批数据交易卖方为深圳市腾讯计算机系统有限公司、广东省数字广东研究院，买方为京东云平台、中金数据系统有限公司。
不好意思，上面扯了很多政策性的东西，也比较符合我在人民日报的风格。
以上主要是想说明，现在大数据在国家层面已经得到了很大的支持，未来大数据产业，会有一个非常大的发展，大数据行业是大有可为的。但是，我想说，但是，我们在实践的过程中，尤其是很多的政府部门，传统行业，还处在大数据时代非常初级的阶段。
拿人民日报来说，正部级单位，正宗的传统媒体行业。2014年8月18号，习总在北戴河会议回来之后，发表的第一次重要讲话，就提出了《关于推动传统媒体和新兴媒体融合发展的指导意见》。
人民日报作为党报，传统媒体，必然面临改革。但是对于人民日报来说，我们不缺数据，人民日报的报纸发行量过千万，人民日报手机客户端下载量7000多万，微博将近4200万，微信公众号用户500万以上，还有旗下上市公司人民网的数据，各大地方媒体的数据等等。
这些数据随便一个拿出来，都可以算是海量的数据了，其价值也是无法估量的。但是，我们真的需要大数据么？
答案是肯定的，但是困难重重，原因如下：
1. 人工成本：作为央企，传统行业，我们无法让每个人都能拿到与一线互联网公司的大数据开发工程师相匹配的工资。（虽然我们在努力做到）
2. 业务场景：如此多的数据带来如此多业务场景，每个业务场景解决不同问题，他们都要求投入巨大的人力，物力。而报社最重要的业务是党报，是各大编辑/记者，他们需要大数据，但是没有，也一样能写出传播力，影响力很强的稿件。
3. 统筹规划：如此多的数据，业务场景，如何做到统筹规划，做到资源共享？是筹建统一的一个媒体云？还是各自为政？
4. 利益纷争：此处和谐忽略
5. 资本投入：一个大数据中心，需要基础设施建设，云构建，应用系统构建，系统部署上线等等，整个过程需要持续不断的资本投入。
以上的简单几点，在传统行业改革转型过程中，都是无法一步到位的，都是逐步实施的过程，在项目的初期，我们遇到了很多的问题，构建了一个小型的私有云，发现用户不感兴趣，而且盈利模式没有想清楚。
在不断地摸索的过程中，我们发现，一切还是要以业务驱动为中心，数据驱动为业务驱动服务，首先要发现业务中的新的增长点，在提供额外业务服务的情况下，利用现有的用户技术，先行接管并逐步替换成我们自己的大数据服务平台提供支持，形成了一个“三步走”的战略，当然，现在还只是初级阶段。
我上面说的很多内容，我想很多人，企业都会遇到，大数据时代我们应该怎么做，这里没有各种高大上的报表和术语，只是我们切实在做的，简单的说点自己的观点：
1. 积累数据：积累各种各样的与业务有关的各类数据，在不断的数据积累中，发现数据的价值所在。
2. 深入业务：不管是哪个行业，深入业务，才能发现新的价值。
3. 改变传统观念：未来是一个大数据的世界，各种数据复杂多变，要改变传统的依赖关系型数据库来实现一切业务的观念。
4. 关注行业动态：关注行业内的发展，不能固步自封，虚心向行业内、技术学习。（现在的交流风气很好，只要不涉及核心利益，大家都是很愿意交流分享的）
5. 不迷恋技术（工具），以实现价值为目标：当前各种技术，工具，概念层出不穷，不能过滤迷恋，不同的技术（工具）只能应对某一个业务场景，不能解决全部问题。
大数据，“据”是关键，否则“大”和“数”就是一堆二进制，不能带来价值，反而浪费大量的人力，物力以及各种资源。
欢迎大家就各类问题来与我们一起交流学习，我的分享结束了。
感谢天天向上给咱们讲解大数据的产生背景以及国家对大数据这个行业的态度，大数据涉及的方面很多，问题都比较关心什么呢？可以开始讨论了！
提问一： 业务数据可以用mongo存储吧 如果用mogo 会导致什么风险吗？相对于mysql来说。
同程吴文波：我们不建议用nosql来存储带事务的交易数据。我们也是将一些资源，例如政策数据同步存储到nongo。
天天向上：@北京-hylink-Hao,William如果有排序，有的时候你要考虑排序。。。而且数据量非常大的时候非常吃内存。
Hao,William：mongo加索引排序应该还好吧。 相对于mysql，nosql基本上1000w的数据没问题吧。比如存储用户的积分流水 用户信息。
天天向上：@北京-hylink-Hao,William你试一下它的子文档排序就知道了。很多都需要自己实现排序。
天天向上 ：@北京-hylink-Hao,William流水没有问题。。
Hao,William：我们现在设计都不用子文档。都是跟关系数库存设计差不多。
天天向上：@北京-hylink-Hao,William那基本上没有问题。
Hao,William：现在担心的就是mongo 会不会丢数据，并发能不能扛得住？
同程吴文波：mongodb不会丢，但是在分片的过程中会有一些问题。Mongodb扛并发也没有问题的。
天天向上：@北京-hylink-Hao,William不会的。Mongodb并发没有问题的。
Hao,William：那完全满足会员中心的需求，我们会员中心800w用户。
提问二：对于分布式环境来说，集群中大量服务器的日志收集和管理需要相当成本，你会怎么办？（by 小小蜗牛爬上墙）
天天向上 ：@小小蜗牛爬上墙 回答你刚才的那个问题，我们现在的服务器日志最多只保留７天，不会是非常海量的日志。
小小蜗牛爬上墙：现在主要的困惑是，一个联机集群里有几十台主机，你讲的那些基本开发的思维，对于生产环境来说是否适合？生产环境的话，时效才是第一要素。
天天向上：@小小蜗牛爬上墙 几十台主机都基本上不会存放特别多的日志，会统一收集。
小小蜗牛爬上墙：收集是一方面，我们目前还是基本定位哪个节点有异常，然后登到主机上查看，沿用小机和大机的处理方式
天天向上：@小小蜗牛爬上墙 刚才波哥讲了，弄个ELK，很简单就搞定了，所有的机器的日志都收集上来了。
提问三：我想问一下，具体分析日志和转化的问题，如何进行的？（by 高不高 ）
高不高：我们公司有点像YY，但是一直推不下去这块。
同程吴文波：你问到点上了。这个需要结合前端的埋点，后端的分析，业务的规则来定。
高不高：嗯，运营那边要数据，但是我们的数据分析人员都快成了提取数据的了，根本做分析的工作很少，埋点这块，还在推，有很大阻力。
高不高：对于事物性的数据是否一块导入到hbase ?
提问四：我想问一下收集日志是将原数据保存再压缩吗？
铮：一般压缩为什么格式？
天天向上：@铮 看你的场景。。最近的日志不压缩，归档需要压缩。
同程吴文波：@铮 我们是直接收集网络点击日志，存储在Hadoop的时候使用了snappy进行，没有用lzo，gz等。snappy的压缩比是非常高效的，google
铮：但snappy不是不能分割吗？用hadoop会不会慢
同程吴文波：@铮，我们就是用snappy，没有问题的。
铮：你们是把一天的数据一起传到hdfs上？还是实时传
同程吴文波：@铮 我们是用storm实时写入
铮：一天大约多大的数据
同程吴文波：每天1.5亿的记录数
天天向上：@铮 我们的日志是实时跟踪，但是会有一点延时。。
春天在心里：和阿里的实时是一样的吧
铮：嗯，这样比较好
同程吴文波：我们会实时收集pc，app，touch的行为数据。同程app的下载量超过7亿了。其实行为日志收集的架构本身一定要按场景来进行，确保日志一条不丢失才是关键。
Hao,William：现在我们记录的行为日志都是谁在什么地方干了什么。
春天在心里：哦，原来这个叫行为日志啊 阿里的生意参谋都是这种东西。
铮：确保日志一条不丟么？
同程吴文波：我们是使用kafka集群。kafka本身保留3天的数据。tengine负载方面保留一个月。从flume，到kafka，到storm，到db这些是确保不能丢失的。
Hao,William：kafka和rabbitmq 功能一样吧。 我们用的后者。。。
同程吴文波：校验的方式也很简单，你在app上设计一个计数器。
同程吴文波：kafka比较变态，本身能存储10几T。
铮：还有一点，如果程序在前台处理了，用户点击的数据在后台没留下？该如何收集？
同程吴文波：@铮 如果前端有处理，那要坚持日志是否到达你的接口层，接口层一定要实时输出到文本中。
提问五：请说说大数据的核心是什么？有一种观点，不上hadoop就不是大数据，你如何看这个问题？
天天向上：@内心召唤 我个人理解的核心还是有价值，如何从海量的数据中提取出基于业务的，并且有市场前景的价值。hadoop只是一种数据存储和计算解决方案。mysql的大集群也可以存放海量的数据。
提问六：有个关于mongodb的问题，就是当主从复制集，主集按照某个索引条件删除大量数据时，瞬间完成。但是从集却是按id一条一条删除，导致长时间主从数据不一致，这个大家有遇到过吗？
小小蜗牛爬上墙：对于mysql主从复制，在生产环境我们是不允许的
高不高：@小小蜗牛爬上墙 ,为什么不允许？
小小蜗牛爬上墙：因为binlog没法保证slave数据实时，建议异步写两份
Hao,William：mysql其实横向扩展已经能承载大数据了。mongo我们考虑到是维护和成本低。
同程吴文波：mongodb集群的硬件要好点，才行
Hao,William：现在800多w日志才5g 呵呵。我们小数据来说还可以 呵呵。
Daniel Jiang：GreenPlum怎么样？比起Mysql的横向扩展？
天天向上：mysql我们现在是双主。。。
Hao,William：mongodb 还是很牛逼的目前看起来
大米：@天天向上 双主可以同时写吗？数据会一致吗
天天向上：@杭州-服裝-大米 一致的啊。分开随机写。
王东：能透漏下你们mongodb都什么配置么？
小小蜗牛爬上墙：我们目前部署的都是双主，主从还会有个毛病就是，主机宕机后，从机数据无法保证能够恢复和主机一致。
Hao,William：一台机器8g内存，4核，1t硬盘。
02Topic
话题二&三：Hadoop应用、分布式架构、日志系统在Hadoop的应用及实现
主持人：讨论太激烈了，可以体会到大数据有多热了，很多企业都面临转型，很多企业也都在摸索，大家才会有这么多的问题，大家都希望利用大数据技术为公司赢来更大的利润，可以想象我们现在以及未来的大数据人才有多吃香了!
大家快来学习吧，天善为你提供了这样的学习平台， 哪里不会点哪里! 哈哈！
废话不多说，我们下面两个话题一起来分享2、Hadoop应用、分布式架构3、日志系统在Hadoop的应用及实现。
大家好，我是同程的吴文波，大家可以叫我Bob。一直是在同程旅游负责数据的研发。
今天先分享下我们在日志方面的一些处理方式。
企业日志的几种情况：
A. 服务器监控日志
B. 内部应用程序日志
C. 网站用户点击行为日志
服务器监控日志
服务器监控日志对企业来讲是非常重要的一个部分。这部分数据包含服务器的性能监控，也包含应用程序站点的日志监控。企业上了一定规模以后，是迫切需要解决当前服务器的运行状态、应用程序运行状态。如果在外部市场投放了广告，带来巨大流量后，可视化实时监控web应用程序运行状态是很关键的。
服务器监控通常会用到Cacti，zabbix，ganglia，Splunk等工具。
其中Splunk是一个顶级日志分析软件，它不仅可以用多种方式来添加日志，生产图形化报表，最厉害的是它的搜索功能 - 被称为“Google for IT”。Splunk是商业版。
Cacti，zabbix大部分是用来做服务器CPU、磁盘、网络等情况进行监控。
日志信息分析工具中推荐使用Logstash+Elasticsearch+ Kibana这三个组合进行监控。
这三个产品的大致工作流程是：logstash agent 监控日志——》 redis(队列) ——》logstash index——》全文搜索服务ElasticSearch.前端通过Kibana 来结合自定义搜索进行页面展示。
在安装这些的时候要准备好Ruby，JDK等环境，过程中一定要考虑Logstash+Elasticsearch+ Kibana这三个版本的兼容性，切莫追求最新最高大上的版本。
官网：
logstash支持的inputs、codecs、filters和outputs的参数配置:
如果大家有兴趣，推荐中文学习资料：
内部应用程序日志
应用程序内部产生的日志，码农专用。
应用程序的日志是在研发体系中一个非常重要的环节。一个产品上线后出现问题，例如需要排查程序过程中拼接产生的SQL，记录查询接口的请求参数和输出参数等，随着应用程序的访问量上升，存储量增大，存储的内容也非常复杂。团队在处理这类问题时，如果都是采用cat、tail、sed、awk、perl以及 grep来处理，则非常耗时。
在这种情况下，我们非常需要一种既能灵活查询，又支持海量存储的程序日志架构。考虑到程序日志的特殊性，我们建议使用mongodb来负责程序日志的存储问题。Mongodb的好处不用多说。
网站用户点击行为日志
网站用户点击行为日志，是本次主要想给大家分享的。用户和互联网公司之间主要有两个方面的接触：
1. 消费数据
这部分需要实时响应，用户提交一个表单，通过应用程序存放到关系型数据库(Oracle、Mysql、sqlserver)。
2. 点击数据
用户在网站、App上的所有操作，例如页面访问量、用户行为、搜索情况。这些数据是准实时性的消息流。公司可以根据这类消息做个性化推荐，运营监控，营销等一系列的应用。
第一点的数据及其重要，是创营收的程序，这是大部分码农必须要保障的根本性任务，要做好关系型数据库的维护工作，能抗每秒**订单的指标就行。
点击数据是企业做精细化过程中非常重要的一个宝库。它能做如下事情：
1. 分析流量的ROI，指导流量投放。
前端的点击做好渠道跟踪体系，根据用户的访问流量来统计付费渠道、免费渠道的效果。指导网站该在哪些渠道上做改进。每个互联网公司几乎都有竞价、应用市场等各个渠道的流量来源，而实时监控并统计效果，则能让流量投放更加有的放矢，把钱都花在刀刃上。
2. 建立浏览跟踪体系，优化产品页面设计
Web程序中首页、列表页、产品详情页、预订页都是可看做一个一个独立的产品。为每个类型的页面打上标记，并在用户浏览的时候记录下来。这样就可以根据用户的是否成单、停留时长、跳出率等指标来评定哪些页面是需要改进，并且也可以给出参考的数据指标。例如A页面需要改进，提升转化率到30%；B页面需要改进，提升支付率到60%等等。
3. 统计分析页面质量，分析漏斗转化率
根据流量漏斗，我们可以知晓页面的质量。运营此页面的人员可以跟进，迭代优化。
4. 优化用户访问路径
有了用户点击数据，我们就可以进行web路径分析，找出用户从首页到产品的最短路径。
5. 专题活动分析
专题活动页面的上线，一定要做好用户点击数据的收集工作。这些数据决定了你的专题活动的好坏。例如有些专题是专门上线拉流量的，那通过用户点击数据可知道是否达到了此目标；有些专题上线是为了促进转化，那用户点击专题后都做了什么，有没有成单，这些数据便可以考核这个专题的好坏。
6. 营销推送效果分析
短信、app推送等都是激活老会员，增加会员忠诚度的一种营销手段。如果每天发送几万或几十上百万的短信，就要根据用户点击短信中的url来分析效果。这些url中可根据url参数、点击时所在地、浏览时长、页面点击等数据来分析短信的效果。
App推送也是一样的效果。在app推送上一般都是h5页面，那就要考虑多少用户打开，能不能获取设备ID,用户在h5页面的点击行为，及后续的浏览行为。
7. 丰富会员浏览等偏好数据
用户在网站或app上的所有点击都透露了一些信息。
例如在哪个地方访问，如果这个地方出现次数最多，那是不是就可判断为用户常用地。
用户经常逛哪些产品，哪些资源，在点评信息的停留时间，浏览的深度等等这些数据。
当然用户经常不登录，但是如果在pc上有登录了，那就要想办法把历史数据和当前会员匹配上。
8. 监控转化率数据，指导运营
转化率等数据是运营的一些核心指标，用户点击行为数据是完全可以支持的。
9. 浏览的推荐行为，丰富用户接触点
当搜索无结果、当用户下完单了等场景中，我们是一定要根据用户访问的数据来为用户推荐一些结果。
网站页面本身就是一个广告位，要尽可能为用户呈现一些感兴趣的产品，增加产品的曝光度，也丰富了用户的接触点。
10. 数据分析和预测
每次的用户点击行为数据，都是可以积累下来作为数据分析和预测的依据之一。例如在当前的流量情况，预测下月的流量。考虑季节和节假日因素的话，还可以预测下一年的流量，为投放做好依据。
也可以根据现有某个产品的转化率进行分析，找出几个可能提升的点，配合业务部门一起提升。
用户行为日志技术架构
用户点击行为数据一般都是巨大的，场景方面有离线和准实时。
在这些情况下，各个企业一般都要贴合实际来出发。例如每天流量如果只有几万UV，那就没必要上大数据来处理；反之，流量增长到几百万UV以后，用关系型数据库来处理也不合适。
每天流量如果只有几万UV的情况下，则采用如下的技术架构：
Web程序：用户在浏览和点击时，触发js或app sdk事件，负责将数据以json等方式提交到接口程序。
接口程序：负责解析接收到的数据，并存储到数据库。在这个地方，最好考虑下做个负载均衡。
关系型数据库：数据库方面做个读写分离。相关的监控措施配套齐全即可。
后台统计：负责统计呈现用户行为数据
如果流量提升了，并需要准实时，一般是如下的技术架构：
我们会用到Flume，kafka，storm等，这些都是分布式的。
前端的Tengine主要是输出接口程序收到的json数据到文本中。
Flume：推荐使用Flume-NG.
Kafka:在分布式集群方面要考虑一个topic多个partition的配置，还需要考虑zookeeper集群。
Storm：如果条件允许，就升级集群配置的内存。
用户行为数据共有几个类别：
a) 需要实时查询。这些可存储到索引集群中，例如elasticSearch，solrcould等，方便业务通过字符串等快速检索数据。
b) 需要准实时。这些数据主要是用来计算用户的下一次访问、感兴趣的产品。可以用spark执行计算，并将结果输出到hbase。利用hbase集群来承担对外的应用查询。
c) 一般应用数据。这些主要是离线的统计分析。可以使用关系型数据库来存储，让用户能看到隔天的数据效果。
从以上内容可以看出，kafka集群是非常重要的一个环节。如果我们想做到数据驱动产品，那么用户点击就数据，这些数据通过中央存储队列kafka，被不同 的应用程序消费，并计算反馈最优结果。这也是我一直期望去做的“实时消息驱动”，驱动的背后可以是营销，大盘监控，运营监控，也可以是推荐。
以上内容是我自身工作整理的一部分内容，接下来请牟兄分享下他在Hadoop的一些讲解。
趁大家都在聊日志相关的内容，我们先开始第三个话题，后面再介绍hadoop的几个案例。
日志在计算机系统中是一个非常广泛的概念，任何程序都有可能输出日志：操作系统内核、各种应用服务器，数据库服务器等等都有可能产生日志。
日志数据就像大数据宇宙的暗物质，在每一层，每一节点产生，然后在包括智能手机和互联网终端在内的分布式信息技术生态系统中生成。它们被收集，处理，分析和广泛使用，但大多时候，这些都发生在幕后。
日志数据对许多微型企业应用起到很基础的作用，如故障排除，调试，监控，安全，反欺诈，法规遵从和电子发现。然而，它也可以成为一个强大的工具，以用于分析点击流，地理空间，社交媒体，以及许多以客户为中心的使用情况等记录相关的行为数据。
日志文件的格式及其包含的信息
①2006-10-1700:00:00访问时间;
②202.200.44.43 用户IP地址;
③218.77.130.2480访问的URL，端口;
④GET请求方法(“GET”、“POST”等);
⑤/favicon.ico访问模式;
⑥Mozilla/5.0+(Windows；+U；+Windows+NT+5.1；+zh-CN；+rv：1.8.0.3)+Gecko/20060426+Firefox/1.5.0.3。agent，即用户使用的操作系统类型和浏览器软件。
一、日志的简单分析
1、注意那些被频繁访问的资源。
2、注意那些你网站上不存在资源的请求。常见的扫描式攻击还包括传递恶意参数等。
3、观察搜索引擎蜘蛛的来访情况。
4、观察访客行为。
应敌之策：
1、封杀某个IP。
2、封杀某个浏览器类型（Agent）。
3、封杀某个来源（Referer）。
4、防盗链。
5、文件重命名
作用：
1.对访问时间进行统计，可以得到服务器在某些时间段的访问情况（PV,UV）。
2.对IP进行统计，可以得到用户的分布情况。
3.对请求URL的统计，可以得到网站页面关注情况。
4.对错误请求的统计，可以更正有问题的页面。
5.对用户的来源进行分析，通过百度搜索？还是直接跳入？通过手机访问？还是PC浏览？通过微信的群聊？单聊？还是朋友圈转发。
二、网站挖掘
根据所挖掘的网站 数据的类型，可以将网站 数据挖掘分为以下三类：网站 内容挖掘(网站 ContentMining)、网站 结构挖掘(网站 Structure Mining)、网站 使用挖掘(网站 Usage Mining)（也称为网站日志挖掘）。
①网站内容挖掘。网站内容挖掘是指从文档的内容中提取知识。网站内容挖掘又分为文本挖掘和多媒体挖掘。目前多媒体数据的挖掘研究还处于探索阶段,网站文本挖掘已经有了比较实用的功能。
网站文本挖掘可以对网站上大量文档集合的内容进行总结、分类、聚类、关联分析,以及利用网站文档进行趋势预测等。网站文档中的标记,例如<Title>和<Heading>等蕴含了额外的信息,可以利用这些信息来加强网站文本挖掘的作用。
②网站结构挖掘。网站结构挖掘是从网站的组织结构和链接关系中推导知识。它不仅仅局限于文档之间的超链接结构,还包括文档内部的结构。文档中的URL目录路径的结构等。网站结构挖掘能够利用网页间的超链接信息对搜索引擎的检索结果进行相关度排序,寻找个人主页和相似网页,提高网站 搜索蜘蛛在网上的爬行效率,沿着超链接优先爬行。网站结构挖掘还可以用于对网站页进行分类、预测用户的网站链接使用及网站链接属性的可视化。对各个商业搜索引擎索引用的页数量进行统计分析等。
③网站使用记录挖掘。网站使用记录挖掘是指从网站的使用记录中提取感兴趣的模式，目前网站使用记录挖掘方面的研究较多,WWW中的每个服务器都保留了访问日志,记录了关于用户访问和交互的信息,可以通过分析和研究网站日志记录中的规律,来识别网站的潜在用户;
可以用基于扩展有向树模型来识别用户浏览序列模式,从而进行网站日志挖掘;可以根据用户访问的网站记录挖掘用户的兴趣关联规则,存放在兴趣关联知识库中,作为对用户行为进行预测的依据,从而为用户预取一些网站页面,加快用户获取页面的速度，分析这些数据还可以帮助理解用户的行为,从而改进站点的结构,或为用户提供个性化的服务。
三、网站日志挖掘的方法
（一）首先，进行数据的预处理。
从学习者的访问日志中得到的原始日志记录并不适于挖掘，必须进行适当的处理才能进行挖掘。因此，需要通过日志清理，去除无用的记录；对于某些记录，我们还需要通过站点结构信息，把URL路径补充成完整的访问序列等等；然后划分学习者，并把学习者的会话划分成多个事务。
（二）其次，进行模式发现
一旦学习者会话和事务识别完成，就可以采用下面的技术进行模式发现。模式发现, 是对预处理后的数据用数据挖掘算法来分析数据。分有统计、分类、聚类、关等多种方法。
①路径分析。它可以被用于判定在一个站点中最频繁访问的路径，还有一些其它的有关路径的信息通过路径分析可以得出。路径分析可以用来确定网站上的频繁访问路径, 从而调整和优化网站结构, 使得用户访问所需网页更加简单快捷, 还可以根据用户典型的浏览模式用于智能推荐和有针对性的电子商务活动。
②关联规则。使用关联规则发现方法，可以从网站的访问事务中找到的相关性。
③序列模式。在时间戳有序的事务集中，序列模式的发现就是指那些如“一些项跟随另一个项”这样的内部事务模式。它能发现数据库中如“在某一段时间内，客户购买商品A，接着会购买商品B，尔后又购买商品C，即序列A[表情]B[表情]C出现的频率高”之类的信息。
④分类分析。发现分类规则可以给出识别一个特殊群体的公共属性的描述，这种描述可以用于分类学习者。分类包括的挖掘技术将找出定义了一个项或事件是否属于数据中某特定子集或类的规则。该类技术是最广泛应用于各类业务问题的一类挖掘技术。
⑤聚类分析。可以从网站访问信息数据中聚类出具有相似特性的学习者。在网站事务日志中，聚类学习者信息或数据项能够便于开发和设计未来的教学模式和学习群体。聚类是将数据集划分为多个类，使得在同一类中的数据之间有较高的相似度，而在不同类中的数据差别尽可能大。在聚类技术中，没有预先定义好的类别和训练样本存在，所有记录都根据彼此相似程度来加以归类。
⑥统计。统计方法是从网站站点中抽取知识的最常用方法, 它通过分析会话文件, 对浏览时间、浏览路径等进行频度、平均值等统计分析。虽然缺乏深度, 但仍可用于改进网站结构, 增强系统安全性, 提高网站访问的效率等。
⑦协同过滤。协同过滤技术采用最近邻技术，利用客户的历史、喜好信息计算用户之间的距离，目标客户对特点商品的喜好程度由最近邻居对商品的评价的加权平均值来计算。
（三）模式分析
最后，进行模式分析。基于以上的所有过程，对原始数据进行进一步分析，找出用户的浏览模式规律，即用户的兴趣爱好及习惯，并使其可视化，为网页的规划及网站建设的决策提供具体理论依据。其主要方法有：采用SQL查询语句进行分析；将数据导入多维数据立方体中，用OLAP工具进行分析并给出可视化的结果输出。 （分类模式挖掘、聚类模式挖掘、时间序列模式挖掘、序列模式挖掘、关联规则等）
四、网站中网站日志挖掘内容
（1）网站的概要统计。网站的概要统计包括分析覆盖的时间、总的页面数、访问数、会话数、惟一访问者、以及平均访问、最高访问、上周访问、昨日访问等结果集。
（2）内容访问分析。内容访问分析包括最多及最少被访问的页面、最多访问路径、最多访问的新闻、最高访问的时间等。
（3）客户信息分析。客户信息分析包括访问者的来源省份统计、访问者使用的浏览器及操作系统分析、访问来自的页面或者网站、来自的IP地址以及访问者使用的搜索引擎。
（4）访问者活动周期行为分析。访问者活动周期行为分析包括一周7天的访问行为、一天24小时的访问行为、每周的最多的访问日、每天的最多访问时段等。
（5）主要访问错误分析。主要访问错误分析包括服务端错误、页面找不到错误等。
（6）网站栏目分析。网站栏目分析包括定制的频道和栏目设定，统计出各个栏目的访问情况，并进行分析。
（7）商务网站扩展分析。商务网站扩展分析是专门针对专题或多媒体文件或下载等内容的访问分析。
（8）行为分析。有4个方向可以选择:[表情]对用户点击行为的追踪，click stream研究；[表情]对网页之间的关联规则的研究；[表情]对网站中各个频道的浏览模式的研究；[表情]根据用户浏览行为，对用户进行聚类，细分研 究；（如果你能够结合现有的互联网产品和应用提出一些自己的建议和意见，那就更有价值了。）
（9）发现用户访问模式。通过分析和探究网站日志记录中的规律，可以识别电子商务的潜在客户，提高对最终用户的服务质量，并改进网站服务器系统的性能。
(10)反竞争情报活动。反竞争情报是企业竞争情报活动的重要组成部分。
五、日志分析的价值或应用
①在自己的网站上安装了网站统计的代码，如Google analytics、量子统计、百度统计、cnzz、51.la等，这些工具可以统计网站的流量，也就是网站上访客可看到的所有页面的访问量，但是这些统 计工具都不能统计你主机上资源的原始访问信息，例如某个图片被谁下载了。
②如果你的网站遭到了攻击、非法盗链和不良请求等，通过分析原始访问日志能大概分析出端倪来，例如：往主机上传了一个mp3，不幸被百度mp3收录，引来大量的盗链，导致我的主机流量猛增！通过分析日志，可以找出问题根源，删除了那个mp3，主机流量也降下来了。
③分析访客来源（Referer）。这一段是告诉我们访客是从哪里来到这一个网页。有可能是网站其他页，有可能是来自搜索引擎的搜索页等。通过这条来源信息，你可以揪出盗链者的网页。
④网站日志分析软件都能提供关于服务器的浏览量、统计网站所有页面和相关文件被显示的次数、访问最多的网页、客户端访问最频繁的文件、访问者的IP分布、每日访问统计、每周每月等的统计结果。
访问者访问时段分析：
结合IP地址和时段之间的关系可以将来访者大致的身份作一个基本的判断。如按上班前、工作期间、下班后、节假日等，可以针对访客的初步性质安排合适的内容，如产品信息和广告；
访问者地区分布：
分析通过将访问者的IP地址转换为地理区间可以分析出来访者的大致地理分布范围。
⑤相关产品推荐。通过以上的关联分析，有了用户频繁访问路径和链接之间的兴趣度，可以构建个性化推荐系统模型。对于实证例子，我们可以在置信度高于最低置信度的相关链接之间，建立某种信息快速互联的桥梁，亦或是在网页规划中，充分考虑链接之间的关联关系，从而为更人性化、合理化的网页设计提供决策依据。
⑥个性挖掘：针对单个用户的使用记录对该用户进行建模，结合该用户基本信息分析他的使用习惯、个人喜好，目的是在电子商务环境下为该用户提供与众不同的个性化服务。
⑦系统改进：网站服务（数据库、网络等）的性能和其他服务质量是衡量用户满意度的关键指标，网站用法挖掘可以通过用户的拥塞记录发现站点的性能瓶颈，以提示站点管理者改进网站缓存策略、网络传输策略、流量负载平衡机制和数据的分布策略。此外，可以通过分析网络的非法入侵数据找到系统弱点，提高站点安全性，这 在电子商务环境下尤为重要。
⑧站点修改：站点的结构和内容是吸引用户的关键。网站用法挖掘通过挖掘用户的行为记录和反馈情况为站点设计者提供改进的依，比如页面连接情况应如何组织、那些页面应能够直接访问等。
⑨智能商务：用户怎样使用网站站点的信息无疑是电子商务销售商关心的重点，用户一次访问的周期可分为被吸引、驻留、购买和离开四个步骤，网站用法挖掘可以通过分析用户点击流等网站日志信息挖掘用户行为的动机，以帮助销售商合理安排销售策略。
⑩网站特征描述：这类研究跟关注这样通过用户对站点的访问情况统计各个用户在页面上的交互情况，对用户访问情况进行特征描述。
六、 相关工具、软件及算法
(一) 相关工具、软件
a) hell/python/perl直接对日志文件进行解析
b) Excel 导入excel来统计PV，UV等
c) HIVE 直接使用hive的正则表达式
d) Flume+Kafka +Hadoop + Hive
利用flume来收集日志，Kafka做日志缓存，Hadoop做存储，Hive做分析
e) ELK（logstash+ elasticsearch + kibana）
Logstash负责日志收集，elasticsearch负责保存、索引，kibana负责报表展示。
f) Hadoop stream/stom/spark 实时流计算
(二) 算法
a) 各种排序算法
b) 分类算法：决策树等
c) 聚类算法：k-means, DBSCAN等
d) 关联规则分析：Apriori、FP-growth算法等
e) 推荐算法：协同过滤等等
f) PageRank算法和HITS算法利用网站页面间的超链接信息计算“权威型”（Authorities）网页和“目录型”（Hubs）网页的权值
g) 参考检索引擎的挖掘算法，比如Apache的lucene等，solr等
大数据落地：从日志分析开始的分享就先到这里，下面我分享几个Haoop的简单场景。
一个简单的日志分析系统：
1.不同网站应用通过埋点的方式来获取想要的数据，然后访问一个1*1的图片请求。
2.图片的请求记录都会存放在nginx日志里面。
3.定期备份access.log日志文件到hadoop的HDFS文件系统中。
4.通过Hive的正则表达式来解析access.log。
5.Sqoop和ketlle两种ETL工具来清洗、汇总数据到mysql中。
6.mysql默认存放的数据是1个月的数据，更多的数据存在hdfs中，通过hive的查询接口来返回更多的历史数据汇总。
7.用百度的echars+SpringMVC的方式自己开发报表展示。
再来分享一个安全审计系统
安全审计系统，主要作用是对用户的恶意应用访问起到过滤。
数据流程图：
架构图：
为什么是kafka？
Apache Kafka是由Apache软件基金会开发的一个开源消息系统项目，由Scala写成。Kafka最初是由LinkedIn开发，并于2011年初开源。
解耦性
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
冗余性
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
灵活性 & 峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
为什么要使用Spark？
Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用并行框架。
1.轻量级快速处理。着眼大数据处理，速度往往被置于第一位，我们经常寻找能尽快处理我们数据的工具。Spark允许Hadoop集群中的应用程序在内存中以 100倍的速度运行，即使在磁盘上运行也能快10倍。Spark通过减少磁盘IO来达到性能提升，它们将中间处理数据全部放到了内存中。
2. 易于使用，Spark支持多语言。Spark允许Java、Scala及Python，这允许开发者在自己熟悉的语言环境下进行工作。它自带了80多个高等级操作符，允许在shell中进行交互式查询。
3. 支持复杂查询。在简单的“map”及“reduce”操作之外，Spark还支持SQL查询、流式查询及复杂查询，比如开箱即用的机器学习机图算法。同时，用户可以在同一个工作流中无缝的搭配这些能力。
4. 实时的流处理。对比MapReduce只能处理离线数据，Spark支持实时的流计算。Spark依赖Spark Streaming对数据进行实时的处理，当然在YARN之后Hadoop也可以借助其他的工具进行流式计算。
5.可以与Hadoop和已存Hadoop数据整合。Spark可以独立的运行，除了可以运行在当下的YARN集群管理之外，它还可以读取已有的任何Hadoop数据。这是个非常大的优势，它可以运行在任何Hadoop数据源上，比如HBase、HDFS等，这个特性让用户可以轻易迁移已有Hadoop应用。
6. 活跃和无限壮大的社区。Spark起源于2009年，当下已有超过50个机构250个工程师贡献过代码，和去年六月相比，代码行数几乎扩大三倍，这是个令人艳羡的增长。
好的，我的分享就到这里。多说一句，大数据涉及的内容非常多，欢迎大家一起交流。
向上老师分享的太赞啦！
Hadoop 入门及其基础学习【连载更新中】
向上老师的视频，欢迎大家围观，我们一起来学习大数据，一起为大数据的发展添砖加瓦！下面我们进入自由讨论环节：
提问一：关于使用spark做olap靠谱么？有没有成熟案例？
同程吴文波：spark做olap？
天天向上：@大连-K12-王东 spark现在还是一种计算框架 。。
王东：greenplum和spark选型如何取舍呢？
同程吴文波：真有这样的方案哦
小小蜗牛爬上墙：olap用cognos，ibm推广较好的，据说11R版本的cognos会支持hadoop。
锋：spark现在是不是发展很快。
小小蜗牛爬上墙：看来从传统数据仓库往大数据平台迁移任重道远呀。
天天向上：还是要找到价值点，不能盲目的上大数据。
春宇：传统数据仓库和大数据平台分工不同，列存，MPP能够解决的事情，不见得非得挪到Hadoop上去。
同程吴文波：@大连-K12-王东 怎么想到用spark做olap？
春宇：现在就是觉得系统太多，企业统一化的数据视图更难画了
大米：主要的生产数据还是用主流关系数据库，分析用hadoop是这样理解吗？
王东：@同程吴文波 我就是觉得数据层的东西太多，开发维护成本有点高，所以想用spark解决olap和大数据分析等各种场景
同程吴文波：@大连-K12-王东 试试Hadoop+kylin 或spark+cassandra等组合
王东：我们也打算围绕spark做呢，但是这块儿没实际操作过，比较担心olap的响应速度。
Shadow 杨：@大连-K12-王东 [发呆]多大的数据量，数据量不到一定程度，根本发挥不出来。
王东：@Shadow 杨 事实表千万级别，维度表特别多有上百。
同程吴文波：@大连-K12-王东 你的这些用普通db来构建olap就好
Shadow 杨：@同程吴文波 同意你
天天向上：普通的就可以啊，微软的sass就搞定了。
王东：事实表千万级别greenplum行吗？
同程吴文波：@大连-K12-王东 gp是可以搞定的。但是你的那个数据量用SSAS也就行的。使用SSD 3.2T的+128G内存 或 256G就OK
王东：cognos和ssas是一个量级的么？
春宇：Cognos你用什么？PowerCube?Dynamic Cube?还是TM1？
王东：cognos也没实际用过，这几个cube啥区别啊
春宇：@大连-K12-王东 话题太长，可单聊，但就性价比而言，还是建议你选择SSAS或者开源的OLAP引擎。
提问二：对于初学者学数据分析有没有推荐的书籍？
梁勇：想要做数据分析的话可以看的书——基础篇
，Shadow杨的博客上面很多，菜鸟数据教你从零开始学习数据分析】课程已更新，由芥末网高级数据分析师 Shadow 精心录制，每周更新四集。想要入门数据分析和提升的小伙伴们赶紧学习起来吧~免费学习地址： 及博客专栏 菜鸟数据 数据分析——从菜鸟到高手，书和视频教程双管齐下，定会给想学习数据分析却还迷茫没有方向的小伙伴儿们照亮学习的路，给大家一把利剑，助大家一臂之力，斩除学习过程中的疑惑困顿和妖魔鬼怪！
Shadow 杨：数据分析太大，不是一本书能讲明白的，而且本身方向就很多，因为业务需求不同，数据分析师所思维都不同。我建议初学者，可以先从一个方向下手，比如，电商，游戏，或者互联网，或者传统，找一个方向研究。
Let it be：数据分析的关键应该是目标清晰，知道要做什么，然后才是方法，技术实现吧。
Echo：问下 现在数据分析的工作大概分为那几块？
小小蜗牛爬上墙：数据分析都是业务驱动的。
Shadow 杨：都需要，业务驱动是必须的，技术也是必须的。
Let it be：想要什么？游戏和马云要的显然不同，方法可能就不一样了
轩子：你们都说从基础学，那基础到底是啥咩？…
Shadow 杨：你要做什么方向的分析师，技术还是业务，数据分析师分为技术向和业务向，业务向并不是不需要技术啊。
夏尔康：数据分析师是以业务为王，业务都不清楚，分析出来的东西很空洞。
轩子：关键，学习肯定学的是技术技能方面，业务是软的，我主要不知道学习技能从哪些入手？
小小蜗牛爬上墙：基础，还是应该从理论原理入手吧，那些技术只是实现方法不同
Echo：就说技术吧，都有负责哪些技术的？
吴君-51随意行-客流专家：我是创新方向，市场上有啥痛点没解决，大数据就可以有地方切入。
魏龙江：数学不好的可能学好吗
夏尔康：那你必须掌握统计的常用算法和参数解读，分析软件也得会一两个。
Shadow 杨：我录菜鸟数据的目的就是让更多的人了解数据分析，我一直觉得，数据分析应该是一种技能，未来无论什么行业，什么职业都要会。
提问三：大数据方向有哪些技术或哪些职位？
天天向上：与大数据有关的：云计算，Ｈａｄｏｏｐ运维工程师，开发工程师，数据分析，数据挖掘工程师。正在做的有爬虫，推荐，用户行为等等。
提问四：学习数据分析，感觉软件太多，基础要用到统计学，sql采集语句，数据仓库等，不知道哪些是要先学？
Echo：我觉得学习统计的话就可以走算法路线 做研发，，不需要数据库方面的知识，对吗？
天天向上：@轩子 优先SQL．这个到时候会用到。
Shadow 杨:@轩子 统计学，sql，数据库结构与算法，R语言，python，这些可以了，足够你应聘工作。再深一点的，就是机器学习，建议你学习一下数理统计。应用数学，如果是金融向的，计量经济学和软件stata可以看一下。
Shadow 杨：技术是没有办法跟上潮流的，现在流行什么很快就会被替代，抓住一个点，研究透了就好了。
夏尔康：数据分析师玩弄懂模型意义，参数解读，统计学的那些模型是经得起考验的。
小小蜗牛爬上墙：理论和原理不变，技术只是实现手段。
给大家看看12月4日的火爆情况，
这么多聊天记录都没有全部囊括今天所有的分享及问题讨论内容，直接粘贴到word中有上百页，然后经过小编的整理，留下了50多页的精华，参与人数众多，讨论时你一言我一语，还有同学很久之后又回复好久之前的问题，小编一点一点看懂了之后整理成按问题+回复的形式，小编在整理的过程中也学到了好多，大家如果觉得小编的整理还合你们的胃口，点赞+分享吧，小编希望整理的精华能让更多人看到！谢谢！
每周 Friday BI Fly 微信直播参加方式，加个人微信：liangyong1107 并发送微信：行业+姓名，参加天善智能微信直播。