我正在努力在Big Query上构建原型以进行性能和成本分析，
要求：
为销售运营（激励，潜在客户，权利，预测，营销，潜在客户等）数据构建DW（星型模式），以便进行报告和高级分析。 每天从CRM和其他上游销售/营销系统批量加载数据。数据量约为每天5 TB数据，90％附加数据，10％数据具有旧指标更新（最多7天）。
设计
创建日期分区的Big Query事实表 - 很多查询都是
趋势和时间序列类型查询。
为报告和其他重复创建聚合表 查询/仪表板限制扫描量并降低成本。
摄取逻辑
上游ETL和cron作业，以便在Google云端存储中删除加载就绪文件（已经实施了第三方和其他业务逻辑）。
更新的临时表（ODS），由于分区表无法使用DML更新，因此请复制最近7天的分区临时表（ODS）以处理更新。 （复制操作无成本） - 每天创建一个新临时表，以便更容易复制回事实表。
如果源文件中存在记录，则更新临时表中的记录 - DML操作。
旧日的新记录，附加到相应的日期临时表。
截断并将最后7天的分区从临时表替换（复制）到DW事实表。 - 复制操作无需费用。
将新数据（占总数据的90％）附加到DW事实表 - 数据加载无成本
问题
对于给定的要求，是否有更好的设计选择？
DML操作性能 - 我需要更新500MB - 1 TB的数据，使用BigQuery中的DML操作对性能产生的影响以及需要考虑的任何成本？
如何估算和预测更新和复制操作性能？
答案 0 :(得分：0)
关于星形架构，BigQuery中规范化数据的首选方法是使用nested and repeated structures。 IMO，您可以看到BigQuery是一个非常强大的数据库，可以用作DW。
对于您的时间序列需求，您可以使用ingestion-time partitioned tables
您可以将schedule queries或GCS triggers与云功能一起使用来代替cron作业进行查询。在GCS中添加新文件时可以触发它们。
关于摄取逻辑，我建议使用Cloud Composer，它是GCP中Airflow的集成。
您将能够使用BigQuery operators完成您所说的一切。使用此运算符，您将不需要使用DML创建表，因为您可以使用BigQueryCreateEmptyTableOperator。使用Airflow，您将不需要cron作业。
关于费用，您可以使用pricing calculator
我希望这会有所帮助！
答案 1 :(得分：0)
此工作流程几乎与我在GCP上为销售/营销/产品数据设置的工作流程相同。
我的工作流程由Python，BigQuery标准SQL，Google Cloud Composer（GCP Airflow实例）和Google Container Registry组成。
我们的工作流程是在python类中本地开发的，该类处理ETL复制所需的所有步骤。复制的大多数实际步骤都是bigquery中的Just DML语句，但是我们依赖python类进行标准化，代码重用和执行顺序/记录。
我们将其打包到一个docker容器中，然后放在Google云注册表中。
我们使用Google Cloud Composer（Airflow）Kubernetes Pod Operator在容器中运行python文件。这有帮助，因此我们不必担心维护虚拟机的任何开发问题。
气流非常适合计划和依存关系绘制。 Bigquery中没有一种方法可以轻松地调度查询并维护汇总表的执行顺序。使用Airflow，您可以在ETL管道完成后轻松启动这些汇总查询。
我不确定100％您会期望得到什么费用，但是在BigQuery中，存储和处理非常便宜。 Composer和Kubernetes是我们大部分支出的地方。
虽然此工作流程需要花费几天的时间来设置，但当您需要使用销售数据进行预测性/规范性分析时，它会变得更加强大。使用python / Airflow，您可以完成所有的etl，运行聚合查询，从R或scikit学习进行任何机器学习分析，然后将结果按正确的顺序以正确的顺序全部返回给BigQuery和CRM
如果您想获取一些代码示例或GCP网站上的快速入门帮助，可以直接与我联系。