EotalkVol。03结合APIampampampDaaS

　　Eotalk是由EolinkCEO刘昊臻发起的泛技术聊天活动，每期都会邀请一些技术圈内的大牛聊聊天，聊些关于技术、创业工作、投融资等热点话题。
　　Eotalk的第3期，很高兴邀请到TapdataCEOTJ唐建法，TJ可以说是一位超级大咖，因为他之前作为MongoDB大中华区的首席架构师，以及MongoDB中文社区的主席，被整个圈子里面人所熟知。
　　今天TJ以一个比较新的身份：Tapdata的创始人和CEO来参加我们这次Eotalk，和大家聊一下DaaS和API相关的一些故事。
　　什么是数据孤岛？对企业和IT团队有什么影响？
　　TJ：数据孤岛这个现象一直都有，但是最近几年大家讲的比较多的一个词叫做数字化转型。这里面其实涉及到方方面面，但是最底层的都离不开下面的一些数据需要打通。
　　这个时候会发现大家的数据其实是在各个孤立的系统之内的。回到二三十年前，企业最开始的时候做的事情都叫信息化，从人工手动到变成自动化，建系统把人工流程用程序的方式把它自动化起来。
　　比较典型的就是做ERP、订单系统、HR系统、财务系统等。财务最开始用Excel，现在有专门的金蝶、用友这样的财务系统。
　　这些都是叫做信息化建设，它的特点就是每一次立项建系统的时候，都有非常明确的业务目标。
　　比如我们要上一套新的业务流程管理或者采购系统，基本上会有一个前端、后端、数据库，差不多是三层架构，形成非常独立的自我运行的一套业务系统。这个情况就是随着从30年前开始，一直到现在。
　　你可以想象得到企业积累了多少像这样多的系统，稍微有规模的企业基本有四五百套独立系统。
　　中国一个三甲医院，它的平均数量是250多套这样的业务系统。比如是像一个教育系统，那它可能就有几十套。制造行业的话，也是有上百套这样的业务系统。
　　这些都是我们所谓的信息系统，之前不叫孤岛。但什么时候开始叫孤岛了呢？当我们希望对数据做洞察，了解我们的客户到底怎么样在用我们的产品，我们的生产流程到底哪里会有问题，我们整个所有的业务放在一起会是什么样的一个情况等等。需要做数据分析的事情时，你会发现你的数据其实都是在不同的业务系统里面的，做一个上报数据都要花几周，甚至还不一定拿得到。
　　这时你就会发现，我的数据其实都是在被孤立在每一个自己的后台的数据库里面。此时数据孤岛就出现了。
　　还有就是做一些新的业务场景，我想把数据给到我的业务用户去使用，都是会涉及到这个所谓的数据孤岛的问题。那我们就是试图在这样的一个大环境下，能够给企业提供一个更好的方式，来帮助他们把数据给用起来。
　　回到Tapdata取名的由来，我们是一个水管工，我们Makeyourdateontap。
　　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有非常多可以互相结合的地方。比如：Tapdata本身作为一个非常实时的一个数据源，那它是可以把各种的数据直接做整合，然后处理输出API。可以和各种网关结合。生产出来的这些数据能够直接对外提供，由网关负责保障API的调用安全以及做各种日志监控等事情。Tapdata上面所生成出来的这些API，可以发布到Eolink的API管理产品里，让开发者可以更好地管理、对接和测试这些API。
　　TJ：没问题，这也是未来的趋势，产品之间有更多的合作，让用户有更好地使用体验。
　　刘昊臻：好的，我们今天先聊到这，感谢TJ和Tapdata的支持，大家再见。
　　推荐阅读：
　　EotalkVol。01：Eoapi，我们希望以开源的方式构建API生态系统
　　EotalkVol。02：从极客到CEO，开发者应该如何提升技术领导力？