94 lines
4.4 KiB
Markdown
94 lines
4.4 KiB
Markdown
# AllData社区与Dinky社区分享
|
||
|
||
### AllData社区发起人邀请Dinky的作者文末aiwenmo对AllData社区建设进行分享和宝贵建议
|
||
### Dlink为Apache Flink而生，让Flink SQL尽享丝般顺滑，致力于实时计算平台的构建
|
||
### Dinky项目：https://github.com/DataLinkDC/dlink
|
||
### AllData项目：https://github.com/alldatacenter/alldata
|
||
### 感谢社区成员@yg9538的会议纪要
|
||
- **第一：如何激发社区对用户来参与到项目的建设，一起推动项目的发展？**
|
||
- **第二：完成整个项目的基本功能路线，流程是如何的？**
|
||
|
||
**我首先回答第二个问题。首先AllData用到的技术栈包括我们所设想的整个流程是非常全面丰富的。但然，凡事都是有利有弊的，技术栈的全面会导致各个技术功能点实现复杂度增高。**
|
||
|
||
### 2.1 最小MVP
|
||
|
||
**对于第一个问题，其实跟第二个问题是非常有关系的。当我们具备了一个可使用的一个MVP最小可行性产品时候，用户将产品用在测试或者生产实践将会给项目带来极大的益处**
|
||
**最大的好处是用户将会主动参与到我们那个项目的推动中。比如说项目的在实践中进行的测试和提出的ISSUE作为项目经验必不可少，其次用户在实际生产中遇到的二开需求，对于我们整个项目提升也是有极大的帮助。**
|
||
|
||
### 2.2 门户与KM知识库
|
||
|
||
**当然就是除了有一个最小可行性产品门户和知识库也必不可少，门户可以对整个项目进行一个详细的介绍。比如我们要进行部署的话我们可以进行搜索，百度上也会提供许多文档。但是百度的文档质量参差不齐，非常影响用户的体验。**
|
||
|
||
**我看到AllData有提到三个概念我是非常赞同的：**
|
||
|
||
- **重设计**
|
||
- **轻编码**
|
||
- **中度测试**
|
||
|
||
**对于社区来说，我们可以总结自己的经验形成文档放在社区中。**
|
||
|
||
### 2.3 用户分类
|
||
|
||
**然后第三点，因为项目前期用户是较少，在前期用户对项目的发展至关重要。这就不仅需我们仔细的聆听用户的需求，用户的反馈，还要积极的为用户来进行解答，一般用户会划分为两大类：**
|
||
|
||
- **有完整的技术经验——较少数**
|
||
- **无完整的技术经验——占多数**
|
||
|
||
**第一种用户是自身具备一定的技术栈，一定的能力。**
|
||
|
||
**第二种用户是作为项目经理或技术他引入该开源项目来作为解决方案的**
|
||
|
||
**门户网站和知识库至关重要，它可以帮助客户进行部署。所以问题点就是如何教导用户会用我们的产品。**
|
||
|
||
### 2.4 工作推动
|
||
|
||
**然后，就是进行一个分工推这方面。如果作为一个领导者要去领导我们的协作者去完成一件事情的时候，首先要达到一个统一的共识才可以，然后如何如何来达到这个统一的共识呢**
|
||
|
||
#### 2.4.1 获得认可
|
||
|
||
**首先就得需要认可你的方案**，认可你的思路。
|
||
|
||
#### 2.4.2 产品定位
|
||
|
||
**就是说你不要让用户上生产的时候就把你所有的功能都要上去，而是可以用你几块核心功能就可以完成一个产品。**
|
||
|
||
### 2.5 技术选型
|
||
|
||
#### 2.5.1 大数据平台选型
|
||
|
||
基于这些平台，你可以独立完整的跑起一个MVP。这样不仅仅能享受到社区福利也可以获得用户的认可
|
||
|
||
#### 2.5.2 MLOPS平台选型
|
||
|
||
|
||
#### 2.5.3 CI/CD
|
||
|
||
**CI/CD那一块我认为就比较独立了。这些也是有现成的项目，然后我们要做的其实就是调研好现成的项目。然后把它集成进来。**
|
||
|
||
### 2.6 需求场景
|
||
|
||
**我个人对AllData的定位是一个把很多开源的项目平台统一管理、集成起来，提供一个能力开放的平台**
|
||
|
||
#### 2.6.1 定义场景
|
||
|
||
**一般离线开发都是需要开发需求。**
|
||
|
||
### 2.7 其他要求
|
||
|
||
#### 2.7.1 文档要求
|
||
|
||
**第一，文档永远没有交流重要，文档的规范可以放松，但是交流是最主要的。**
|
||
|
||
#### 2.7.2 设计逻辑
|
||
|
||
**第二就是设计。先是高层级设计，再是具体细节设计。**
|
||
|
||
**这具体如何实现呢？例如我们如何去把数据开发平台、调度平台、管理平台关联？首先就需要把他们打通，作为一个底层Base先把他们真正的打通起来。然后让他们可以再以流一个流程化的方式来跑起来。**
|
||
|
||
**建议总结：**
|
||
|
||
- **压缩技术栈**
|
||
- **理念转变为团队思想**
|
||
- **多于其他社区沟通，达到互帮互助引流的效果**
|
||
|