administrators

bplayer

bplayer

bplayer

背景
数据是任何企业不可或缺的方面。它允许解决方案开发、指标跟踪，并为简化和集成的流程创建结构。数据助力业务决策。
我之所以这么说，是因为像麦肯锡这样的咨询公司发现，在他们的研究中，使用人工智能和分析的公司可以将20%的收入归因于人工智能和分析。同样，我已经能够为几个客户提供咨询，并帮助他们找到新的收入来源以及降低成本的机会。

有一个问题。您将需要开发某种形式的数据基础架构或更新当前的数据基础架构，以确保您可以充分利用现代数据世界提供的所有好处。澄清一下，我并不是说你需要使用最豪华和最昂贵的数据工具。有时，在数据分析工具方面，我会引导客户使用更简单、最具成本效益的解决方案。

重要的决策点之一是选择合适的数据管道和连接器提供商。这些数据管道是将数据导入未来数据仓库和数据湖的原因。
许多公司都在这一点上挣扎，通常只是选择自定义代码数据管道。这并不总是一个好的选择。
它可能导致大量可以避免的技术债务和未来成本。
这就是像Airbyte这样的工具的用武之地。

什么是Airbyte？

Airbyte是一个开源数据管道平台，可替代Stitch数据和Fivetran。尽管现有的数据管道平台提供了与Stripe和Salesforce等知名来源的大量集成，但当前模型中存在一个差距，遗漏了小型服务集成。

Airbyte 通过构建和维护连接器来解决此问题，同时培养一个从彼此的自定义连接器中受益的用户社区。公司通常的做法是构建自定义连接器来支持其应用程序。Airbyte的开源模型创建了一个社区，公司可以通过构建和维护其独特的连接器来相互支持。

Airbyte 上的连接器在 Docker 容器中运行，允许独立操作。您可以轻松监视每个连接器，根据需要刷新它们，并计划更新。Airbyte 首先对新连接器进行认证，以确保它们已准备好投入生产;目前，有超过 46 种连接器可用。已经有超过250家公司从这个开源数据管道平台中受益。

为什么转向Airbyte？

公司正面临一个持续存在的问题。他们现有的 ETL（提取、转换和加载）平台通常难以维护。
大多数需要大量自定义代码，反过来也需要许多开发人员来创建一些管道。
许多公司正在构建内部连接器。问题是定制连接器的维护是有代价的。ETL专注于他们的底线，限制提供的连接器数量，即使这在使用其平台的公司的解决方案中造成了差距。
此外，现有的 ETL 具有基于数量的定价模型，如果其中一名员工意外复制大型数据库，最终可能会使公司损失数千美元。随着安全问题空前高涨，公司对ETL系统缺乏可见性，这造成了怀疑和不信任。
由于这些问题持续存在，公司正在寻找更便宜的解决方案，允许他们的公司扩展，而不必构建和维护其ETL解决方案应该涵盖的相同类型的管道。

为什么ETL要选择开源产品?

ETL 需要开源，因为它授予您直接访问更正代码错误的权限。您不必在来回支持票证上浪费时间，而是拥有编辑代码、清理数据并继续执行下一个任务所需的访问权限。

使用开源，您不再受 ETL 提供商的摆布。与其试图说服他们您需要的连接器类型值得花费时间和金钱来开发和维护它，不如完全绕过您的 ETL 提供商，并在 Airbyte 社区的帮助下继续构建所需的连接器。

Airbyte的开源模型全面提高了效率。您不必依靠客户服务团队在几个工作日内处理您的请求，而是获得了随意调试的自主权。通过自己修复任何错误，将解决问题所需的时间缩短一半以上。

Airbyte 未来？
Airbyte的目标是到今年年底提供200个连接器。开发人员可以用任何语言编写连接器，他们的图形界面非常适合那些技术不如开发人员的用户。

由于它们的连接器作为Docker镜像运行，因此它们受到包括Fargate和Kubernetes在内的众多系统的支持。此优化允许用户根据需要运行连接器，而无需担心他们所处的环境类型。

Airbyte 最近增加的内容
最近，Airbyte发布了一个连接器开发工具包（CDK），允许用户在大约两个小时内构建一个连接器。这是通过使用特定于连接器的代码实现的，这意味着用户可以享受简化的过程，将 75% 的代码从开发阶段中取出。

