【Friday BI Fly】2015年12月04日大数据分析背景、Hadoop架构及日志系统在Hadoop的应用与实现微信直播文字版记录 【全程回放】

浏览: 4937

Clipboard Image.png

公告

【公告】周五BI飞起来,天善商业智能BI社区每周五下午举办问答社区在线答疑活动,每周五晚上举办行业、厂商工具、技术相关的微信在线直播活动。

【预告】下周微信直播的话题有:

1、旅游行业如何根据不同的人群做精准的酒店推荐匹配。

2、大数据技术在智慧旅游行业中如何应用?

3、旅游行业数据收集,数据预处理,个性化推荐等。

Clipboard Image.png

Clipboard Image.png

2015年12月04日 Friday BI Fly 微信直播主题 – 大数据分析背景、Hadoop架构及日志系统在Hadoop的应用及实现。

主持人:加入本群的同学们,感谢大家参加由天善智能举办的 Friday BI Fly 活动,每周五微信直播,每周一个话题敬请关注。

【群规】本群为BI 行业、技术、工具交流和学习群。不准发广告,只能发红包,发广告者一律移除微信群。

本次微信直播讨论内容:

1、大数据分析背景。

2、Hadoop应用、分布式架构。

3、日志系统在Hadoop的应用及实现。

嘉宾介绍

Bob

同程旅游大数据BI架构师。 从C#到java, 从sql到BI,从cube到Hadoop,从Hadoop到nosql+mpp+storm。一路走来,只为心中的执着。

个人专栏:http://www.flybi.net/people/Bob 

博客专栏:http://www.flybi.net/blog/Bobwu

Clipboard Image.png


Clipboard Image.png

天天向上

7年工作经验,2年项目管理经验,曾就职于知名互联网公司担任软件经理,现就职于人民日报媒体技术中心担任大数据开发工程师,负责构建人民日报媒体数据平台构建与开发。

关注范围:分布式高性能并发处理,开源技术,大数据实现,数据可视化,数据分析与挖掘(算法与解决方案)

个人专栏:http://www.flybi.net/people/marey111

博客专栏:http://www.flybi.net/blog/marey_marey111 

学院Hadoop视频:Hadoop 入门及其基础学习【连载更新中】http://www.hellobi.com/course/39
Clipboard Image.png

Clipboard Image.png


主持人:欢迎我们两位嘉宾的到来,两位都在大数据方向有丰富的经验,很期待今天的分享,我们开始第一个话题的分享吧,我们来一起聊一下大数据产生的背景。 有请我们的嘉宾@同程吴文波 @天天向上 

话题一:大数据分析背景

天天向上

大家好,我是牟瑞(MuRui),这个姓读Mu,不读Mou,在天善的论坛里面是叫天天向上,目前是在人民日报媒体技术公司工作,非常感谢梁总和吕总给了我这次与大家交流学习的机会。天善智能大数据交流群 : 225978231 加群请注明: 天善智能。

先说点政府层面的大数据分析背景。

现在大数据这次词在时下的热门程度,无需多说,在今年的9月5号,国务院总理李克强还特别印发了《促进大数据发展行动纲要》,系统部署了大数据发展的工作。

《纲要》的官网地址:

http://www.gov.cn/zhengce/content/2015-09/05/content_10137.htm

我挑了一点重要的分享一下。

《纲要》提出,要加强顶层设计和统筹协调,大力推动政府信息系统和公共数据互联开放共享,加快政府信息平台整合,消除信息孤岛,推进数据资源向社会开放,增强政府公信力,引导社会发展,服务公众企业;以企业为主体,营造宽松公平环境,加大大数据关键技术研发、产业发展和人才培养力度,着力推进数据汇集和发掘,深化大数据在各行业创新应用,促进大数据产业健康发展;

