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!