海外数据整合赛道玩家浅析

发表于 2022-05-27 分类于创业阅读次数：

Fivetran:

ETL 到 ELT+E 的转变

Extract->Transform->Load 是过去数据整合分析常用的套路，而且 ETL 主要是在涉及数仓的时候才被提及的话题。这里的 Transform 主要指的是定义数据模型、按照定义的数据模型和数据清理标准在正式写入到对端数仓的时候进行转换。Fivetran 将 Transformation 交给对端在他们视角主要考虑的核心点是：

客观可行性：存储成本降低、强大数据库的诞生
迁移同步链路、模型开发的标准化：T 解耦后，EL 可以输出标准化输出物，整个同步链路是可以标准化和模板化的。Fivetran 称之为这样的产品为 Data building tools(DBT)。不同数据源之间无需建立复杂协调机制。

ELT+E 的总体模式如下，通过产品层面一站式提供二次的 Extract，用户最终可以直接拿到最终结果。Transform 的复杂过程，交给数仓数据库去执行即可。

面向分析师客群

产品聚焦的客群还是分析师。T 的解耦，也是为了避免目标分析师陷入同步链路的管理运维之中，像黑盒子一样完成 Extract->Load 就好了。

官网提供的核心 4 个解决方案全部是围绕分析场景的。

官方的视频介绍也是专注介绍一件事情，构建中心化的数据中心，通过数据发现价值助力企业更好的发展。

更进一步靠近业务价值、数据价值

Fivetran 的 ELT 逻辑是实打实的，数据迁移同步只是他工作的一部分。如果建模、数据转换以及利用数据同样是 fivetran 关注的事情。

Fivetran 的任务创建流程包含最后的 transformation 处理，包括定时的报表产出、报表任务维护、建模维护。除了内置的模式以外，现在主要基于 DBT 去做了。

连接器管理以外，transformation 和数仓占据重要的位置

定价

Fivetran 的定价模型很有意思，引入信用额度的概念。好处就是大客户 MAR 高，使用起来的单价越便宜。可以比较好的留住大客户。

1	信用额度与企业的使用Fivetran产品中的每月活动行数（Monthly Active Rows），简称MAR,对应。企业客户使用的MAR越多，你消耗的信用额度就越少。

如何做客户成功：围绕现代数据栈来兜售产品

fivetran 落地 Oldcastle(一家建筑公司)的案例，查看他们博客Oldcastle Infrastructure Sees $25M ROI With The Modern Data Stack 和其他案例有以下总结。

客户成功主要体现在更高的效率、成本的大幅度降低，fivetrans 也没有自己深入业务
关注生态伙伴的合作，尤其是各种数据湖、数仓、BI 工具和可视化软件，以现代化的 data stack 整体出售

为什么收购 HVR

看 fivetran 的发展历程，发现其收购了 HVR。在了解背后原因前，可以先说下 Gartner 对数据整合赛道评级需要的四种关键能力：

数据工程：偏向 AP 的能力，类似 fivetran 在面向数据分析、实时数仓报表可视化这个领域很擅长。
云迁移：云化能力，云的支持能力
业务数据整合：主要是在线业务、关键业务数据的整合与治理。类似构建电商数据的实时索引、异地多活、灾备、主数据管理、DDL 同步等都是这个领域内的能力。
数据编织：利用主动式元数据访问、机器和语义分析等手段让人更快更好的访问数据。这个比较前沿，暂时其实没这块的场景

了解这 4 个关键能力就知道，fivetran 在数据工程、云迁移方面能力强悍。围绕 snowflake 和亚马逊云，重点面向数据分析场景。但是在业务数据整合方面能力比较弱，但是 HVR 则补足了这块短板。HVR 对于 fivetran 重要的能力是：