完善法规制度和标准体系,科学规范利用大数据,切实保障数据安全。《纲要》明确,推动大数据发展和应用,在未来5年至10年打造精准治理、多方协作的社会治理新模式,建立运行平稳、安全高效的经济运行新机制,构建以人为本、惠及全民的民生服务新体系,开启大众创业、万众创新的创新驱动新格局,培育高端智能、新兴繁荣的产业发展新生态。

《纲要》要求,各有关部门要进一步统一思想,认真落实各项任务,共同推动形成公共信息资源共享共用和大数据产业健康发展的良好格局。

在纲要下发之前,大数据主要还是存在于民间,各大互联网行业做的比较好,那么在纲要下发之后,说明大数据行业已经作为一个产业,得到了政府的支持和认可,并在政策上予以扶持。

另外,贵阳大数据交易所于2015年4月15日,正式挂牌运营并完成首批大数据交易,贵阳大数据交易所完成的首批数据交易卖方为深圳市腾讯计算机系统有限公司、广东省数字广东研究院,买方为京东云平台、中金数据系统有限公司。

几家单位简单截个图

Clipboard Image.png

同时在今年的6月17号,习总还特意到贵阳市大数据广场,走进大数据应用展示中心,听取贵州大数据产业发展、规划和实际应用情况介绍。

不好意思,上面扯了很多政策性的东西,也比较符合我在人民日报的风格。

以上主要是想说明,现在大数据在国家层面已经得到了很大的支持,未来大数据产业,会有一个非常大的发展,大数据行业是大有可为的。但是,我想说,但是,我们在实践的过程中,尤其是很多的政府部门,传统行业,还处在大数据时代非常初级的阶段。

拿人民日报来说,正部级单位,正宗的传统媒体行业。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,Williammongo加索引排序应该还好吧。 相对于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 小小蜗牛爬上墙)

天天向上 @小小蜗牛爬上墙 回答你刚才的那个问题,我们现在的服务器日志最多只保留7天,不会是非常海量的日志。

小小蜗牛爬上墙:现在主要的困惑是,一个联机集群里有几十台主机,你讲的那些基本开发的思维,对于生产环境来说是否适合?生产环境的话,时效才是第一要素。

天天向上:@小小蜗牛爬上墙 几十台主机都基本上不会存放特别多的日志,会统一收集。

小小蜗牛爬上墙:收集是一方面,我们目前还是基本定位哪个节点有异常,然后登到主机上查看,沿用小机和大机的处理方式

天天向上:@小小蜗牛爬上墙 刚才波哥讲了,弄个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,Williamkafka和rabbitmq 功能一样吧。 我们用的后者。。。

同程吴文波:校验的方式也很简单,你在app上设计一个计数器。

同程吴文波:kafka比较变态,本身能存储10几T。

铮:还有一点,如果程序在前台处理了,用户点击的数据在后台没留下?该如何收集?

同程吴文波:@铮 如果前端有处理,那要坚持日志是否到达你的接口层,接口层一定要实时输出到文本中。

 

提问五:请说说大数据的核心是什么?有一种观点,不上hadoop就不是大数据,你如何看这个问题?

天天向上:@内心召唤 我个人理解的核心还是有价值,如何从海量的数据中提取出基于业务的,并且有市场前景的价值。hadoop只是一种数据存储和计算解决方案。mysql的大集群也可以存放海量的数据。

 

提问六:有个关于mongodb的问题,就是当主从复制集,主集按照某个索引条件删除大量数据时,瞬间完成。但是从集却是按id一条一条删除,导致长时间主从数据不一致,这个大家有遇到过吗?

小小蜗牛爬上墙:对于mysql主从复制,在生产环境我们是不允许的

高不高:@小小蜗牛爬上墙 ,为什么不允许?

小小蜗牛爬上墙:因为binlog没法保证slave数据实时,建议异步写两份

Hao,Williammysql其实横向扩展已经能承载大数据了。mongo我们考虑到是维护和成本低。

同程吴文波:mongodb集群的硬件要好点,才行

