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

发表于 2022-05-27 分类于创业阅读次数：本文字数： 2.4k 阅读时长 ≈ 8 分钟

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去做了。

定价

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更加关注数据分析师这个目标客群。支持企业快速稳定的产出报表。可以料想，有这类报表需求的企业一般也为有较强付费能力的公司。关注他们的诉求，专注于高净值客群的需求，在商业转化上应该会有更好的效果。