https://www.bilibili.com/video/BV1tT411g7PA/?aid=470724972&cid=766317673&page=1

點擊上方鏈接，一分鐘快速了解 Tapdata

6月29日，Tapdata產品發布暨開源說明會線上開幕，圍繞「Your Last ETL」這一主題，緊扣「實時數據」這一詞眼，正式官宣自帶 ETL 的實時數據平臺 Tapdata Live Data Platform 上線，以及 Tapdata 核心功能的開源計劃等重磅消息。

發布會現場，Tapdata 核心團隊成員與多比特數據行業專家、數據生態先行者、開源數據產品代錶、企業客戶代錶及投資機構代錶齊聚，著眼於“流動的”、“新鮮的”數據，結合曆史解决方案與實踐案例，站在生產、消費與資本等不同視角，共同探討實時數據應用場景及技術變遷，深度剖析新一代實時數據平臺的技術架構，深入洞察數據行業的發展現狀與前沿優勢，帶來持續的幹貨內容和密集的精彩觀點分享，高能不斷，下面帶您回顧本次活動亮點。△ 點擊觀看完整視頻回放

一、時代為何需要一個全新的實時數據架構？

離線分析場景的數據訴求是已經發生了的過去，而實時業務場景的數據需求是明確的未來。而場景差异已然足够孕育一個新的技術架構。

不斷增長的數據孤島和曆史方案的局限性



數據孤島的形成背景

在過去數十年間，企業搭建了非常多的業務系統，且數量仍在不斷擴張。而隨著數據架構日益低代碼化和平臺化，企業又可以以更低的成本創建更多新的業務系統。企業的數據和系統由此也越來越多，這就直接導致數據孤島問題的產生。由於系統間彼此並不連通，取用數據的過程就變得複雜，在真正用上數據之前，還需要做很多“額外”的工作，包括數據的打通、集成、融合等等。

從曆史信息系統到新的業務系統，企業數據集成的常見模式

企業數據集成的常見模式包括傳統的 API、ETL，早期的 ESB，以及今天的主流 Kafka，在多種既有方案的影響下，企業內部產生了大量各種各樣的數據集成鏈路。這些方案在滿足了一部分技術需求的同時，也不可避免地在數據時代的演進中暴露出局限性。



曆史數據集成解决方案及其局限性

其中，API 集成成本相對較低，只要具備一定的代碼能力，無需第三方工具，即可由研發團隊按照數據共享需求對系統進行 API 封裝，為下遊新業務供數。但直接在源庫上構建 API 對性能的影響也比較大，且 API 通常會有 Rate Limit，難以支撐海量數據讀寫。此外，API 基本上只能對單庫發布數據，難以跨庫操作。

ETL 也是過去很長一段時間裏的主推方案，這種方式的優勢在於，不需要寫太多 Java 代碼或服務代碼，而是通過工具或脚本的方式，來實現數據向下遊系統的抽取複制。ETL 的局限性主要體現在不易管理上，因為太過簡單且無法複用，導致每個新起業務都需要不少數量的 ETL 鏈路，最終散落在企業各處。

缺乏統一管理的的下場，就是痛苦的意大利面式結構狀態。面對這一痛點，二十年前就出現了不錯的架構解决方案——用** ESB/MQ** 將數據都推到中央化的企業消息隊列、服務總線上，然後將企業各個需要共享數據的系統，通過 API 和 Service 的方式連接起來，省去了多個系統之間兩兩交互的重複工作，降低了系統之間的對接成本。但整體成本仍較高，所以多用於商業化方案。而且開發複雜、系統耦合較高，性能又較低，很快就退熱成了“明日黃花”，被類似於 Kafka 這樣的分布式開源產品所取代。

大約十年前，Kafka 迅速流行起來，大量企業開始基於 Kafka 實現數據集成。但由於 Kafka 並非為此而生，最初只是一個分布式的日志存儲，所以其架構設計特性更傾向於高並發、高性能、分布式。相較於數據集成要求的鏈路短、耗時短、延遲短，基於 Kafka 的 ETL 架構因節點較多，反而顯露出長鏈路、數據容易中斷、排查難等特性。如果想要實現，還需要做很多 Java 代碼開發，使用複雜度很高。

