Fivetran簡介

公司發展

Fivetran提供SaaS服務，它連接到業務關鍵數據源，提取並處理所有數據，然後將其轉儲到倉庫中，以進行SQL訪問和必要的進一步轉換。
參考今年9月的融資消息，這家公司過去一兩年里發展很迅速：

2012年由Y Combinator發起，種子輪融資$4M。
2018年12月，A輪融資額$15M，有80名員工。
2019年9月，B輪融資額$44M，有175名員工。過去12個月收入增長3倍，當前有750多個客戶。

核心理念

Fivetran要打造的是基於雲的數據分析平台，其設計哲學可以概括為三點：

選擇合適的數據（倉）庫：基於雲的數據存儲，存儲與計算分離，例如Snowflak、BigQuery、Redshift。
將數據源可靠的複製到數據倉庫，Ingest階段儘量少地涉及數據轉換。類似思想的還有Kafka Connect等系統，但Fivetran更強調自動化，包括：自動欄位映射，數據與schema的同步。
徹底的踐行E-L-T模式，用SQL語言在數據倉庫上做業務層分析。

架構

與其核心理念一致，Fivetran是完全構建在雲基礎設施上的一套服務，使用到虛擬機、函數、對象存儲、VPC、日誌等服務。

這張圖非常清晰描述了三個階段:

獲取源數據到工作節點，圖例1、2、3。
準備數據寫到臨時存儲，圖例4。
將臨時存儲數據加載到目標數據倉庫，圖例5A、5B。

攝入與準備數據

支持150多種connector，分兩大類：

pull connector：Fivetran主動發起請求下載數據，以固定時間間隔做周期調度。例如：通過ODBC/JDBC訪問資料庫，通過API訪問web服務。
push connector：從源主動寫數據到Fivetran，例如Webhook、Snowplow。接收到事件後，Fivetran以JSON格式存儲數據到對象服務的文件。

connector獲取到數據後，Fivetran會對數據做一些準備工作，包括：簡單的過濾、排序和去重。在這個過程中，數據會緩存落盤，使用臨時秘鑰做加密。

加載數據到臨時存儲

Fivetran將準備完成的最終數據記錄到文件，存儲到bucket（可配置雲廠商）。bucket歸Fivetran所有，存儲文件是經過加密的。

值得一提的是加密使用的秘鑰是臨時的，且秘鑰只存放在connector進程內。為什麼這麼做？

加載數據到數倉

Fivetran將文件拷貝至目標數倉，同時該處理進程將秘鑰也傳遞給數倉用於解密數據。當數據倉庫完成對用戶表的數據插入或修改後，connector進程運行完成並結束，scheduler在下一次觸發時再次啟動connector進程。
至此，回答上一節的問題。密鑰只存在於connector進程的內存中，即使後台系統的VPC、Bucket、EC2被入侵，用戶的數據也能保證不被泄露。

系統生成內容

Fivetran會為用戶生成一些系統表格、列。例如fivetran_audit表格記錄每次任務的運行概覽，包括：任務id、起止時間、狀態、唯一的update_id、處理數據行數等。

系統為目標數倉表添加的保留列有：

fivetran_synced (UTC TIMESTAMP)：數據處理時間。
fivetran_deleted (BOOLEAN) ：數據在源中是否被刪除。
fivetran_index (INTEGER)：對於無主鍵表，標識update發生的順序。
fivetran_id (TEXT) ：系統分配的唯一ID，用於無主鍵表的去重。
fivetran_id2 (TEXT) ：系統分配的唯一ID，在null主鍵情況下，用於再區分。

這些保留欄位的加入，主要用意還是透明化，幫助用戶了解數據集成幹了哪些事，方便問題追溯。

日誌

Fivetran記錄connector的操作事件，可以存儲到AWS CloudWatch、GCP Stackdriver、Azure Log Analytics。

數據集成

數據源

Fivetran將數據源分為四類：