Airbyte正在通过其开源模型解决集成问题，并缩短连接器构建过程，同时创建一个支持性的社区，从彼此的独创性中受益。

他们的长期目标是实施开放核心战略，这意味着他们可以提供企业版。他们正在努力包括简单的登录、角色和访问管理、合规性功能以及数据质量协议。

当前用户的反馈也让他们努力创建托管版本。Airbyte的目标是成为行业的数据标准。通过发展其社区和工具，它正在顺利进行。

我应该为Airbyte聘请数据解决方案架构师吗
像Airbyte这样的工具使开发ELT变得非常容易。调度、连接器和转换消除了许多需要数据和软件工程师的繁重基础设施负担。

但是，这并不意味着您不需要数据专家。

在需要根据数据构建仪表板以及创建可靠且健壮的 SQL 查询之间，拥有强大的数据专家非常重要。

原文：https://gitee.com/report/china-open-source-2022/advanced-technology#big-data

新一代数据栈将逐步替代国内单一“数据中台”
2021 年，美国硅谷最火爆的词汇就是现代数据栈（Modern Data Stack，简称 MDS），它们是以云原生、开源为背景的一系列全新数据技术引擎。相对于传统的闭源、私有化的数据技术来讲，现代数据栈凭借其开放性及公有云的 SaaS 服务快速得到了大量企业用户的认可。

现代数据栈分为若干层次，每个层次相互支持，相互协助，形成一个有机的整体。企业使用的时候，很容易就能利用 SaaS 模式将其整合到一起解决企业数据问题。而开源模式，又给 MDS 生态加入了新的活力，快速发展社区的同时让上下游快速出现新的合作。

近几年，国内出现了大量的开源数据技术。2022 年，这些技术形成了具有上下游的有机集合体，从新一代数据源体系到数据处理体系，再到数据分析、AI 算法体系，逐步相互融合、相互支持形成有机整体。可以看到，国内新一代的数据栈在支持云原生技术基础上，还支持私有云/公有云部署，用新一代的计算引擎、算法、调度、同步机制来支持新一代的数据基础建设。

这些新一代技术栈的流行和商业工具生态的整合，将逐步替代国内单一“数据中台”服务四五个领域的局面。这变得跟美国类似——若干家各自领域的专业企业相互集成，最终给用户提供高效且灵活的专业解决方案。

同时，我也高兴看到，这些开源现代数据栈中很多的商业公司，正在美国、欧洲快速建立社区、SaaS 和相关的商业服务，也有一些公司已经和全球的开源现代技术栈公司进行竞争。整体上，来自国内的新一代的开源现代数据栈（Open-source MDS）现在刚刚兴起。我相信，国内具有大量优秀的开发者、丰富的场景和大量的数据基础，一定会有若干家卓越的开源商业公司出现，最终在全球开源现代数据栈中有一席之地！

一、Airbyte是做什么的？

简单来讲，airbyte是做数据集成和连接的。将应用程序、API和数据库中的数据同步到数据仓库、数据湖和其他目的地

支持200个Source类型连接器，100 个Destination类型的连接器

2021年，9000多家公司使用Airbyte从PostgreSQL、Oracle、MySQL、Facebook广告、Salesforce、Stripe等来源同步数据，并连接到Redshift、Snowflake、Databricks和BigQuery等目的地

社区：拥有4500名数据从业者和200名贡献者

预计到2022年底将有500个高质量连接器且涵盖更多类型的数据移动，包括反向ETL和流式接收

Airbyte解决了什么问题？
第一：公司总是必须自己构建和维护数据连接器，因为大多数不太流行的“长尾”数据连接器不受封闭源ELT技术的支持。

第二：数据团队通常必须围绕预建连接器进行定制工作，以使其在其独特的数据基础架构中工作。

二、整体架构
Airbyte一些核心概念
Airbyte Connector——连接器

在Airbyte的概念中，connector或者是收集从数据源推送过来的数据，或者去跟数据源发送请求去抓取数据。

Airbyte规定每个connector都放在一个完整的docker镜像中