最近十年，各種中央化數據平臺打得火熱，特別是以 Hadoop 為主的大數據平臺，以及傳統數倉、新一代數倉等代錶，這一類方案的錶現是將企業內散落在各個數據孤島的數據集中化到一個平臺裏，從而實現通過中央平臺統一獲取需要的數據。但由於其技術架構多基於 Hadoop，本質上還是一個以離線分析為核心場景的技術棧，多用於對曆史數據進行洞察、分析，數據不够實時，無法支撐對實時數據要求較高的一些 TP 型業務場景。

在綜合考察了既有諸多解决方案背後的技術架構和局限性之後，Tapdata 開始思考用一種更好的方式來解决數據孤島問題的可能性——做最後一次 ETL，也是實時的 ETL，通過數據鏡像實現數據虛擬化，並對鏡像數據進行中央化存儲，經過一定的加工處理，形成一個可複用的數據 Copy 模型。然後在這個中央化平臺上，以各種服務化方式為下遊業務提供最新鮮的需求數據，本質上即 DaaS 概念的實現。基於此，Tapdata 自研了一套完整的產品化方案：Tapdata Live Data Platform。

Tapdata 選擇了完全自研

優秀的開源組件如此多的今天，Tapdata 為什麼不在這些優秀組建的基礎上搭建解决方案，而是設計一套新架構呢？

誠然，沿用開源組件這樣的模式的確可以在一定程度上解决一些問題，但並非最佳選擇。Tapdata 之所以選擇自研一套新的技術架構，除了想要讓產品變得小而輕、更好維護之外，還包含了自身的技術認知和追求。



離線分析場景 vs 實時業務場景

在真實的案例場景中，Tapdata 發現，實時業務場景（OLTP） 對數據的訴求與 傳統的離線分析(OLAP) 具有本質不同。實時業務場景下，數據訴求一般是秒級；數據本身參與核心業務流轉，每一條數據都與真實業務掛鉤，單比特價值高，對數據准確性的要求是 100%；業務數據量較之離線分析場景小很多。

如何更好地適應實時業務場景特性，並同時滿足傳統離線分析場景需求？Tapdata 基於 DaaS 架構的Live Data Platform 或將會是當前時代的最優解。Tapdata Live Data Platform 的重點在於 Live，在於數據的流動和鮮活，而這個一體化實時數據服務平臺的技術架構，也是為了契合這個主題而設計的。

二、Tapdata Live Data Platform：首個基於 DaaS 架構的實時數據平臺

事實證明，DaaS 體現了當下一種非常自然且合理的服務化趨勢，即將數據抽象為服務，為下遊的所有業務提供極易用的數據能力。Tapdata 的願景就是構建一個以實時數據為 DNA 的 DaaS 平臺，讓用戶無需關注底層技術，只需要關注業務邏輯和數據——像自來水一樣，打開水龍頭就能使用新鮮數據，就應該這樣簡單！

Tapdata 誕生於一個大家對 DaaS（Data as a Service）有了解但少有觸及其本質的時期。彼時，將 DaaS 作為基礎架構的數據產品可謂少之又少，但 Tapdata 認定了這個方向，並沿著這個方向不斷努力。曆時三年，精心打磨出首個基於 DaaS 架構的實時數據平臺——Live Data Platform（LDP）。

三年鋒芒初顯：從 DaaS 先行者到自帶 ETL 的實時數據平臺

從錨定實時數據賽道邁出 DaaS 第一步開始，曆時三年，Tapdata 目標中的數據服務化產品已初具規模。那麼我們到底可以在哪些場景下用 Tapdata LDP 來完成怎樣的工作？



一圖速覽我們可以用 Tapdata LDP 來做什麼？

場景1：實時數據集成平臺