Hao,William现在800多w日志才5g 呵呵。我们小数据来说还可以 呵呵。

Daniel JiangGreenPlum怎么样?比起Mysql的横向扩展?

天天向上:mysql我们现在是双主。。。

Hao,Williammongodb 还是很牛逼的目前看起来 -->

大米:@天天向上 双主可以同时写吗?数据会一致吗

天天向上:@杭州-服裝-大米 一致的啊。分开随机写。

王东:能透漏下你们mongodb都什么配置么?

小小蜗牛爬上墙:我们目前部署的都是双主,主从还会有个毛病就是,主机宕机后,从机数据无法保证能够恢复和主机一致。

Hao,William一台机器8g内存,4核,1t硬盘。

 

提问七:第一、二类产业如何开展大数据建设?

对于互联网、商业、银行等行业,现在只需要关心技术就可以了,而其他行业该如何开展大数据建设还是很迷茫的,比如说我们石油行业,领导说给你资金搞搞大数据,搞了一年都不知道从何入手,我们行业的领导喜欢追新,有些想法脱离实际。其实很多行业,尤其是第一二类产业更需要考虑如何开展大数据建设,这些行业才是兴国之本啊

同程吴文波:像这种情况,你应该直接给领导出一份数据分析报告,然后告诉他这是大数据的结果。分析报告可以使用spss,R语言来完成。

内心召唤:我们是石油开采行业,传统技术在找油方面遇到了一些瓶颈,基础理论没有突破,领导的想法是看看大数据能不能做些工作,搞的我们这些IT人员很迷茫和困惑。

天天向上:@内心召唤 你们是找油么?是否可以根据你们之前找到油田的经验,来收集各种数据,做一个数据挖掘。

内心召唤:@天天向上 ,你和我的思路一致,我们有几十年的数据积累,应该先从找规律开始着手。

春宇:@内心召唤 我倒觉得你们需要科学家做头脑碰撞,但凭IT搞也是瞎搞

天天向上:@内心召唤 真别着急搞什么hadoop什么的,先确定方向。。关系数据库,甚至是Excel都可以来做你们的数据分析的模型。。

内心召唤:@春宇 说的是,最近在和IBM的研究院在开展合作,和石油大学也有合作,正在探索中。

在路上:@春宇 我们也认为这种专家很重要,单是IT没成效

内心召唤:@天天向上 领导层一直认为要上个大数据平台才高大上

春宇:@内心召唤 你们主要负责把基础数据层打好,科学家们有数据洞察能力,如果没有慢慢磨砺也会产生,毕竟是研究了几十年的成熟的科学。

夏尔康:基础层是支撑你们数据分析的。

天天向上:@内心召唤 看你们的数据的规模和数据形式。。

内心召唤:@天天向上 个人认为如果传统的数据分析和挖掘技术能够解决问题,没必要上hadoop之类的东东,运维成本和难度太高

天天向上:传统行业转型,人才成本比较高。

小小蜗牛爬上墙:传统金融行业,转型开放平台,担心的更多是时效性,特别是联机系统。

春宇:@内心召唤 你们这个有难度,是从未知->已知,所以也不知道哪些数据是需要的,哪些是不需要的,需要大量的数据研究,这个IT人是做不了的,一定是和石油科学家通力协作。以及去翻看国际上知名的论文,但是否能从中有所收获。我大概猜你们领导的观念实际上和舍恩伯格的思路一致,就是不是结果导向的,是建立好关系以后,再去分析出结果。真是任重道远。

小小蜗牛爬上墙:我们最近搞云平台和集群,工作量比小机多了N倍

内心召唤:@小小蜗牛爬上墙 那些行业分析模型基本已经建立,剩下只是性能的问题了

天天向上:@春宇 @内心召唤 我们遇到的情况都差不多。。。但相对的,我们这边没有还算比较理性,目前算是找到了比较好的切入点。各方势力也比较配合。