Airbyte的connector的类型如下图：

三、流程演示
配置同步作业
1、从Airbyte支持的“Sources”中选择想要连接的数据源，并配置相应信息

2、从Airbyte支持的“Destinations”中选择数据

3、刷新数据源schema

4、数据同步

5、结果展示

6、10w数据同步测试

数据生态是基础架构生态的最重要一环，数据的处理分发与计算，从始至终贯穿了整个数据流通生态。自从数据集中在数据仓库和数据湖中，数据集成已经发生了翻天覆地的变化，我们现在通常称其为现代数据技术栈。但今天的现代，也可能成为明天的过时。

如今，数据治理愈发重要，我们常常发现 80% 的数据业务，其实是靠 20% 的数据在支撑；同样，80% 的数据质量问题，其实是由那 20% 的系统和人产生的。Gartner 曾预计，到 2025 年，80% 寻求扩展数字业务的组织将失败。因为他们没有采用现代方法来进行数据和分析治理。

这其中的数据集成问题引人关注，就不得不提到现代数据技术栈底部的 E (数据抽取 Extract) T (数据转换 Transform) L (数据加载 Load) 和反 ELT 问题。行业预计，未来企业仍会增加他们必须构建和维护的内部连接器数量。
ELT：不只是变换顺序

要聊 ELT，我们还是需要先从传统的 ETL 讲起。从传统而言，当我们开始构建数据仓库时，都要先去了解业务流程，明晰业务是如何运转的，数据是如何留痕的。通过收集用户的相关需求，从而去规划设计报表。企业需要进行数仓分域、分层、逻辑建模等一系列操作，完成这些后才会去数据仓库中建表。

在这之后，企业就需要进行 ETL 操作了，由于多数数仓仅接受 SQL 的关系数据结构，因此，企业需要将不符合要求的数据转换为基于 SQL 的数据。这种方式在有限内存和处理能力的本地数据库中普遍存在。我们不难发现 ETL 的问题，主要是流程长和笨重。如果企业业务或者底层数据频繁变化，ETL 流程就要随之调整，这不仅浪费时间，而且也受制于吞吐量，成本极高。

因此，ELT 应运而生。工程师发现 ETL 复杂的地方主要是在 T 和 L 的强耦合，所以 ELT 的核心思想就是解耦。与 ETL 不同，ELT 不需要在加载过程之前进行数据转换。ELT 将原始数据直接加载到数仓中。使用 ELT 数据管道，数据清理、丰富和数据转换等过程都在数仓内完成。原始数据无限期地存储在数仓中，允许进行多次转换。

来源：作者绘图
使用 ELT 的优势是突破性能瓶颈、程序简化、组件替换、维护成本降低等。尤其是解耦后可以适应业务的敏捷变化，灵活性和效率均大幅提升。

产品：专注 & 拥抱开源生态
Airbyte 最主要的产品还是 Extract 数据抽取和 Load 数据加载产品。简单来说，就是利用连接器 (Connector) 连通多平台间的数据，其逻辑是平台连接的数据源越多，平台越稳定，而平台就会拥有壁垒。

来源：Airbyte 网站截图
其次，Airbyte 也提供 Transform (数据转换) 产品，实际上 Transform 数据转换产品 Airbyte 也是集成了 Dbt 这样一个开源工具 (Dbt Labs 也是估值 42 亿美金的独角兽)，用户使用 SQL 语句就可以进行数据转换，在这里我们也不难发现美国 Infra 基础架构领域的良好生态，大家专注在自己的领域，通过生态互相集成，而不是做大而全的产品。

最后，是 Embed 报表插件类型的产品，主要解决 BI 工具和前端页面重复建设问题。公司将数据迁移到云上后，定制化报表需求会需要搭建数仓和 BI 工具。通过 Airbyte Embed 产品，其将此过程变简单化，数据上云数仓后，自动产生分析报告，节省了时间。

来源：Airbyte 网站截图
机遇：云数仓发展 & 数据量爆发

说了这么多 ETL 和 ELT，那么 Airbyte 这家专注于 ELT 赛道的新兴创业独角兽崛起的机遇是什么呢？我想一切还得从云开始聊。

