BigQuery 与Machine Learning | ML#Day27

在引用资料来源的时候,除了上传csv的选项,另外一个就是BigQuery。

早在开始摸索ML之前,Google的人员就无数次跟我们推荐BigQuery,只是一直觉得没有应用的场景。

那麽如果是处理表格式的资料,或许先将资料整理写进BigQuery里面,也是一种选择,搭配Vertex就变成另外的组合技。

因此我们也对於BigQuery的收费方式和适用性稍微评估了一下:

  1. 储存空间的价格相对非常便宜,比起在GCE开VM,外挂硬碟空间的做法相比,还是相对便宜。
  2. 但任何查询的流量都需要收费,譬如说连join的数量也是要算钱,那麽也就是说query的技巧和切partition之类的设置,会大幅影响这部分的费用。
  3. 由於可设置的部分和DB提供改调整参数的项目,没有自己像在VM完全自己弄那麽弹性,无法应付客制化的需求,因此不被考虑了。但是如果只是为了跑ML,单纯当作资料储存的地方,是可以考虑使用的。
  4. 资料在存入BigQuery之前,必须要先开好schema,也就是说BigQuery个很制式化的储存格式,而log类型的资料本身属於弹性,且栏位不定的资料,除非愿意投入事先整理的成本,不然不适用log资料随便乱塞的需求。

除了报表类型的资料,我们大部分系统的行为和纪录会在ELK log,ELK本身已经提供很好的资料储存和查询的便利性,BigQuery的角色就相对有点鸡肋。不过若未来在做更进阶一点的题目,或许经过资料的整合,BigQuery还是可以当作考虑的存放选项。

另外值得一提的一点,研究Vertex的期间,我们意外的发现BigQuery还有一个BigQuery ML的功能。

这也是表格式资料相比其他资料类型的ML可以运用的方式。

参考资料

虽然尚未亲自试用,看起来十分有趣,Google的策略给人感觉起来,想打造出一个各产品结合的生态系。


<<:  Day 20 api介绍

>>:  Day 23: WAF web ACL、rules group建立

Day 30 - 故事的最後不是句点,是开始

我成功了吗 经过了这段特别长的暑假,我好像学会了蛮多的东西的!我想对於一个有严重拖延症的患者而言,我...

DAY28 mongodb aggregate(2)

上次我们在mongo shell里使用mongodb aggregate 不过 我们需要在程序里面去...

效能监视器--Windows的隐藏监控器

今天要讲的是效能监视器(Performance Monitor),他是Windows内建的监控程序之...

Day6 Director & Match Function

首先我们会介绍 Director 是如何实作的,并介绍 Director 跟 Open-Match ...

html清单

今天学习如何在网页上显示清单列表,我们需要用到ul li与ol li 首先是ul li,在body里...