Tapdata 发布了自带 ETL 的实时数据平台 Tapdata Live Data Platform（LDP），基于 DaaS 架构，解决数据孤岛和实时业务需求。该平台支持多种数据源，提供实时数据集成、服务化数据发布，并强调低延迟、易用性。Tapdata 选择了自研架构以适应实时业务场景，未来将推出实时主数据服务。此外，Tapdata 宣布开源计划，首批开源体验官招募中。
🚀 优质资源分享 🚀
| 学习路线指引（点击解锁） | 知识定位 | 人群定位 |
|---|---|---|
| 🧡 Python实战微信订餐小程序 🧡 | 进阶级 | 本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。 |
| 💛Python量化交易实战💛 | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
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 核心团队成员与多位数据行业专家、数据生态先行者、开源数据产品代表、企业客户代表及投资机构代表齐聚，着眼于“流动的”、“新鲜的”数据，结合历史解决方案与实践案例，站在生产、消费与资本等不同视角，共同探讨实时数据应用场景及技术变迁，深度剖析新一代实时数据平台的技术架构，深入洞察数据行业的发展现状与前沿优势，带来持续的干货内容和密集的精彩观点分享，高能不断，下面带您回顾本次活动亮点。△ 点击观看完整视频回放
一、时代为何需要一个全新的实时数据架构？
离线分析场景的数据诉求是已经发生了的过去，而实时业务场景的数据需求是明确的未来。而场景差异已然足够孕育一个新的技术架构。
不断增长的数据孤岛和历史方案的局限性
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B0c18jAd-1657214298003)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c41d9c28059642fe8ef488be4aafbf16~tplv-k3u1fbpfcp-zoom-1.image)]
数据孤岛的形成背景
在过去数十年间，企业搭建了非常多的业务系统，且数量仍在不断扩张。而随着数据架构日益低代码化和平台化，企业又可以以更低的成本创建更多新的业务系统。企业的数据和系统由此也越来越多，这就直接导致数据孤岛问题的产生。由于系统间彼此并不连通，取用数据的过程就变得复杂，在真正用上数据之前，还需要做很多“额外”的工作，包括数据的打通、集成、融合等等。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s6WmXq9J-1657214298009)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1ceebe03ed5402cb36442d9354a47d2~tplv-k3u1fbpfcp-zoom-1.image)]
从历史信息系统到新的业务系统，企业数据集成的常见模式
企业数据集成的常见模式包括传统的 API、ETL，早期的 ESB，以及今天的主流 Kafka，在多种既有方案的影响下，企业内部产生了大量各种各样的数据集成链路。这些方案在满足了一部分技术需求的同时，也不可避免地在数据时代的演进中暴露出局限性。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-618ik843-1657214298012)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/426026a3d34e47308a85d71b6ed48cd4~tplv-k3u1fbpfcp-zoom-1.image)]
历史数据集成解决方案及其局限性
其中，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 模型。然后在这个中央化平台上，以各种服务化方式为下游业务提供最新鲜的需求数据，本质上即 D
最低0.47元/天 解锁文章
扫一扫
432
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