可將 Tapdata LDP 用作一個實時數據集成平臺（Real Time Data Integration），用以替換昇級老一代 ETL 工具，像是 Kettle、OGG、Kafka ETL 等相對複雜的方案，或是 ETL 脚本等。

場景2：實時數據服務平臺

昇級後的實時數據服務平臺（Incremental DaaS），可以用來搭建企業級的數據共享中心，將企業核心數據放到中央化平臺裏，取代 ESB/MQ，在某些場景下還可以替代 Hadoop 大數據平臺、數倉等，可以更好地為企業 BI 數據分析等下遊業務提供數據服務支撐。

場景3：實時主數據服務

未來，Tapdata 還將推出實時主數據服務（Active Master Data Service），可以昇級傳統的以周或月為單比特進行主數據更新的解决方案，Tapdata 的目標是通過實時的方式來更新主數據，並且借助 API 服務直接接入遊業務中，讓下遊業務可以直接用上企業核心數據。

Tapdata LDP 是如何工作的？



Tapdata LIve Data Platform 的工作機制

如上圖所示，左側是企業的所有數據源，包括主流的 OLTP 數據庫，以及業務系統、文件、信息流事件等等。 Tapdata LDP 的工作機制是：

第一步，先基於日志解析的能力，通過開放式框架 Plugin Framework，以實時等方式，第一時間對這些數據源頭中修改/更新/變動的數據進行采集並標准化，形成標准時間後進入流處理框架；

第二步，通過 Tapdata 自研方案，無需離開進程，在進程內即可完成數據計算、建模和轉型，快速得出結果，進入 DaaS Storage 層；

第三步，在將數據放入 Storage 層時，實際上已經形成了一套邏輯模型，在這裏，用戶無需關心數據存儲在哪裏，只需要關注真正需要的是哪些數據信息；

第四步，也是 DaaS 的關鍵價值所在，在服務層，有兩種主流的數據服務模式，分別是 Pull 和 Push。前者指的是 Tapdata 會自動發布一些 API，這些 API 支持低代碼發布，可以按照具體需求發布數據。而當所需數據在業務系統中已有存儲時，就可以通過 REVERSE ETL，反向把這些經過整理、治理的數據推送給用戶，這也就是 Push 模式。

通過上圖大家不難發現，所有數據驅動業務都在最右側，並不包含在 Tapdata 四步工作流程之內。因為無論最終要用數據做什麼樣的業務，都是用戶自身需要關注的事情，Tapdata 只專注於提供准確、一致的最新數據。這就是 DaaS 的精髓：我們不做業務，我們只為實時數據做准備。

Tapdata 技術架構

如下圖所示，Tapdata 技術架構由一個大的插件體系、數據管理、系統和交互三部分構成。



Tapdata 技術架構概覽：一圖了解 Tapdata LDP 平臺架構方案

其中，插件體系又包含數據和結構的集成、計算和算子集成、緩存集成等多個組成部分：

  • 數據集成：用以對接各種數據源，包括平臺主打的基於日志實時解析的數據庫實時集成、以 API 和 Webhook 為特點的服務或應用的實時集成、來自 Excel/TXT 等文件的集成，以及來自 Kafka 等各種消息隊列的集成等。目前，Tapdata 平臺內已實現了對 40+ 不同數據源的支持，包括 Oracle、MySQL、PostgreSQL、SQLServer 等主流數據庫、API、隊列、物聯網等，並且還在持續擴充更多的數據源和類型。

  • 結構集成：與數據集成密不可分，提供數據結構的觀察視圖，可以幫助用戶更理解自己的數據，了解數據結構自身的流動和變化。

  • 計算和算子集成：對應引擎組件，承擔了 LDP 的計算功能。是 Tapdata 專為實時數據服務場景打造的計算組件。在引擎中，用戶可以完成拖拉拽、低代碼構建 ETL 的任務，也可以基於 JS Python 等開發語言，可視化封裝各種各樣的操作組件，還能實現多流寬錶流式聚合這樣繁重的高階能力，使用更方便。



    相較於基於 Kafka 的 ETL，在使用上無需進行冗長的鏈路開發，鏈路更短、延遲更低、更易排查

  • 緩存集成：對應緩存存儲，是 Tapdata 基於流計算場景對於存儲的獨特訴求而特別設計的組件，是順序和隨機的矛盾結合體，代錶了性能和准確性之間的高度平衡。

  • 數據源插件：在完成數據計算之後，數據可以通過數據源插件寫入用戶需要的目標庫，完成流轉閉環。

  • Data API：利用 Tapdata 內置的數據存儲服務，還能直接將計算後的數據發布為 API 接口，做到了真正的數據即服務。

