Hadoop 和 Flume 分布式日志收集（二）
八、实时分布式数据采集的实际情况
在这最后一章中，我想我们将讨论一些我对 Hadoop 数据收集的不太具体、更随机的想法。 这背后并没有严格的科学依据，你完全可以放心地反对我的观点。
虽然 Hadoop 是一个使用大量数据的伟大工具，但我经常会想起 1886 年发生在明尼苏达州圣克罗伊河上的堵塞(www.nps.gov/sacn/histor…)。 在处理太多数据时，您需要确保不会堵塞河流。 请务必认真对待上一章中关于监控的内容，而不是仅仅将其视为一件好事。
传输时间与日志时间
我遇到过这样一种情况：使用文件名中的日期模式放置数据，并且/或者 HDFS 中的路径与目录的内容不匹配。 预计 2013/03/29 年度的数据将包含 2013 年 3 月 29 日的所有数据。 但现实情况是，日期是从运输工具中取消的。 事实证明，我们使用的 syslog 版本正在重写标题，包括日期部分，导致数据占用传输时间，而不反映记录的原始时间。 通常情况下，偏移量很小--只有一两秒钟--所以没有人真正注意到。 但有一天，其中一台中继服务器死了，当滞留在上游服务器上的数据最终被发送时，它的时间是当前的。 在这种情况下，它被移了几天。 啊!怎么这么乱呀。
如果您按日期放置数据，请确保这种情况不会发生在您身上。 检查日期边缘案例以确定它们是否符合您的预期，并确保在真正投入生产之前测试您的停机场景*。*
正如我前面提到的，由于计划内或计划外维护(甚至是微小的网络故障)而导致的这些重新传输很可能会导致重复和无序事件的到来，因此在处理原始数据时一定要考虑到这一点。 Flume 不提供单次交货/订购保证。 如果需要，可以改用事务性数据库。
时区是邪恶的
如果你错过了我在第 4 章，Sink and Sink Processor中反对使用本地时间的偏见，我在这里再重复一遍--时区是邪恶的。 邪恶如邪恶博士(en.wikipedia.org/wiki/Dr._Ev…)--让我们不要忘记它的“迷你我”(en.wikipedia.org/wiki/Mini-M…)对应的夏令时。
我们现在生活在一个全球化的世界里。 您正在将数据从各地拉到您的 Hadoop 集群中。 您甚至可能在国家(或世界)的不同地区拥有多个数据中心。 在尝试分析数据时，您最不想做的事情就是处理歪曲的数据。 夏令时在地球上的某个地方一年中至少会改变十几次。 只需查看历史(ftp://ftp.iana.org/tz/releases/)。 省得自己头疼，把它正常化到协调世界时就行了。 如果你想在它变成人类眼球的路上把它转换成“当地时间”，那就放心吧。 但是，当它位于您的集群中时，请将其标准化为 UTC。 考虑通过此 Java 启动参数随时随地采用 UTC(如果您不能在系统范围内设置它)：
-Duser.timezone=UTC
我住在芝加哥，我们工作的电脑使用的是中部时间，根据夏令时进行调整。 在我们的 Hadoop 集群中，我们喜欢将数据保存在YYYY/MM/DD/HH布局中。 一年两次，有些东西会轻微破碎。 在秋天，我们凌晨 2 点的数据是原来的两倍。 目录。 春天没有凌晨 2 点。 目录。 疯了！
能力规划
无论您认为您拥有多少数据，情况都会随着时间的推移而改变。 新项目将弹出，现有项目的数据创建率将发生变化(向上或向下)。 数据量通常会随着当天的流量而起伏不定。 最后，为 Hadoop 集群提供支持的服务器数量将随着时间的推移而变化。
对于 Hadoop 群集中应该保留多少额外的存储容量，有许多流派的看法(我们使用 20%这个完全不科学的值-这意味着我们通常在订购额外硬件时计划 80%的存储容量已满，但在达到 85%到 90%的利用率数字之前不要开始恐慌)。
您可能还需要在单个代理内设置多个流。 源处理器和宿处理器目前都是单线程的，因此当数据量很大时，调优批处理大小的能力是有限的。
供给 Hadoop 的 Flume 代理数量应根据实数进行调整。 观察通道大小，查看正常负载下的写入保持情况。 调整最大信道容量，以处理任何让您感觉良好的开销。 您总是可以花费远远超过您所需的费用，但即使是长时间的停机也可能超出最保守的估计。 这就是你必须挑选和选择哪些数据对你更重要，并调整你的通道容量以反映这一点的时候。 这样，如果您超出了您的限制，不太重要的数据将首先被丢弃。
您的公司可能没有无限的资金，在某个时候，数据的价值与继续扩展集群的成本之间的关系将开始受到质疑。 这就是为什么对收集的数据量设定限制是非常重要的。 任何将数据发送到 Hadoop 的项目都应该能够说明这些数据的价值，以及如果我们删除较旧的内容会有什么损失。 只有这样，开支票的人才能做出明智的决定。
多个数据中心的注意事项
如果您在个数据中心之外运营业务，并且收集了大量数据，您可能需要考虑在每个数据中心设置 Hadoop 群集，而不是将所有收集的数据发送回单个数据中心。 这将使分析数据变得更加困难，因为您不能只对所有数据运行一个 MapReduce 作业。 相反，您必须运行并行作业，然后在第二遍中合并结果。 您可以通过搜索和计算问题来做到这一点，但不能像平均数这样的东西-平均数的平均数与平均数不同。
将您的所有数据集中到一个集群中也可能超出您的网络所能处理的范围。 根据您的数据中心之间的连接方式，您可能无法传输所需的数据量。 最后，考虑到完全群集故障或损坏可能会抹去所有内容，因为大多数群集通常太大，无法备份除高价值数据以外的所有内容。 在这种情况下，拥有一些旧数据有时总比什么都没有要好。 对于多个 Hadoop 集群，如果您不想等待发送到本地集群，则可以使用故障转移接收器处理器将数据转发到不同的集群。
如果您确实选择将所有数据发送到单个目的地，请考虑添加一台大磁盘容量的计算机作为数据中心的中继服务器。 这样，如果出现通信问题或延长集群维护时间，您可以让数据堆积在与试图服务客户的机器不同的机器上。 即使在单个数据中心的情况下，这也是合理的建议。
合规性和数据过期
请记住，贵公司正在收集的客户数据可能包含敏感信息。 您可能受到其他访问数据的法规限制，如支付卡行业(PCI-en.wikipedia.org/wiki/PCI_DS…)或萨班斯·奥克斯利(SOX-en.wikipedia.org/wiki/Sarban…)。 如果您没有正确处理对集群中这些数据的访问，政府将依靠您，或者更糟的是，如果他们觉得您没有保护他们的权利和身份，您将不再有客户。 考虑对您的个人信息数据进行加扰、修剪或模糊处理。 你想要的商业洞察力可能更多地落入“有多少搜索锤子的人真的买了？”这一类。 而不是“有多少客户叫 Bob？” 正如您在第 6 章，拦截器中看到的，当您四处移动时，编写一个拦截器来混淆个人身份信息(PII-en.wikipedia.org/wiki/Person…)是非常容易的。
您的公司可能有一个文档保留策略，其中很可能包括您要放入 Hadoop 的数据。 确保你删除了你的政策规定你不应该再保留的数据。 你最不想看到的就是律师的来访。
摘要
在本章中，我们介绍了规划 Flume 实施时需要考虑的几个实际注意事项，包括：
- 传输时间并不总是与事件时间匹配
- 在你基于时间的逻辑中引入夏令时的混乱
- 容量规划注意事项
- 当您拥有多个数据中心时需要考虑的事项
- 数据合规性
- 数据过期
我希望你喜欢这本书。 希望您能够在您的应用/Hadoop 集成工作中直接应用这些信息。
谢谢。 这很有趣。
