树盾科技完成1亿元C轮融资
06-18
近十年来，以Hadoop为代表的大数据技术发展如火如荼，各种数据平台、数据湖、数据中台等产品解决方案层出不穷。
这些解决方案最常用的场景包括企业数据的统一聚合以及对这些线下数据的分析和洞察，以达到辅助决策或辅助营销的目的，例如传统的BI报表、数据大屏、标签画像、但除了这种分析型业务（OLAP）之外，还有一些对数据实时性要求较高的交互业务场景（OLTP或Operational Applications），比如电商行业常见的统一商品或订单查询，金融行业的实时风控、服务行业的客户CDP等，这些场景对于企业来说往往是关键任务。
除了OLTP场景之外，很多新一代运营分析（Operational Analytics）也逐渐成为主流数据应用。
运营分析的特点是还需要业务系统的最新实时数据来帮助客户做出更及时的业务响应。
。
对于这些交互APP或者运营分析场景，传统大数据平台由于对实时数据的支持有限，无法有效支撑。
今天我们将探讨有关实时数据的问题：? 什么是实时数据？ ? 如何获取实时数据，目前有哪些解决方案？问题是如何解决的？优缺点都有什么？ ? 理想的实时数据架构应具备哪些特征？ ? 如何用新一代实时架构升级或替代传统解决方案？ 1.什么是实时数据？一般来说，实时数据是指在数据刚产生的短时间内发生的数据传输、处理或最终交付，例如实时同步、实时消息处理等。
用于衡量数据实时性的指标。
衡量实时性是指数据从生产端到消费端的传输延迟。
另一类实时数据是指对查询或计算的响应是否足够快，更针对数据库内置的分析或查询引擎。
这种实时数据技术的衡量标准是响应时间。
如果传输延迟或响应时间可以控制在亚秒或秒内，我们可以将这些技术称为“实时数据”技术。
从用户的角度来看，他们能够体验到的是一种“交互”的体验。
例如，如果我执行查询或检索最新的统计信息，通常会在 1-3 秒内返回结果，这是理想的情况。
实时体验。
如果我们把实时数据技术放到一个完整的数据架构图中，可能会更容易理解实时数据意味着什么。
A16Z 的 Matt Bornstein 在《现代数据基础设施的新兴架构》一文中很好地总结了新一代数据基础设施的主要组成部分。
他将数据基础设施的整个生命周期分为几个阶段：摄取、存储、查询和处理、转换、分析和输出。
以此框架为参考，我们可以对离线数据技术和实时数据技术进行比较： 如图所示，实时数据包括实时采集和同步、实时计算、实时存储在实际工作中，这些技术支持的场景案例如下： 实时采集同步/实时集成 以数字化防疫场景为例，在疫情特殊阶段疫情防控期间，“核酸码”、“健康码”成为日常出行的必需品，特别是在核酸检测频率较高的时期，因检测结果影响日常工作和生活的情况很多。
没有及时显示。
应对这一问题的核心环节是核酸检测数据的实时、准确采集。
实时计算以数据可视化大屏的应用场景为例。
实时产能大屏作为传统制造业实现数字化转型的常用辅助工具，可以为自动化生产提供数据基础；实时监控运行情况并及时发出警告；并帮助企业分析产品。
循环实现精准洞察，助力业务发展。
实现这些目标的基础是实时数据——通过对所有系统数据的实时采集和实时计算，可以使数据分析和显示更加高效。
实时分析以金融行业反欺诈平台为例。
随着用户数量不断增加，客户历史行为数据不断积累。
为了在不影响交易行为的情况下对数据进行分析和处理，新时代的风控工作面临着更多实时性的挑战，传统的数据仓库架构逐渐无法满足相应的需求。
因此，需要结合多渠道性能，对客户行为数据进行实时分析和反馈，快速区分欺诈交易和正常交易，便于快速决策。
实时查询和服务银行个人贷款、互助小额贷款、保险等在线金融服务需要对客户进行实时风险控制。
通过实时数据服务，可以统一汇总来自金融系统和外部系统（征信、司法、公安等）的个人数据，在申请过程中实时查询客户的风险信息并提供给用于决策的算法引擎。
2、实时数据技术的来源：实时数据集成。
无论是哪一种实时数据处理技术，都离不开一个事实：我们需要实时数据源。
Doris作为实时数据仓库，只有第一时间获取新鲜数据，才能获得即时有效的洞察； Flink的实时流计算需要Kafka提供数据；而Kafka作为消息队列，需要用户对源数据负责。
数据被推送到Kafka Topic。
可以说，所有的实时数据技术都离不开源头——实时数据的采集和整合。
对于实时数据集成，常见的技术解决方案包括以下几种： ? 自定义API集成或使用低代码API ? ETL工具 ? ESB或MQ ? Kafka 让我们分别看看这些解决方案的优缺点。
API、ETL 和 ESBAPI 集成是一种不需要第三方工具的解决方案。
通常，研发团队可以根据数据共享的需求定制开发相应的API接口，并测试上线以支持下游业务。
这种方式的优点： ? 无需购买商业解决方案，因地制宜 ? 可高度定制化 缺点也很明显： ? 当需求增加时，开发成本会更高，API 管理会出现新的问题 ? 性能对源库有相当大的影响，一般是核心业务系统所不能容忍的。
? API方式不适合全量或大量数据下发的场景。
ETL通过提取所需数据将其复制到下游系统。
根据需求，可以编写一些定时运行的脚本，或者使用一些成熟的ETL工具。
优点：? 对源数据库性能影响不大，可以安排在半夜等业务高峰时段执行。
? 实现比较简单，可以用很多开源或商业的软件来实现工具。
缺点：? 定期执行，无法支持对数据时效性要求较高的应用。
场景 ? ETL无法复用，每次新增业务都需要大量ETL链路，导致数量激增，管理困难。
作为企业数据总线，ESB 将独立的软件系统连接到通过总线连接在一起的中央。
如果每个系统需要向另一个系统传输数据或消息，可以通过ESB进行传输。
ESB的架构优势体现在： ? 消除了多个系统之间的重复交互 ? 降低了系统之间互连的成本，只需要与标准ESB中间件交互 ? 数据实时可用 然而，ESB已经被证明成为“过去的事情”。
其主要问题是： ? 接口定义极其繁琐； ? 性能低下，无法支持新一代大量实时数据处理需求； ? 与系统耦合度较高，有可能更新上游系统会影响下游系统 ? 成本高，只有商业解决方案 当今主流：Kafka ETL 十年前，随着大数据技术的发展，一种叫Kafka的消息中间件开始流行，并迅速在实时领域流行起来数据集成主导架构。
作为消息事件平台最主流的代表，Apache Kafka最初只是一个分布式日志存储。
后来逐渐增加了Kafka Connect和Kafka Streams功能。
基于这些能力，我们可以利用Kafka构建实时ETL链路，满足企业内部业务系统之间实时数据集成的需求。
然而，这种基于Kafka进行实时ETL的架构有非常明显的缺点： ? 需要自身具有连接和实现数据收集的能力，这往往意味着双写应用程序（代码入侵！）或额外的开源组件 ? 需要Java代码开发，超出一般数据工程师的能力 ? 节点多、环节长、数据容易中断、排查困难。
DaaS：以服务化的方式解决数据集成问题。
综上所述，现有的技术方案在一定程度上满足了需求。
在此前提下，存在一些明显的痛点： ? API 开发过于繁琐，对源端性能影响较大 ? ETL 实时性不够，无法有效复用，导致意大利面条式卡顿 ? ESB 有具有中心化优势，但成本太高 性能太弱，已经过时 ? Kafka架构复杂，开发成本高，关键数据排查困难。
DaaS（Data as a Service）是一种新型的数据架构，将数据进行物理或逻辑聚合，然后以标准化的方式为下游提供数据支持，如下图所示： 该架构的优点是： ? 数据集中化，可以在一处为多个业务提供数据，充分提高数据复用能力 ? 接口标准化 ? 数据采集只需完成一次，结合元数据管理技术，为企业构建全面的数据目录，可以快速发现所需数据 ? 解耦：数据仓库和数据服务分离，无耦合性 但是，传统的 DaaS 解决方案，例如数据中间件实现，有一个很大的局限性，就是通过批量采集的方式来收集数据，导致数据不够新鲜和真实。
-时间，直接影响传统DaaS的商业价值。
3、新一代DaaS解决方案：实时ETL的数据服务平台。
展望新十年，完全自主研发的新一代实时数据平台“Tapdata实时数据平台”作为实现DaaS架构的新型数据平台应运而生。
Tapdata LDP的核心突破点是能够实现完整的基于CDC的异构数据实时融合+计算建模能力。
通过不断实时采集数十个源数据库并传输到DaaS存储，保证DaaS的数据始终实时更新，实现了Incremental DaaS，增量数据服务平台的理念。
通过这次DaaS的实时性增强，Tapdata将肩负起将企业ETL数量从N个减少到1个的使命。
凭借“全链路实时”的核心技术优势，Tapdata将加速连接、统一数据孤岛打造一站式实时数据服务基地，为企业数据驱动业务“仓库原生”提供全面、完整、准确的生鲜数据支撑。
一张图看懂Tapdata LDP的工作模式和特点? 第一个同时支持TP和AP业务场景的实时数据平台? 两大核心技术能力：实时数据集成（ETL）和实时数据服务（DaaS） ） ? 首创DaaS方式 解决实时数据集成问题，数倍减少ETL链路数量 ? 40+数据源实时复制能力，瞬间打通企业数据孤岛 ? 多线程等实时流计算能力-流式合并和复杂宽表构建?对于程序员：首创Fluent ETL，用代码代替SQL处理数据?对于数据工程师：完全可视化，拖拽完成开发建模?开放+开源，使用PDK自行-拓展更多对接处理能力，免费获取实时能力的同时回馈社区实时应用场景 ? 实时数据管道：可以用Tapdata替代CDC+Kafka+Flink，快速构建几分钟完成数据采集+循环管道，避免CDC数据采集易出错、Kafka阻塞、链路排查困难等重大坑。
? 实时ETL：Tapdata 可用于替代ETL 工具或脚本，例如Kettle / Informatica 或Python。
基于JS或Python的UDF函数可以无限扩展处理能力；分布式部署能力可以提供更高的处理性能；基于拖放的新一代数据开发更加容易。
此外，还支持通过自定义算子快速扩展平台的数据处理和处理能力。
? 宽表实时构建：从大数据分析到数据仓库构建再到Dashboard，数据工程师使用大量的批处理任务生成宽表或视图进行展示和分析。
这些宽表的构建通常需要大量的资源，并且数据更新不及时。
但是，如果您利用 Tapdata 独特的增量宽表构建功能，您可以以最低的成本提供最新鲜的数据结果。
? 实时数据服务：企业在数字化转型过程中需要构建大量新业务，这些业务往往需要来自其他业务系统的数据。
传统的基于ETL的数据传输方案存在很大的局限性，比如链路复杂、无法复用、大量数据链路对源端影响很大等。
Tapdata的实时数据服务可以对数据进行最后的ETL，并将其同步到基于MongoDB或TiDB的分布式数据平台。
结合无代码API，可以直接在数据平台上为众多下游业务提供快速的数据API支持。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-18
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态