Eotalk Vol.03：结合 API DaaS，让使用数据更方便

Eotalk 是由 Eolink CEO 刘昊臻发起的泛技术聊天活动，每期都会邀请一些技术圈内的大牛聊聊天，聊些关于技术、创业工作、投融资等热点话题。

 Eotalk 的第 3 期，很高兴邀请到 Tapdata CEO TJ 唐建法，TJ 可以说是一位超级大咖，因为他之前作为 MongoDB 大中华区的首席架构师，以及 MongoDB 中文社区的主席，被整个圈子里面人所熟知。

今天 TJ 以一个比较新的身份：Tapdata 的创始人和 CEO 来参加我们这次 Eotalk，和大家聊一下 DaaS 和 API 相关的一些故事。

什么是数据孤岛?对企业和 IT 团队有什么影响？

TJ：

数据孤岛这个现象一直都有，但是最近几年大家讲的比较多的一个词叫做数字化转型。这里面其实涉及到方方面面，但是最底层的都离不开下面的一些数据需要打通。

这个时候会发现大家的数据其实是在各个孤立的系统之内的。回到二三十年前，企业最开始的时候做的事情都叫信息化，从人工手动到变成自动化，建系统把人工流程用程序的方式把它自动化起来。

比较典型的就是做 ERP、订单系统、HR 系统、财务系统等。财务最开始用 Excel，现在有专门的金蝶、用友这样的财务系统。

这些都是叫做信息化建设，它的特点就是每一次立项建系统的时候，都有非常明确的业务目标。

比如我们要上一套新的业务流程管理或者采购系统，基本上会有一个前端、后端、数据库，差不多是三层架构，形成非常独立的自我运行的一套业务系统。这个情况就是随着从 30 年前开始，一直到现在。

你可以想象得到企业积累了多少像这样多的系统，稍微有规模的企业基本有四五百套独立系统。

中国一个三甲医院，它的平均数量是 250 多套这样的业务系统。比如是像一个教育系统，那它可能就有几十套。制造行业的话，也是有上百套这样的业务系统。

这些都是我们所谓的信息系统，之前不叫孤岛。但什么时候开始叫孤岛了呢？当我们希望对数据做洞察，了解我们的客户到底怎么样在用我们的产品，我们的生产流程到底哪里会有问题，我们整个所有的业务放在一起会是什么样的一个情况等等。需要做数据分析的事情时，你会发现你的数据其实都是在不同的业务系统里面的，做一个上报数据都要花几周，甚至还不一定拿得到。

这时你就会发现，我的数据其实都是在被孤立在每一个自己的后台的数据库里面。此时数据孤岛就出现了。

还有就是做一些新的业务场景，我想把数据给到我的业务用户去使用，都是会涉及到这个所谓的数据孤岛的问题。那我们就是试图在这样的一个大环境下，能够给企业提供一个更好的方式，来帮助他们把数据给用起来。

回到 Tapdata 取名的由来，我们是一个水管工，我们 Make your date on tap。

Tap 这个单词，大家知道就是水龙头，因为我比较喜欢喝扎啤，一拧水龙头就来了。

我们的使命就是进到企业里面，帮他们把这些孤岛系统用我们的超级水管连接起来。当你想要用这个数据的时候，就像自来水一样，把它给拧开来就可以用了。

刘昊臻：

理解，我的感受还很深的，毕竟我们都作为CEO。会看到公司里面其实有非常多的系统，我想把它连接起来的时候就会发现，系统虽然提供了很多的功能或很多的接口，但是它要打通的起来其实没有那么简单，底层的一些数据库它是分开的。

可能在很久之前，大家还没有太多所谓叫数据孤岛的概念。因为那个时候你不太需要把它连起来。但现在即使不是特别大的公司都已经有非常多的数据库要连起来。这个时候数据孤岛的问题就很严重了。

包括我们 Eolink 的用户也偶尔问我们，能否帮助他们将 API 对接起来，为业务赋能。

所以如果有一个大水管能够把所有东西全部连接起来，以标准的方式来对外输出，能够把各种系统串起来，这对整个公司来讲的话，我觉得是非常不错的一个解决方案。

目前解决数据孤岛有什么方案？

TJ：

数据连接是个老问题了，只不过现在需求会越来越明显，所以需要用更新的方式。

以前如果我们要去系统里面取数据，DBA 会说业务系统不能随便操作，需要提供一个 API 来对接取数据，但这个过程需要开发写代码、测试和上线，周期会比较长。当需求慢慢多起来的时候，这就会变成一个不太舒服的事情，因为生成一些数据 API 的工作很繁琐，也没有什么特别大的业务价值。

