ARTS 第 2 周 - AWS 云服务之 Glue

Algorithm

这周仍然是腾讯精选练习 50 题列表中的一道简单题：爬楼梯，可以拆解出子问题，即爬到第 n 阶台阶有两种方式：从第 n - 1 阶爬 1 个台阶，或者从第 n - 2 阶爬 2 个台阶，所以：f(n) = f(n - 1) + f(n -2)。我的题解使用了一种带缓存的递归，时间复杂度是 O(n)：

class Solution {
    private Map<Integer, Integer> cache = new HashMap<>();
    public int climbStairs(int n) {
        cache.put(1, 1);
        cache.put(2, 2);
        return f(n);
    }

    private int f(int n) {
        if (cache.containsKey(n)) {
            return cache.get(n);
        }
        int y = f(n - 1) + f(n - 2);
        cache.put(n, y);
        return y;
    }
}

Review

这周读了 Martin Fowler（1963-）的一篇关于 Data Lake 的博客文章《Data Lake》，Martin Fowler 既是资深软件工程师，也是软件开发方面的著作者和国际知名演说家，他最有影响力的著作就是《Refactoring: Improving the Design of Existing Code》。

回到这篇文章，文章首先阐述了 Data Lake 和 Data Warehourse 在数据 schema 上的区别，他认为不太可能在 Data Warehourse 中创建一个 Common Data Model，所以 Data Lake 是一个更经济的选择，随后列举了存储 Raw Data 可能给数据分析挖掘带来的好处，解析这些 Raw Data 的任务应该交给具体的分析人员（或者数据科学家）。文章中还提到，Data Lake 需要添加访问控制，限制能够接触到 Raw Data 的人员，注意隐私和安全问题；另外还强调因为 Data Lake 中数据的复杂性，它不应该用于系统间协作，应该通过 API 调用或者异步消息的机制进行系统间的协同。

最后，可以配合 Medium 上的解说文章《My Understandings of Martin Fowler’s “Data Lake” Masterpiece》一起阅读。

Tip

最近工作中需要解析 Parquet 文件，需要确认下是否在 Parquet 内部 Block 压缩的基础上，还会施加整个文件的压缩，结论是一般不会再施加整个文件的压缩，这可能会影响 Parquet 的 Splittable 性质，从 parquet-mr 源码中的 CodecConfig 类也能看出，ParquetOutputFormat 优先使用 parquet.compression 配置设置的压缩格式，如果没有设置则使用 mapreduce.output.fileoutputformat.compress.codec，如果仍然没有设置，则不使用压缩。

public abstract class CodecConfig {
  ...
  public CompressionCodecName getCodec() {
    CompressionCodecName codec;
    Configuration configuration = getConfiguration();
    if (isParquetCompressionSet(configuration)) { // explicit parquet config
      codec = getParquetCompressionCodec(configuration);
    } else if (isHadoopCompressionSet()) { // from hadoop config
      codec = getHadoopCompressionCodec();
    } else {
      if (INFO) LOG.info("Compression set to false");
      codec = CompressionCodecName.UNCOMPRESSED;
    }

    if (INFO) LOG.info("Compression: " + codec.name());
    return codec;
  }
  ...
}

AWS（Amazon Web Services）从 2006 年发布存储服务 S3（Simple Storage Service）和计算服务 EC2（Elastic Compute Cloud），到现在已经拥有非常丰富的云产品体系，成为云计算领域的先驱者，也是国内云厂商争相模仿的对象。透过 AWS 的云产品可以了解这一领域的发展现状，同时也能看到未来的发展方向，所以我计划花些时间研究一下 AWS 的云产品，先从跟我工作比较相关的 Glue 开始吧。

Data Lake

Data Lake 示意图（来自 AWS 官网）

Glue 是 AWS 数据湖（Data Lake）解决方案 Lake Formation 的核心部分，介绍 Glue 之前先来看一下什么是数据湖，不同云厂商都有各自不同的定义，下面是 AWS 的定义：

A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.

简单来说，数据湖就是一个存储你所有的结构化和非结构化数据的「中央仓库」，你可以对其中的数据进行分析（机器学习等），提取有价值的信息来指导决策。数据湖经常拿来和数据仓库（Data Warehouse）对比，通常认为数仓中的数据在写入的时候 schema 就是确定的，而数据湖存储的各种原始数据（Raw Data）没有统一的 schema。

Data Lake 这个概念是在 2010 年由一个叫做 James Dixon 的人提出的，当时是为了与数据集市（Data Mart）做对比。没必要对新概念趋之若鹜，数据湖本质上也并不是特别新鲜的东西，很多大数据相关的企业应该早就把自己的数据一股脑放到 Hadoop 的 HDFS 上面了，也有放到 S3 这样的云存储上的，但是往往因为缺乏治理而变成数据沼泽（Data Swamp），数据加工处理的效率也比较低下，各个云厂商就是基于这样的现状纷纷拿出了自己的数据湖解决方案，这个概念也因此变得火热起来。

Glue

AWS Lake Formation 示意图（来自 AWS 官网）

2017 年 8 月 AWS 发布了 Glue 服务，接下来 2018 年 11 月发布了 Lake Formation 服务，基于 Glue 帮助客户搭建和管理数据湖，先看看 AWS 官网对 Glue 的介绍：

AWS Glue is a fully managed extract, transform, and load (ETL) service that makes it easy for customers to prepare and load their data for analytics. You can create and run an ETL job with a few clicks in the AWS Management Console. You simply point AWS Glue to your data stored on AWS, and AWS Glue discovers your data and stores the associated metadata (e.g. table definition and schema) in the AWS Glue Data Catalog. Once cataloged, your data is immediately searchable, queryable, and available for ETL.

简单来说，Glue 是一个 ETL 服务，它能发现你在 AWS 上面存储的数据，并将其元数据维护在 Data Catalog 中，ETL 任务可以根据 Data Catalog 中存储的元数据读取你的数据进行转换，产出的结果供下游的分析服务使用。

AWS Glue 界面（截自 AWS 官网）

从 Glue 的界面上就能看出它主要有三部分的功能：Data Catalog、ELT、Security。其中 Data Catalog 是元数据目录，支持采集 S3、Amazon RDS、Amazon Redshift、Kafka、DymanoDB 等的元数据并抽象成表，统一管理起来；然后可以自动生成 ETL 任务脚本（Spark Python），通过界面选择 transform 算子或使用 notebook 进行编辑，最后运行任务产出结果；Security 部分提供一定程度的访问控制。

乍看之下，可能觉得 Glue 的功能其实很「简单」，实际上确实很简单，虽然实现这些功能有很多工作要做，但也不是什么很难攻克的技术难题，有一定技术水平的公司应该都能开发出来。但是注意，Glue 的中文名是「胶水」，是它把 AWS 上面的其他服务粘合在了一起，前提是客户已经在其他服务产生了大量的数据，这时 Glue 才是有意义的。

操作界面的左栏其实还有一个 Tutorials 模块（截图没有截到），这个模块通过一个「航班日志分析」的例子演示了 Glue 的主要功能，用户跟着一步步走下来基本就入门了，提供一份好的使用指南其实是相当有必要的，不然就等着人肉答疑和工单吧。即使提供了使用指南，这类云产品的使用门槛也并不低，我在想这些产品是否可能达到像「微信」这样的应用的易用程度呢？最后分享一下，我是使用万事达卡全球付（Global Cash）虚拟信用卡开通 AWS 免费账户的，这个虚拟信用卡也可以用来开通 Apple 美区账号。

Algorithm

Review

Tip

Share

Data Lake

Glue