# 大，小，热还是冷-条带，Tapad，Etsy 和 Square 的健壮数据管道示例 > 原文： [http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html](http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html) [](http://surf.transworld.net/1000104592/features/the-10-best-surf-photos-in-the-history-of-transworld-surf/) *这是 [Hakka Labs](https://twitter.com/petesoder) 的创始人 [Pete Soderling](https://twitter.com/petesoder) 的[访客转发](http://www.hakkalabs.co/articles/big-small-hot-cold-data-needs-robust-pipeline)，创建了软件工程师成长的社区。* 针对 MongoHQ 最近发表的题为“ [您没有大数据](http://blog.mongohq.com/you-dont-have-big-data/)”的帖子，我通常会同意作者的许多观点。 但是，无论您称其为大数据，小数据，热数据还是冷数据-我们都有能力承认*更多*数据将保留下来-这是由于许多不同的因素造成的。 如本文所述，可能主要是由于存储成本随着时间的推移而降低。 其他因素包括对开放 API 的访问，在线上不断增长的消费者活动的数量，以及公司相互“共享”数据时在幕后形成的（主要是）幕后发展的大量其他激励措施。 （您知道[他们这样做](http://www.theguardian.com/business/2013/jun/24/barclays-bank-sell-customer-data)，对吧？） 但是，过去两年来我学到的最重要的事情之一是，对于具有远见卓识的公司而言，开始设计更强大的数据管道以收集，汇总和处理不断增长的数据量至关重要。 这样做的主要原因是能够以一致的方式准备好看似神奇的类似量子的操作的数据，这些操作可以推断数据之间的关系，否则这些关系肯定不会引起注意-在引用的文章中巧妙地描述为“ 从针头堆中确定针头的性质。” 但这提出了一个问题-精心设计的数据管道的特征是什么？ 您难道不可以将所有数据都放入 Hadoop 并称之为一天吗？ 正如许多工程师所发现的那样-答案是巨大的“不！” 我们汇总了 Stripe，Tapad，Etsy & Square 的智能工程师的四个示例，这些示例展示了您实际上可以在野外看到的一些实际数据管道的各个方面。 ## **Stripe 如何做到？** 我们在 [Stripe](http://www.hakkalabs.co/companies/stripe) 上与 Avi Bryant 进行了交谈，后者为我们很好地描述了 Stripe 进行数据管道构建的方式。 > Stripe 从各种来源向 HDFS 馈送数据，其中许多是非结构化或半结构化的 > -例如服务器日志或 JSON > 和 BSON 文档。 在每种情况下，第一步都是将 > 转换为结构化格式。 我们已经标准化了使用 Thrift 来定义 > 的逻辑结构，并使用 Parquet 作为磁盘上的存储 > 格式。 > > 我们选择 Parquet 是因为它是 Cloudera Impala 查询引擎固有的高效列格式 > ， > 使我们可以快速关联数据访问临时报告。 > Parquet 和 Thrift 的组合也可以有效地使用，并且 > 可以从 Twitter 的 Scalding 框架中惯用，这是我们为复杂批处理选择的 > 工具。 > > 下一阶段是``非规范化''：为了保持我们的分析工作和 > 查询快速，我们会在 Scalding 中提前进行最常见的联接， > 写入新的 Thrift 模式集。 同时，我们进行了大量的 > 增强和注释数据：例如，对 IP > 地址进行地理编码，解析用户代理字符串或清除丢失的值。 > > 在许多情况下，这会导致结构具有嵌套结构， > 在 Scalding 中效果很好，并且哪个 Parquet 很高兴存储，但是 > 目前 Impala 无法查询。 我们开发了一个简单的工具 > ，该工具可将任意嵌套的 Parquet 数据转换为等效的 > 扁平化架构，并在必要时使用它来 > 维护每个数据源的并行副本以供 Impala 使用。 > 我们期待着 Impala 的未来版本，该版本可能会删除 > 这个额外的步骤。 ## **Tapad 的数据管道** [Tapad](http://www.hakkalabs.co/companies/tapad) 是纽约市的一家广告技术公司，在过去几年中，其流量和数据均实现了大幅增长。 因此，我联系了他们的 CTO [Dag Liodden](http://www.hakkalabs.co/engineers/dag-liodden) ，以了解他们如何构建数据管道以及他们使用的一些策略和工具。 用达格的话来说，这是他们的做法： * 所有摄取的数据都以 pub-sub 方式流过消息队列（我们使用 Kafka 并每小时通过它推送多个 TB 数据） * 所有数据均使用支持架构演进的一致的非规范化架构进行编码（我们使用 Avro 和 Protocol Buffers） * 我们的大多数数据存储都从消耗消息队列的流程进行实时更新（将热数据推送到 Aerospike 和 Cassandra，将实时可查询的数据推送到 Vertica，并且原始事件通常存储有来自 Aerospike 集群的数据， 在 HDFS 中） * 高级分析和数据科学计算通常在 HDFS 中对非规范化数据执行 * 实时更新始终可以通过脱机批处理作业复制到 HDFS 存储的数据上。 我们努力使我们的计算逻辑，使其可以在流中*和*以批处理 MR 模式运行，而无需进行任何修改 他指出，最后一点使他们可以随意更改其流计算，然后用更新的预测回填其他数据存储。 Dag 还解释了在存储方面使用多种类型的数据技术背后的“原因”，并解释了它们中的每一个都有其自己的特定“最佳位置”，这使其对它们具有吸引力： * Kafka：高吞吐量并行发布订阅，但宽松的传递和延迟保证，有限的数据保留和无查询功能。 * Aerospike：按键（我们拥有 32 亿个键和 4TB 复制数据），跨数据中心复制，高可用性但查询功能非常有限，按键具有极快的随机访问读/写性能 * Cassandra：中等的随机访问读/写性能，原子计数器和数据模型，非常适合时间序列存储。 灵活的一致性模型和跨数据中心复制。 * HDFS：高吞吐量和廉价的存储。 * Vertica：快速和强大的即席查询功能，用于交互式分析，高可用性，但不支持嵌套的数据结构，多值属性。 基于存储的定价使我们限制了我们在此处放置的数据量。” ## **Etsy 如何处理数据** 再举一个例子，我们联系了 [Etsy 的](http://www.hakkalabs.co/companies/etsy)数据团队的工程经理 Rafe Colburn，并询问他们如何处理他们的管道。 这是 Rafe 的独家新闻： > Etsy 的分析渠道不是特别线性。 它从我们的工具开始，它由一个事件记录器组成，该事件记录器在浏览器中运行，而另一个事件记录器可以从后端调用。 两者都 ping 一些内部“信标”服务器。 > > 实际上，我们使用良好的旧 logrotate 程序将生成的 Apache 访问日志在达到一定大小时运送到 HDFS，并使用 Hadoop 处理它们。 我们还将每晚对生产数据（驻留在 MySQL 中）进行快照，并将其复制到 HDFS 中，以便我们可以将点击流数据添加到事务数据中。 > > 通常，我们会将 Hadoop 作业的输出发送到 Vertica 数据仓库，在该仓库中我们也复制生产数据，以进行进一步分析。 我们使用这些数据来提供我们自己的报告和分析工具。 > > 对于 [etsy.com](http://etsy.com/) 上使用从 Hadoop 作业生成的数据的功能，我们有一个自定义工具，该工具获取作业的输出并将其存储在分片的 MySQL 集群中，可以在该集群上进行大规模访问。 今年，我们正在考虑将 Kafka 集成到管道中，以将数据从我们的工具移至 Hadoop（以及流分析工具），并将数据从我们的分析平台发送回公共站点。 ## **Square 的方法** 拥有复杂数据管道的公司的另一个示例是 [Square](http://www.hakkalabs.co/companies/square) 。 我们与他们的工程经理之一 [Pascal-Louis Perez](http://www.hakkalabs.co/engineers/pascal-louis-perez) 取得了联系，他们为我们提供了他们的管道架构的战略视图。 由于支付在整个系统中的重要性，Square 已在整个数据管道中扩展了“对帐”的概念； 每个转换数据必须能够被审核和验证。 据 Pascal 称，这种方法的主要问题在于扩展规模可能具有挑战性。 对于收到的每笔付款，“大约需要 10 到 15 个会计分录，对帐系统的规模因此必须比处理的帐目规模大一个数量级，而处理的帐目已经非常大。” Square 解决此问题的方法利用流处理，这使他们可以将相应的数据域映射到不同的流。 用 Pascal 的话来说，“流表示将数据流水线与数据源的多样性区分开的第一层抽象。下一层是将多个流之一组合在一起并产生一个或多个流的运算符。一个示例运算符是” “匹配器”，它接收两个流，从中提取相似种类的密钥，并根据匹配条件产生两个流。 Pascal 指出，流处理和基于流的运算符的系统类似于关系代数及其运算符，但是在这种情况下，它是实时的并且具有无限关系。 很明显，将数据塞入 Hadoop 并不会为您提供这些功能！ 有趣的例子特别时髦。 在前端，您会看到艺术家和手工艺人像在线公开市场一样出售其商品。 可以很好地了解后端的工作方式。 这是一个非常有用的技术概述，它对我来说是个新名词-数据管道如何工作。 我最近一直在使用 [TitanDB](http://thinkaurelius.github.io/titan/ "TitanDB") 和 hbase 来处理图形方面，您可以在此处阅读[，尽管它不是真实的示例。](http://tjadclark.com/blog/article/11-big-data-putting-it-in-a-graph "Big data in a graph") 看到在现实世界中有使用 HBase 的用例，这使我对将来使用 HBase 的决策更有信心。