本文轉(zhuǎn)載自微信公眾號「 木東居士」，轉(zhuǎn)載本文請聯(lián)系 木東居士公眾號。

[[329322]]

0x00 前言

三年前寫過一篇ETL的文章，最近又被小伙伴問到了，因此略作整理放進(jìn)數(shù)據(jù)百問系列。

雖然已經(jīng)過去兩三年了，ETL 領(lǐng)域的一些組件也都有了一些更新，但是整體來看設(shè)計(jì)的理念變化不是特別大(比如實(shí)時處理以前流行的是Spark Streaming，現(xiàn)在流行 Flink，而對于組件，本文也不會講解他的一些使用教程。本文更多地是分享做ETL和數(shù)據(jù)流的思考。)

文章結(jié)構(gòu)

先聊一下什么是 ETL。聊一下大致的概念和一般意義上的理解。

聊一聊數(shù)據(jù)流是什么樣子。因?yàn)?ETL 的工作主要會體現(xiàn)在一條條的數(shù)據(jù)處理流上，因此這里做一個說明。

舉個具體的例子來說明。

0x01 什么是 ETL

ETL，是英文 Extract-Transform-Load 的縮寫，用來描述將數(shù)據(jù)從來源端經(jīng)過抽取(extract)、轉(zhuǎn)換(transform)、加載(load)至目的端的過程。

嗯，怎么理解 ETL 這個東西呢?直接上一個網(wǎng)上搜到的招聘信息看一下：

• 職位名稱：ETL工程師
• 職位職責(zé)：
• 負(fù)責(zé)ETL系統(tǒng)研發(fā)和對外支持工作;
• 設(shè)計(jì)科學(xué)的數(shù)據(jù)抽取、轉(zhuǎn)換、加載的工作流程，保證數(shù)據(jù)及時、正確地抽取到數(shù)倉中;
• 負(fù)責(zé)安排ETL工程流程的調(diào)度和成功執(zhí)行;
• 協(xié)調(diào)數(shù)據(jù)建模建立風(fēng)控模型、對數(shù)據(jù)進(jìn)行挖掘、優(yōu)化及統(tǒng)計(jì)。
• 職位要求：
• 熟練掌握數(shù)倉方法論，理解維度建模;
• 熟悉hadoop,hive,hbase,spark,flume等工作原理;熟悉kettle,informatica,sqoop等工作;
• 精通hive語法，熟練SQL優(yōu)化，熟悉python/shell等一種腳本語言;掌握mysql,oracle,sqlserver等數(shù)據(jù)庫;
• 有互聯(lián)網(wǎng)大數(shù)據(jù)平臺數(shù)據(jù)開發(fā)經(jīng)驗(yàn)優(yōu)先。

看上面的要求，有幾個點(diǎn)可以關(guān)注一下：

數(shù)倉的理論

• 計(jì)算引擎：Hadoop、Spark、hive
• 數(shù)據(jù)同步：Flume、Sqoop、Kettle
• 存儲引擎：Mysql、Oracle、Hbase等存儲平臺

我們大致分析一下這些內(nèi)容。首先說數(shù)倉的理論，這個在前面的博客也都有提到，很重要，從理論上指導(dǎo)了怎么來進(jìn)行數(shù)據(jù)處理。存儲引擎也就不提了。這兩者不太算是 ETL 的范疇。

那就聊一下計(jì)算引擎和數(shù)據(jù)同步的工具。我們可以大致理解 ETL 的主要工作就是利用這些工具來對數(shù)據(jù)進(jìn)行處理。下面舉幾個栗子來說明 ETL 的場景：

1. Nginx 的日志可以通過 Flume 抽取到 HDFS 上。
2. Mysql 的數(shù)據(jù)可以通過 Sqoop 抽取到 hive 中，同樣 hive 的數(shù)據(jù)也可以通過 Sqoop 抽取到 Mysql 中。
3. HDFS 上的一些數(shù)據(jù)不規(guī)整，有很多垃圾信息，可以用 Hadoop 或者 Spark 進(jìn)行處理并重新存入 HDFS 中。
4. hive 的表也可以通過 hive 再做一些計(jì)算生成新的 hive 表。

這些都算是 ETL，其中 1 和 2 都比較典型，它們把數(shù)據(jù)從一個存儲引擎轉(zhuǎn)移到另一個存儲引擎，在轉(zhuǎn)移的過程中做了一定的轉(zhuǎn)換操作。3 和 4 也同樣是 ETL 只是它們更側(cè)重的是數(shù)據(jù)的加工。

到了這一步，我們不再糾結(jié)于具體的 ETL 概念是什么，僅從自己的直觀理解上來定義 ETL，不管嚴(yán)謹(jǐn)不嚴(yán)謹(jǐn)，反正這些活 ETL 工程師基本都要干。

ETL 是對數(shù)據(jù)的加工過程，它包括了數(shù)據(jù)抽取、數(shù)據(jù)清洗、數(shù)據(jù)入庫等一系列操作，大部分和數(shù)據(jù)處理清洗相關(guān)的操作都可以算是 ETL。