随着云计算的兴起，数据仓库云化进程加速。它的按需取用、弹性扩容等特性也深深地影响了整个基础软件行业的变革。行业初期，很多所谓的“云数仓”只是将物理硬件环境直接打包上云，存算没有分离，弹性扩展也无法实现，这种 “上云”并没有进行针对云环境特点的优化。

行业的转变来自 2014 年，Snowflake 的云原生数仓横空出世，它通过多集群共享数据存储和计算分离架构开始深度融合云平台。传统企业基于本地部署的资源，计算、存储以及网络带宽等都相对昂贵且受限。所以将 T 环节放在 E 和 L 中间是可以理解的，毕竟我们需要平衡硬件成本和计算效率。

但 Snowflake 这种云原生数仓的出现，带来了企业计算和存储成本的持续下降，这意味着企业可以在数仓中直接存储未经转换的数据。事实上，也确实有越来越多的数据被存储在了云端，这为 ELT 的兴起提供了土壤。

来源：IDC 报告
另一方面，我们不得不谈及企业数据量的爆发。数据已经成为现代企业成功的必备要素。越来越多的企业需要数据的聚合，无论是结构化、非结构化抑或半结构化数据，他们都希望以统一的平台接口来收集和处理。也正是因为这些数据资源的增长，推动了企业的数字化进程，他们需要更灵活和敏捷的方式来处理数据，显然，传统的 ETL 并不能满足这些需求。

来源：IDC 报告
开源：构建竞争壁垒

Airbyte 的商业模式是比较典型的开源商业模式，分为免费版、云版本和企业版。

开源版本可用作自助服务、免费解决方案。它可以访问无限连接器、复制、监控和通过社区为用户提供支持。云版本除了提供开源的所有功能之外，还提供其平台的云托管服务，并按积分收费。其信用消耗与基础设施计算时间相关。它带有云数据托管、数据管理、多个工作区等。

云版本提供 14 天的免费试用期，之后按每个积分 2.50 美元的价格按月收费。

企业版是针对处理大数据量需求的用户，依据客户用例收费。Airbyte 不对失败的客户用例收费。Airbyte 希望通过开源模式和付费贡献者计划，解决行业对长尾连接器的需求。从这方面来看，闭源产品大多是无法满足的。此外，他们还希望通过开源加快业界使用他们的连接器，从而提高产品可靠性。

事实上，开源完善了 Airbyte 的商业飞轮，加速了它的产品完善，提供了更好的竞争优势。它让活跃的贡献者社区参与发布他们自己的数据连接器以造福所有人，这是他们连接器快速增长的重要原因之一。

在产品层面，开源模式帮助了连接器保持高水平的可靠性。Airbyte 通过激励机制，鼓励开源贡献者维护他们贡献的连接器。个人和公司也可以像手机应用商店一样在其中发布他们的连接器。此外，开源工具负责以安全、快速和可靠的方式移动数据，维护者只需要简单配置数据连接器即可。

开源模式看起来也得到了资本的认可。Airbyte 在 2021 年 12 月的 B 轮融资时，ARR 收入不足 100 万美元，但得到了 15 亿美金的估值。目前，根据 Airbyte 自己官网的披露，其每月同步 600 TB+数据，已经有 25,000+ 公司使用了它们，并且拥有 10K+的社区成员。我们有理由持续关注和期待未来 Airbyte 公布的相关财务信息，以追踪其商业化进程。

未来：马太效应，赢者通吃
一个数据集成平台能更快地链接来自不同来源的数据，构建更多的连接器，其将获得行业壁垒，这个市场很可能会具有马太效应，赢者通吃的特点。与此同时，Airbyte 也并不寂寞，数据集成市场仍在有新老玩家涌入。

我们看到了老玩家，比如：成立于 2012 年的业界最早的 ETL 工具提供商 Fivetran (56 亿美金估值的独角兽企业，目前已转向 ELT 领域)，也在致力于为广泛使用的平台和数据源构建连接器。其优势在于，它是最成熟的数据集成平台之一，受到世界上一些大公司的信任；而缺点在于定价较高，对长尾数据连接器的支持也有限，内部开发的可能性很小。当然，它是闭源模式。

