共计 2837 个字符，预计需要花费 8 分钟才能阅读完成。
我是韩山峰，来自金红叶纸业团体。明天，我将向大家介绍 Apache SeaTunnel 在咱们金红叶纸业团体中的利用场景，包含咱们为何抉择 Apache SeaTunnel , 以及咱们如何基于其晋升咱们外部的数据开发效率。
文|韩山峰
编辑整理| 曾辉
讲师介绍
韩山峰
金红叶纸业 数据分析师
01 产品抉择历程
在我刚退出金红叶的时候，所有数据都在 Oracle 数据库中。在那时，咱们用的是 Oracle 视图来做数仓。
如果一个视图不能满足需要，咱们就会创立另一个视图，如果两个视图还不能满足需要，咱们就会再套一个视图。但随着工夫的推移，这种形式的效率问题开始浮现，于是咱们开始寻找新的计划。
第一个工作是钻研 Oracle 和 Clickhouse 之间的数据同步。这一阶段，咱们的指标很简略，即间接将零碎表数据推送到 Clickhouse，而后由 Clickhouse 间接做前端利用。当解决了 Oracle 到 Clickhouse 的数据同步问题后，咱们开始进入第二个阶段。
第二阶段，咱们开始解决 SAP 的数据。作为一个传统企业，咱们的制作、营销及供应链生产，都依赖于 ERP 零碎，特地是 SAP，这也给咱们带来了数据输入的挑战。咱们抉择了应用 SAP 的 RFC 接口进行数据输入，并且很偶合的是咱们在第一阶段应用的工具 Kettle 也反对这种形式。
第三阶段，咱们布局应用 Hive 来建设咱们的数仓。然而，因为 Kettle 自身存在的问题和限度，咱们开始寻找新的工具，可能将咱们的 Oracle 数据库和 SAP 接口的数据导入到 Hive，并在数仓中进行模型解决和数据荡涤。
第四阶段，咱们开始摸索如何将荡涤过的 Hiv e 数据推送到 Clickhouse，因为咱们的 BI、报表以及可视化利用，更多的是依赖于 Clickhouse。咱们在这一阶段探讨了如何买通整个数据生态的问题。
在这个过程中，咱们评估了多种解决方案，包含商业解决方案和开源的 Apache SeaTunnel，我还记得刚接触 Apache SeaTunnel 时，过后它的名字叫“Waterdrop”。
咱们具体浏览了它在 GitHub 上 的文档，进行了深刻的代码剖析，并最终决定基于 Apache SeaTunnel 来搭建咱们的数据集成工具。
在定好工具之后，咱们开始面临新的挑战。企业外部除了规范的业务零碎外，咱们还购买了一些 SaaS 服务。很多 SaaS 服务只给你一个客户端或者一个 Web 账号密码，获取想要的数据会有一些艰难。
这就引出了咱们的第五阶段，即如何将所有的数据通过一个工具集成到咱们的平台中，而后通过咱们的 Clickhouse 对外提供服务。这个过程对咱们来说是艰巨的，但咱们最终实现了指标，晋升了咱们的数据开发效率。
咱们经验了五个阶段来抉择并施行适合的数据产品。通过对不同产品的比拟，从 Kettle 进行迭代降级到 SeaTunnel。
咱们列举了几个要害的步骤：
首先，咱们解决的是传统的离线数据接入。其次，咱们实现了通过 RFC 接口进行数据接入，这一步 Apache SeaTunnel 在原生状态下只局部反对。为了残缺反对这一性能，咱们钻研了 SAP 文档和 Apache SeaTunnel 的源代码，对其进行了开发和优化。
在这个过程中，SeaTunnel 为咱们技术团队提供了具体的文档，包含中英文版本。当咱们遇到问题时，咱们能够通过提交 Github 申请或 Slack、Apache SeaTunnel 的社区群来寻求解决。过程中配置文件和文档对于开发者来说绝对容易了解，这也是咱们抉择 Apache SeaTunnel 的起因之一！
02 产品利用场景
在数据接入方面，咱们次要有以下几个利用场景：
离线数据接入：这是咱们最次要的利用场景，咱们将各个业务零碎的数据库和不同的库表通过 Apache SeaTunnel 同步到咱们的 Hive 中，而后在 Hive 外部解决业务逻辑，再将解决后的数据输入到咱们的 Clickhouse 中，最初通过前端的 BI 或报表工具对数据进行展现。
RFC 数据接入：这是咱们的另一个次要利用场景。在这个过程中。咱们应用 SAP 的 RFC 接口进行数据接入，该接口是 SAP 提供的规范对外接口之一，同时提供 Java 和 Python 的实现。
第三方数据接入：尽管这种场景在咱们的利用中比重较小，咱们会通过 HTTP 协定或 Kafka 协定接入这些数据，而后进行外部的数据分析。
03 开发效率晋升
接下来跟大家介绍一下，咱们团队在开发效率方面的晋升，这么说吧！它基本上把咱们算是彻底地变成了这种“复制粘贴”工程师了，所有的主题，都采纳这种标准化的目录构造、标准化的模板去建造，而后散发分工解决；就是齐全变成一个流水线的一个工作。
而后第二个就是说在“流水线”的过程中，咱们有很多这种固定化的一些货色，也是一方面是外部的一个规范性的束缚，一方面就是说咱们也从开源的里边学了一些，学习到一些货色，而后把它用在咱们这边。
当咱们的团队第一次接触开源时，咱们的态度次要是借鉴和利用。然而咱们发现 SeaTunnel 这个活跃度高文档齐全的我的项目，咱们就拿来应用。
在应用过程中，咱们发现它的确可能解决咱们公司外部，包含咱们的数据团队外部的一些问题。在应用过程中，咱们也发现了一些问题，这促使咱们提出了 PR 并尝试反馈一些正向的倡议。这种反馈其实也帮忙了咱们，所以咱们也想始终在做一些对于社区来说是踊跃的反馈。
咱们在 2021 年时应用的是 1.0 的版本，2.0 的版本过后还没进去。咱们在应用 1.0 的版本时，遇到了很多问题，到了 2.0 时代，反对的协定真的很多，有一些是咱们十分须要的，比方 HTTP 这种协定。在咱们外部的测试之后，咱们发现这的确能极大地加重咱们的开发工夫。
04 产品升级迭代
在咱们刚开始的那个架构图中，咱们实际上应用的是 Azkaban，这是因为过后咱们没有太多的工夫去测试不同的产品，所以咱们抉择了最简略的 Azkaban 来做咱们整个集群的资源调度工具。
但它也存在一些问题，比方它不能很好地治理我的各种脚本。
随着咱们接入的主题越来越多，相干主题的依赖也变得越来越多。原来可能只有一两个主题相互之间能够解决，当初咱们须要十分小心地调整各个依赖之间的调度工夫。有的时候，可能忽然呈现数据量大的工作须要消耗一两个小时，那么接下来的工作可能就会执行失败。咱们须要十分小心地解决各个依赖的调度。
而后，咱们接触到了 Apache DolphinScheduler 这个工具，它基本上可能很好地解决咱们的调度依赖问题和资源管理问题，咱们的后续打算就是应用 DolphinScheduler 这个工具去代替以后的 Azkaban。
最初，我想分享一本我最近浏览关于软件行业书籍中的一段话，它让我有很深的感触。这本书形容的是 1960 年代，那个时候还是真空管的年代，芯片还在初始阶段。
书中有一段话我感觉十分粗浅，它说：芯片越简略，它所提供的可靠性和电力节俭水平就越好。我感觉这也实用于咱们的软件程序。如果咱们的程序对用户来说足够简略，它的可靠性和它提供的性能就会越弱小。
本文由 白鲸开源科技 提供公布反对！
