数据是建立体式的核心部分，每个团队都以自己的方式依赖它。我们的成长团队依靠事件数据来分析实验（A/B测试）。我们建立了许多快速的实验——我们经常一次有很多在飞行中——并且让对参与度和其他关键指标的影响来指导我们放弃哪些实验，哪些测试应该投资。项目经理、设计师和产品工程师调查使用数据，以帮助了解不可避免的折衷，如简单性与动力性。通过这一点，我们了解哪些新产品方向可以释放出最大的潜力。市场营销部门需要弄清楚哪些活动促使新用户使用体式。金融业需要关于我们总体增长模式的极其可靠的统计数据，以确保体式在2064年出现。如何构建一个系统来支持所有这些不同的需求？体位数据基础设施从小规模开始，随着时间的推移不断扩大上面的图并不是我们最初构建的；我们从一个简单得多的系统开始：基本上是一堆python脚本和MySQL都在一个盒子上运行。首先，一个简单的系统可以减少对系统的维护，如果您还没有任何用户，您可能也希望从那里开始。但体位自2011年推出以来稳步发展（见下图），我们开始触及很多极限。最近，我们对我们的数据基础架构进行了一系列更改，这些更改都被证明非常有价值：投资于监控、测试和自动化以减少火灾从MySQL迁移到Redshift以实现可伸缩的数据仓库从本地日志处理迁移到Hadoop以实现可伸缩的日志处理引入商业智能工具，允许非专家回答自己的数据问题随时间推移通过体式的"事件"数量的图表；原始数据量的度量。结束无尽的火焰一年前，我们在处理数据时遇到了很多稳定性问题。当图表发生重大变化时，人们立即质疑数据的完整性。很难区分有趣的见解和bug。数据科学已经是一门艺术，因此您需要基础设施来为您提出的问题提供可靠的答案。99%的正确率是不够的。在数据基础设施团队中，我们花了大量时间在扑救紧急火灾上，这阻碍了我们取得长期进展。很痛苦。获得灵感当坏事发生时，我们用5个为什么来找出根本原因并加以解决。例如，有一次，我们有一个数据处理脚本编写了一个错误日志文件，这个文件太大了，我们无法通过电子邮件发送日志内容。作为响应，我们开始在发送电子邮件之前截断日志文件，并在电子邮件失败时发出警报，并添加了对脚本输出的监视。在其他情况下，如果我们没有足够的洞察力来了解发生了什么，我们会添加日志记录、监视和警报。例如，当我们的实验处理经常落后时，我们在不同的处理阶段添加了大量日志记录，以查看它大部分时间都花在了哪里，并用它来通知哪些部分需要优化。当我们的监测和记录不足时，最严重的火灾持续了几个月。在一个特别的例子中，我们的一个工作比以前花了很多时间。很长时间后，我们发现有些查询被传递给一个带有特定时区信息的datetime对象，由于某些原因，我们仍然不能完全理解查询时间的急剧增加。由于此作业需要一天以上的时间才能完成，第二天的作业将开始并导致MySQL锁定超时。当图形生成最终运行时，这些作业从未拥有所需的所有数据。我们缓存了零值，每次都要做大量的手动工作来清理这些值。失败会传播到更多的失败，返利微信，所以补丁被证明是不成功的。最终，这一事件启发了我们真正优先考虑测试。一年前，我们的数据基础架构代码几乎没有测试。虽然我们仍然不为我们的测试覆盖率感到自豪，但我们已经取得了很多进展。当你在测试中失败并意识到如果你的改变投入生产的话会有什么问题，那就太棒了。我们使用Python的内置unittest模块，尽管我们一直在探索nose添加的特性。我们把我们的努力集中在容易实现的成果上，特别是在我们可以构建框架代码的领域，使我们的数据科学家和其他数据消费者能够编写自己的测试。自动化调查我们以前都是通过cron来管理一切的。作业将在不同的时间运行，我们希望它们在依赖它们的作业开始之前完成。如果不是这样的话，比如一个工作崩溃了，就需要大量的人工清理。然后，我们开始使用Luigi构建一个理解并尊重依赖关系的管道，正如下面我们的管道的一小部分所示。在Luigi中，当一个作业失败时，我们会得到关于它的警报，在我们解决问题之前，它的依赖项不会运行。恢复管道非常容易，只运行未完成的作业。这也是我们将这些工作并行化的第一步。这是我们的数据ETL管道图，如Luigi所示我们的警报以前很粗鲁。我们收到了明显的警报，比如可用磁盘空间，但是我们花了很多心思和精力去克服痛苦，才得到今天的一切。现在，我们将讨论从内存/CPU使用情况到Redshift集群上长时间高负载的所有系统警报。我们监控数据管道的进度，当需要的时间比预期的长，或者某些作业在我们预期的时间内没有完成时，我们会发出警报。我们监控数据本身，确保临界值不为零，并使用回归分析在事件记录比前几周少或多很多时发出警报。我们改进了电子邮件警报的筛选流程。我们在很大程度上依赖于体位法，这在分担负担和在已知情况下通知消费者数据方面尤其有效。将所有这些投资，火势开始降温。一旦我们不花时间保护我们现有的数据基础设施不倒塌，我们就有时间建设未来。数据基础设施的最新发展可扩展数据仓库（Redshift）我们最初选择MySQL作为我们的数据仓库，企业管理类软件，因为我们的工程师知道如何很好地优化它。但是，由于MySQL是基于行的，物联网大会，所以它不是为海量数据集上复杂连接的聚合查询而构建的。当遇到性能问题时，返利联盟，我们调整索引；当遇到更多性能问题时，我们在MySQL上构建了一个自定义的面向直方图的查询缓存层。在MySQL中，一个查询在Redshift中需要大约1秒的时间尽管如此，自助建站模板，每一次优化都只是到目前为止，我们不想花费宝贵的工程资源来建立一个分析数据库。许多公司都发表过红移技术给他们带来了巨大的加速效果，所以我们决定尝试一下。结果非常好。在极端情况下，我们在MySQL上尝试的一个每日查询需要6个小时；在Redshift上则需要几秒钟而没有任何修改！迁移过程迁移到红移是一个不小的壮举。我们现有的数据管道是基于MySQL构建的，每个人都很熟悉它。我们预先做了大量的工作来抽象出很多红移的细节，比如通过S3加载数据，在考虑主键的同时将数据合并到一个现有的表中。缺少对主键的支持是最大的意外成本。然后开始了迁移现有数据管道的乐趣。复杂的依赖关系意味着我们必须小心以正确的顺序迁移写操作。当我们将从MySQL读取的所有查询从MySQL迁移到Redshift时，我们不得不在一段时间内对MySQL和Redshift进行双重写入。协调跨组织的工作来迁移大量相互依赖的MySQL查询，其中一些查询很少有人使用和理解，这是最困难的部分。我们从数据科学和商业团队那里得到了关于他们主要摩擦点的反馈，并使他们不那么痛苦。解锁新分析虽然我们选择Redshift的主要目标是解决性能和可伸缩性问题，但它也对可访问性做出了巨大贡献。这有点出乎意料和间接。在迁移到Redshift的同时，我们一直在研究BI工具。我们评估了几种工具，最喜欢Looker，并决定尝试一下。不幸的是，当我们把它连接到MySQL上时，分析速度太慢了，以至于不能向我们的业务团队推荐它。将Looker连接到Redshift将性能配置文件从几分钟改为能够实时迭代大多数查询。这种组合非常强大，业务团队基本上都是自己采用的。我们的大多数业务团队现在都能够自己探索数据，即使那些不熟悉SQL查询的人也是如此。更好的是，他们能够做到这一点，而不需要数据基础架构团队的任何帮助。他们的领队说"就像我用1995年的手动吉普牧马人换了一辆法拉利…。快多了，有趣多了！"进一步扩展Redshift还提供了限制单个进程和应用程序资源的工具。我们大量地使用这些工具来防止其他人无法使用数据库。只需点击几个按钮，我们就可以通过增加机器数量，在半小时内加快速度并增加存储量。我们甚至可以在将来自动扩展。可伸缩日志处理（Elastic MapReduce）我们每天的数据处理延迟越来越长，我们争先恐后地把它控制在24小时以内。虽然Redshift帮助很大，但我们也需要扩展日志处理部分。我们决定采用长期的行业标准hadoopmapreduce。除了易于扩展外，它也是考虑大量数据处理的一种更简单的方法。再加上我们努力构建一个非常易于使用的框架，这导致了