10余万行C代码开源之后,我被震惊了。。。

阅读 2833
收藏 48
2019-07-22
原文链接:mp.weixin.qq.com

7月12日,涛思团队对外宣布将研发了两年多的产品TDengine开源,10多万行C代码,包括最核心的存储引擎和计算引擎都上传到了GitHub 上。上周末7月14日我写了一篇文章《比Hadoop 快至少10倍的物联网大数据平台,我把它开源了》。一周时间,这篇文章的微信阅读量已经超过19 万,留言超过560条。GitHub上,star数目超过5300,fork 数超过1300,issue数超过135。官网taosdata.com流量暴涨,邮箱几天之内就是一千多封邮件,下载链接的邮件都无法发出,不得不购买腾讯的企业邮箱服务,不得不购买CDN 服务。这个网络传播速度之快,远超我的想象。

很多朋友戏称我是网红程序员,应该去发币,我只能哈哈大笑。殊不知,为这个开源,我们团队已经花了两年多时间,光我自己就贡献了3万多行代码,就更别说无数没日没夜的debug。我曾经连续两个月时间,每天至少12 个小时,坐在笔记本前,一动不动。就在开源后,涛思数据整个团队在过去的一周每天14小时以上,回答各种网友提出的问题,还要迅速解决发现的一些BUG。币圈里,找到象我们这样的团队,估计难。

 

微博、朋友圈里很多人不看我们详细文档,不下载源码,不测试,直接质疑,怎么可能会比Hadoop,比InfluxDB快那么多,Jeff就是一个标题党,会营销。殊不知,我们是为了好记,才说快10 倍,其实远远不止10倍。幸好有热心网友,制作docker,让大家几乎不写代码就能测试10亿、100亿条记录的查询。团队的胜亮同学,花了至少三天时间,将InfluxDB 与TDengine的对比,一步一步的解释很清楚,而且公开整个测试代码、测试数据集和环境。国内有众多的实时数据库厂商,还有一批时序数据库厂商,都宣称性能超强,但至今还没有一个公开测试代码的,我希望起个头,大家都晒晒。

 

TDengine之所以超强性能,是由于我认真分析过物联网大数据的特点,充分利用这些数据特点,从零开始,专门打造出的一个大数据平台。涛思数据团队在所有的场合,都强调,TDengine只能解决物联网、车联网、工业互联网、运维监测等场景的时序数据处理问题,不是一个通用大数据系统。如果我们这个专用的不比那些通用的大数据系统好上十倍,那我这个35 年码龄的程序员的程序真是白写了。

 

在开源之前,TDengine定位为“专业高效的时序空间大数据处理引擎”,团队一直觉得不够合适,太技术,让客户的决策者搞不懂。而且TDengine不只是一个时序数据库,它还有缓存、数据订阅、流式计算等功能。严格的来讲,它能处理所有结构化的日志数据,包括运营商的通话记录、上网记录、交通卡口记录、股票交易数据等等。但做公司,必须客户定位精准,有所放弃。因此我们决定采用“为物联网而生的大数据平台”这个定位。这个定位,让TDengine 在物联网与大数据这个交叉的领域独占鳌头,因为市场上还找不到这样的产品。我们坚信,5年的时间,世界上90%的数据都将是物联网类型的数据,如果大家处理这些数据,想到的第一品牌就是TDengine,那我们独角兽的梦想应该不会落空。

总有一些合作伙伴担心我们团队太小,因为我们到现在为止,全职的才整整9个人。但殊不知,我们这个团队是超级战队。9个人里面,5个是中国科大本科毕业,4 位在美国留学过,还有两位是中国科大最高荣誉的郭沫若奖学金获得者。非中国科大系的,毕业于科学院计算所、清华和上海交大,整个团队就有三位博士。如果大家要找10倍程序员,涛思数据就有7位。我十分的幸运,凭自己的实力、激情和对未来的憧憬,吸引了我力所能及引进的最优人才。我宁愿慢下来,我也不会放弃对团队素质的要求,因为涛思数据是一定要面向全球市场,是一定要与国际一流的软件企业PK 的。如果团队没有世界一流的水平,仅靠996和口号是无法取胜的。我更坚信,创业初期的团队更加重要,因为公司壮大后,每个人都将是带兵打仗的悍将。

 