在數據管理部分，針對用戶對數據探索和感知能力的訴求，LDP 提供了數據溯源、搜索和數據目錄的功能。

在系統和交互的部分，系統模塊主打企業特性，包括監控告警、全員審計等模塊；交互部分則提供了基於瀏覽器的界面操作、交互式的命令行操作，以及可遷入 SDK 的集成操作，用來滿足不同用戶的需求。

初步了解 LDP 架構大框架之後，下文將基於幾個重點模塊來解析其設計原則的細節、搭建中遇到的問題和對應的解决思路。

Tapdata 架構核心自研組建

  • Plugin Framework：插件化平臺擴展體系設計

Tapdata 插件體系中的各個組件分別對應不同的擴展能力，“可擴展”這一原則體現在 Tapdata 架構設計的方方面面，為適應不同場景帶來了便利。可以說 Tapdata 就是在插件體系上生長的平臺。



插件設計 Tapdata LDP 的能力擴展加速

選取幾個具有代錶性的數據連接插件（DataSource Plugin）為例：

① DATA：准確高效而穩健的數據接入

實時場景不僅對數據接入的性能和准確性要求高，對各種异常情况下的可排查性、可恢複能力的要求也很高。為此，Tapdata 在批流一體等常見接口之外，還提供了很多雖然不常見但非常有用的接口方法，共同支撐起一個能够提供企業級數據准確性和穩定性保障的實時數據平臺。例如：

  • 全量增量的斷點續傳：偶爾犯錯, 快速恢複
  • 數據回放：錯已鑄成, 快速回滾
  • 獲取源庫最新事件時間：精准延遲判斷
  • 無條件心跳廣播：避免稀疏事件的斷點影響
  • 幂等設計: 保證數據的最終准確性

② META：優雅的模型自動推斷體系

在數據准確性這個問題上，數據本身外，數據結構的准確性也不容忽視。隨著數據源數量和類型的不斷擴展，异構複制等場景對 Tapdata LDP 造成的維護壓力只會越來越大，編譯成本也會越來越高。對於這個問題，常見的解法有兩種。一是基於 JSON 類型或語言原生類型進行結構描述，其弊端是往往會導致异構同步錶結構不准確，需要用戶手動調整。二是基於一些開源框架，使用時需要先在目標端手動創建錶，才可以開始做計算。顯然都不是很好的方案。



Tapdata LDP 針對數據結構的准確性做出優化

為此，Tapdata 給出了創造性的新思路——引入一個抽象的中間層，只需要描述數據源到中間層的映射，就會自動匹配出最適合的目標類型，給出映射關系，並自動構建目標錶模型。該系統上線之後，用戶側遇到的建錶不准問題大幅减少，同時也從根本上解决了數據源數量擴展的一大難題。

https://www.bilibili.com/video/BV1uZ4y1Y7KK/?aid=385693533&cid=766330100&page=1

戳上方鏈接，查看數據連接插件的成品效果演示，展示一個 MySQL 數據源從注册到使用的全過程

  • Incremental Engine：分布式輕量實時計算引擎

Tapdata LDP 的計算引擎全稱是 Incremental Engine，顧名思義，專為增量實時計算設計，也是我們目前發現的最適合實時數據服務的引擎架構。引擎是一體化設計，相較於傳統架構的多進程數據互通模式，Tapdata LDP 將鏈路變得極其簡單。



