我的最后两个问题是如何在ipython笔记本中使用python连接器连接雪花和添加和读取数据。但是，我在下一步最好的步骤上很麻烦，无法使用我想要可视化的数据来创建报告。
我想上传所有数据，进行存储，然后进行分析，有点像自制仪表板。
所以到目前为止，我所做的只是一个小版本：
我的数据开始时会很小，但是随着时间的流逝，我会想像我必须将计算移至云中以最小化用于小型仪表板的本地内存。
我的问题是，我的数据是从一个生成json文件的api调用的，新数据每天不超过75 MB，即8列，其中两个聚合调用是在sql调用中完成的。如果我每月运行这些可视化，是否最好在Snowflake或本地汇总信息？
答案 0 :(得分：0)
将原始数据放入Snowflake。使用任务和过程来聚合它并存储结果。或者更好的是，除了需要数据时，不要进行任何聚合-让Snowflake对原始数据进行实时聚合。
我认为您可能要问的是应该ETL您的数据还是ELT您的数据：
ETL和ELT均有效。许多公司可交替使用带有雪花的两种方法。但是Snowflake的建立是为了让它成为您的数据湖-这个想法是：“只需将所有数据放在这里，然后使用我们强大的计算和存储资源即可快速轻松地对其进行转换。”
在“ Snowflake ELT”或“ ELT vs ETL”上进行Google搜索以获取更多信息。
以下是一些需要考虑的问题：
正在使用的工具：某些SSIS之类的工具是在考虑到ETL的基础上构建的-在将数据存储到仓库之前先进行数据转换。并不是说您不能进行ELT，但并不是在考虑ELT的情况下构建的。更现代的工具-如Fivetran或什至Snowpipe都假设您要将所有数据聚合到Snowflake中，然后将其转换到那里。我真的很喜欢ELT范例-即只要将您的数据放入云中-在那里就可以快速对其进行转换。
数据的大小和增长：如果数据在增长，则在本地资源上进行管理的难度将越来越大。您的数据是千兆字节还是数百万行可能并不重要。但是，随着您获得数十亿行或TB的数据，云的可扩展性已无法匹敌。如果您认为可能会发生这种情况，并且认为将其放入云中并不是一个过早的优化，那么我会将原始数据加载到Snowflake中，然后在将其转换后进行转换。
计算和存储容量：也许您可以轻松掌握大量的存储和计算功能。也许您有一个本地群集，您可以一口气配置资源。大多数人没有。
短期计算和存储成本：：也许您今天可以使用一些适度的资源，而您不愿为Snowflake支付费用，而适度的资源却可以胜任。话虽如此，听起来转换数据的计算将非常少，您每天或每月只需要执行一次。如果真是这样，那么计算成本将非常低。
数据安全性或隐私权：也许您需要先将数据匿名化，然后再将其移至公共云。如果这对您很重要，则应查看Snowflake的安全功能，但如果您所在的组织很难获得安全审核，则需要继续前进，在等待安全审核的同时进行本地转换是一个很好的选择。
数据结构：：数据中是否存在重复项？您是否需要访问Snowflake中的其他数据才能加入才能执行转换？当您开始将越来越多的数据放入Snowflake时，将其转换为Snowflake是有意义的-那就是您所有数据所在的位置，您会发现在所有其他数据所在的云中更轻松地进行连接，查询和转换。
答案 1 :(得分：0)
我的问题是，我的数据是从一个生成json文件的api调用的，新数据不超过每天75 MB的8列，其中两次聚合调用是在sql调用中完成的。如果我每月运行这些可视化，是否最好在Snowflake或本地汇总信息？
我会用python或Snowflake整理您的数据-取决于您使用哪种格式或数据的复杂程度。您可以直接在json上进行所有操作，尽管我很少考虑自己设计这种方式（这将是查询最慢的方式。）
就汇总数据而言，我总是在Snowflake上进行。如果您想以各种方式对数据进行切片和切块，则可以设计一个数据集市数据模型，并使您的仪表板通过查询即时汇总数据。雪花应该可以很好地解决这个问题，但是对于更高的速度，然后将其聚合长达几个月可能也是个好主意。
您可能会由于受本地python脚本驱动（例如无服务器lambda和带有调度程序的事件驱动）的影响而使您的进程成熟。