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