春宇:@内心召唤 科研性质更强,不是传统DataAnalytic的思路

内心召唤:@春宇 嗯,要想突破确实难啊,希望有此类想法或是有些成果的交流合作啊。

 

提问八有些电商系统总是推荐用户已经购买过的同类商品,如何使系统推荐关联商品而非相似商品呢?希望做过的讲一下,采用的什么算法?

同程吴文波:@深圳-DM-海原 我做过此类的。

海原星宿:@同程吴文波 是事先将每一种商品都编写一个关联规则吗? 

同程吴文波:@深圳-DM-海原 不需要每种。你需要设计一个关联规则的模型。输入参数是你的资源,输出关联结果。


提问九:我们的系统日志因为历史原因现在都写文件里面了,这个能不能不改系统直接pipeflume呢?

天天向上:@大连-K12-王东 可以的,直接读一下就可以的。


提问十:如果使用mysql碰到分库的话,你们使用哪种方式快速定位哪个库的哪条异常数据呢?(by 小小蜗牛爬上墙)

同程吴文波:我没有用mysql集群,我搭建了greenplum集群。之前搭建过postgresql-xl的集群,测试了发现有bug。现在GreenPlum开源了,就火速用了。

春宇:@同程吴文波 GP开源的事老早就听说,但没找到地方下载啊?

Daniel Jiangoschina.net有下载GP的地址

同程吴文波:http://pivotal.io/这个是官方的。emc成立的子公司,叫pivotal。

小小蜗牛爬上墙:你们生产用的哪种方式?

同程吴文波:生产用ms sql。