所以大家就换了一种思路，通过工具把数据都定时拿到一个地方，像 ERP 每天晚上都会开通一个时间段去抽取数据，白天的话你就等等。

这里面就会涉及到一个数据实效性的问题，比如像核酸数据，早期你做完核酸以后，数据会分批上报给国家平台、省平台，当别的省需要用的时候，就是要 48 小时、72 小时之后，这就导致效率很低。所以第二种方式也解决不了实质性的问题。

之后就出现了第三代产品，用一些 MQ 或者Kafka 做数据的连接。但它的要求是你自己要把数据放给到 Kafka，没办法自动把数据传上去，因此使用成本还是比较高，而且运维 Kafka 也不是一个小成本的事情。

Tapdata 希望解决让用户不需要开发也可以实时获取数据，并且需要简单易用。因此推出 DaaS 的概念, 通过一种自动获取数据的能力，把它中央化集中到一个平台，配上我的自动化的低代码的 API 生成、反向推送等功能，用户不需要理解底层有多少链路、数据模型、数据库格式等，是 Oracle、DB2 还是 MySQL，你只要关注数据的层面。

刘昊臻: 

所以像 Tapdata 这样第四代的产品，可以用一个统一的平台，能够快速接入各种数据源，能够在一个界面上把各种数据源做一些像数据的编排，或者是处理再输出成你想要的 API。

我觉得这个是一个非常吸引人的点，毕竟企业内部之间的数据打通的确是非常麻烦的事情。

DaaS 和 SAAS 的概念其实很像，把数据作为一种服务，关注如何使用数据，而不是软件本身。

DaaS 和 API 是相辅相成的关系，就是 DaaS 通过快速获取和封装数据，将数据变成输出成 API 方便后续对接。

DaaS 的数据中台的关系？

TJ：

我认为数据中台的字面定义，跟我们实际上看到的数据中台厂商做的事情还是有一些差异的。

目前大部分的供应商在做的事情是一个帮助企业在做数字化的升级。在此之前，企业的数据能力是比较基础的，或者是没有的，基本上都是一些业务系统、信息系统。

通过数据中台这种模式把数据进行集中化管理，形成一个有效的数据级别的资产，提供给下游的各种业务，主要集中在做营销，打标签，做分析，BI 这些主流的场景。

数据中台是一种架构形式，是指的是对企业各种业务系统数据进行集中化以后，在这过程中心治理完了交付给下游业务使用的这一个整个的事情。

而 Tapdata 则比较强调工具属性，Tapdata 就是一个非常纯粹的标准化的一个产品。你可以用它来帮助你搭建数据中台, 我们的工具跟其他的工具相较比起来, 或者跟绝大部分的数据中台的产品能力比起来，会非常关注全链路实时能力。

我们从数据采集开始到数据处理，数据加工到服务，采用的一整套技术栈都是非常强调实效性数据的，这样我能够保证数据到了这个中央化平台里面。服务的业务场景会是个全集，而非只是偏离线数据的一个场景。

刘昊臻：

我在业内看到了很多做数据中台产品的公司，最后都做成了有点像项目型公司，在标准化产品方面的能力会偏弱一些。

我们的用户，他可能直接面向的是我们的 IT 团队，是面向于开发者，面向的数据部门。我们给到你的是一个更加标准化，更加灵活，可扩展的一种解决方案。

TJ: 

是的，从我们的愿景来说，我们是要做一个很长期的 Business。从企业服务的角度上来说，我们相信未来肯定是各种分工精细化的。肯定是每一个环节都是有一个专门的、专攻的、做的非常精湛的供应商。

海外为什么没有数据中台这样的项目，连大数据这样的事情都消慢慢消亡，越来越少。就是因为海外比较多的就是各种搭积木一样的，每一个能力它都有几个做的不错的供应商在那里可以选用。配合起来一个比较完整的生态把这事情给做了，但国内就处于比较早期的阶段。

企业的数字化程度太低了，团队能力也参差不齐，没办法驾驭这些工具，只能是希望供应商能够提供一揽子方案。

能否举例介绍一下目前企业应用 Tapdata 的效果？

TJ : 

我们现在大量的大数据平台，绝大部分先做采集数据，采集入库、入仓、入湖。他们基本上会写一些脚本定期执行，每天晚上把数据拿过来，然后开启一系列的批量的处理的任务，对这些数据进行加工。常见的工作，比如会对我们的客户重新打标签，这些客户是不是我的 VIP 还是 VVIP。