我们也看到了新玩家，比如：2021 年从 GitLab 剥离出来的 Meltano，它也是以开源模式运作。但与 Airbyte 不同，它集成了 Singer 协议，并且暂时没有提供无代码或低代码选项，更适合技术水平相对较高的数据工程团队。

总览

本教程将介绍如何浏览 Airbyte Workspace 文件夹。

如果您需要浏览在 docker 卷上Airbyte server 和 workers 存储的额外数据，可以参考本教程，它们可能无法通过 web 界面访问。

浏览日志

当您在 Airbyte 中运行 Sync Job 时，您可以通过 web 查看日志，如下所示。

识别 Workspace ID

在下面的屏幕截图中，您可以注意到突出显示的蓝色框显示用于此Sync Job的选定"尝试"的 ID 号。

在这种情况下，Job在/tmp/workspace/4/2/文件夹中运行，您可以看到当前选择了第三次尝试的选项卡（第一次尝试是/tmp/workspace/4/0/）。

右侧红色圆圈中突出显示的按钮将允许您下载 log 文件。
然而，实际上在同一个工作区文件夹中记录了很多文件。因此，我们可能希望更深入地查看这些文件夹，并更好地了解 Airbyte 正在运行的内容。

理解 Docker run 命令

我们把日志再向下滚动一点，我们可以看到一些以 docker run 开头的命令，像下面这样：

docker run --rm -i -v airbyte_workspace:/data -v /tmp/airbyte_local:/local -w /data/2/2 --network host ...

从这里，我们可以看到 Airbyte 调用-v选项将名为 airbyte_workspace 的 docker 卷挂载到容器的 /data 目录。

参考 Docker 卷的文档, 我们可以检查和操作这些卷中的持久化数据。

通过UNIX Shell 浏览 docker 卷的内容

例如，我们可以创建一个容器，然后将卷挂载到我们新建的容器，进入容器我们就可以看见卷的内容, 这里我们是用 busybox 镜像。

docker run -it --rm --volume airbyte_workspace:/data busybox

上一步我们将进入到是 sh 的shell环境中，它由我们刚创建的容器提供。通过它我们就可以浏览卷里面的数据，上一步我们将卷挂载到了 /data 目录，接下来我们再就可以在这个目录浏览到数据了。例如，我们执行下列命令

ls /data/9/2/

示例输出：

catalog.json                  normalize                     tap_config.json
logs.log                      singer_rendered_catalog.json  target_config.json

通过本地 shell 浏览 docker 卷的内容

或者，如果您不想转换到 docker 镜像内的 shell ，您也可以通过 docker 来代理执行命令，将结果输出到当前 shell 环境，例如：

docker run -it --rm --volume airbyte_workspace:/data busybox ls /data/9/2

示例输出：

catalog.json                 singer_rendered_catalog.json
logs.log                     tap_config.json
normalize                    target_config.json

读取 Catalog.json

例如，我们经常会需要读取 catalog 的内容。这种情况下我们可以像上面的例子一样，将数据挂载到容器，然后使用cat命令查看。

docker run -it --rm --volume airbyte_workspace:/data busybox cat /data/9/2/catalog.json

示例输出：

{"streams":[{"stream":{"name":"exchange_rate","json_schema":{"type":"object","properties":{"CHF":{"type":"number"},"HRK":{"type":"number"},"date":{"type":"string"},"MXN":{"type":"number"},"ZAR":{"type":"number"},"INR":{"type":"number"},"CNY":{"type":"number"},"THB":{"type":"number"},"AUD":{"type":"number"},"ILS":{"type":"number"},"KRW":{"type":"number"},"JPY":{"type":"number"},"PLN":{"type":"number"},"GBP":{"type":"number"},"IDR":{"type":"number"},"HUF":{"type":"number"},"PHP":{"type":"number"},"TRY":{"type":"number"},"RUB":{"type":"number"},"HKD":{"type":"number"},"ISK":{"type":"number"},"EUR":{"type":"number"},"DKK":{"type":"number"},"CAD":{"type":"number"},"MYR":{"type":"number"},"USD":{"type":"number"},"BGN":{"type":"number"},"NOK":{"type":"number"},"RON":{"type":"number"},"SGD":{"type":"number"},"CZK":{"type":"number"},"SEK":{"type":"number"},"NZD":{"type":"number"},"BRL":{"type":"number"}}},"supported_sync_modes":["full_refresh"],"default_cursor_field":[]},"sync_mode":"full_refresh","cursor_field":[]}]}