Tapdata LDP 單進程完成數據互通，鏈路極簡

源→引擎→目標，所有工作都在一個進程內完成，極大地降低了用戶的使用負擔。而極簡並不意味著功能上的代償，LDP 引擎的功能齊全。從基本的同步、轉換，到高級的多流合並、多種聚合計算，LDP 引擎都有能力支持；數據來源、計算、算子、存儲也都可以實現插件化擴展。此外，多個計算引擎之間，還實現了任務的自動故障轉移，具備分布式高可用的優勢。而且在多流無窗合並場景下，Tapdata 在滿足數據准確性的前提下數十倍降低了資源消耗，這也是 LDP 的一項特色能力。引擎為 Tapdata LDP 提供了核心動力，完美適配實數據服務平臺計算框架的需求。

  • CDC CACHE STORE：專為流計算場景優化的緩存引擎

CDC Cache Store 組件的設計初衷是用來緩存 CDC 增量事件。如下錶所示，市面上常見的幾種數據庫，在增量訂閱方面的錶現，或多或少都存在一些缺陷，並不能很好地滿足實時數據服務場景的需求。**



面對流計算對存儲引擎提出的順序訂閱和隨機讀寫的矛盾訴求，Tapdata 選擇對緩存存儲進行抽象，自主開發了一個緩存引擎，在具備一定高可用性能的隨機讀寫基礎上，對事件定義的並發性能做了很大的提昇，在支撐平臺處理更多預算任務的同時，也讓整個平臺的技術架構變得更加幹淨。



Tapdata CDC CACHE STORE 架構設計

  • API Service：打造端到端完整閉環產品方案

面對如黃金般珍貴的實時數據，Tapdata 力求將數據獲取的便利性最大化。作為一體化解决方案，LDP 已實現如下能力：寬錶直接發布為接口，幫助業務快速上線；數據庫類型上層抽象，屏蔽接口差异；支持在線接口調試、運行；支持企業級管理，審計與監控功能一應俱全……由此，Tapdata LDP 讓數據價值的發揮實現了完美閉環，這也是 Tapdata 的一個設計目標。

Tapdata 優勢特性

作為新一代數據平臺，Tapdata LDP 具有以下三大特征：

① 面向服務的清晰架構：用最高效的方式來使用數據



服務化架構意味著，我們能够把數據同步到中臺中央化平臺裏進行複用，從而大幅减少從源頭發出的數據鏈路，把鏈路的數量從數百降到數十甚至更少，降低對源頭源庫的影響。從實時數據集成角度來看，Tapdata LDP 需要更少的節點，可以從十幾個進程降到兩三個進程。而且邊界清晰，專注於數據的第一公裏或者前幾公裏，拒絕全家桶，專注基礎能力。

② 全鏈路實時的能力：支持 TP+AP 場景，發揮更大的數據價值



這也是 Tapdata 主打的 DNA 品質，從 LDP 的命名就能看出 Tapdata 對 Live 的高度重視。Live 即鮮活、新鮮，Tapdata 全程面向具有最高價值的 TP 和實時分析的 AP 場景，旨在發揮更大的實時數據價值，主要體現在這幾個方面：

  • 采集實時：Tapdata 支持超 40+個數據源，支持源到目標 Any to Any 的數據實時同步對接，接下來還將通過開源的方式，在 Tapdata 主力之餘，讓開發者們參與共創，一起努力讓數據源版圖快速拓展到 100+。
  • 傳輸實時：從源端到目標端，精准控制，實現了低至亞秒級的傳輸延遲。
  • 計算實時：過程中需要計算時，Tapdata LDP 具有每秒數萬條的實時流計算處理能力，單節點的情况下，通過並行分布式該能力還可以進一步提昇。

③ 最易用的數據開發體驗：面向開發者、面向數據工程師



