请问单月数亿/年度超过十亿级规模的日志分析系统需要使用Hadoop吗？
目前在小范围试用的一个系统，生产环境用的Oracle数据库。系统的行为日志模块要详细记录所有用户（总的活跃用户规模大概几百万）的每一个操作，根据目前小规模试用的现状评估，预计全面使用后单月的行为日志数会达到数亿的规模。
用户行为日志分析在系统中是一个蛮重要的模块，目前在小规模试用期几百万数据量的情况下用Oracle速度还可以，但是如果全面铺开后一年累计几十亿记录这种规模，用关系型数据库去做数据分析和统计会不会太吃力了？以前听说上 TB、PB级数据才用Hadoop类的大数据系统，而我们的系统其实日志的字节量并不大，也就是几十几百G的水平，所以一直没考虑。但是现在发现日志的条目数量比较大，而且要做的关联分析比较多，所以担心Oracle数据撑不撑得住。
是否需要将日志分析这部分需要单独拿出来，上Hadoop+Spark这种分布式处理系统？
请专家们指点迷津。
Oracle数据库内做数据分析在使用了parallel并行之后，在1亿级规模的数据其处理速度跟小型hadoop集群（5-10台，128-256MB内存）速度差不多，但依然存在缺点：1、其处理逻辑在数据库本身，复杂逻辑处理时影响数据库对外服务的性能，导致其他用户无法正常访问是经常的，尤其在加了parallel并行之后；2、规模超过1亿级之后，运行速度大幅降低，且容易卡死。
建议使用hadoop，原因两点：1、数据必然增长，有备无患；2、转移处理实体，保证数据库的正常性能。
发布于 2016-02-22 添加评论 感谢
shangrz
日志分析全套Elasticsearch+kibana+logstash准实时,数据展示,离线分析还可以用es-hadoop结合了不错.
实在想省事不差钱上splunk,非常适合这种条目数超多单条小的log分析,准实时,dashboard报表功能简单好用,SIEM相应的功能如关联分析\事件记录也适合套用到题主记录用户所有行为的场景
发布于 2016-02-11 添加评论 感谢
程磊
潜心修炼中~~~
这样的数据量级没有必要用hadoop，spark，但传统的存储引擎有些吃力了。
考虑到业务增长，有一定的前瞻性的话，还是迁移到hadoop上吧；
发布于 2016-01-30
匿名用户
本司每日上亿浏览日志，分发一直用sql server，暂时运行流程，归档用hive，hbase，olap 用greenplum
发布于 2016-01-30
桑文锋
神策数据创始人兼CEO，前百度大数据部技…
建议可以试试Hadoop了， 几十亿的记录灌到Oracle进行数据分析，还是会比较吃力的。如果用Oracle去做，经过精心设计可能也能吃得消（我没试过）。但你这里要对比一下业务数据库的应用场景和用户行为分析即日志分析的差异。
在日志分析时，我们一般是把尽量多和全的数据采集为文件记录，然后方便做各种adhoc的分析，不管是单机也好，Hadoop也好，强调的是一个灵活。
我们用Oracle做业务数据库时，在设计理念上，会倾向于精简的表结构获取高性能，为了性能会做一些拆表或尽量减少字段的记录。这样一方面是信息不够全，另一方面是表结构比较复杂。这样在做数据分析时，光理解表结构都比较麻烦，特别是对业务人员来说。并且这样导致分析性的需求强依赖业务数据库。业务数据库的变更，就会影响到分析类的支持。
现在使用CDH或HDP搭建Hadoop已经是一个很简单的事情，不妨自己动手搭建试试，反正不亏什么。如果对自己公司业务发展有信心，用Hadoop是迟早的事。
使用不使用Spark，我觉得主要取决于你是否有机器学习的需求，第一步我认为不着急。当然，Spark SQL在查询性能上，比Hive更好一些。但是Hadoop生态更成熟。
发布于 2016-01-30
sec island
日志分析
直接用es更方便，足够应付了。
发布于 2015-12-19
sprite101
大数据的概念不是你以数据多少条来解释的，PB级别的就算大数据了
编辑于 2015-08-04
侯门霸王
想得却不可得,你奈人生何?
mysql分库或者分表足以，日志的天然优势就是顺序的，非常适合分表
发布于 2015-07-25
王红波
2GB 内存的1850处理过百亿级20T 数据，自…
按照之前DW的项目经验来看，关系数据库在几十亿级别数据处理方面没多大问题。区别是数据分区分表分文件方面细致点，索引覆盖优化一下，数据在重要维度预处理多做一些就好了。
从量级上看，暂时不必要上hadoop。
发布于 2015-07-17
detail lee
证券 IT 大数据
hadoop天然适合存储日志数据，结合hive kettle等工具。
去年也蛮有兴致的搭了10个节点的集群，存储终端行为日志，后来日志分析需求不强烈平台就慢慢荒废了。
发布于 2015-07-15
大魔头-诺铁
INTP，软件手艺人，诺铁@新浪微博，Thoug…
现在就可以制造一百亿条日志试试你的oracle能不能撑住
编辑于 2015-07-13
qiqiqi
大数据软件工程师
Spark是基于内存的分布式计算引擎。只要你有对数据计算需求，而且这种需求已经超出了单机能够处理的范围，都可以考虑spark。Spark搭建并不难，而且也并不一定要绑定Hadoop。从目前Spark的发展来看，Spark最大的强项在于它一个产品就可以提供覆盖数据提取，多数据源融合，分析，存储的一站式解决方案。很多企业都有以上的数据处理需求，而在spark以前，他们往往的每一个阶段都需要单独的，难以兼容的产品来完成。有了Spark，企业无疑可以花更少的成本，人力，物力，更快的速度完成它的分析需求。这也是企业界开始积极引入Spark的原因。我特别要提醒一下，大家可以多关注一下Spark的机器学习能力。传统的SQL能够提供一些统计，汇总功能，但是机器学习更能挖掘数据内在的价值，况且Spark的机器学习库也很好用。
发布于 2015-07-13
人生很短也很美妙
hadoop推荐起步12TB 少了SQL够了
数据量不足硬上hadoop 属于个人业余爱好 没什么经济价值
spark可能更适合中小数据集
编辑于 2015-07-13
灵魂机器
从事 Hadoop, Hive, Presto 等大数据工具…
我个人经验，如果日志大小每天增长不超过1G，一年总大小不超过100G，那没必要用Hadoop.
我现在用一个10台机器的Hadoop集群来处理日志，日志每天增长300G，10台机器轻松应对。
发布于 2015-07-13
目前在小范围试用的一个系统，生产环境用的Oracle数据库。系统的行为日志模块要详细记录所有用户（总的活跃用户规模大概几百万）的每一个操作，根据目前小规模试用的现状评估，预计全面使用后单月的行为日志数会达到数亿的规模。
用户行为日志分析在系统中是一个蛮重要的模块，目前在小规模试用期几百万数据量的情况下用Oracle速度还可以，但是如果全面铺开后一年累计几十亿记录这种规模，用关系型数据库去做数据分析和统计会不会太吃力了？以前听说上 TB、PB级数据才用Hadoop类的大数据系统，而我们的系统其实日志的字节量并不大，也就是几十几百G的水平，所以一直没考虑。但是现在发现日志的条目数量比较大，而且要做的关联分析比较多，所以担心Oracle数据撑不撑得住。
是否需要将日志分析这部分需要单独拿出来，上Hadoop+Spark这种分布式处理系统？
请专家们指点迷津。
Oracle数据库内做数据分析在使用了parallel并行之后，在1亿级规模的数据其处理速度跟小型hadoop集群（5-10台，128-256MB内存）速度差不多，但依然存在缺点：1、其处理逻辑在数据库本身，复杂逻辑处理时影响数据库对外服务的性能，导致其他用户无法正常访问是经常的，尤其在加了parallel并行之后；2、规模超过1亿级之后，运行速度大幅降低，且容易卡死。
建议使用hadoop，原因两点：1、数据必然增长，有备无患；2、转移处理实体，保证数据库的正常性能。
发布于 2016-02-22 添加评论 感谢
shangrz
日志分析全套Elasticsearch+kibana+logstash准实时,数据展示,离线分析还可以用es-hadoop结合了不错.
实在想省事不差钱上splunk,非常适合这种条目数超多单条小的log分析,准实时,dashboard报表功能简单好用,SIEM相应的功能如关联分析\事件记录也适合套用到题主记录用户所有行为的场景
发布于 2016-02-11 添加评论 感谢
程磊
潜心修炼中~~~
这样的数据量级没有必要用hadoop，spark，但传统的存储引擎有些吃力了。
考虑到业务增长，有一定的前瞻性的话，还是迁移到hadoop上吧；
发布于 2016-01-30
匿名用户
本司每日上亿浏览日志，分发一直用sql server，暂时运行流程，归档用hive，hbase，olap 用greenplum
发布于 2016-01-30
桑文锋
神策数据创始人兼CEO，前百度大数据部技…
建议可以试试Hadoop了， 几十亿的记录灌到Oracle进行数据分析，还是会比较吃力的。如果用Oracle去做，经过精心设计可能也能吃得消（我没试过）。但你这里要对比一下业务数据库的应用场景和用户行为分析即日志分析的差异。
在日志分析时，我们一般是把尽量多和全的数据采集为文件记录，然后方便做各种adhoc的分析，不管是单机也好，Hadoop也好，强调的是一个灵活。
我们用Oracle做业务数据库时，在设计理念上，会倾向于精简的表结构获取高性能，为了性能会做一些拆表或尽量减少字段的记录。这样一方面是信息不够全，另一方面是表结构比较复杂。这样在做数据分析时，光理解表结构都比较麻烦，特别是对业务人员来说。并且这样导致分析性的需求强依赖业务数据库。业务数据库的变更，就会影响到分析类的支持。
现在使用CDH或HDP搭建Hadoop已经是一个很简单的事情，不妨自己动手搭建试试，反正不亏什么。如果对自己公司业务发展有信心，用Hadoop是迟早的事。
使用不使用Spark，我觉得主要取决于你是否有机器学习的需求，第一步我认为不着急。当然，Spark SQL在查询性能上，比Hive更好一些。但是Hadoop生态更成熟。
发布于 2016-01-30
sec island
日志分析
直接用es更方便，足够应付了。
发布于 2015-12-19
sprite101
大数据的概念不是你以数据多少条来解释的，PB级别的就算大数据了
编辑于 2015-08-04
侯门霸王
想得却不可得,你奈人生何?
mysql分库或者分表足以，日志的天然优势就是顺序的，非常适合分表
发布于 2015-07-25
王红波
2GB 内存的1850处理过百亿级20T 数据，自…
按照之前DW的项目经验来看，关系数据库在几十亿级别数据处理方面没多大问题。区别是数据分区分表分文件方面细致点，索引覆盖优化一下，数据在重要维度预处理多做一些就好了。
从量级上看，暂时不必要上hadoop。
发布于 2015-07-17
detail lee
证券 IT 大数据
hadoop天然适合存储日志数据，结合hive kettle等工具。
去年也蛮有兴致的搭了10个节点的集群，存储终端行为日志，后来日志分析需求不强烈平台就慢慢荒废了。
发布于 2015-07-15
大魔头-诺铁
INTP，软件手艺人，诺铁@新浪微博，Thoug…
现在就可以制造一百亿条日志试试你的oracle能不能撑住
编辑于 2015-07-13
qiqiqi
大数据软件工程师
Spark是基于内存的分布式计算引擎。只要你有对数据计算需求，而且这种需求已经超出了单机能够处理的范围，都可以考虑spark。Spark搭建并不难，而且也并不一定要绑定Hadoop。从目前Spark的发展来看，Spark最大的强项在于它一个产品就可以提供覆盖数据提取，多数据源融合，分析，存储的一站式解决方案。很多企业都有以上的数据处理需求，而在spark以前，他们往往的每一个阶段都需要单独的，难以兼容的产品来完成。有了Spark，企业无疑可以花更少的成本，人力，物力，更快的速度完成它的分析需求。这也是企业界开始积极引入Spark的原因。我特别要提醒一下，大家可以多关注一下Spark的机器学习能力。传统的SQL能够提供一些统计，汇总功能，但是机器学习更能挖掘数据内在的价值，况且Spark的机器学习库也很好用。
发布于 2015-07-13
人生很短也很美妙
hadoop推荐起步12TB 少了SQL够了
数据量不足硬上hadoop 属于个人业余爱好 没什么经济价值
spark可能更适合中小数据集
编辑于 2015-07-13
灵魂机器
从事 Hadoop, Hive, Presto 等大数据工具…
我个人经验，如果日志大小每天增长不超过1G，一年总大小不超过100G，那没必要用Hadoop.
我现在用一个10台机器的Hadoop集群来处理日志，日志每天增长300G，10台机器轻松应对。
发布于 2015-07-13
扫一扫
758
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