从 docker 卷导出catalog

如果您想将 catalog 从 docker 卷中到出来，您可以再您的主机上执行下列命令：

docker cp airbyte-server:/tmp/workspace/9/2/catalog.json .
cat catalog.json

在K8S环境浏览数据文件

如果您的 Airbyte 运行在 k8s 上, 使用以下命令来浏览文件并将其复制到本地。
选择一个您感兴趣的 pod 替换 podname，将 namespace 替换为您 airbyte 运行的 namespace。

#替换podname 和 namespace
kubectl exec -it <pod name> -n <namespace> -c main bash
#例子
kubectl exec -it destination-bigquery-worker-3607-0-chlle  -n jobs  -c main bash
root@destination-bigquery-worker-3607-0-chlle:/config# ls
FINISHED_UPLOADING  destination_catalog.json  destination_config.json

想将pod内的文件复制到本地，可以执行下列命令:

#替换podname 和 namespace
kubectl cp <namespace>/<pod-name>:/config/destination_catalog.json ./catalog.json
#例子
kubectl cp jobs/normalization-worker-3605-0-sxtox:/config/destination_catalog.json ./catalog.json
cat ./catalog.json

使用 CSV 或者 JSON 作为目标的：检查本地数据目录

如果您使用 CSV 或者 JSON 作为连接（管道）的目录，Airbyte 会将包含数据的结果文件写入容器的特殊目录/local/中。默认情况下，这个卷会挂载到宿主机的 /tmp/airbyte_local。因此，您可以到到您部署 Airbyte 宿主机的/tmp/airbyte_local目录，浏览产看对应文件。

::: 警告
请确保 Docker Desktop 可以访问/tmp目录（如果使用mac系统，还需要确保docker desktop对 /private 目录具有权限，因为 /tmp 有一个指向 /private 的符号链接，否则它将无法工作）。
:::

或者，您也可以通过 docker 进行查看:

#!/usr/bin/env bash

echo "In the container:"

docker run -it --rm -v /tmp/airbyte_local:/local busybox find /local

echo ""
echo "On the host:"

find /tmp/airbyte_local

示例输出:

In the container:
/local
/local/data
/local/data/exchange_rate_raw.csv

On the host:
/tmp/airbyte_local
/tmp/airbyte_local/data
/tmp/airbyte_local/data/exchange_rate_raw.csv

概述

就像前面介绍 Workers & Jobs, 一共具有四种不同类型的job.

尽管我们可以为所有四种类型的job配置资源，但是我们还是重点关注你Sync job，因为它是最常运行的作业。
有三种不同的方法可以让我们给连接器配置Sync Job的资源需求：

• Instance-wide - 应用到Sync Job的所有容器上。
• Connector-specific - 应用到Sync Job的所有指定类型连接器的容器上
• Connection-specific - 应用到Sync Job的所有指定连接（管道）的容器上

一般来说，要求的范围越窄，优先级越高。

按优先级递减顺序：

• Connection-specific - 最高优先级。覆盖所有其他配置。我们建议根据具体情况使用它。
• Connector-specific - 第二高的优先级。覆盖实例范围的配置。主要供 Airbyte 内部使用。我们建议远离这个。
• Instance-wide - 最低优先级。被所有其他配置覆盖。旨在成为默认设置。我们建议将其设置为基准。

配置 Instance-Wide 资源限制

Instance-wide 资源限制是最简单的资源限制配置。所有的配置都只需要修改以下环境变量：

• JOB_MAIN_CONTAINER_CPU_REQUEST - 定义job容器的最低 CPU 数量。单位遵循 Docker 或 Kubernetes，具体取决于部署。默认为空。
• JOB_MAIN_CONTAINER_CPU_LIMIT - 定义job容器的最大 CPU 数量。单位遵循 Docker 或 Kubernetes，具体取决于部署。默认为空。
• JOB_MAIN_CONTAINER_MEMORY_REQUEST - 定义job容器的最小 RAM 使用量。单位遵循 Docker 或 Kubernetes，具体取决于部署。默认为空。
• JOB_MAIN_CONTAINER_MEMORY_LIMIT - 定义job容器的最大 RAM 使用量。单位遵循 Docker 或 Kubernetes，具体取决于部署。默认为空。

