DAY 12 Big Data 5Vs – Variety(速度) Lambda

在Variety主要说的速度问题是指单次任务运算处理的速度，速度的压力可能来自於使用者对回应速度的要求。所以说，容量问题像是资料流(data pipeline)中的推力，而速度问题像是资料流中的拉力。

在资料处理的过程中，典型的架构就是ETL流程。这个架构是描述将资料从来源端(Data Source)抽取（Extract）後经过转置（Transform）再载入（Load）至目的端(Data Target)的流程。从速度来看可将资料处理可以分为「批量处理」与「串流处理」，他们有各自的架构且适用不同时间间隔需求的分析场景；在许多系统中更是两种架构并行，因为即使是同个资料集，经过不同的处理流程也可以萃取出不同的资讯。以下简单差异比较：

批量处理：Batch Process:
可以使用采用较复杂的分析取得更深入的洞察
延迟可能几分钟至数小时
一系列的ETL流程会在同一个处理系统中执行
单次处理资料量相对较大

串流处理：Streaming Process:
可以利用简单分析提供几乎即时的反馈
延迟低至秒级甚至毫秒级
ETL流程会在分散独立在各自串流处理系统中执行
单次处理资料量小

AWS上可以最快速建立的资料处理服务是 — AWS Lambda，它是「无服务器服务」所以不需要担心服务器组态的管理，但使用者仍然可以方便的监控它的状态。Lambda function会将程序码静态加密後储存在 Amazon S3 中，而程序码在执行时也会做完整性检查。每个Function的 /tmp 目录都有 500 MB 的暂存空间。要注意的是，Lambda最长的执行时间只有15分钟。

一进到服务首页可以看到当前帐户下的所有资源状态

右方可以直接进入建立function分页

进入後选定程序执行环境(Runtime)
如果要在特定的网路环境执行可以在进阶设定选定VPC(virtual private cloud)，建立後可调整

以建立Python程序码为例，建立後会进入程序码页面，可以在下方code分页中编写程序码，完成後可以在下一个test分页测试。如果是预先准备好的程序码，可以从右上角”upload from”从本机上传压缩好的ZIP档，或是将档案先上传至S3再给定位置，要注意的是压缩後的大小不能高过50 MB。

如果是有额外准备的library可以从Add a layer来导入

要监控function的状态可以到monitor分页，这里整合了不只是CloudWatch的报告即时指标，甚至从右上方可以找到更细节的指标状态。

值得一提的是，Lambda function是无状态的，这个特性让每个function可以被事件驱动进而及时扩展以应付使用者需求。因为它的轻量与灵活性，让它常常出现在需多只需要简单ETL的架构中以减少开发时间，或是在分析架构中来串接各个分析阶段。