站在審視一個數據產品的角度，Tapdata 非常關注 LDP 的易用性和靈活性，無需部署十幾個節點，開發者、數據工程師直接下載就可以非常方便地使用起來，打造卓越的使用體驗。Tapdata 提供了兩種使用交互的方式：

  • 全程可視化：面向數據工程師，支持對企業的所有數據進行托拉拽式的加工、建模、處理、合並，所見即所得，快速獲取一個永久實時更新的數據模型。
  • 首創 Fluent ETL API：面向開發者，特別針對開源社區，無需 SQL，只需要寫一段程序就可以擁有數據集成能力，完成數據開發工作。

Tapdata 相信，IT 服務化是一個非常明確的趨勢，從 20 年前亞馬遜把基礎架構作為服務開始（IaaS, Infrastructure as a Service），到十多年前把數據庫中間件作為服務（PaaS, Platform as a Service），再到近幾年特別火熱的 SaaS（Software as a Service），“服務化”的發展非常快，服務化價值也得到了曆史的證明。而如今的趨勢，就是將數據抽象為一種服務，為下遊的一切業務提供支撐。讓數據使用像打開水龍頭使用自來水一樣簡單，這是 Tapdata 的願景，也是 Tapdata 命名的初衷——Make Your Data on Tap。



IT 服務化趨勢下，DaaS 的發展已成必然

與此同時，我們也欣慰地發現，行業中已經有越來越多的視線開始投向這一賽道，期待集結更多力量推動數據技術的發展更進一步。

Tapdata LDP 現已開放自助體驗通道

讀到這裏，相信大家對 Tapdata LDP 已經有了一定的認知。想要進一步了解更多相關信息？想要真正上手體驗 LDP 產品功能？歡迎注册成為 Tapdata LDP 首批體驗官，獲取體驗官專屬服務：



自助流程：

第1步：點擊這裏 注册成為“Tapdata 體驗官”

第2步：注册成功後進入“體驗官個人中心”

第3步：在專屬服務中點擊“下載安裝包並獲取企業版 License”，按照試用指引完成安裝和 License 激活。或點擊“企業版線上 DEMO 體驗”獲得登錄賬號和密碼

三、「魚」與「熊掌」兼得：Tapdata 並駕齊驅的開源與商業化

Tapdta 創始人 TJ 從寫下 Tapdata 的第一行代碼開始，就决定一定要將源代碼開放出去。

6月的最後一天，Tapdata 開源版本正式上線。

無論是從公司的角度還是從行業生態的角度，開源與商業化從來都不是“魚”與“熊掌”的關系，而是互為引擎的相輔相成。開源帶來技術創新，為 Tapdata 輸送生生不息的迭代動力；商業化收益反哺開源社區，又將為開源模式持續運轉提供穩定的基礎支撐。“開放”與“開源”正是 Tapdata 刻進 DNA 裏的戰略堅持。

Tapdata 為什麼要做開源？



基於開源組建的數據集成解决方案

今天，已經有越來越多的企業和用戶意識到了數據的價值。但複雜且繁瑣的既有開源解决方案往往讓很多用戶望而卻步。面對現存數據平臺開源解决方案存在的鏈路長、非實時、成本高、難維護等缺陷，Tapdata 正在全力打造與之相對的一種快速、實時、簡單、易用的新平臺。Tapdata 希望以全自動化的實時數據集成能力為基礎，連接並統一企業的數據孤島，成為企業的主數據底座。



Tapdata 致力於打造快速、實時、簡單、易用的新方案

同時我們也深知：一個人、一個公司的力量是有限的，而 Tapdata 的願景是遠大的，在通往目標的路上，有大量挑戰在等待著我們。我們需要社區的聲音、用戶的鞭策、積極的參與以及多方的幫助，一同將產品打造得更强。我們希望通過開源，讓越來越多的開發者參與到 Tapdata 的使用與開發中來，幫助 Tapdata 開源項目實現更快的成長，更快地滿足更多用戶的訴求，讓更多用戶能够獲得新鮮數據的價值，並帶來更多的需求與場景。

