leehom
leehom
> @leehom Can you translate this issue to english? ok，i have a try
目前正在开发弹性资源组件，  原理，资源分两条线a线 现有资源，b线 待定资源 a) 4资源请求->5a 分配可用资源-> 6a 请求使用资源-> 7a 提供资源->8a 提交任务 b) 4资源请求->5b 分配待定资源-> 6b 请求新worker-> 7b 部署worker->8b 注册/报告资源 a线是分配现有资源；b线请求新资源，新资源注册后成为现有资源，变成a线资源，在a线分配 该组件时通用的弹性资源，准备接入组件，增加弹性能力，如，datax，xxl-job，eventbridge，dolphin-scheduler 下图是开发架构：  实现业务资源消费者和launcher，下图xxl-job集成设计  xxl-job的master负责实现业务资源消费者，分片后，分发器按分片(组)申请资源；申请资源后，发布指令，新建执行器
> 链接失效了 哦，最近换了博客平台 https://www.toutiao.com/article/7166086687578243598/
官方是单机的，集群我所知 1. datax-web，基于xxljob，我理解是前面放个代理，管理多个worker，按负载分发到worker，我没有深入了解，不知道怎么做failover和大数据量分片的，知道的可以补充一下； 2. 这个是我们公司的方案，源于elastic-job打造的分布式调度 https://www.toutiao.com/article/7166086687578243598/
> @TrafalgarLuo 现在的情况怎样。 。后续如何？ 后续还有些特性打算pr： 配置中心 rbt https://xie.infoq.cn/article/77c1a56d807abadefb83a944e cdc 基于debezium增量同步 作业snapshot/summary streaming report 作业状态报告(持久化) mertics report https://xie.infoq.cn/article/37864acac9f62718f09a8dde4 分布式调度器
https://www.toutiao.com/article/7098577703061848606/ 这个是同构的，按官网的那个算法 https://www.toutiao.com/article/7109709746328060431/ 这个是异构，也是我们实际产品化，结构跟源不一样，有灵活的空间
梳理一下现在我们设计的关键点， 1. 放弃了datax的星型潜规则，即，reader/wrier互换，以图库writer作为中心开发reader，这个大大增强的实用性，以及后面的开发 2. 二阶段，先节点，后关系，关系写入会有 事务冲突，支持retry 3. 扩展Record，携带信息，如label，origId，fromId，toId，这个跟1)是对应，datax的星型架构得益于简单的record 4. origId，fromId，toId，源数据的Id，用于构建关系 5. 生成图库schema，配合配置中心，简化配置，写入cypher动态生成 6. 以图库中心的Transformer设计，怎么从源数据获取节点/关系的数据 ``` 1001 n_[customer] =:low and customer_id 1001 n_[address] select address_id addressId, address, postal_code postalCode, address_id _origId...
> > 梳理一下现在我们设计的关键点， > > > > 1. 放弃了datax的星型潜规则，即，reader/wrier互换，以图库writer作为中心开发reader，这个大大增强的实用性，以及后面的开发 > > 2. 二阶段，先节点，后关系，关系写入会有 事务冲突，支持retry > > 3. 扩展Record，携带信息，如label，origId，fromId，toId，这个跟1)是对应，datax的星型架构得益于简单的record > > 4. origId，fromId，toId，源数据的Id，用于构建关系 > > 5. 生成图库schema，配合配置中心，简化配置，写入cypher动态生成 > > 6. 以图库中心的Transformer设计，怎么从源数据获取节点/关系的数据...
> > 梳理一下现在我们设计的关键点， > > > > 1. 放弃了datax的星型潜规则，即，reader/wrier互换，以图库writer作为中心开发reader，这个大大增强的实用性，以及后面的开发 > > 2. 二阶段，先节点，后关系，关系写入会有 事务冲突，支持retry > > 3. 扩展Record，携带信息，如label，origId，fromId，toId，这个跟1)是对应，datax的星型架构得益于简单的record > > 4. origId，fromId，toId，源数据的Id，用于构建关系 > > 5. 生成图库schema，配合配置中心，简化配置，写入cypher动态生成 > > 6. 以图库中心的Transformer设计，怎么从源数据获取节点/关系的数据...
> > 梳理一下现在我们设计的关键点， > > > > 1. 放弃了datax的星型潜规则，即，reader/wrier互换，以图库writer作为中心开发reader，这个大大增强的实用性，以及后面的开发 > > 2. 二阶段，先节点，后关系，关系写入会有 事务冲突，支持retry > > 3. 扩展Record，携带信息，如label，origId，fromId，toId，这个跟1)是对应，datax的星型架构得益于简单的record > > 4. origId，fromId，toId，源数据的Id，用于构建关系 > > 5. 生成图库schema，配合配置中心，简化配置，写入cypher动态生成 > > 6. 以图库中心的Transformer设计，怎么从源数据获取节点/关系的数据...