提问十一:我们的关系数据库中有些对象是hadoop不支持的,而且数据表多,字段多,相对数据量倒不大,做过一些简单的测试,比如说查询,效率还不如关系数据库。(by内心召唤

同程吴文波:@内心召唤 不要盲目上Hadoop或其他的大数据。

春宇:@内心召唤 先用关系型数据库吧,GP都开源了,一般的都能搞定

同程吴文波:恩,我自己搭建了gp,和Hadoop互相结合使用

春宇:从前移动一天8000W数据,Oracle 9i也一样跑,就是稍微慢点

内心召唤:@春宇 那应该是有集群支持吧

春宇:嗯,我也没用过GP,不过你们的东西科研性质强,对实时性,高可用性这些东西要求其实不高

先锋:greenplum确实不错

春宇:或者你找找列存数据库,压缩比都接近100:1,一个T进去也就是10G,速度飞快

内心召唤:@春宇 同样存在数据对象不支持的情况,目前这些新型的数据库主要特点感觉还是对象类型单一,但数据量巨大的情况


提问十二:因为对于开发和测试环境,做运维的不需要关心太多。主要就是集中精力在生产环境的性能、稳定和时效性,那些技术一上生产并行就不行了,怎么解决?(by小小蜗牛爬上墙

天天向上:@小小蜗牛爬上墙 测试没做好。

小小蜗牛爬上墙:模拟数据和生产数据还有很大差异,测试环境我们测到10000做哟的tps,到生产物理资源更好,就有各种问题。比如:底层NAS读写串行,磁盘达到90%以上繁忙程度。

天天向上:@小小蜗牛爬上墙 预上线环境与生产环境基本上是一致的。

小小蜗牛爬上墙:你说的测试没测好太笼统了,预上线我们叫并行,最后直接切换。

天天向上:@小小蜗牛爬上墙 那你们的压测没做好么?

主持人:讨论太激烈了,可以体会到大数据有多热了,很多企业都面临转型,很多企业也都在摸索,大家才会有这么多的问题,大家都希望利用大数据技术为公司赢来更大的利润,可以想象我们现在以及未来的大数据人才有多吃香了,大家快来学习吧,天善为你提供了这样的学习平台,http://www.hellobi.com/哪里不会点哪里,哈哈!废话不多说,我们下面两个话题一起来分享2Hadoop应用、分布式架构3、日志系统在Hadoop的应用及实现。

话题二&三:Hadoop应用、分布式架构、日志系统在Hadoop的应用及实现

吴文波bob

大家好,我是同程的吴文波,大家可以叫我Bob。一直是在同程旅游负责数据的研发。今天先分享下我们在日志方面的一些处理方式。

企业日志的几种情况:

A.  服务器监控日志

B.  内部应用程序日志

C.  网站用户点击行为日志

服务器监控日志

服务器监控日志对企业来讲是非常重要的一个部分。这部分数据包含服务器的性能监控,也包含应用程序站点的日志监控。企业上了一定规模以后,是迫切需要解决当前服务器的运行状态、应用程序运行状态。如果在外部市场投放了广告,带来巨大流量后,可视化实时监控web应用程序运行状态是很关键的。

服务器监控通常会用到Cacti,zabbix,ganglia,Splunk等工具。

其中Splunk是一个顶级日志分析软件,它不仅可以用多种方式来添加日志,生产图形化报表,最厉害的是它的搜索功能 - 被称为“Google for IT”。Splunk是商业版。

Cacti,zabbix大部分是用来做服务器CPU、磁盘、网络等情况进行监控。

日志信息分析工具中推荐使用Logstash+Elasticsearch+ Kibana这三个组合进行监控。

Clipboard Image.png

这三个产品的大致工作流程是:logstash agent 监控日志——》 redis(队列) ——》logstash index——》全文搜索服务ElasticSearch.前端通过Kibana 来结合 自定义搜索进行页面展示

在安装这些的时候要准备好Ruby,JDK等环境,过程中一定要考虑Logstash+Elasticsearch+ Kibana这三个版本的兼容性,切莫追求最新最高大上的版本。

官网:
https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html
logstash支持的inputs、codecs、filters和outputs的参数配置:
https://www.elastic.co/guide/en/logstash/current/index.html
如果大家有兴趣,推荐中文学习资料:
http://udn.yyuap.com/doc/logstash-best-practice-cn/get_start/introduction.html

内部应用程序日志

应用程序内部产生的日志,码农专用。

应用程序的日志是在研发体系中一个非常重要的环节。一个产品上线后出现问题,例如需要排查程序过程中拼接产生的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的情况下,则采用如下的技术架构:

Clipboard Image.png

Web程序:用户在浏览和点击时,触发js或app sdk事件,负责将数据以json等方式提交到接口程序。

接口程序:负责解析接收到的数据,并存储到数据库。在这个地方,最好考虑下做个负载均衡。

关系型数据库:数据库方面做个读写分离。相关的监控措施配套齐全即可。

后台统计:负责统计呈现用户行为数据

如果流量提升了,并需要准实时,一般是如下的技术架构:

Clipboard Image.png

我们会用到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的简单场景。

一个简单的日志分析系统:

Clipboard Image.png


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的方式自己开发报表展示。
再来分享一个安全审计系统

安全审计系统,主要作用是对用户的恶意应用访问起到过滤。

数据流程图:

Clipboard Image.png

架构图:
Clipboard Image.png

为什么是kafka

Apache Kafka是由Apache软件基金会开发的一个开源消息系统项目,由Scala写成。Kafka最初是由LinkedIn开发,并于2011年初开源。

Clipboard Image.png

解耦性      

在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。

冗余性       

有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。

扩展性      

因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

灵活性 & 峰值处理能力      

在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。

可恢复性          

系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。

顺序保证        

在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。

缓冲           

在任何重要的系统中,都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。

异步通信         

很多时候,用户不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。
为什么要使用Spark

Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用并行框架。

Clipboard Image.png

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 入门及其基础学习【连载更新中】
http://www.hellobi.com/course/39
 向上老师的视频,欢迎大家围观,我们一起来学习大数据,一起为大数据的发展添砖加瓦!下面我们进入自由讨论环节:

自由讨论环节:

提问一:关于使用sparkolap靠谱么?有没有成熟案例?

同程吴文波: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引擎。

 

提问二:对于初学者学数据分析有没有推荐的书籍?

梁勇:想要做数据分析的话可以看的书——基础篇

http://www.flybi.net/blog/CNDT87/2557Shadow杨的博客上面很多,菜鸟数据教你从零开始学习数据分析】课程已更新,由芥末网高级数据分析师 Shadow 精心录制,每周更新四集。想要入门数据分析和提升的小伙伴们赶紧学习起来吧~免费学习地址:http://www.hellobi.com/course/47 及博客专栏 菜鸟数据 http://www.flybi.net/blog/CNDT87 数据分析——从菜鸟到高手,书和视频教程双管齐下,定会给想学习数据分析却还迷茫没有方向的小伙伴儿们照亮学习的路,给大家一把利剑,助大家一臂之力,斩除学习过程中的疑惑困顿和妖魔鬼怪!

Clipboard Image.png

Shadow 杨:数据分析太大,不是一本书能讲明白的,而且本身方向就很多,因为业务需求不同,数据分析师所思维都不同。我建议初学者,可以先从一个方向下手比如,电商,游戏,或者互联网,或者传统,找一个方向研究。

Let it be数据分析的关键应该是目标清晰,知道要做什么,然后才是方法,技术实现吧。

Echo问下 现在数据分析的工作大概分为那几块?

小小蜗牛爬上墙:数据分析都是业务驱动的。

Shadow 杨:都需要,业务驱动是必须的,技术也是必须的。

Let it be想要什么?游戏和马云要的显然不同,方法可能就不一样了

轩子:你们都说从基础学,那基础到底是啥咩?…

Shadow 杨:你要做什么方向的分析师,技术还是业务,数据分析师分为技术向和业务向,业务向并不是不需要技术啊。

夏尔康:数据分析师是以业务为王,业务都不清楚,分析出来的东西很空洞。

轩子:关键,学习肯定学的是技术技能方面,业务是软的,我主要不知道学习技能从哪些入手?

小小蜗牛爬上墙:基础,还是应该从理论原理入手吧,那些技术只是实现方法不同

Echo就说技术吧,都有负责哪些技术的?

吴君-51随意行-客流专家:我是创新方向,市场上有啥痛点没解决,大数据就可以有地方切入。

魏龙江:数学不好的可能学好吗

夏尔康:那你必须掌握统计的常用算法和参数解读,分析软件也得会一两个。

Shadow 杨:我录菜鸟数据的目的就是让更多的人了解数据分析,我一直觉得,数据分析应该是一种技能,未来无论什么行业,什么职业都要会。

 

提问三:大数据方向有哪些技术或哪些职位?

天天向上:与大数据有关的:云计算,Hadoop运维工程师,开发工程师,数据分析,数据挖掘工程师。正在做的有爬虫,推荐,用户行为等等。

提问四:学习数据分析,感觉软件太多,基础要用到统计学,sql采集语句,数据仓库等,不知道哪些是要先学?

Echo我觉得学习统计的话就可以走算法路线 做研发,,不需要数据库方面的知识,对吗?

天天向上:@轩子 优先SQL.这个到时候会用到。

Shadow :@轩子 统计学,sql,数据库结构与算法,R语言,python,这些可以了,足够你应聘工作。再深一点的,就是机器学习,建议你学习一下数理统计。应用数学,如果是金融向的,计量经济学和软件stata可以看一下。

Shadow 杨:技术是没有办法跟上潮流的,现在流行什么很快就会被替代,抓住一个点,研究透了就好了。

夏尔康:数据分析师玩弄懂模型意义,参数解读,统计学的那些模型是经得起考验的。

小小蜗牛爬上墙:理论和原理不变,技术只是实现手段。

 

提问五:请问同程APP里面会有原生代码和h5 的交互吗,怎么处理APP里面行为和h5之间连续性记录?

同程吴文波: h5是基于混合开发的,在hybrid的情况下,h5是可以和app一样执行埋点任务。

周勇:还有你们APP日志上报的时间多久一次啊,在防止或者减少丢失方面有什么举措。

天天向上:@周勇 基本上是实时的。

 

提问六:@同程吴文波一般做日志采集ELK主要还是对应用服务器日志简单分析下UV PV流量等常规指标!要贴合实际业务的还是要靠埋点。但业务系统对埋点js还是不太乐意接受?

同程吴文波:@Detaillee app的埋点确实是需要的。业务系统如果要进行js埋点,那么你的js应该是一个组件。

 

提问七:最近做个问卷调查,不知道用统计分析做报告还是数据挖掘。。

Shadow 杨:@深圳-数据分析(Mr yang) 多少样本

夏尔康:@深圳-数据分析(Mr yang) 问卷需要挖掘什么,尽管根据你的调查数据说话。

JMAN1000有效

夏尔康:如果列很多就要考虑挖掘了,毕竟两个两个的进行相关分析就要弄死人了

JMAN我们做了个大学生使用互联网金融产品的调查,13个列。

夏尔康:十三个列还有什么好挖掘的……

JMAN:用神经网络。

春宇:千万数据,100列都没多少啊

夏尔康:算法不是高级就好,合适才行。十三个列,我觉得用一般统计描述就搞定了

Shadow 杨:做数据报告的时候,理论要上天,实践要落地,必须有结论,不然数据就是废纸一张。

Shadow 杨:这就是纵横江湖这么多年的决招,还有,你得了解他需要你给他看什么,不同身份对数据报告的解读的角度也不一样。数据处理的角度就必须要不一样。

JMAN越高级的领导越只在乎结果

大米:@Shadow 杨 会不会报喜不报忧!

Shadow 杨:不可以,要保持中立,不能带有主观色彩

JMAN感觉数据得出来的东西加入点主观会更接近事实

Shadow 杨:所谓的主观就是你的直觉,心理学里说,人们的直觉95%都是错的。

夏尔康:根据数据说话,谁知道你主观对还是错。

JMAN对,我们只是辅助决策。

Shadow 杨:我是致力于数据驱动。

主持人:今天的话题讨论到23:30都远远没有结束。

Clipboard Image.png

同学们对老师精彩分享的反馈是这样的

Clipboard Image.png

还有这样的

Clipboard Image.png

小编后记

【小编后记】给大家看看12月4日的火爆情况,

Clipboard Image.png

这么多聊天记录都没有全部囊括今天所有的分享及问题讨论内容,直接粘贴到word中有上百页,然后经过小编的整理,留下了50多页的精华,参与人数众多,讨论时你一言我一语,还有同学很久之后又回复好久之前的问题,小编一点一点看懂了之后整理成按问题+回复的形式,小编在整理的过程中也学到了好多,大家如果觉得小编的整理还合你们的胃口,点赞+分享吧,小编希望整理的精华能让更多人看到!谢谢!

再次预告下我们下周微信直播的话题:

1、旅游行业如何根据不同的人群做精准的酒店推荐匹配。

2、大数据技术在智慧旅游行业中如何应用?

3、旅游行业数据收集,数据预处理,个性化推荐等。

感兴趣的朋友不要错过咯。

参与方式

每周 Friday BI Fly 微信直播参加方式,加个人微信:liangyong1107 并发送微信:行业+姓名,参加天善智能微信直播。

Clipboard Image.png


Clipboard Image.png


Clipboard Image.png


Clipboard Image.png


Clipboard Image.png





推荐 4
本文由 天善智能 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

2 个评论

感谢小编整理,收藏啊
感谢天善的组织及小编的整理,这里太好啊

要回复文章请先登录注册