共计 7720 个字符，预计需要花费 20 分钟才能阅读完成。
点击报名
假如原料是一个产品公司的 SaaS 业务零碎、一套 CRM、一套工单零碎、一个外部人事零碎，和外部研发管理系统；当初给到你 40min 的工夫，能做出怎么的数据菜肴？
如果这里的厨师是 Tapdata，那么答案能够是一个实时业务经营看板，也能够是一个经营自动化的流程。如此高效的秘诀是什么呢？
月初，Tapdata 创始人唐建法（TJ）受邀缺席 DTC 2023（第十二届数据技术嘉年华），并在「开源翻新：开源数据技术」专场上，围绕“开源 + 实时 + 数据即服务的架构——古代数据栈工具 Tapdata Live Data Platform”这一议题，给出了这个问题的答案。会间，TJ 从古代数据栈架构的理念个性，以及开源 + 云带来的便利性切入，延长至实时数据服务平台的独特技术劣势与最佳实际案例，播种与会者的宽泛关注。以下为本次分享的核心内容总结。
https://www.bilibili.com/video/BV1Ys4y1R7qx/
点击观看残缺回放
在过来的十年中，“大数据”简直是数据行业最风行的一个名词。直到近几年，一个被称为“古代数据栈”的新术语，开始走进大家的视线，特地是在海内，古代数据栈的理念正在变得越来越受欢迎。
一边是长期以来最支流的数据技术，一边是新兴的热门理念，企业又将如何抉择？
一、数据问题的两个解决思路：Big Data vs Modern Data Stack
咱们渴望在浩瀚的数据中寻找咱们对事件的洞察，或产生更多的业务价值。当数据的有限潜能遇上未知的技术栈、未知的数据架构、未知的人力以及未知的工具和产品，咱们该如何迈出这第一步？
企业在数十年的倒退中，积攒了大量数据，但这些数据却被扩散在不同的零碎中，造成了大量各种各样的数据孤岛。因而，将这些数据整合并利用起来，也就成了企业一直求索的指标，这便是咱们常说的“数字化”。而这些数据的利用多种多样，其中最常见也是最简略的用法就是数据洞察，通过对已有数据进行剖析并得出结论，继而辅助决策。这也是“大数据分析”得以如此风行的重要起因。
另一个同样常见的用法，就是利用这些数据服务新的业务场景，例如客户、商品或生产流程的优化。随着业务场景的一直拓宽，对数据资源的灵便调用需要也在不断加强。而在从数据集成到服务的整个过程中，存在十分多的技术能力须要咱们去关注，包含应用什么工具、什么产品或是什么技术来解决数据。因而，企业在走向数字化的路上，往往面临着令人目迷五色的技术和抉择，在开源社区百花齐放的当下又尤是如此。
面对客观存在的数据需要，和绕不开的选型重任，企业通常会采取如下两种策略：
Plan A：立一个大数据我的项目
在这个大我的项目得以正式立项之前，咱们须要先投入充沛钻研筹备，包含对市面上优良计划和实现形式的调研与理解、收集尽可能残缺的我的项目需要并编写文档等等，其中单是需要文档局部就须要消耗不小的工夫和精力。
当初假如某企业心愿搭建一个数据治理平台，用于对企业的数据进行规范化的治理，以应答各种新场景的需要，在文档局部，就可能要思考到包含数据采集、集成、标准化、建设数据目录、数据品质、元数据和主数据管理，以及平安权限和如何公布服务等方方面面细枝末节的问题和需要。在这之后，还须要通过重复的评审和估算评估，才有机会立项，之后才是依据技术选型的洽购和开发推动。但直到这一步，该我的项目最终可能产生怎么的业务价值都还是未知数。在将来背后，有的都只是畅想和可能性。这也是一些大数据我的项目常停留在数据的收集和存储阶段，却很难最终落地的起因。
而这些大数据我的项目半途“搁浅”的例子，清晰地反映出了大数据技术正在面临的一个关键问题——须要破费大量工夫和投入能力达到冀望的成果。这并非对大数据技术本身价值的否定，大数据的价值不可磨灭，但问题在于整个技术栈宏大而惨重，须要进行很多布局并装备足够多的人力资源。一旦须要做一些新的调整或改变，就又是一轮新的投入。此外，历史数据的采集和存储对于大数据而言也是个辣手的问题。尽管历史数据在大数据分析中也存在价值，但对于许多业务场景来说，最有价值的数据通常是最新的这一部分。很多时候须要对这些数据进行实时收集和剖析，以便及时做出决策和调整。而大数据技术对于存储、计算和应用数据的老本都很高，性价比相对而言就低了很多。
除此之外，长时间的设置和学习过程、对新信息的响应迟缓，以及洞察的老本耗费较低等问题也日益突出。正是因而，从 2018 年开始，大数据畛域的三大厂商 Cloudera、MapR 和 Hortonworks 相继被收买或合并。大数据倒退进入转折期。
Plan B：小步走，应用古代数据栈，疾速迭代
另一个策略则是从问题登程，开始“倒推”求解。先有业务价值的“想要怎么用”，再看为了满足这个需要或解决这个问题该当怎么做。
该策略下，咱们不再冀望建一个可能在“将来”满足所有业务场景需要的大型数据平台，而是优先解决眼前的问题——首先明确哪些数据能够满足这一点需要，那就先获取这部分数据，进行剖析，并展现后果。实现第一个问题后再逐渐迭代，这里体现的正是近年来从海内开始风行的“ 古代数据技术栈（Modern Data Stack，MDS）”思维。
这种形式的特色在于，古代数据栈工具品种繁多，当咱们须要用到领有某种技术能力的工具时，往往能够疾速地做出适合的抉择，并上手运行，且无需破费巨额老本。丰盛的云产品，以及海内十分风行的 SaaS 工具，更是将这一劣势再放大。耗时一两周疾速实现新的数据需要，并将老本胜利管制在几千到几万，甚至收费，也将不再是天方夜谭。
什么是古代数据栈？
事实上，也正是 Snowflake 等云数仓的风行，带动了整个数据处理生态的倒退。云数仓低成本、可弹性扩缩容等劣势，为古代数据栈的衰亡提供了要害的基础设施和工具。因而，古代数据技术栈比拟常见的根底定义是：“因为云数据仓库的衰亡而呈现的一系列数据工具生态系统”。
简略来说，就是不同于大一统的大型数据平台或数据中台，将数据的处理过程拆分成不同的模块，每个模块专一于不同的工作，并由不同的软件和服务来实现各个模块的性能。这些工具包含开源软件、商业软件和云服务等，它们能够依据须要进行组合和定制，以构建适宜特定需要的数据处理系统。
这里拆分形式有很多种，其中比拟常见的包含：
– 三层拆分：采集接入 → 存储计算 → 服务公布
如上图所示，首先，须要对源零碎的数据进行采集和接入；而后，数据会被存入数仓，并对其进行计算和加工解决，以满足各种业务需要；最初才是各种业务价值的展示，例如数据分析、经营型业务等需要场景。
– 更加细分：数据基础架构全生命周期的 5 个阶段
A16Z 的 Matt Bornstein 在 Emerging Architectures for Modern Data Infrastructure 这篇文章里，很好地演绎了新一代数据基础架构的次要组成部分。他将数据基础架构全生命周期分成了如下几个阶段：采集与传输 → 存储 → 查问与解决 → 建模与转型 → 剖析与输入。
古代数据栈的模块划分便能够基于此进一步细化。依然是从数据源开始，先是数据采集的模块，由以 Fivetran 等为代表的许多新一代的供应商撑持。此外，还有专门做数据队列的 Confluent Kafka，用于计算的 Spark，用于数据转换的 DBT，以及专门用于展示的 Tableau……
由此咱们不难发现，像传统数据中台那样包揽了简直全副能力，却并没能把每个能力都做好的大型数据平台解决方案正在变得越来越少见。随着古代数据栈理念的推广，咱们得以在每一个模块中都选到十分不错的产品，通过这些产品的分工组合，共同完成咱们的需要指标。从中咱们也能看出古代数据栈要害特色及劣势：
– 云原生、可托管 ：古代数据栈通常是云原生的，能够在云平台上构建和托管。这意味着能够随时减少或缩小计算和存储资源，并且能够灵便地扩大或放大规模。这种可托管的形式可能帮忙企业升高经营老本和管理负担。
– 可组合、可插拔 ：古代数据栈的组件通常都是可组合和可插拔的。这意味着企业能够依据本身须要抉择和组合不同的组件来构建数据处理流程。这种灵活性可能帮忙企业疾速适应不同的业务需要和数据场景。
– 迭代式 ：相较于传统的中台或大数据我的项目自上而下的开发方式，古代数据栈更偏向于采纳迭代式的形式进行构建和演进，具备麻利开发、轻量级和可扩大、开放性和组件化等差别，可能更快地响应业务需要和变动，并且可能通过继续集成和继续部署等形式实现疾速迭代和交付。
– 自助服务 ：无需供应商染指即可实现自助选型，非技术专家也可能轻松地应用数据处理和剖析工具。这种自助服务的形式可能帮忙企业升高对技术人员的依赖，同时也可能更加疾速地实现业务需要。
二、一个初创公司的案例
基于对古代数据栈要害特色的理解可知，这样的拆分思路和云原生架构，天生非常适合“在建设大型平台方面能力绝对无限”的中小型企业。这里就以咱们本人的小型守业公司芒果英为例，来验证一下古代数据栈思维在实在业务场景下的可行性和适用性实际状况。
先交代下芒果英公司的外围详情：这是一家具备特色和竞争力的晚期守业公司，主营异构数据实时服务平台线下部署软件和云端 SaaS 产品，团队 60 多人，效率和速度是企业的生命线。
公司虽小，但在应用的业务零碎也有十多套，像是客户关系管理系统 Zoho CRM、工单支持系统 Zoho Desk、研发管理系统 Coding、精斗云财务零碎 Kingdee、飞书 OA 零碎等，其中很多是在云上运行，也包含一些自建利用，是十分典型的新一代公司的运行模式。
这样体量的公司显然不须要劳师动众地建数据中台，但的确也少不了要解决很多大数据中台可能解决的问题。比方，须要将数据集中起来以便进行洞察剖析，基于客户数据构建新的利用，自动化交互流程等等。这些工作都须要从零碎中获取数据。
产品经营视角：将芒果英业务挑战翻译为数据需要
针对芒果英面临的 SaaS 版用户留存率低、客户满意度有余的挑战，产品经营提出了从用户转化和留存率角度动手，发现问题，干涉及响应的解题思路，这也是一个数字化洞察的过程。
依据这一思路推动：第一步，须要考量影响各问题的要害指标，例如日、周、月、季、年的用户注册比率；用户转化漏斗，哪个环节散失最多；运行、报错等工作状态下的工作类型占比等。第二步，针对这些要害指标，搭建准实时数字化经营看板。第三步，通过指标察看，获取经营性洞察，进行经营性响应，包含建设用户经营体系，对线上和线下的客户进行及时关心，以及从注册、试用、技术咨询、售后反对等角度进行全方面监控，相应事件间接生成飞书工作等。第四步，察看响应的变动，调整指标和策略。
数据工程师的视角：将数据需要翻译为技术思路
这些指标数据需要来到数据工程师这里，又会被形象为技术层面如何实现的问题，答案就是：采集数据，建宽表模型，做看板，实现推送。
第一步：将客户行为信息从负责存储客户数据的线上客户管理系统 Zoho 和云版 MongoDB 中采集进去；
第二步：对采集到的客户信息数据进行加工解决；
第三步：生成用户宽表，并用 MetaBase BI 进行展现。
基于对用户表的洞察，当问题产生时，就能不便进行一些实时的干涉。
如何利用 Tapdata 疾速实现这一技术思路？
① 登录 Tapdata Cloud
② 进入数据面板
如上图所示，该界面蕴含 4 层显示。其中，源数据层展示的是咱们源数据的业务零碎；两头两层是 Tapdata 平台提供的能力，Tapdata 次要承当数据集成筹备的工作，相当于将数据放到数仓之后，再为上游提供服务。
③ 增加利用数据源 MongoDB、数据源 Coding PM，以及 Zoho CRM
Tapdata 内置 100+ 数据连接器，已涵盖所有支流数据库，无需代码即可实现连贯，无论是数据库，SaaS 还是文件都能够反对。两分钟即可实现 MongoDB、Coding PM 和 Zoho CRM 这三个零碎的对接工作。
④ 将所需数据表拖入缓存层
实质是一个数据入仓的过程，这里的 FDM 相当于贴源层，即对原零碎数据进行复制。此时如果将 Medbase 于该数仓（用 MongoDB 存储）对接，曾经能够开始做相干报表了。
⑤ 将两张客户信息表拖入平台加工层，合并到一个全局宽表
至此，咱们曾经落实了数字化最常见的场景需要——集中数据做各种看板，并由此理解咱们的客户状况、研发的状况等信息。
⑥ 将宽表拖入数据指标和服务层，一键公布 API
但在洞察之外，咱们集中起来的数据还有更广大的利用场景期待咱们来开掘。例如将数据从关系数据库同步至 Elastic Search 用于全文检索；推到云数仓 SelectDB 做数据量更大的剖析工作等等，在 Tapdata 这样的数据集成工具中，这一步也变得尤其简略。因为咱们的数据曾经整顿好了，都只须要通过数据指标和服务层，将数据推上咱们想要的指标即可。
连贯 → 复制和解决 → 服务公布——Tapdata 仅需三步，就可能实现实时数据的按需存储与按需流动，随时随地获取数据价值。
三、Tapdata Live Data Platform：以服务化的形式来解决数据集成的问题
定位：行业首个基于 DaaS 架构打造的开源实时数据服务平台
根据古代数据栈的定义，Tapdata 是一个专一于数据集成和数据筹备的古代数据栈工具，次要承当数据的采集、集成、筹备和服务模块，其外围价值体现在数据集成上：将企业的数据进行联通，为新的数据业务提供陈腐的数据。
既然外围是数据集成，为什么要叫作“实时服务”而不必实时集成呢？
这是因为 Tapdata 启用了 DaaS（Data as a Service，数据即服务）的新理念。
– 传统数据集成计划
如上图所示，传统数据集成的常见实现形式包含 API、ETL、Kafka 等，在各自的缺点之外，一个共性的外围痛点就是难以复用，从现有零碎到新业务，每做一个新我的项目，就得加一条新的链路从新跑一遍。
– DaaS 计划
DaaS 计划则强调对数据“做最初一次 ETL”，而后将数据放到一个地方化的存储中，建好规范的模型对数据按需进行解决，最初通过推送或 API 等形式，将数据提供给上游业务应用。
– 传统数据集成计划 vs DaaS
如上表所示，二者的外围区别次要体现在开发成本、对源端的影响、复用性以及实时性这几个方面：
其中，对源端的影响也是 DBA 通常会十分关注的问题。鉴于 DaaS 是对数据进行 1:1 复制后再解决应用，且除了第一次且仅有一次的全量复制外，其后的数据都将以涓涓细流的形式，源源不断地汇入，对源端系统的影响堪称微不足道。因为同样的起因，DaaS 数据的复用性劣势也很显著。
Tapdata LDP 的能力
Tapdata LDP 的外围能力体现在如下几个方面：
- 自助服务式架构：服务式的集成，更高效地数据集成形式
- 实时数据采集、解决：实时性发明更好的数据体验
- 精确和一致性：助力解锁更多外围业务场景
具体包含：（ 还是做成滑动模块吧 ）
– 100+ 的数据源和数据指标
反对以实时的形式从各个数据起源，包含数据库、API、队列、物联网等数据提供者采集或同步最新的数据变动。已内置 100+ 连接器且一直拓展中，笼罩大部分支流的数据库和类型，下一步将着重拓展 SaaS 数据源的接入。此外，还反对自定义数据源，具备强可扩展性的 PDK 架构，4 小时疾速对接 SaaS API 零碎；16 小时疾速对接数据库系统。
– 欠缺的数据校验能力
通过多种自研技术，保障指标端数据与源数据的高一致性。在惯例校验之外，还设有增量实时校验，可能精准计算数据延迟时间，在一些对实时要求较高的场景中是十分要害的能力。反对通过条数校验、主键校验、行级校验、高级数据校验多种校验形式，以定时校验、轮询校验、分钟级动静校验等不同的校验周期实现一致性校验，保障生产要求。同时反对谬误数据二次校验，以及谬误数据修复，独特为数据一致性提供保障。
– 弱小的宽表模型实时构建能力
反对行级合并和列级合并，还能够很不便地通过可视化的模型构建，疾速汇聚数据。这里用到了 MongoDB 灵便的模型个性。
Tapdata LDP 的技术架构
在实现这些能力的过程中，咱们也遇到了不少难题，像是一些实时数据处理的常见挑战：
- 数据提早或工作中断后的数据一致性保障
- 日志解析的性能，难以跟上数据库引擎的速度
- 源端 DDL 对数据链路的影响
- 多源异构数据汇聚建模的复杂性
而咱们又是如何解决这些问题的呢？
① 坚硬的数据库实时复制底层能力 – 低提早，精准监控，增量校验
利用 Cluster Timer Event，将数据的提早查问准确到毫秒级，一旦提早超过 1 分钟，可能就须要对用户发动提早揭示，从而保障用户体验。
② 牢靠的 Webhook Receive 服务保障 SaaS 事件不失落
在应用 API 获取数据时，HTTP 申请是非常简单的。但 SaaS 平台往往不心愿咱们过于频繁地申请数据，因为这会导致服务器过载，最终可能会拒绝服务。因而，SaaS 平台通常采纳推送数据的形式，比方 Webhook。然而，应用 Webhook 也存在肯定的危险，如果你的服务不牢靠，可能会失落一些事件。为了解决这个问题，Tapdata 针对 SaaS 源提供自研的云上高可用的 Reliable Service，让云上的服务放弃在线的同时，源事件也不会失落，保障了实时数据链路的可靠性。
③ 如何解决日志解析瓶颈？Oracle 及 DB2 裸日志解析
在实时复制，特地是异构数据库的实时复制中，还有一个极为常见且简单的挑战，那就是如何对 Oracle 这样的高性能的数据库进行日志解析。Tapdata 用裸日志解析的形式，跳过 API 间接解析日志文件，可能疾速推送数据到上游零碎，进步了数据复制的效率。目前曾经实现了对 Oracle 和 DB2 的优化。
④ 如何解决 DDL 对工作的影响及多源异构数据合并的复杂性？
数据集成或数据同步的另一个常见“坑”是 DDL。实践上，上游执行 DDL 后，所有上游业务都要被告诉到能力保障整个数据链路的准确性，但这无疑是个不切实际的要求。为此，Tapdata 奇妙地应用 MongoDB 作为中间层，其灵便的 JSON 模型能够轻松解决不同零碎之间的差别。当数据进入时，无需建表或进行任何 DDL 操作，因而能够保证数据的准确性和一致性。即便在 DDL 更新后，MongoDB 也能够保持稳定，只须要将新增的字段间接增加到数据中即可，因而对上游零碎的影响极小。
Tapdata 能够利用到哪些场景？
通过一键将要害数据，如客户、订单、商品信息等，从源零碎中复制到地方数据存储，Tapdata 能够服务各个利用场景：
- 实时交互类场景：公布 Data API、或把数据同步到 NoSQL，为查问减速；
- BI 类场景：为实时看板提供数据筹备，或为云数仓供数；
- AI 类场景：为企业公有 AI 大模型提供外部数据集；
- ……
想要理解更多无关古代数据栈工具 Tapdata LDP 的技术详解，Get 更多行业案例？欢送锁定将于 5 月 10 日举办的直播流动——如何胜利搭建“连贯 1 次孤岛，服务 N 个场景”数据服务平台。届时，Tapdata 还将公布最新的云数据服务平台，辞别数百万级数据中台，数万元包含产品 + 征询，帮忙您搭建麻利型企业级数字化底座。详情请关注咱们的发布会特地 Offer！点击这里，即可预约参会！
原文链接：https://tapdata.net/opensource-real-time-daas-mds-tool.html