sql - 在 BigQuery 中使用所有字符串列的限制

问题描述

我在 BigQuery 中有一个输入表，其中所有字段都存储为字符串。例如，该表如下所示：

name      dob             age     info
"tom"     "11/27/2000"    "45"    "['one', 'two']"

在查询中，我目前正在执行以下操作

WITH
  table AS (
  SELECT
    "tom" AS name,
    "11/27/2000" AS dob,
    "45" AS age,
    "['one', 'two']" AS info )
SELECT
  EXTRACT( year from PARSE_DATE('%m/%d/%Y', dob)) birth_year,
  ANY_value(PARSE_DATE('%m/%d/%Y', dob)) bod,
  ANY_VALUE(name) example_name,
  ANY_VALUE(SAFE_CAST(age AS INT64)) AS age
FROM
  table
GROUP BY
  EXTRACT( year from PARSE_DATE('%m/%d/%Y', dob))

此外，我尝试做一个非常基本group by的操作，将项目转换为字符串而不是，我没有看到约 1M 行的数据集有任何性能下降（实际上，在这种特殊情况下，转换为字符串更快）：

除了“保留”这个全字符串表而不将其转换为正确的类型是不好的做法之外，我通过保留表全字符串会遇到哪些限制（功能或性能方面）将其存储为正确的类型。我知道由于存储字符串而不是数字/日期/布尔/等，大小会略有增加，但是如果我保持这种方式，我会遇到哪些主要限制或性能损失？

在我的脑海中，我看到的唯一限制是：

查询将变得更加复杂（尽管如果使用查询构建器则无关紧要）。
从数组字段中提取非字符串项有点困难。
插入数据变得有点棘手（例如，需要跟踪日期格式是什么）。

但这些似乎都是可以解决的非常小的项目。是否还有其他“更大”的原因为什么使用所有字符串字段会成为一个巨大的限制，无论是限制查询能力还是在各种情况下都会对性能造成巨大影响？

标签： sqlgoogle-bigquery

首先 - 我真的没有看到比你已经知道和入伍的人更大的表演停止者

与此同时，

虽然如果使用查询构建器并不重要......

基于上面的摘录-我想谈谈这种方法的某些方面（全部存储为字符串）

虽然我们通常关心从字符串转换为原生类型以应用相关函数等等，但我意识到在某些情况下使用某种查询构建器构建复杂和通用的查询需要相反 - 将原生类型转换为字符串以应用类似STRING_AGG[just ] 作为一个简单的例子

所以，我的想法是：

当表被设计为通过琐碎甚至复杂 的查询直接用户访问时 - 拥有本机类型是有益的和性能明智的，并且对用户理解更友好等。

同时，如果您正在开发自己的查询构建器并设计表，以便用户可以通过该查询构建器进行查询，并实现了一些通用逻辑 - 将所有字段都放在字符串中可能有助于构建查询构建器本身。

所以这是一个平衡——你可能会损失一点性能，但你可以赢得更好地实现通用查询生成器的能力。这种平衡取决于您的业务性质——既来自数据预期，也包括您设想支持的查询类型

注意：您的问题非常广泛且基于意见（顺便说一句，在 SO 上不太受尊重）所以，显然我的回答 - 完全是我的意见，但基于 BigQuery 的丰富经验

sql - 在 BigQuery 中使用所有字符串列的限制

问题描述

解决方案

推荐阅读