当我在Airbnb时，我有一个很好的机会在一个向BrianChesky汇报的新团队工作。这很令人兴奋——我们正在玩一条新的产品线，所以我们每天都要做出改变游戏规则的决定。但作为团队的数据科学家，我总是负责采购数据来指导我们的产品方向，这意味着大量的分析工作。第一周是对我的上下文切换能力的严峻考验：我必须找到模糊的表并编写大量查询，但甚至通过BeautifulsoupScrapes和VeertricsAPI请求正则表达式。到第三周，我开始感到疲倦，所以我需要一个系统来跟上我的步伐。让我意识到，在使用数据时，只有两种方法可以搞砸：使用错误的数据。数据使用不当。这两个问题都可以通过围绕数据建立更好的上下文来解决。所以我制作了自己的清单来减少这两个错误，以确保我不会将产品引向遗忘。我将在这里分享我的，但这对你来说究竟是什么取决于你公司的特定芯片。使用此作为示例指南，了解如何让自己获得一些良好的上下文以使您使用表单变得危险，但我鼓励您接受它并将其变成您自己的。那么我需要什么背景以及如何获得它呢？那么，您需要任何和所有信息来减少错误或使用错误数据的数据。以我的经验，只需进行三项检查即可获得合理的覆盖率：检查基表METAData.e.g.列名，分区信息，如何生成。检查你的假设。这个专栏里有什么？这是一个空列吗？什么是独特的价值？自从我上次运行此查询以来，这些是否发生了变化？联系别人。其他人都在用这张桌子做什么？你问谁问题？1.检查基本表元数据第一步是找到一个表并弄清楚如何查询它。你必须在它泄露它的秘密之前求爱你的表（经OlyaTanner许可转载）对于列名、索引信息、分区信息、视图定义等最基本的信息，通常可以查询系统表。将这些表的列表放在手边，以便您可以轻松地查询它们。例如，对于符合ANSISQL的数据库（大多数），记住下表通常很有帮助：Information_schema.column列名称、分区信息、列类型、void。Information_schema.tables和Information_schema.viewSnice列出所有表和视图。Views，通常可以得到DDL语句。您通常还会获得其他人编写的查询历史记录，这有助于了解如何使用该表单。您甚至可以按语句类型（例如创建、插入、选择）进行过滤以确定表的创建方式：Information_schema.jobs_by_project(bigquery)table(Information_schema.query_history())2.检查您的假设。写下您的假设并运行查询来检查它们。一个人制作清单的很好的插图，以防你以前没有见过。此时你想看看数据是不是你想的那样。虽然我的典型方法是随机遍历select*并选择不同的语句，但这是次优的。更好的方法是首先弄清楚：我需要回答什么问题，我做了什么假设？写下这些，然后写下回答这些问题/验证这些假设的查询。这听起来很简单，但如果你做出了错误的假设，你就必须重新开始。我们在处理数据时都会做出假设——如果您不知道这些假设，那将是灾难的根源。最近项目的一些例子：每个活动是否只有一行？这个字段有哪些可能的值？这个列是无限的吗？如果是null，这些null值是否有系统模式？我个人使用Whale（CLI工具，如果我不耐烦的话）或运行（甚至安排）这些快速检查的数据框，但无论你使用什么，只要确保它们持久。最后，是的，这很好——继续选择*。有时您只需要查看一部分数据。3.与其他人联系既然你已经有了一种你能感觉到的数据形式，那就潜入并构建你需要构建的东西。不。您需要尽可能多地了解各种社会情况和部落，这在大型组织中尤其如此。现在是收集部落知识的时候了。我知道这些人没有脸，但你不是在得到一些其他社会背景后让右边的人开心吗？不幸的是，仅通过挖掘数据你只能得到这么多。您需要与真人交谈（或查找一些最新文档）。通过查询日志（见上文），通过Github的Slog（如果你的查询是版本化的），或检查谁拥有该表（你通常可以在数据上下文/发现工具中执行此操作，如数据框）-找人偷懒.一般来说，我会问以下问题：这是支撑吗？这是用于{{yourscenario}}的最佳数据吗？你到目前为止所做的是开放的。你可能看错了人，但人们喜欢一些争议。结束语如果这一切听起来有点矫枉过正，请查看DataFrame。我们正在构建一个数据上下文平台，可以轻松找到所有这些信息——而且是免费的。在一处搜索表格、获取基本元数据、探索数据和获取社交背景。好卖。抱歉，我情不自禁-我对我们的产品感到非常兴奋。我希望您能从本文中带走一个信息：尽可能严格地对待您的临时分析。在你的职业生涯中可能发生的最尴尬的事情之一就是意识到你的结果可能是错误的中间解释。在不可分配的上下文中设置一些最佳实践是在每次编写查询时至少减轻一些不利影响的好方法。或亲自体验。然后回到这里再读一遍。
