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等合规要求，服务对数据加密访问做了细致的设计，可以看到安全性在这样的第三方厂商摆在了很高的优先级。
参考资料
个人学习总结，理解不到位处请斧正。
