为什么日志分析是开始使用大数 据的好（坏）起点 了解采用结构化数据的

为什么日志分析是开始使用大数
据的好（坏）起点
英文原文：
http://ibmdatamag.com/2012/05/why-log-analytics-is-a-great-and-awful-place-to-start-with-big-d
ata/
了解采用结构化数据的 Hadoop 的利与弊
作者：Tom Deutsch
发表日期：2012 年 5 月 23 日
首先，我们来定义一下日志分析的含义。最常见的日志分析用例是运用 Apache Hadoop 处
理机器生成的日志（通常是指 Web 应用程序及支持 Web 应用程序的点击流）。日志分
析需要摄取大量半结构化信息，然后将这些信息汇集成更加易于使用的数据集，并从交互中
总结重要信息。（广告位）日志处理是创造 Hadoop 的核心用例，因此它能够在这个场景
中正常运转一点也不奇怪。
Google、Yahoo 及许多其他 Internet 属性均通过业务模型运行，采用的业务模型在很大程
度上依赖于这些操作而且效果确实不错。不过，绝大部分公司在发生 Web 事件时无法及
时获悉，而是需要经历一定的延迟（不是以小时或天来计算，而是动辄持续数周）才能通过
单击或网络日志行为了解这一情况。由于起点极低，因而实现大幅改观并不困难。
此外，由于大多数公司不愿停用现有的数据分析系统（往往由专门从事 Web 点击分析的
第三方担任），采用 Hadoop 的日志分析方案可以说是风险极低，但却是启用大数据技术
的良好起点。它并非任务关键型技术。在日志分析用例中，即使操作错误，用户也不会因此
受到致命影响，更不会致使大量资金面临风险。
对于刚刚开始运用日志分析技术的许多传统企业而言，推行日志处理用例对于 Hadoop 供
应商很有吸引力，因为它依赖于非关键数据，坦白地说，这一点不难做到。失败和实验的成
本很低，可以区别于其他生产应用程序及作业流独立完成，并且可以运用通用 Hadoop 分
发方案自带的命令行工具完成。您完全不必向企业内的其他员工披露实验或方法。
关于弊端…
关键在于：运用 Hadoop 成功分析日志数据并非典型企业场景的成功预言。促使 Hadoop
适应日志分析的各项因素可能会掩盖真正的企业应用及成功需求。日志数据结构化程度相当
大。虽然数据量或许相当大，但可惜重复太多，这也是没有足够的场地供各种来源及各种结
构的数据进行测试的真正原因。
我发现，绝大部分日志分析项目往往是静态的非预测项目，因此只能算作日志 ETL 作业而
不是分析作业。不需要处理信息沿袭问题，并且往往只有一个信息来源，因而我们假设信息
有效且数据质量“过关”。此外，通常无需考虑治理问题（或者说，即使考虑治理问题，也
不会实施治理措施）。一般而言无需遵循任何 SLA，作业时常在夜间运行，所以无论作业
在早上四点还是六点结束均不会对用例造成任何实际影响。
这些作业要求的可视化程度极低（如果需要的话），这通常由于您只需“碾压”这些数据，
然后运用其他系统或手动作业进行处理。没有必要对非开发人员采用 Hadoop 的简便性进
行测试。Hadoop 与公司内的其他商业智能和报告系统之间也不存在任何连接。换句话说，
这些项目并非现实使用成功案例的代表性测试。它们并未运用真实数据流，并且往往无法在
采用相同技术的同一平台上支持第二及第三个用例。
确切的说，并不是说日志分析不是有效的用例，也不是要争辩了解 Hadoop 不好；我要说
的是：不要想当然地认为运用 Hadoop 在日志分析领域获得的初步成就一定会造就企业大
范围部署成功。不要混淆成功概念，本质上而言这只是执行单域隔离 ETL 的另一种方法，
只是没有数据质量和 SLA 要求而已；并不能就此预测哪种方法对您的典型企业生产环境有
效。
您认为呢？日志分析技术是开启大数据之旅的良好起点还是糟糕选择？请在评论中对我们
谈谈您的想法。
相关主题
1.
2.
3.
4.
5.
大数据对数据分析的影响
网络研讨会：大数据简介
飞往 PB 星球的高速火箭
大数据治理：成熟度评估框架
选择您的首个大数据项目