Tapdata 創始人TJ 從寫下第一行代碼開始，就决定一定要將我們的源代碼開放出去。我們已經准備好了——讓 Tapdata 開源版本，為更多開發者輸送實時數據的新鮮血液。

Tapdata 開源 RoadMap



如上面的開源路線圖所示，6 月 30 日發布的首個開源版本核心覆蓋的場景是：實時數據同步、開發和 Fluent ETL。3 個月之後，我們將發布 Tapdata 1.5 版本，預計新增實時數據校驗、增量數據校驗、自定義函數與聚合算子場景支持，同時將數據源補充到 50 個以上。

預計將於 2022 年 11 月 30 日正式發布的 2.0 版本補充的核心能力包括：Any DB-To-API，數據目錄、數據發現、數據溯源，並將支持的數據源數量提昇至 80+。除此之外，我們還有非常多想要和所有社區開發者在演進過程中一同探索實現的能力，和共同交流解决的問題。在未來，Tapdata 開源版本還將推出 Open API、流式存儲引擎、Open Metadata、Master Data 等多重重磅能力，敬請期待！



Tapdata 開源能力清單

Tapdata 首批開源體驗官限量招募中！

為了更好地傾聽開發者們的聲音，共創優雅易用、功能完備的實時數據平臺，Tapdata 現公開征集開源項目體驗官，搶鮮體驗優質開源項目 Tapdata ，成為社區首批成員，結識更多開發者同路人，與 Tapdata 攜手挖掘數據潜能，第一時間獲取項目最新資訊。

作為 Tapdata 社區首批用戶，你將可以：

  • 讓你的數據快人一步，感受 Data on Tap
  • 獲得 Tapdata 開源 Issue、需求的特殊優先級
  • 第一時間收獲社區最新資訊（包括但不限於開發計劃、核心技術、業務場景等）
  • 參與活動、領取開源體驗官新手任務、獲得上午雙肩包、潮牌 T 恤等更多好禮
  • 有機會受邀加入 Tapdata Committer Program，成為正式的 Tapdata Committer
  • 有機會直接參與並影響 Tapdata 的未來走向

原文鏈接：Tapdata 的 2.0 版 ，開源的 Live Data Platform 現已發布 - Tapdata

Tapdata 的 2.0 版 ，開源的 Live Data Platform 現已發布的更多相關文章

  1. 支持國內版Office 365的PowerShell模塊現已發布

    作者:陳希章 發錶於2017年5月12日 上一篇文章我詳細介紹了如何在PowerShell中訪問到Office 365的Graph API,在文章結尾處我留了一個問題,希望有朋友可以根據那個思路,嘗試 ...

  2. 【Alpaca】.Net版開源配置中心 - 技術選型 Vue 3.0

    是否可以用 Vue 3.0 現有的Vue 2.* 不推薦,坐等Vue 3.0出遷移工具吧,手動改的話工作量還是不小的 新項目 考慮下團隊內對Vue + TS + VS Code的熟練程度.過程中你會遇 ...

  3. MvcPager 免費開源分頁控件3.0版發布！

    MvcPager 3.0版在原2.0版的基礎上進行了較大的昇級,對MvcPager脚本插件重寫並進行了大量優化.修複了部分bug並新增了客戶端Javascript API等功能,使用更方便,功能更强大 ...

  4. 基於DDDLite的權限管理OpenAuth.net 1.0版正式發布

    距離上一篇OpenAuth.net的文章已經有5個多月了,在這段時間裏項目得到了很多朋友的認可,開源中國上面的Star數接近300,於是堅定了我做下去的信心.最近稍微清閑點,正式推出1.0版,並在阿裏 ...

  5. [轉載]我的Java後端書架 (2016年暖冬4.0版)

      [轉載]我的Java後端書架 (2016年暖冬4.0版) ps:最近正在初學Java,有一些其他語言的底子,但是還是要好好看書,好好練習,網上找了好久,都沒有這份書單來的實用,特意轉載過來,方便以 ...

  6. SWFUpload 2.5.0版 官方說明文檔 中文翻譯版

    原文地址:http://www.cnblogs.com/youring2/archive/2012/07/13/2590010.html#setFileUploadLimit SWFUpload v2 ...

  7. python實現文章或博客的自動摘要(附java版開源項目)

    python實現文章或博客的自動摘要(附java版開源項目) 寫博客的時候,都習慣給文章加入一個簡介.現在可以自動完成了!TF-IDF與餘弦相似性的應用(三):自動摘要 - 阮一峰的網絡日志http: ...

  8. WordPress版微信小程序3.0版發布

    距離WordPress版微信小程序上一個版本的發布過去了一個月了.在此間,我的工作有些變化,加上正在開發新版本,目前開源版的完善和昇級稍稍有些滯後. 雖然這個版本是3.0版,期間有個過渡的2.8版,不 ...

  9. 打造一個上傳圖片到圖床利器的插件（Mac版 開源）

    寫markdown博客如何將截圖快速上傳到圖床--記一個工具插件的實現(windows版 開源)(2017-05-31 20:23) 打造一個上傳圖片到圖床利器的插件 鑒於寫博客截圖手動上傳到圖床的步 ...

  10. WordPress版微信小程序2.2.0版發布

    2017年8月12日WordPress版微信小程序2.2.0版通過了微信的審核正式發布,此版本的更新以完善功能為主.主要更新的功能是:站內鏈接,猜你喜歡,熱點文章. WordPress版微信小程序開放 ...