Application：例如Google Ads等軟體服務商上記錄了一些系統數據，可以通過API獲取。
Database：RDS、NoSQL。
File：包括Azure、AWS、GCP三家的對象存儲，DropBox，FTP等數據源。
Event：網頁、移動App、郵件等數據源，如下圖，Fivetran額外構建了網關用於接收數據。

Function

如果一定要在數據集成階段就做一些轉換操作，支持AWS、Azure、GCP三家函數服務。這與AWS Kinesis Firehose集成Lambda的方式一致。函數的實現要求做到冪等性，系統會重試請求直到成功，再把結果寫到bucket。

數倉分析

connector的目標包括單機資料庫（MySQL、SQLServer，PostgreSQL）和分布式數倉（推薦）。
connector進程將數據從源複製到base table，base table是數據在用戶數倉上的第一站。Fivetran的同步是帶狀態的，通過和系統內部數據對比可以避免對目標表做全量scan。用戶不直接在base table上做修改，因為可能導致後續的sync策略失效。因此，如果有修改base table再讀需求，推薦用view來實現。

Schema遷移

在一次數倉update中，比較新讀取的源數據與已經投遞給數倉的系統內部數據，可以實現schema的同步。

表改動：新的object會自動創建數倉表。rename解釋為一次delete和create組合。
列改動：新加列會觸發一次對表中的所有行的全量導入。刪除列在數據倉庫中保持不變，該列在新增數據行中設為null。但如果伴隨著其它改動並觸發了表的重新全量導入，那麼已刪除列中的先前的數據會被清除掉。
列類型改動：如果是寬轉換（例如int轉bigint）的，那麼直接在數倉更新列的類型。而窄轉換（例如從varchar(100)轉varchar(20)）的改變會觸發一次全表的重新導入。

Transformation

同樣是做數據轉換，與Function區別是：Function發生在數據Ingest階段，Transformation則是E-L-T的T，發生在數據到達目標數倉的分析階段。

Transformation完全使用SQL，通過觸發器（新數據被load到數倉後）或基於時間的調度策略，自動觸發錶轉換。

觀察與總結

雲數倉

Fivetran是新派的ETL玩家，不僅自己的服務系統基於雲構建，連用戶側分析也是雲上的數倉。
Hadoop、AWS Athena走數據湖線路，可以快速完成初期系統的搭建，但可能因為缺乏數據schema規劃、缺少計算下推的輔助，犧牲了一定的分析效率。
以AWS Redshift、Hive為代表的數倉，提供高效率的壓縮存儲以及存儲、計算的一體化，提升了分析效率，但系統搭建依賴前期表和schema設計，以及在將來schema變化時伴隨著維護成本。
Fivetran選擇適配多數倉系統，由用戶根據業務場景自主選擇用什麼做分析。使用SQL（被廣泛支持的數倉語言）統一用戶的Transform、Analytics使用體驗。

E-L-T

這也是雲數倉帶來的另一個好處，水平擴展的計算和存儲。這簡化了對數據集成的使用，數據只需要安全達到數倉base table即可。而只要base table數據存在，通過交互式的查詢可以動態修正業務分析的策略，並快速拿到結果。

自動化管道

無論是數據的導入還是schema的同步，自動化都在嘗試解決ETL pipeline維護複雜的問題，這個功能具有現實意義。Fivetran CEO表示他們在幕後驅動自動化的過程非常複雜，但服務會努力向客戶隱藏這種複雜性。

安全很重要

涉及到PII信息或是滿足GDPR等合規要求，服務對數據加密訪問做了細緻的設計，可以看到安全性在這樣的第三方廠商擺在了很高的優先級。

參考資料

https://fivetran.com/docs
https://www.youtube.com/watch?v=5-s8NfuPf9s
圖片取自fivetran材料

個人學習總結，理解不到位處請斧正。

作者：唐愷

Fivetran：自動化數倉集成服務