配置 Connector-Specific 资源限制

连接到 Airbyte 工作数据库并且执行以下 query（注意需要将 image-name 替换为你想要配置资源限制的连接器类型 ）

select * from actor_definition where actor_definition.docker_repository like '%<image-name>';

替换 id-from-step-1 为上一步查询中获取到id，然后替换资源限制的值为想要限制的值，然后执行query

update actor_definition set resource_requirements = '{"jobSpecific": [{"jobType": "sync", "resourceRequirements": {"cpu_limit": "0.5", "cpu_request": "0.5", "memory_limit": "500Mi", "memory_request": "500Mi"}}]}' where id = '<id-from-step-1>';

配置 Connection-Specific 资源限制

登录到 Airbyte Web 中，点击对应连接（管道）并从 url 中提取连接（管道） ID。

• url的格式是http://<airbyte-server-ip:port>/workspace/<workspace-di>/connections/<connection-id>/status。如果您连接（管道）的url是http://localhost:8000/workspaces/92ad8c0e-d204-4bb4-9c9e-30fe25614eee/connections/5432b428-b04a-4562-a12b-21c7b9e8b63a/status,那么连接(管道) id 就是5432b428-b04a-4562-a12b-21c7b9e8b63a`

连接到 Airbyte 工作数据库并且执行以下 query（注意需要将 id-from-step-1 替换您上一步获取的连接（管道）id，并将资源限制修改给您想要限制的值）

update connection set resource_requirements = '{"cpu_limit": "0.5", "cpu_request": "0.5", "memory_limit": "500Mi", "memory_request": "500Mi"}' where id = '<id-from-step-1>';

Debugging Connection 资源限制

Airbyte 在创建容器时将资源需求记录为job log的一部分。源容器和目标容器的资源配置记录都将被log记录。

如果 job 容器的内存不足，只需登录到 Airbyte Web 中的 job 页面，检查日志查看 job 的资源配置是否符合预期，如果确实给的资源不足，可以根据上面的步骤修改资源限制配置。

Docker部署环境，日志显示示例:

Creating docker container = destination-e2e-test-write-39-0-vnqtl with resources io.airbyte.config.ResourceRequirements@1d86d7c9[cpuRequest=<null>,cpuLimit=<null>,memoryRequest=200Mi,memoryLimit=200Mi]

K8S部署环境，日志显示示例:

2022-08-12 01:22:20 INFO i.a.w.p.KubeProcessFactory(create):100 - Attempting to start pod = source-intercom-check-480195-0-abvnr for airbyte/source-intercom:0.1.24 with resources io.airbyte.config.ResourceRequirements@11cc9fb9[cpuRequest=2,cpuLimit=2,memoryRequest=200Mi,memoryLimit=200Mi]

配置 Airbyte 数据库

Airbyte 使用不同的对象来存储内部状态和元数据。数据是由各种 Airbyte 组件存储和操作，但您可以通过以下两种方式管理数据库的部署

• 使用默认的 postgres 数据库，它已经写到 docker-compose.yml 中，即 docker-compose.yml 中的 airbyte/db 服务。
• 使用单独的 postgres 实例（这种情况下 airbyte/db 就不再被使用，您可以将它从您的 docker-compose.yml 中移除。）。将数据库部署到 docker 和 k8s 中不是一种很好的实践。使用专门的数据库实例将让您的 airbyte 环境有更高的可靠性。此外，使用云托管的Postgres实例（如AWS的RDS，GCP的Cloud SQL），您将得到更细粒度的备份和实例大小调整。例如，一开始业务量不大，我们可以选择一个相对小的实例，后续我们根据数据量的增长情况，进行弹性的扩容或者缩容。

Airbyte 中的各种实体保存在两个内部数据库中：