总有VC或根本不清楚底层软件开发难在何处的人说,TDengine没有什么技术含量,BAT、华为这样的公司一出手,就把它灭了。但他们不知道,象TDengine 这样的底层软件,不是原理多难,算法多难,而是实现的工程难度大。这个难度大,不是靠人多、钱多解决的。如果靠人多能解决,源自中国的的操作系统和数据库早就引领全球。在2016年底决定启动TDengine时,我就意识到这个技术挑战相当之大,因此才下决心亲自操刀,毕竟我自己身经百战,踩过无数技术的坑,而且有相当的产品的经验,应该能写出一个具有超强竞争力的框架和核心出来。

 

但项目启动后,我才发现,TDengine的难度远远超出预期。因为想充分利用物联网数据的特点,所以没有依赖任何第三方软件,开发了内存管理、文件管理、消息队列、开发了自己的RPC 。为了保证数据写入有足够的资源,不被耗时的数据分析抢占,只好写了自己的线程调度。担心各种原因导致数据写不进系统,又实现了客户端的流控。分布式计算查询设计的好好的,但最后发现,要KILL一个分布在多个节点的查询,复杂度相当之高,为防止在KILL后的各种资源泄露,只好实现了一整套的checkpoint 。

 

客户端的driver实现也是难度极大,最开始的版本,我自己就重写了两遍。服务器的设计,一切操作都是异步的,都是事件或消息驱动的。但到了客户端,传统的SQL操作都是同步阻塞的操作,只能实现将异步专为同步的机制。为了高效,又提供一套异步的API ,导致同步、异步纠缠在一起。再加上IP重定向,元数据缓存等等,整个问题变的极为复杂。团队的廖博士和洪泽,经常被客户端问题折腾。

 

TDengine从设计的第一天起,就定位为一个分布式系统。分布式系统最难的是DEBUG,因为牵涉到多台服务器,每台服务器有多个模块。当你从应用插入100亿条记录,其中一条记录丢失,如何定位,如何找到原因?所幸的是,我十多年从事无线数据核心网络设备研发的经验帮了大忙。通讯设备,历来都是分布式的,都是可以热插拔的,是水平扩展的。通讯行业早有成套的方法论来解决这类问题,那就是日志。但日志怎么写,欢迎各位程序员去GitHub 下载源码看看涛思数据团队是怎么写的。

 

早几天,博主byongda想解读一段TDengine代码,我稍微思索一下,提出可以分析tsched.c。这段程序实现的是一个任务队列,同时带有线程池。因为这段程序是计算机操作系统里经典的consumer-producer (生产者-消费者)问题的实现。凡是真正学过操作系统这门课的,都应该知道这个问题。但遗憾的是,我2008年回国后 ,面试过数百人,到目前为止,还没有一个人在面试时,随手正确的写下这个问题的伪代码。曾有人面试还给我较真,他的程序就是对,但是我明确的告诉他,如果你不用两个semaphore (信号量),一个mutex (互斥量), 你的程序一定错,回去好好看书。我也相信,中国高校里教操作系统的老师,也没有几个能随手写出这段程序的。如果你能随手写下正确的这段程序,那么你就有资格开发底层软件了。否则,开发出成功的底层软件只是你的梦想。在美国,我的一些同事就能随手写出来,我想这就是中美软件开发的差别。

 

开发TDengine是有真正的技术挑战,这样的挑战,让我在50岁的年龄,还乐意尝试一把,不为别的,就为“Leavea dent in the world” 。如果你也乐意接受技术挑战,欢迎加入涛思数据,即便不加入,也欢迎做TDengine开源项目的contributor。如果你不写程序,但喜欢与我们这类程序员呆在一起,喜欢听程序员的故事,喜欢与程序员互动,那也欢迎加入涛思数据,我们正在组建开发者社区运营团队,需要你!

无论如何,只要你保持对我们的关注,到GitHub上下载源码,测试体验,反馈意见,就是对我们开源的最大支持,中国底层软件突破就有希望。

 

Together, we make difference!

 

评论