网站建设金手指稳定深圳网站建设.

当前位置： 首页 > news >正文

网站建设金手指稳定,深圳网站建设.-方维网络,网站如何进行内外营销运营,黑龙江跃众品牌策划公司Eotalk 是由 Eolink CEO 刘昊臻发起的泛技术聊天活动#xff0c;每期都会邀请一些技术圈内的大牛聊聊天#xff0c;聊些关于技术、创业工作、投融资等热点话题。 Eotalk 的第 3 期#xff0c;很高兴邀请到 Tapdata CEO TJ 唐建法#xff0c;TJ 可以说是一位超级大咖#x… 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 有非常多可以互相结合的地方。比如 Tapdata 本身作为一个非常实时的一个数据源那它是可以把各种的数据直接做整合然后处理输出 API。可以和各种网关结合。生产出来的这些数据能够直接对外提供由网关负责保障 API 的调用安全以及做各种日志监控等事情。Tapdata 上面所生成出来的这些 API可以发布到 Eolink 的 API 管理产品里让开发者可以更好地管理、对接和测试这些 API。TJ 没问题这也是未来的趋势产品之间有更多的合作让用户有更好地使用体验。 刘昊臻 好的我们今天先聊到这感谢 TJ 和 Tapdata 的支持大家再见 推荐阅读 Eotalk Vol.01Eoapi我们希望以开源的方式构建 API 生态系统 Eotalk Vol.02从极客到 CEO开发者应该如何提升技术领导力