-
Notifications
You must be signed in to change notification settings - Fork 102
01.概述
scaleph ['skəlef] 是一个开放的数据平台项目，以 flink 作为底层计算引擎，提供 admin 后台，加速开发者和企业能够快速地进行数据集成，数据开发，完成数据应用的开发。
在现代企业越来越重视企业内部数据整合，梳理数据资产，打造数据中台的潮流下，很多企业在招聘人员的时候，会问出这样的一个问题：给你一个团队，你能多久搭建出数据中台？
数据中台是个很大的主题，包含了底层的大数据引擎，如计算引擎，存储引擎和查询引擎，数仓开发，对外的数据服务如报表、BI、数据应用。
scaleph 定位在计算侧，使用 flink 作为唯一的计算引擎，提供 admin 后台，打通数据集成、数据开发。
- 释放 flink 潜力
- 数据集成
- 流批一体的数据开发
- 拖拉拽式 DAG 支持。调度系统
- 云时代的数据平台。容器和 kubernetes 深度集成
作为国内早期的 flink 用户，阿里巴巴搜索团队积累了大量的使用 flink 打造搜索 dump 平台的经验：
使用 flink 实现数据同步方面有如下优势：
- 天然的分布式支持。flink 支持多种部署和运行方式，即可以单机运行，也可以部署在 YARN、Kubernetes 上进行动态资源调度。
- 低延迟，海量吞吐。flink 在众多大厂的应用早已证明了自身性能的强大。
- 监控指标丰富。flink 提供了完善的 metrics 功能。
- 生态支持。flink 提供了众多开箱即用的 connector，支持 csv、avro 等数据格式，kafka、pulsar 等消息系统，以及众多的存储系统，和大数据生态紧密结合。
- 任务运维支持。基于分布式轻量异步快照机制实现的 Exactly-once 语义，可以为任务的失败，重启，迁移，升级等提供数据一致性保障。
scaleph 尝试统一底层计算引擎，为企业和开发者带来底层技术一致的技术体验：
- 数据同步产品众多，仅 apache 社区已有的顶级项目就有 nifi、hop、gobblin，比如老牌的 datax，新进的 airbyte。flink 社区生态活跃，除了 flink 项目外，还有 Stateful Functions、ML、Table Store，scaleph 期望在数据集成这一环能够同样以 flink 实现，扩展 flink 生态版图。
- 更容易融入现有生态。flink 的成功吸引了众多的开发者和企业引入，使用 flink 实现数据同步可以和企业现有基础设施无缝衔接。
- 企业和开发者能够专注于 flink 相关技术，更容易达成相互匹配。
scaleph 云原生尝试：
- 容器化的本地开发体验
- 容器化的运行环境
- kubernetes 集成
scaleph 数据同步 connector 功能：
- seatunnel on flink。seatunnel 在 flink 和 spark 之上构建了高性能、分布式、海量数据集成平台，scaleph 为 seatunnel on flink 提供 web 拖拉拽式的使用方式。
- native flink connector。flink 官方仓库以及其他开源软件提供的 flink connector 大部分是面向 ETL 任务开发，在数据同步场景使用需进行一定的适配改造。但是受限于 connector 本身实现，适配改造后的效果并不一定好。例如 flink-connector-jdbc 在读取 JDBC 数据时以批量的形式，基于 flink-connector-jdbc 实现的数据同步功能也会以离线批量为主，难以支持增量同步。因为在读取数据时天然不支持 cdc 技术，基于时间戳的数据同步也需要做额外的工作 。flink-cdc-connector 则是直接面向数据同步的 connector 实现，可以为用户提供开箱即用的数据同步体验。flink-cdc-connector 在基于 flink 做数据同步方面开创了一个很好的方向：ETL 的 connector 和数据同步的 connector，存在难以统一的情况下，需要根据数据同步的特性提供 native flink 数据同步 connector。
- schema registry。面向 ETL 的 connector 和数据同步 connector 的区别之一就是 schema。用户在开发 ETL 任务时，无论是 jar 包或者 sql + udf 形式的任务，都需要在任务中提供数据的 schema。而数据同步场景也需要提供对应数据的 schema，但是任务中以 bean 类型、sql 字段定义形式的 schema 在数据同步场景中则需要以另一种方式提供。数据的 schema 发生变更是常态，ETL 任务同样会遇到这个问题，schema registry 在为 ETL 任务提供数据 schema 管理的时候，也应该能够在数据同步领域提供 schema 管理。
- 源于兴趣，欲望驱动。
- 小步快跑，持续迭代。
- 保持专注，学会克制。
scaleph 项目源于个人兴趣，最初的目的只是想突破职场限制，拓宽个人职业道路，后期则以高昂的欲望持续驱动开发者投入时间和精力。罗老师说过：低级的欲望是放纵，高级的欲望是自律，顶级的欲望是煎熬。
罗马不是一天建成的，scaleph 项目在开始之初只是在为 seatunnel 提供 admin 后台。当我们实现了 flinkful 库，要为 flink 集群和任务管理功能打通 scaleph 与 flink 的隔阂时，我们发现除了 seatunnel on flink 任务提交，还可以做 flink 通用的 jar 包和 sql +udf 任务的提交。
当我们实现 seatunnel on flink 任务的页面拖拉拽任务任务创建时，我们也为更复杂的 ETL 任务依赖打好了基础。
当我们在使用 docker 来统一开发环境的时候，我们也把 scaleph-api 和 scaleph-ui 制成了镜像，通过 docker compose 实现了项目一键启动和部署，而在不久的将来，在 Kubernetes 上部署的 helm charts 也会面世。
在 scaleph 项目发展过程中，我们不会走蓝图规划的道路，而是选择逐步迭代。
蓝图规划和持续迭代的方向抉择不是一个选择问题，而是一个能力问题。
当确定了项目目标，开始进行功能拆解，设计路线图，区分技术难点和常规工作，而后按部就班地把蓝图翻译为现实。这个过程中的每一步都是考验参与人员的能力，前一步的结果要作为后一步地起点，为后面的项目功能实现打好基础，最总实现从 A -> A+ -> AA -> AA+ ->...... -> AAAAA 的迭代路线。
而选择持续迭代的道路可以最大程度上发挥参与人员的能力和兴趣，我们在找到一个切入点后，逐步地按照参与人员的能力和兴趣丰富扩展我们项目的能力，这个过程是：A -> A+ -> AB -> ABC -> ...... -> ABCDE。
在项目迭代的过程中，参与人员也要提防其中的陷阱，不要给项目添加过重的意义和目标，最后这些意义和目标转化为压力，反而成为了项目轻装上阵，快速迭代的阻碍。
Welcome to Scaleph wiki!