DAY 25 Big Data 5Vs – Veracity(准确性) Athena(2)

如同近年被热烈讨论的 微服务架构* 与 CQRS架构*,AWS上推广的资料分析原则之一也是建议要将资料储存与资料处理解耦,白话意思就是储存资料由专门的系统负责;资料处理也交由另外专门运算的系统来执行,每个系统各司其职。当然这个架构不一定符合所有的应用需求,但以资料分析的应用情境来看,解耦的好处之一是:资料能够以它更接近原始的样貌被储存着,当使用者有多元的分析需求时(,比如说同一个公司的行销部门与研发部门要对同一份产品使用资料集产出不同的分析报告),这样不同的分析程序都能触及最原始的资料,避免後续不同资料流的分析处理相互影响而导致结果失真,导致决策者做出失准的决定。

在AWS上最常见的资料储存服务S3就常担任分析资料流中那唯一真实资料源single source of truth*的角色,例如前一篇所介绍的Athena查询服务就是将储存工作交由S3负责,而Athena专门执行分析查询等任务。

下图为AWS分析中的一个典型快速分析架构,就是串接S3、Athena与Glue。
https://ithelp.ithome.com.tw/upload/images/20211007/20140161XYlQrPsVPP.jpg
资料存进S3之後,就可以建立编目程序/Crawler(可参考Day13*)
利用编目程序在Glue中创建Data Catalog
https://ithelp.ithome.com.tw/upload/images/20211007/20140161OktoJ8Wulp.jpg

确认Data Catalog建立之後就可以进入Athena服务页面,透过网页编辑器来下SQL查询语法
https://ithelp.ithome.com.tw/upload/images/20211007/201401615rYwXBNpSP.jpg
如果S3中是以压缩档来储存的话可以大幅降低语法的扫描资料量
选用parquet等column-based 压缩档时也提升聚合语法的效能
https://ithelp.ithome.com.tw/upload/images/20211007/201401610ujSzObux4.jpg
有返回资料就是有扫描资料量,可以再编辑器下方查看

注意Athena是扫描的资料量是收费的标准,所以值得一提的节省用量方法是在Data Catalog中建立partition key,partition key相当於S3中的资料夹名称(实际上就是prefix)
https://ithelp.ithome.com.tw/upload/images/20211007/20140161PgbJtRdFKI.jpg
如果在S3储存档案时按照Key=Value 的prefix格式储存,编目程序执行时会将prefix建立在Glue catalog 的partition key 栏位,方便在Athena下SQL时使用
https://ithelp.ithome.com.tw/upload/images/20211007/20140161znlPzmjNmk.jpg

*微服务架构( https://zh.wikipedia.org/wiki/%E5%BE%AE%E6%9C%8D%E5%8B%99 )
*CQRS架构( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation )
*Single source of truth ( https://en.wikipedia.org/wiki/Single_source_of_truth )
*Day13( https://ithelp.ithome.com.tw/articles/10271765 )


<<:  [Day 23] props

>>:  Whistle proxy

ISMS 程序书1~4阶着样写

(一)政策性(第一阶文件) 说明ISMS目标、方向及执行原则。 文件:资安政策、资安组织 ISMS-...

【Day20】维持连线 ─ 工具实作篇(二)

哈罗~ 昨天我们实作了Netcat(nc)的基本操作, 今天想来补充一些类似Netcat(nc)的东...

#30 [Final] Had Fun Learning JavaScript?

Congratulations to all of us! The final day has al...

Day 22. Unreal 再见

有鉴於我的Macbook pro开unreal engine时,实在是真的卡,所以只好先放着。   ...