• Job database
  • 里面存放有关 Airbyte 作业执行和各种运行时元数据的数据。
  • 里面存放有关 Airbyte、Temporal.io 使用的内部编排器的数据（任务、工作流数据、事件和可见性数据）。
• Config database
  • 里面存放连接器、同步的连接和各种 Airbyte 配置对象。

请注意，来自源（或目标）连接器的实际数据不会传输或保留在此内部数据库中。

如果您需要操作这些数据库，例如进行备份或执行一些清理维护，您还可以通过 API 或 UI （在管理页面的配置选项卡中）进行。

连接外部的 Postgres 数据库

让我们来看看使用不由 Airbyte 管理的 Postgres 实例需要什么。首先，在本教程中我们将使用以下命令通过 docker 创建的独立的 Postgres 环境。如果您已经存在其他的 Postgresql 实例，你可以不执行此操作。

docker run --rm --name airbyte-postgres -e POSTGRES_PASSWORD=password -p 3000:5432 -d postgres

为了让 Airbyte 使用我们刚才创建的数据库实例，我们需要修改airbyte的环境变量（docker 方式部署的环境变量配置文件通常为airbyte安装目录下.env）。我们需要修改一下环境变量。

#外部数据库的用户名
DATABASE_USER=postgres
#外部数据库的密码
DATABASE_PASSWORD=password
#外部数据库的 ip 或者域名
DATABASE_HOST=host.docker.internal 
#外部数据库的端口
DATABASE_PORT=3000
#外部数据库的 db 名称
DATABASE_DB=postgres

默认情况下，Config Database 和 Job Database 根据上述设置使用相同的数据库实例。但是，可以通过指定单独的参数将前者与后者分开。例如：

CONFIG_DATABASE_USER=airbyte_config_db_user
CONFIG_DATABASE_PASSWORD=password

此外，您必须重新构造DATABASE_URL环境的 JDBC URL，让它包含正确的主机、端口和数据库。如果您需要向 JDBC 驱动程序提供额外的参数（例如， SSL），您也应该在此处添加它：

DATABASE_URL=jdbc:postgresql://host.docker.internal:3000/postgres?ssl=true&sslmode=require

如果要将Config database 和 Job database 分开，则同样需要重新构造JDBC URL：

CONFIG_DATABASE_URL=jdbc:postgresql://<host>:<port>/<database>?<extra-parameters>

初始化数据库

注意：当前步骤只用于当用户使用自己的数据库实例的情况。

如果您提供了一个空的数据库实例给 Airbyte 并且是首次启动 Airbyte，Airbyte 会自动进行初始化。 请确保：

• 连接库已经在Postgres中创建好
• 连接用户同时具有读写权限
• 连接库是一个空库
  如果连接库不是一个空库，并且拥有一个和 Airbyte 自身创建表的表名相同的表，Airbyte 会认定当且数据库已经完成了初始化，就不会再初始化创建表了，导致Airbyte 运行失败。当出现这种问题的时候，您只需清除到当前数据库中的所有表，然后重新拉起 Airbyte 即可。

访问Airbyte的默认工作库即airbyte/db

使用默认数据库的情况下（即使用docker-compose.yml中的airbyte/db），如果开发人员想要访问airbyte工作库，可以按照以下说明进行操作
如其他的说明所示，所有的数据库账号密码配置都在airbyte部署目录下的.env文件内。默认情况下，这些配置有：

#数据库的用户名
DATABASE_USER=docker
#数据库的密码
DATABASE_PASSWORD=docker
#数据库的库名
DATABASE_DB=airbyte

查到配置后，您可以执行以下命令接入到airbyte工作库中。

#如果您修改了.env文件中数据库相关的配置，请把用户名，库名，和密码修改成您修改后的值
docker exec -ti airbyte-db psql -U docker -d airbyte

在Airbyte库中，您将看到以下表：

• workspace : 包含名称、通知配置等工作空间信息。
• actor_definition : 包含源和目标连接器定义。
• actor : 包含源和目标连接器信息。
• actor_oauth_parameter : 包含源和目标 oauth 参数。
• operation : 包含 dbt 和自定义规范化操作。
• connection : 包含目录详细信息、源、目标等连接配置。
• connection_operation : 包含为给定连接配置的操作。
• state : 包含连接的最后保存状态。