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

[[329322]]

0x00 前言

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

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

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

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

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

舉個(gè)具體的例子來(lái)說(shuō)明。

0x01 什么是 ETL

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

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

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

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

數(shù)倉(cāng)的理論

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

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

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

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

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

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

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

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

舉個(gè)栗子

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

數(shù)據(jù)流的分類(lèi)

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

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

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

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

0x03 舉個(gè)栗子

前段時(shí)間和一個(gè)哥們?cè)倭臄?shù)據(jù)流的設(shè)計(jì)，正好這里大概描述一下場(chǎng)景和解決方案。

一、場(chǎng)景

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

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

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

二、方案選型

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

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

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

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

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

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

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

存儲(chǔ)引擎

存儲(chǔ)引擎主要考慮 HDFS、Hbase 和 ES。

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

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

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

使用 Canal 來(lái)實(shí)時(shí)監(jiān)聽(tīng) Mysql 的數(shù)據(jù)變動(dòng)

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

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

四、一些問(wèn)題

有兩個(gè)小問(wèn)題列一下。

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

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

0xFF 總結(jié)

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