數據讀取和寫入性能碾壓MySQL、Cassandra、InfluxDB、Open TSDB和ClickHouse，同時將數據庫、消息隊列、緩存、流式計算等功能融合一起，應用無需再集成Kafka/Redis/HBase/Spark等軟件，TDengine是如何做到的？
近期，IDC對物聯網支出作出預測，2019年全球物聯網支出將達到7450億美元，IDC報告表明，各行業的物聯網解決方案支出佔比持續提升，物聯網的預期增長仍然很高。物聯網的下一章剛剛開始，在濤思數據創始人陶建輝看來，未來5年內，世界上90%的數據都會是物聯網採集的數據，於是他們打造了TDengine。這是一個專爲物聯網、車聯網、工業互聯網、IT 運維等設計和優化的大數據平臺。除了高性能的核心時序數據庫功能，TDengine還提供緩存、數據訂閱、流式計算等功能，旨在最大程度地減少研發和運維的工作量。從7月12日在 ArchSummit 全球架構師峯會（深圳站）2019宣佈開源至今兩週時間，TDengine開源項目在GitHub上已經收穫了超過6800個Star，Fork數超過1700，在業內引發熱議。
InfoQ 記者有幸在 ArchSummit 全球架構師峯會（深圳站）2019 現場採訪到了濤思數據創始人陶建輝，聽他分享TDengine性能做到Hadoop十倍背後的技術創新、TDengine開源的初衷以及未來對TDengine商業化推廣和開源社區的規劃。
以下是視頻採訪的全部內容，爲方便讀者查看，視頻下方也附上了文字內容。
InfoQ：您好，非常感謝您參加ArchSummit全球架構師峯會（深圳站）2019的視頻採訪，首先請您做一下簡單的自我介紹，包括您的工作經歷和創業經歷。
陶建輝：大家好，我叫陶建輝，我是濤思數據的創始人。今天很高興來到現場與大家互動。我是86年考上大學，94年到美國留學，97年開始在芝加哥摩托羅拉工作，後來又到了3Com公司。我在2008年回到北京創業，前面做過兩家創業公司，一個叫和信，做的是手機實時消息推送服務，後來這家公司被聯發科收購了；13年我又重新創業，做了一家做智能硬件的公司，叫快樂媽咪，主要是做母嬰健康大數據服務平臺，這家公司在16年年初被太平洋網絡收購了。然後我休息了一年。我覺得物聯網一定會發展起來，隨着數據量越來越大，需要一個新的方式來處理物聯網採集的海量數據，這是一個機會。再結合我前面那家創業公司的經驗，我覺得我還沒老。那時候，我正好49歲，我覺得我可以自己做，而且我認爲現在大家的處理物聯網數據的方法不太合適，我找到了一種更好的創新方法來存儲和處理這些物聯網數據，因此我就自己一個人寫了兩個月代碼，來證明我的想法是對的。然後我就開始融資、組建團隊，濤思數據就是在17年5月份正式成立的。
InfoQ：所以TDengine這款產品一開始的定位就是專門爲物聯網而設計的嗎？
陶建輝：物聯網是一個很寬泛的概念，包含了車聯網、工業互聯網、IT智能運維監測等，只要通過各種機器設備傳感器採集數據，都屬於這個範疇。因爲我上一家創業公司做的是智能硬件，需要採集各種各樣的數據送到雲端，做健康數據的分析。後來我又瞭解了很多物聯網項目，包括工業互聯網、智能硬件、智能家居等項目，這裏面共性的東西實際上就是數據的處理，怎麼存儲、怎麼高效地查詢計算和分析。濤思數據這兩年多的時間，一直在做的就是這樣一件事情。
InfoQ：TDengine是什麼時候正式對外推出可用產品的？從TDengine開始研發，到推出對外可用的產品，一共花了多長時間？
陶建輝：我們第一款產品真正可以交給用戶使用是在2018年8月份，從一開始研發到對外推出可用的產品大概花了一年半的時間。
InfoQ：在TDengine的研發過程中，團隊遇到最大的困難是什麼？這背後有什麼故事可以跟我們分享嗎？
陶建輝：最大的困難就是技術，技術挑戰相當大。我們這款產品看上去很簡單，不就是把各種採集的數據存儲起來再做查詢，實際上因爲這屬於底層軟件，所以它的技術挑戰很大。比方說我們經常要做一百億條記錄的插入、查詢測試，這一百億條記錄如果中間丟了一條，你要找出丟的是哪一條、爲什麼丟，涉及的模塊很多，技術挑戰相當大。
我可以分享一個我們在TDengine開發過程中的小故事。因爲我自己在做這個產品，它主要強調性能和易用性這兩個方面。如果性能不夠好，那它就沒有代替其他軟件的可能，我就舉一個性能的例子。有一次我們團隊一個工程師，改了一行代碼，他改的那行代碼還是我寫的，大家都沒有意識到，這行代碼讓整個產品的性能下降了一半都不止。整個團隊都急死了，花了整整一天時間，回滾代碼查看，最後才找出原因並修復了問題。
InfoQ：在性能測試報告中，你們對比了TDengine和MySQL、ClickHouse等開源數據庫產品的讀寫性能，這是否意味着這些產品是TDengine的對標對象？
陶建輝：雖然MySQL、ClickHouse這些是大家更熟悉的開源數據庫產品，但我們真正對標的是測試報告上寫的InfluxDB、OpenTSDB，包括阿里的HiTSDB等產品，這些纔是我們真正對標的產品。但是也不完全公平，因爲這些產品只是一個數據庫。TDengine的核心功能也是個數據庫，但除了數據庫之外，TDengine還支持很多其他功能，比如說大數據處理所需要的緩存、消息隊列、流式計算等一系列功能。我們的性能測試報告針對的是數據庫這項功能，因爲數據庫測試相對標準化，一般看的就是插入速度、查詢速度，所以我們基於此做了對比。目前TDengine在大數據領域還沒有真正完全對標的對象，我們是全球第一個真正做物聯網大數據平臺的產品。這也是爲什麼我們不把自己叫做數據庫的原因。
InfoQ：官網上對TDengine的介紹中提到了“超融合”，指的是將大數據處理需要的消息隊列、緩存、數據庫、流式計算、訂閱等功能融合在一起。但目前大數據生態中普遍是不同的產品負責不同的功能、各司其職，很少有集大成的產品。能否詳細談談爲什麼要做“超融合”？
陶建輝：爲什麼要做“超融合”呢？目前通用的大數據平臺，往往要集成五六個甚至七八個軟件，對於研發者來講挑戰很大，因爲你不只要學一個軟件、掌握一個工具，而是要同時掌握好多個工具。對於企業管理人員來講，連招人都很困難。而且每個開源軟件，你認真細究都會出問題。如果我們把所有這些功能集成在一起，只需要一個軟件就能提供所有功能，就能夠把開發的難度大大降低。而且因爲我們使用的是標準的SQL接口，只要學過計算機的人，幾乎沒有不會用的，因此我們就讓研發和維護都變得極其簡單，這點改進是非常重要的。同時，TDengine也有它特別的地方，它只面向物聯網行業。它不適合做輿情分析，不適合做用戶畫像，不適合好多通用的互聯網行業應用場景，我們只能做物聯網、車聯網、工業互聯網、運維監測這些場景，比如風力發電、國家電網物聯網的建設等。
InfoQ：能不能再談一談怎麼實現“超融合”，技術上可以分爲哪幾塊?
陶建輝：數據庫插入數據的時候，一般需要先進入消息隊列緩存起來。而物聯網的數據很特殊，它實際上非常類似消息隊列，因爲物聯網採集的數據是按照時間順序源源不斷發過來的，它本身就是一個隊列。第二點，物聯網最重要的特點就是要看實時狀態，因此我們會把每個設備的數據都直接緩存在內存裏一段時間，緩存的時間會根據它採集的時間長度定。而互聯網應用的緩存不是由這個決定的，它的緩存是由用戶行爲決定的，比如說這條微博點擊的人特別多，就要一直緩存着。但物聯網數據不是這樣的，對於物聯網數據，大家最關心的是剛採集到的數據，已經過去幾個小時或幾天的數據，大家都不在乎。因此我們巧妙地利用了這些特點實現了消息隊列和緩存。另外還有流式計算，因爲物聯網數據本身就是流式的，我們能夠順其自然地推出流式計算，當然最後這些數據也要存起來，數據庫也要能做歷史數據的分析，這都是數據庫本來就擅長的。
InfoQ：從性能測試結果來看，TDengine在讀寫性能、集羣水平擴展性能等各方面表現都非常驚人。能否談談你們在技術上做了哪些創新？
陶建輝：主要是我們的數據模型不一樣。我們的數據模型要求對每個採集點，或者每個採集設備單獨建表。比如說你有一千萬個智能電錶，它就建一千萬張表。單獨建表的好處是什麼？單獨建表之後，每個設備採集的數據在內存裏或者硬盤上，就會是一塊一塊連續存放的。當然，不可能完全無限連續，但可以做到4K、16K、64K這樣連續。這樣一來，讀數據的時候就會讀完整的一塊。因爲物聯網還有一個特點是從來不關心單個點的值，而更多關心的是整個趨勢。因此物聯網場景下做查找的時候，往往是查5分鐘的數據。但5分鐘的數據又包含很多點，因此我們這種設計，就能夠讓查詢速度大大加快。按照我們的數據模型設計，一次讀取可能可以讀一千條記錄出來，而按照以前的數據庫設計，如果要讀一千條記錄可能就要一千次IO操作，一定會慢。
那麼寫操作爲什麼我們也能夠做到很快？對於物聯網設備來講，我們設計成一個設備一張表以後，每寫一張表其實就是一個設備在寫。因爲物聯網的數據，比如說車或者智能電錶、智能手環，數據一定是某一個設備產生的，一張表對應的數據生產者是唯一的，同時只會有一個設備在寫這個表，從技術上來看就很簡單了。另一方面，物聯網數據是按時間順序來的，這就意味着它是一個追加操作，所以寫操作自然就很快。
但是我們這種數據模型，也有另外一個問題，那就是表的數量太多了，比如說一千萬個智能電錶，那就一千萬張表。這些表如果只是單獨看，那我們這個方法已經足夠好了。對單個電錶或者單個汽車的數據的插入、查詢速度，都不可能有比我們快的。但是如果要做聚合，那就很麻煩。因此，我們還有另外一個很重要的創新，叫超級表。超級表指的是將同一類型的設備看作一個表，每個表可以帶標籤，比如喜來登酒店11樓某個房間的電錶，聚合的時候只要統計11樓的十幾個電錶，或者整個喜來登酒店一百個電錶，查詢起來還是很快的。如果沒有這個超級表的創新，我們的產品也不太可能受歡迎。
InfoQ：TDengine在高可靠性方面做了哪些工作？其可靠性可以做到什麼程度？
陶建輝：我們研發TDengine的時候是基於一個假設，那就是任何軟件、任何硬件都是不可靠的，也就是說任何軟件不可能沒有Bug，任何硬件不可能不出問題。基於這個假設，我們就要做一個多副本的分佈式系統，數據都可以丟，硬盤都可以換，甚至我們做到了什麼程度呢？我們支持熱插拔，硬盤壞了可以當場換，甚至IDC機房遷移的過程中，數據庫仍然可以繼續工作，做到了這種程度。
在可靠性方面，我們主要用到了業內公開的一些NoSQL分佈式數據庫的方法。當然我們也充分利用了物聯網數據的特點，才能夠做得足夠好。我們堅信物聯網一定會發展起來，可能不到五年或五年左右的時間，世界上90%的數據都會是物聯網類型的數據。
InfoQ：與現有的時序數據庫產品相比，TDengine的優勢是什麼？
陶建輝：TDengine的優勢是高性能而且簡單易學，它的安裝包只有1.5MB，從下載到安裝成功運行不會超過5秒鐘，這是現在沒有任何大數據軟件能做到的。但我們跟現有的大數據產品相比當然也有弱點，我們的產品僅僅開發了兩年時間，生態還有待完善，而InfluxDB數據採集接口和應用軟件的接口已經有很多了，這是我們後面要長期努力的目標。
InfoQ：TDengine做到了高性能和易用性，但技術沒有完美的技術，TDengine是否在其他方面做了平衡和妥協？
陶建輝：我們做的妥協是什麼？第一個，剛纔我一直強調，我們是專門做物聯網的數據，做不了微博的數據，做不了微信、電商的數據，這些都做不了，我們真正做的是物聯網、車聯網，這是一個。第二個妥協是，從技術的角度來看，我們是採用結構化方法實現的，這意味着開發者需要自己定義表的結構。而像InfluxDB、OpenTSDB是不需要定義表的結構的，因爲他們都是NoSQL，不用定義Schema，開發者愛怎麼寫數據就怎麼寫，如果已經習慣了這種做法可能就會覺得TDengine不好用。但如果你歷來都只是用MySQL、Oracle這種結構化數據庫，那就沒有問題。但結構化的方法在物聯網、車聯網行業並不是個問題，這是我們在準備開發之前就決定的。因爲物聯網數據都是由硬件設備採集的，硬件的數據格式是固定的，一般很少改動，除非固件更新，但固件更新的可能性很小。而互聯網應用開發則需要頻繁迭代和更新，變化太大，所以它用Schemaless這種不需要定義結構的方法就是很合適的。但物聯網、車聯網、工業互聯網的數據格式可能一輩子都不更新，所以結構化就不是很大的障礙。
InfoQ：現階段大部分企業都已經搭建了自己的大數據平臺，讓他們整套切換到一個新的大數據平臺並不現實，TDengine是否可以與已有的大數據生態兼容？對於TDengine的落地應用和推廣，您是怎麼考慮的？
陶建輝：基礎軟件切換的成本極其高，最終還是要看這個企業有沒有遇到真正的難點和痛點，現在我們付費的客戶都是已經遇到了難點和痛點，他覺得非得拋棄眼前已有的大數據平臺。那麼難點和痛點在哪裏？第一，我們有一個做車聯網的客戶，目前已經擁有PB級別的數據，查歷史數據幾乎讀都讀不出來，他們現在就用HBase層的，他們老闆找他，無論怎麼搞都要查出來，哪怕幾秒鐘也行，但問題是幾秒鐘都查不出來，他非得解決這個問題，就成了我們的客戶。還有另外一個客戶，他們的數據量已經很大了，他們覺得成本太高了，而我們能夠把他們的總擁有成本降到原來的20%都不到，比如原來需要十臺服務器，現在一臺就夠了。因爲TDengine的存儲做得很好，以前10個T的數據，到我們這裏變成一個T了，那這肯定就要換，因爲能省很多錢。還有一類是什麼？因爲大數據系統，尤其是Hadoop這個體系已經深入人心了，但其實它在很多場景下數據量並不大，但是Hadoop要做一套私有化部署的時候，可能要裝HDFS、HBase、Kafka等一系列的東西，這個成本真的高，不是機器的成本，而是安裝部署維護的成本極其高。那如果我們能夠提供一個統一融合的解決方案，只要一個小軟件全部搞定，就能大大簡化安裝部署維護的難度，那麼客戶就會有足夠的動力來換。同時，對於已經自建大數據平臺的企業，我們也會提供一些工具，比如數據遷移的工具，甚至我們會兼容一些現有的接口，對於用戶來說接口和以前可能一模一樣，只要換個IP地址就行了。
InfoQ：目前已經有客戶在試用或在實際業務中使用TDengine了嗎？
陶建輝：我們試用的客戶有好幾十家了，而最終買單的客戶馬上就超過十家，包括車聯網、電力、數控機牀、智慧城市等不同行業場景的客戶。
InfoQ：當前TDegine還存在哪些問題有待解決？
陶建輝：應該不算是問題，而是一些需要不斷改善的地方。其中一個是我們的流計算做得還不夠，比如說我們現在支持簡單的滑動窗口，未來需要把它變成事件驅動的流計算，然後我們還要支持用戶自定義函數。等我們把用戶自定義函數和事件驅動完善後，TDengine會在物聯網領域發揮機器大的作用，數據清洗、規則引擎都可以用一套軟件完全搞定，很多工具都不再需要了。
InfoQ：對於TDengine接下來的研發重點和推广部署，您還有什麼進一步的計劃？
陶建輝：今天我們就是來宣佈TDengine開源的，開源是我們的一個推廣方式。當然我們確實越需要開源，尤其是要把我們最核心的代碼開源出來。就像剛纔講的，爲什麼TDengine能夠比其他產品快一二十倍？如果你不相信，你可以去看我們開源的源代碼，看完之後你就知道，這個代碼保證快。在中國，很多用戶都不願意付費，都希望用開源軟件，那我們就開源給你用，這是我們的一個推廣方式，我們希望把這個社區經營起來，從而打造品牌、擴大影響力。另外一方面，我們也非常歡迎其他開發者加入進來共同爲這個項目做貢獻，比如說我們需要各種數據採集接口，開源之後可能就會有人蔘與進來一起貢獻代碼。
另外一方面，我們除了開源版之外，還會有企業版。企業版是要收費的，它是一個高可靠可擴容升級的版本，並且會提供專業的一對一服務。我們還有第三個版本就是雲服務版本，我們會將這個版本放在阿里雲、AWS等不同的雲平臺上面，企業可以直接購買我們的服務，按照用量和使用時長來收費。
InfoQ：現在TDengine已經在GitHub正式開源，你們採用的是什麼樣的開源許可？
陶建輝：我們採用是AGPL許可，這個開源許可意味着，只要你使用了我們的開源軟件，你也必須開源。
InfoQ：作爲一款開源產品，肯定繞不開開源和商業盈利模式的問題，TDengine開源之後的盈利模式，您是怎麼考慮的？
陶建輝：我們開源的技術一定會盡最大的努力去維護，但我們還有企業版，就像我們的競爭對手，比如說InfluexDB，我們的模式幾乎跟它一模一樣，都是有開源版、企業版和雲端版。像MongoDB也是這樣，有企業版、社區版和雲端版本。
InfoQ：但其實現在MongoDB跟雲廠商之間也存在一些糾葛，那你們未來和雲廠商之間的關係是怎麼考慮的？
陶建輝：當然，我們希望跟雲廠商採取合作的方式，但你完全免費地拿這個東西在雲上提供服務，我們的AGPL許可是不允許的。不可能我們整個團隊辛辛苦苦開發的代碼，直接被你拿去賺錢，這是整個開源社區和雲廠商之間最大的問題。比如說MySQL這麼流行，結果雲廠商什麼貢獻都沒做卻從MySQL賺了很多錢。我們所使用的AGPL許可和MongoDB搞的服務器端公共許可證（SSPL）都是來解決這個問題的，包括Redis，最近大家修改開源協議的原因都是爲了避免這樣的情況發生。
InfoQ：目前TDengine跟國內雲廠商已經有一些合作了嗎？
陶建輝：還沒有。但我的信號十分明確，肯定不能讓他們免費使用我們的開源代碼，他們必須有貢獻。等我們的開發者社區和用戶羣慢慢壯大起來，我相信一定能走到合作的一天。其實開源和雲不是天生敵人，而是可以互利互贏的。
InfoQ：那麼下一步TDengine的開發者社區和生態，您打算怎麼去推進？
陶建輝：這是下一步整個公司的重心，我們新上線的網站裏面會有博客，我們會在GitHub上、Twitter上、微博上、Stackoverflow上，各種技術論壇與開發者互動，我們也會參加比如像ArchSummit架構師峯會這樣的開發者大會，我們也會自己組織活動，線上線下一起來推動社區的發展。
採訪嘉賓介紹：
陶建輝，濤思數據創始人，1986年考入中國科大，1994年到美國印第安納大學攻讀天體物理博士，曾在美國芝加哥Motorola、3Com等公司從事2.5G、3G、WiFi等無線互聯網的研發工作，國際頂尖無線數據專家。2008年回到北京創辦和信，專注移動互聯網IP Push和IP實時消息服務，2010年和信被臺灣聯發科收購。2013年再度創業，創辦快樂媽咪，專注母嬰智能硬件和母嬰健康服務，2016年初快樂媽咪被太平洋網絡收購。2017年5月創辦濤思數據，專注時序空間大數據的實時高效的處理（存儲、查詢、計算等），其產品TDengine比其他業內標杆能好10倍以上，可廣泛運用於物聯網、車聯網、工業大數據、金融等領域。