但这个过程实效性很差，我举几个客户的例子。比如说一个快递公司，他们在做一个新的业务系统，叫运单管理系统，但是数据之前是存在各种第三方系统，因此会每三个小时同步一次运单进度。

大家可以想象一下，我刚刚把这个货单给了，但是三个小时之后才知道状态是否被揽收。但现在客户要的是分钟级的数据，传统方式就给不到。

我们有另外一个零售商的客户，百年老店，已经有十几套不同的业务系统，不同的门店、地域都是卖的类似的东西，但是有不同的业务系统在支撑。由于历史原因，他有很多套相同类似的系统，在做类似的业务。每天晚上它会有 BI 系统，把所有的数据汇总过来，做一些业务的报表。

但是他解决不了什么问题呢，比如有个客户走到门店想知道我这个戒指有没有货？他这个时候只能看我自己的系统里面有没有，其他门店有没有是不知道的。

互联网公司没这个问题，因为一开始就是一套云架构，不存在数据孤立问题。但对很多传统厂商来说，这种数据孤立非常常见，他们真的没办法知道这些数据。

数据中台也可以帮他们做把这些数据汇总到他的中台里面，提供 API 让他去查询，但查询的是昨天的库存。如果你需要实时库存，原有的那些中台是没法实现的。

这个是 Tapdata 的场景，就是我们把数据会从各个系业务系统把它抓过来。但是抓的方式就是那边有一个单下了，库存改了一下，我这边就已经直接一秒之内就已经到了我们的中台里面，而且你 API 去调的时候马上就可以获取到最新的数据。

Tapdata 为何选择现在开源？

刘昊臻：

你之前是在 MongoDB，一直在做开源。为什么 Tapdata 没有一开始就选择开源的方式，而先走商业化，然后在时机成熟的时候，再选择在现在这个时间点来开源，你是怎么去考虑这个事情呢？

TJ：

首先是我要想好怎么开源，毕竟做公司不是个人爱好，我想做成一个产品让用户用，我认为一个简易标准是有客户付费，你付费的东西才是正儿八经的在创造价值，否则就是一个 Hobby，就是个爱好，大家玩一玩。

第二是我觉得开源软件太多了，很多公司为了开源而开源。反过来我想给大家一个真的有价值的东西，再来大家来一起来共创。我希望先跑出一些成绩来确认一下，再来做开源，我希望给社区的是一个真的是初步验证过的产品，也是一个开源老兵的责任。

咱们都是做创业者的，很辛苦，真的压力非常大。像 Eolink 和 Tapdata 是工具软件，或者是基础架构软件现在不靠开源是很难触及到用户。

刘昊臻：

是的，Eolink 其实是 16 年的时候就先做的开源，然后 17 年才成立的公司。后面我们发现要把产品打磨的足够好，必须要获取到商业支持，后续才能够有更多的精力投入在开源方面。所以我们重新思考要重新做一个开源的 API 产品会是什么样的一个形态，它能不能够去引领行业潮流，或者说在未来有一个比较好的发展空间。

我觉得这个是一个负责的态度，尤其是把经过企业验证的，客户验证的东西，放到开源社区里面去，让更多的开源开发者，让更多的中小客户能够去享受到这个福利。

像我们新的开源 API 管理产品 Eoapi 和网关产品 Apinto，我们也维护了几个月，现在陆陆续续有贡献者加入进来，比如说帮助我们的网关去做界面，帮助我们去承担某一块功能的开发，或者给予新的 idea。

Eolink 和 Tapdata 的合作展望？

刘昊臻：

Tapdata 和 Eolink 有非常多可以互相结合的地方。比如：

1. Tapdata 本身作为一个非常实时的一个数据源，那它是可以把各种的数据直接做整合，然后处理输出 API。可以和各种网关结合。生产出来的这些数据能够直接对外提供，由网关负责保障 API 的调用安全以及做各种日志监控等事情。
2. Tapdata 上面所生成出来的这些 API，可以发布到 Eolink 的 API 管理产品里，让开发者可以更好地管理、对接和测试这些 API。

TJ：

没问题，这也是未来的趋势，产品之间有更多的合作，让用户有更好地使用体验。

刘昊臻：

好的，我们今天先聊到这，感谢 TJ 和 Tapdata 的支持，大家再见～

推荐阅读：

Eotalk Vol.01：Eoapi，我们希望以开源的方式构建 API 生态系统

Eotalk Vol.02：从极客到 CEO，开发者应该如何提升技术领导力？