假设原料是一个产品公司的 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
标签：Tapdata,场景,唐建法,SaaS,校验,实时,干货,2023,数据 From： https://www.cnblogs.com/tapdata/p/17369713.html