DDL 同步
关系型数据库 CDC 领域的沉淀，实时同步
数据校验
支持数据移动拓扑结构。它支持数据的单向和双向移动，用于数据整合（单一目标）或数据广播（多个目标），以及级联复制，用于分发准备好的数据。对于主动/被动配置，支持数据的多向移动
支持在基于 CDC 的数据复制基础上进行复杂的数据转换。例如，它支持自动数据类型映射和转换、行级转换、缺失值的存根、异常值的修复和字符集转换。如果需要，可以使用软件开发工具包（SDK）来调用外部数据转换逻辑，由 HVR 完成协调工作。
在数据治理支持方面需要做更多工作。与第三方工具的数据治理集成需要用户编写自定义 SQL 代码。同样，HVR 也没有自己的数据目录来获取元数据，而是依赖于与其他供应商的数据字典的集成。

DBT(Data build tool)

DBT 是一个开源的工具，这个工具是 python 写的，提供一些列命令，可以用于结合 fivetran 来做一些 transform。ELT 的三个步骤中，该工具专注于 T 这个细分赛道。之所以有 DBT 这个产品，作者们的一些认知可以借鉴。

DBT 核心要素：

SQL 文件：一个 SQL 文件对应一个模型
jinja 模板语言：就是支持 if else 等逻辑来组织模型
DAG：根据模型之间依赖可以构建 DAG，按序执行。
物化策略：这个是个值得注意的亮点。这里的物化指的是 DBT 定义的模型如何在数仓中持久化。除了很容易想到的 table 和 view，DBT 额外提到的incremental和ephemeral。
像软件开发一样的模型开发：互相协作来生成模型和分析工作流。更加标准化、高效管理。将软件工程的思想引入到数据处理领域

一次增量构建的 DBT 脚本示例

{{
    config(
        materialized='incremental'
    )
}}

select
    *,
    my_slow_function(my_column)

from raw_app_data.events

{% if is_incremental() %}

  -- this filter will only be applied on an incremental run
  where event_time > (select max(event_time) from {{ this }})

{% endif %}

AirByte

EL(T)

总体上也是支持 ELT 的未来趋势，但是在隔离 T 上做的更加彻底，不像 fivetran 一开始还是有内置的去做一些 transform 的事情

开源&社区

总体模式上采用开源的方式，这个是和 fivetran 最截然不同的一点。希望构建 EL 的行业开源标准。EL 层面的高度抽象结合社区贡献 connector。这和 fivetran 有着截然不同的商业路径。通过这一点相信确实可以打动不少投资人。从 2020 年成立以来，在支持的数据源上、使用的用户数上快速追赶上了 fivetran

收益分享

这个很特别，高质量的连接器 airbyte 会和作者分享利润。其中如何分配利润以及对双方的责任约定和边界值得再了解一番。

数据连接器作为核心对象

connector 是其主体，围绕其提供产品能力。airbyte 对于未来五年数据整合的发展方向认知是。感觉 airbyte 定位，可以称之为“连接器平台”。平台提供分润机制、统一的连接器接入模式和管理方式。管理包括调度、编排、监控、升级、高可用。

关注长尾用户

由于开源，并且利用了社区力量，支持的数据源种类非常多，而且同时也是关注 CDC 的，不像 fivetran 一开始可能对 CDC 没有那么重视。airbyte 认为长尾用户带来的价值不容小觑，现在 fivetran 大概 150+数据源支持，airbyte 目标在近期支持到 500+数据源。

关注隐私合规

一开始就注重隐私合规问题，包括：

安全和隐私合规功能
数据质量监控功能
权限和用户访问管理

总结启示

技术上

从技术上来说，EL 结合开源确实是比较优秀的方式，而且我也相信这应该是未来的方向。技术上聚焦 EL 并且开源带来诸多好处：

树立行业标准：可以慢慢树立起数据集成领域的行业标准。技术上如何对 EL 做好抽象，定义好标准，这块我们可以从 airbyte 上去学习。
分离职责：其实 connector 层面有很多细枝末节以及烦人的细节问题，利用社区的力量完善 connector，产生优质的 connector。而平台聚焦其本身平台商业价值，不拘泥于太多 connector 细节问题，能够更快的发展

商业上

商业上其实 fivetran 由于成立比较久，其参考意义更大些。fivetran 更加关注数据分析师这个目标客群。支持企业快速稳定的产出报表。可以料想，有这类报表需求的企业一般也为有较强付费能力的公司。关注他们的诉求，专注于高净值客群的需求，在商业转化上应该会有更好的效果。