优化事实阅读＆amp;写雪花

Question

总而言之，

我正在研究一些技巧，以优化雪花事实表上的ELT。 150亿行。

每35分钟，我们每35分钟就会得到大约30,000行，我们始终将获得3个帐户维度键值，即销售，COGS＆amp; Mkt。

Finance_Key	Date_Key	Department_Group_Key	Scenario_Key	Account_Key	Value	IsCurrent
001	2019-01-01	001	0012	SALES_001	100	Y
001	2019-01-01	001	0012	COGS_001	300	Y
001	2019-01-01	001	0012	MKT_001	200	Y

This is then PIVOTED based on Finance Key and Date键并加载到另一个表中进行报告，例如

Finance_key	Date_key	Department_group_key	specario_key	seales	cogs	mkt	iscurrent
001	2019-01-01-01	001	001 0012	100	300	200	y

有时会进行调整，并进行1个帐户密钥。

finance_key	date_key	Department_keke	specor_key	account_key	account_key
001	2019-01-01	001	0012	sales_001	50

必须

Finance_key	Date_key	department_key	saceario_key	account_key	councel_key	001
account_key	account_Key	001	，	我们	此	Department_key
spectario_key	因此	300	​	​	执行	Y
001	2019-01-01	001	0012	MKT_001	200	Y
001	2019-01-01	001	0012	SALES_001	50	Y

And the resulting value should be

Finance_Key	Date_Key	Department_Group_Key	Scenario_Key	SALES	COGS	MKT
001	2019-01-01	001	0012	50	300	200

However my question是如何优化查询以进行扫描并更新枢轴表格的大约。雪花上有150亿行。

这更多是读写的优化。

任何指针

谢谢

Answer 1

因此，一个更长的表单答案：

我要假设date_key值是过去的，只是示例日期的功能，因为如果您有15B行，并且每35分钟就有〜 10k（30k /3）更新要应用，并且它们涵盖了您数据的整个日期范围，那么您几乎无法做到优化它。雪花查询加速服务可能有助于IO。

但是，改善总处理时间的主要方法是过程较少。

例如，在我的旧工作中，我们拥有IoT数据，这些数据可能会有长达两周大的消息。作为管道错误处理的一部分，我们重复了负载上的所有消息（实际上是一个类似的过程）。我们发现，以-2周的分钟为单位（也有数十亿行）的时间为-2周，大部分时间都使用，阅读/编写表。通过将摄入到比几个小时大的边线消息中，并将其处理推迟到“午夜”，我们可以在不到5分钟内完成所有批次完成的所有及时点（我们进行了大量其他处理，在此间隔中）每批次），我们可以将仓库群集大小从核心数据小时降低，并使用保存的积分在午夜的“ catchup”中运行更大的实例，以将所有天数的侧面数据带入船上。这种最终一致的方法在我们的应用程序中效果很好。

因此，如果您的目标表非常聚集，因此读/写入只是数据的一小部分，那么这对您来说应该不那么问题。但是，根据提出问题的本质，我认为事实并非如此。

因此，如果表自然聚类与加载数据未对齐，则是因为目标表需要是关键读取表正在处理的重要形状，在此时，成本/时间更敏感。另一个选项是将目标表按日期聚集（再次假设新数据是一个很小的时间窗口），并在该表的顶部具有物质化的视图/表格，以便使用其他类型，以便完成重写对于您来说，Snowflake，现在这不是免费的。但这可能会允许更快的时间和更快的使用性能。假设两个时间敏感。