隨機推薦

  1. Fis3的前端工程化之路[三大特性篇之聲明依賴]

    Fis3版本:v3.4.22 Fis3的三大特性 資源定比特:獲取任何開發中所使用資源的線上路徑 內容嵌入:把一個文件的內容(文本)或者base64編碼(圖片)嵌入到另一個文件中 依賴聲明:在一個文本文 ...

  2. gitlab遷移庫地址後遠程的切換

    本地需要把origin删除,然後再添加新的origin git remote rm origingit remote add origin [url] git push --set-upstream ...

  3. -_-#【JS】defer / async

    引用JavaScript文件時的兩個屬性defer和async <script src="js1.js" defer></script> <scrip ...

  4. VMware虛擬機ping出現DUP!

    VMware虛擬機ping出現DUP!   ping 外網, 還是ping 網關都出現DUP! 百度查了許久,各種方法都無效,無奈只能google看老外的方法. http://codeblog.co. ...

  5. angular 過濾排序

    <table class="table"> <thead> <tr> <th ng-click="changeOrder('id ...

  6. spring mvc 中自定義404頁面在IE中無法顯示favicon.ico問題的解决方法。

    此處用的是jsp,控制層用的是ModelAndView, 具體解决方法如下: @RequestMapping(value = "notfound", method = Reques ...

  7. nginx偽靜態配置教程總結

    在nginx中配置偽靜態,也就是常說的url重寫功能,只需在nginx.conf配置文件中寫入重寫規則即可. 當然,這個規則是需要熟悉正則錶達式,只掌握nginx自身的正則匹配模式即可,對正則不了解的 ...

  8. Xamarin中 ios 修改Assets.xcassets 文件後 無法調試和編譯

    根本問題是因為 vs項目裏面 沒有包含 如果提示找不到對應png 請檢查 iOS 項目卸載後 編輯 並找到對應文件檢查 <ImageAsset Include="Assets.xcas ...

  9. ubuntu中設置xampp開機啟動

    sudo ln -s /opt/lampp/lampp /etc/init.d/lampp sudo update-rc.d -f lampp defaults

  10. 3. Javascript學習筆記——變量、內存、作用域

    3. 變量.內存.作用域 3.1 基本類型和引用類型的值 ECMAScript 變量可能包含兩種不同數據類型的值:基本類型值[Undefined.Null.Boolean.Number 和 Strin ...