本文首发于 2020-06-05 19:37:10
《ClickHouse和他的敌人们》系列文章转载自圈内好友 BohuTANG 的博客,原文链接:
https://bohutang.me/2020/06/0...
以下为注释。
一次偶尔的机会,和ClickHouse团队做了一次线下沟通,Alexey提到ClickHouse的设计哲学:
- The product must solve actual problem
- And do it better than others
用工程思维解决商业问题的榜样啊!
对用户来说,他们关怀的不是什么天花乱坠、上天入地的高科技,只是须要一个能很好解决本人问题的计划,这在开源社区是十分难得的,靠实力“横蛮式”成长。
于是,我对这个散发着伏特加滋味的利器充斥了好奇,并参加到ClickHouse的社区中一探到底,第一感觉是凋谢、敌对、战斗力强(AK47 vs CK16, ClickHouse 2016年开源)。
本文先从编译和测试动手,再到如何为社区奉献Patch,心愿对那些想参加CK社区的同学有所帮忙。
如何本地编译和测试ClickHouse?
源码获取
git clone --recursive https://github.com/ClickHouse/ClickHouse
编译筹备
sudo apt install build-essentialsudo apt-get install software-properties-commonsudo apt-add-repository ppa:ubuntu-toolchain-r/testsudo apt-get updatesudo apt-get install gcc-9 g++-9 git python ninja-buildsudo snap install cmake
开始编译
cd ClickHousemkdir buildcd buildexport CC=gcc-9export CXX=g++-9cmake ..ninja
测试方法
ClickHouse的测试在官网development/tests文档里有具体的介绍,这里列举3个罕用的测试模式:
1. Functional Tests
功能测试,次要用于ClickHouse外部功能测试,形式:输出一个sql文件,输入一个result,相似MySQL里的mtr,测试汇合
cd tests./clickhouse-test -c "../build/programs/clickhouse-client" 00001_select_1
2. Integration Tests
集成测试,次要用于波及第三方服务的测试,比方MySQL/Postgres/MongoDB等,以容器化形式编排调度(pytest)运行,测试汇合
因为波及模块较多,集成测试环境的搭建有肯定的难度,倡议应用官网的docker镜像。比方要跑test_mysql_protocol下的集成测试集:
cd tests/integrationdocker pull yandex/clickhouse-integration-tests-runner./runner --binary /your/ClickHouse/build/programs/clickhouse --bridge-binary /your/ClickHouse/build/programs/clickhouse-odbc-bridge --configs-dir /your/ClickHouse/programs/server/ 'test_mysql_protocol/test.py::test_java_client -ss -vv'
3. Unit Tests
单元测试,次要用于代码模块的测试,测试集在各个模块的tests目录,比方: Core/tests
如果大家想理解某个模块是如何工作的,强烈建议去翻翻该模块的tests目录,比方想理解processor的工作机制,跟踪调试 Processors/tests/ 即可。
如何给ClickHouse社区提Patch?
1. fork
首先在本人的github上fork一份ClickHouse代码,比方 https://github.com/BohuTANG/C...
2. clone到本地
git clone --recursive https://github.com/BohuTANG/ClickHousegit checkout -B mysql_replica(branch名字)
3. 创立新的分支
git checkout -B mysql_replica(branch名字)
4. 性能开发
开发者能够提交一个Draft Pull Request到官网,github会显示这个Pull Request处于Draft状态,官网是无奈Merge的
5. can be testd标签
期待Upstream打[can be tested]标签,一旦被标记CI狂魔们就强势开跑,跑一轮大略须要几十个小时。
帮助开发者发现一些代码Style、编译以及测试等谬误,这样开发者就能够在本人的分支不停的迭代、修改。
如果只是批改typo,这个标签Upstream通常不会增加。
6. 开发结束
开发实现,测试OK,把Draft晋升为正式Pull Request,期待Upstraem Review。
7. Merge到Master
如果Upstream通过,你的代码会被Merge到Master,祝贺你成为ClickHouse贡献者
8. 注意事项
ClickHouse Upstream迭代十分快,肯定要多关注master分支进度,尽量放弃本人的分支代码与master同步。否则Upstream Docker更新,本人的test可能就过不了。
倡议把doc/development读一遍。
欢送关注我的微信公众号【数据库内核】:分享支流开源数据库和存储引擎相干技术。
题目 | 网址 |
---|---|
GitHub | https://dbkernel.github.io |
知乎 | https://www.zhihu.com/people/... |
思否(SegmentFault) | https://segmentfault.com/u/db... |
掘金 | https://juejin.im/user/5e9d3e... |
开源中国(oschina) | https://my.oschina.net/dbkernel |
博客园(cnblogs) | https://www.cnblogs.com/dbkernel |