0x02 數(shù)據(jù)流長什么樣子

舉個栗子

舉個簡單的栗子，下面是一個種數(shù)據(jù)流的設(shè)計(jì)，藍(lán)色的框框代表的是數(shù)據(jù)來源，紅色的框框主要是數(shù)據(jù)計(jì)算平臺，綠色的 HDFS 是我們一種主要的數(shù)據(jù)存儲，hive、Hbase、ES這些就不再列出來了。

數(shù)據(jù)流的分類

我們常說的數(shù)據(jù)流主要分兩種：

• 離線數(shù)據(jù)
• 實(shí)時數(shù)據(jù)

其中離線數(shù)據(jù)一般都是 T+1 的模式，即每天的凌晨開始處理前一天的數(shù)據(jù)，有時候可能也是小時級的，技術(shù)方案的話可以用 Sqoop、Flume、MR 這些。實(shí)時數(shù)據(jù)一般就是指實(shí)時接入的數(shù)據(jù)，一般是分鐘級別以下的數(shù)據(jù)，常用的技術(shù)方案有 Spark Streaming 和 Flink。

現(xiàn)在的大部分?jǐn)?shù)據(jù)流的設(shè)計(jì)都會有離線和實(shí)時相結(jié)合的方案，即 Lambda 架構(gòu)，感興趣的同學(xué)可以了解一下。

0x03 舉個栗子

前段時間和一個哥們再聊數(shù)據(jù)流的設(shè)計(jì)，正好這里大概描述一下場景和解決方案。

一、場景

數(shù)據(jù)源主要為 Mysql，希望實(shí)時同步 Mysql 數(shù)據(jù)到大數(shù)據(jù)集群中(肯定是越快越好)。

目前每日 20 億數(shù)據(jù)，可遇見的一段時間后的規(guī)模是 100 億每日以上。

能快速地查到最新的數(shù)據(jù)，這里包含兩部分含義：從 Mysql 到大數(shù)據(jù)集群的速度快、從大數(shù)據(jù)集群中查詢的速度要快。

二、方案選型

遇到這個場景的時候，根據(jù)經(jīng)驗(yàn)我們主要考慮下面兩個點(diǎn)：數(shù)據(jù)抽取引擎和存儲引擎。

數(shù)據(jù)抽取引擎

這里我們主要考慮兩種方案：

Sqoop 定時抽取 Mysql 數(shù)據(jù)到 HDFS 中，可以每天全量抽取一份，也可以隔段時間就抽取一份變更的數(shù)據(jù)。

Canal 監(jiān)聽 Mysql 的 binlog 日志，相當(dāng)于是 Mysql 有一條數(shù)據(jù)久變動，我們就抽取一條數(shù)據(jù)過來。

優(yōu)缺點(diǎn)的對比也很明顯：

• Sqoop 相對比較通用一些，不管是 Mysql 還是 PostgreSql都可以用，而且很成熟。但是實(shí)時性較差，每次相當(dāng)于是啟動一個 MR 的任務(wù)。
• Canal 速度很快，但是只能監(jiān)聽 Mysql 的日志。

存儲引擎

存儲引擎主要考慮 HDFS、Hbase 和 ES。

一般情況下，HDFS 我們盡量都會保存一份。主要糾結(jié)的就是 Hbase 和 ES。本來最初是想用 Hbase 來作為實(shí)時查詢的，但是由于考慮到會有實(shí)時檢索的需求，就暫定為ES

三、方案設(shè)計(jì)

最終，我們使用了下面的方案。

使用 Canal 來實(shí)時監(jiān)聽 Mysql 的數(shù)據(jù)變動

使用 Kafka 作為消息中間件，主要是為了屏蔽數(shù)據(jù)源的各種變動。比如以后即使用 Flume 了，我們架構(gòu)也不用大變

數(shù)據(jù)落地，有一份都會落地 HDFS，這里使用 Spark Streaming，算是準(zhǔn)實(shí)時落地，而且方便加入處理邏輯。在 落地 ES 的時候可以使用 Spark Streaming，也可以使用 Logstach，這個影響不大

四、一些問題

有兩個小問題列一下。

小文件，分鐘級別的文件落地，肯定會有小文件的問題，這里要考慮的是，小文件的處理盡量不要和數(shù)據(jù)接入流程耦合太重，可以考慮每天、每周、甚至每月合并一次小文件。

數(shù)據(jù)流的邏輯復(fù)雜度問題，比如從 Kafka 落地 HDFS 會有一個取舍的考慮，比如說，我可以在一個 SS 程序中就分別落地 HDFS 和 ES，但是這樣的話兩條流就會有大的耦合，如果 ES 集群卡住，HDFS 的落地也會受到影響。但是如果兩個隔開的話，就會重復(fù)消費(fèi)同一份數(shù)據(jù)兩次，會有一定網(wǎng)絡(luò)和計(jì)算資源的浪費(fèi)。

0xFF 總結(jié)

仔細(xì)想了一下，數(shù)據(jù)流應(yīng)該是我做的最多的一塊了，但是總結(jié)的時候感覺又有很多東西說不清楚，先簡單寫一部分。