企业数据现状分析：为什么需要实时数据？如何高效挖掘实时数据价值？

2022-08-26 319

如今，数据的时效性会真正影响到一个企业的生存。

一直以来，以传统 BI 报表、数据大屏、标签画像等为代表的分析型业务（OLAP），都是企业数据资源的重点应用场景。但 AP 型业务并不是企业的全部，同时还存在对数据实时性要求更高的新一代的运营型分析（Operational Analytics）以及越来越多的交互型业务场景（OLTP 或 Operational Applications），更是企业的核心命脉。

本期分享将从企业当前的实时场景需求出发，围绕以下几个要点，具体解析实时数据的内涵与新时期的方案选择：

回顾当下企业的数据现状

介绍已有的实时数据集成场景

盘点常用的实时数据集成架构和中间件

新老数据集成架构的技术对比，以及新一代企业级数据平台的技术架构详解

一、企业为什么越来越需要实时数据？

从依赖“人肉手工”写代码，到消息总线开始出现，再升级到后来的事件流中间件……数据集成架构在演进的过程中，解决了一些旧的问题，又逐渐遇上一些新的问题。对数据实时性要求的提高，就是眼下很多企业遇到的一个新的挑战。

企业数据现状与实时数据场景

以制造业和零售行业真实环境下的典型场景为例：

① 高端制造业：影响工厂产能

企业类型：某国内大型半导体制造厂商

业务描述：通过 MES 统一调度生产线上的机械臂，完成芯片制造

实时问题：产能受限、基台告警不及时

不同于常规生产流水线，半导体制造的无人实验室生产模式，高度依赖机械臂作业对复杂性与精密性任务的完成度，而这整个生产调度过程，又要通过 MES 系统来完成。因此，MES 系统数据推送或信号下发的时间间隔，直接关系到机械臂空转时间，继而影响整个实验室的产能。这个间隔一般是10分钟。

反过来说，如果能成功缩短数据推送间隔，就相当于提升了机械臂的利用率；如果间隔能达到秒级实时，生产速度则有望百倍增长，这其中蕴含的商业价值与竞争优势不言而喻。对于企业而言，最直接获益就是产能升级，充分挖掘实时数据优势也一跃成为加速发展的迫切需求。

② 高端零售：阻碍销售开单

企业类型：某珠宝行业

业务描述：店员通过商品中心完成调货/ 取货/查货

实时问题：商品信息不准确导致商机流失

不同于常规快消品，珠宝由于自身客单价较高、交易频率较低、更多依赖线下门店的独特属性，在零售行业的细分领域中更偏向传统、高端一类。也正是因为这样的特殊属性，对高端零售行业而言，单笔订单的成败，对销售额的影响也相对较大，对门店销售服务的准确、快速响应也有更高的要求。

在商品信息存储在多套系统的情况下，门店一线销售人员就很难准确、实时地获取完整的订单信息以及每一件商品的最新状态。如果不能在顾客提出需求后，第一时间反馈商品是否有库存、是否需要调货，以及调货所需时间等信息，就非常容易在信息查询与确认的“等待时间”里，导致潜在订单流失，对成交率造成不小的打击。这也是高端零售行业特别关注数据实时性的重要原因。

产能之于制造业；销量之于零售业——结论就是，实时数据，切实关乎企业的生死存亡。

不同数据集成方案在企业中的现状

数据集成的解决方案演进史

① API 集成：开发太繁琐，对源端性能侵入影响高

优势：不需要第三方工具，可以直接在源库上根据数据需求定制开发 API，随时调度扩展，直接从源端获取新鲜的业务数据。

缺点：对源端业务库产生较大压力，关系到核心业务系统时尤为致命，以制造业为例，如果 MES 系统因 API 调度崩溃，最直接的后果就是产能挂零。因此并不建议在核心库上发布 API。

② ETL：实时性不够，无法有效复用，造成意大利面的摊子

优势：通过抽取的方式将需要的数据复制到下游系统，对源库性能影响较小。可以通过自己写一些定期运行的脚本，或者使用一些成熟的 ETL 工具来实现，相对简单。

缺点：实现原理是轮询，需要对源端数据库进行一些改造，例如要求源库有一个时间戳字段，然后通过轮询的方式拿到近一段时间的变化数据，再把这些数据推到目标去，因此并不能达到真正意义上的实时，它达不到事实。定期执行，无法支撑对数据时效性要求比较高的场景。同时也无法复用，每个新起业务都需要不少数量的 ETL 链路，管理困难。

③ Kafka：架构复杂，开发成本不低，关键数据排错很困难

优势：相对成熟的数据集成方案选择，可以用 Kafka 来搭建一个实时 ETL 链路，用事件流的方式能够捕捉到所有数据变化的每一个状态，并推到目标。

缺点：研发及运维管理成本较高。需要自己对接、实现数据采集的能力，很多时候意味着应用双写（代码侵入）或额外的开源组件；需要 Java 代码开发，超出一般数据工程师的能力范围；节点多、链路长、数据容易中断、排查不容易，没有可视化管理，链路难以维护。

综上所述，随着新目标业务系统的不断拓展，对源端业务的核心数据诉求越来越高，这三大类数据集成方案在企业中长期运行沉淀的过程中，也产生了大量链路，而链路的复杂度、开发和维护成本，以及管理压力也逐渐变得不可控起来。摊子越拉越大，任务难度不断升级——新的需求由此产生。这不是面向一个研发团队或是一个企业的挑战，这是新时期对数据集成解决方案的变革提出的要求。

二、矛盾决定需求：如何简化数据集成链路，实现快速交付？

已知：实时场景普遍存在，对实时数据的需求很明确，挖掘并充分利用实时数据来创造价值的目标也非常清晰。在这样的背景下，我们要做的就是优化调整中间的实现过程。假设存在这样一个数据平台，能够解决当下数据集成面临的各种问题与实时需求，它应该如何设计？

新一代企业级数据集成平台：以服务化方式为下游业务提供数据

数据即服务的架构理念

设计思路：节省数据开发投入，专注业务创新

形成一个数据集成平台，让企业能够在这个平台里快速完成一系列的数据具加工、清洗工作，从而得以更专注于业务开发本身，减少大量繁琐的数据连接、数据重试等数据层面的开发工作。

架构理念：数据即服务（Data as a Service, DaaS）

IT 服务化是一个非常明确的趋势，从 20 年前亚马逊把基础架构作为服务开始（IaaS, Infrastructure as a Service），到十多年前把数据库中间件作为服务（PaaS, Platform as a Service），再到近几年特别火热的 SaaS（Software as a Service），“服务化”的发展非常快，服务化价值也得到了历史的证明。

在这一趋势的启发下，我们尝试将数据即服务的概念引入新一代数据集成解决方案，主张以服务化的方式来解决数据集成的问题。本质是将数据抽象为服务，为下游的所有业务提供极易用的数据能力。目的是以中央化的能力替代传统方案中的复杂链路，更专注于计算处理环节。

核心优势追求：快速、实施、简单、易用

最后一次 ETL：对源端系统只做最后一次数据同步。把源端业务库的数据 1:1 抽取过来之后，同步进来的数据将在中间的中央化存储里完成数据的全部清洗、加工等处理，同时对源端的业务库不会再有任何抽取工作了。直接弱化了链路的复杂程度，极大降低对源端业务的侵入。

API 服务：最后可以通过 API 的方式将数据推送到目标端。这里可以想象一下，当我们完成了一次订单的宽表或是订单的数据汇总之后，接下来所有业务系统想要获取该订单的数据，都可以直接通过读取 API 获得，非常简单。甚至连存储都不需要，因为所有的数据都是实时的，又可以通过 API 服务的方式直接提供，这对于接下来要做的新的业务系统来说都是非常方便的。

基于这样的方案设想，我们设计了一套 全新的数据架构：

新一代数据集成平台的工作机制

如上图所示，从左至右，是这个数据集成平台的数据流向：左侧包含各种各样的业务系统，在分析型业务之外，更多的还是企业的关键业务系统，例如 ERP、MES、供应链等企业核心命脉。右侧代表数据目标，平台要做的，就是将所需数据从左侧的业务系统中实时采集、推送过来。

CDC Capture（采集与同步）：基于 CDC 的无侵入数据实时采集与同步模块，以实时的方式，第一时间对数据源头中修改/更新/变动的数据进行采集并标准化。

Stream Process（计算与处理）：无需离开进程，在进程内即可完成数据计算、建模和转型，快速得出结果，将存储过程对性能消耗极大的计算部分放到这一层来解决，也可缓解源库压力。

Storage（中央化存储）：形成能够复用的统一的数据模型，提供统一的数据标准，支持按需取用。

Service（发布与服务）：通过数据发布能力，以 API 的形式呈现，或是直接按需传入数据目标，例如数据库、应用，或是 Web 服务等，从而达到更快获取所需数据的目的。

实时数据平台的核心技术路线

在推进新方案落地的过程中，我们在技术层面遇到了如下四点挑战：

基于 WAL 日志的实时异构同步（实时异构同步的 CDC 能力）

数据开发建模

中央化存储

数据发布 API

① 重中之重：异构数据的实时同步（CDC）

实时数据同步方式盘点

CDC，即 Capture Data Change，捕捉事件变化，不同于传统 ETL 定期执行轮询的方式，已经完全脱离了数据 SQL 的查询方式本身，直接监听日志变化，实时追踪数据记录的增删改。在实现 CDC 能力之前，其实已经有很多实时同步的技术架构出现，像是基于时间戳或者增量字段的采集方式，以及 Trigger 推送等，但或多或少都存在一些局限性。在这些挑战中，首要一点就是连接层（Connector）的问题。

核心技术：异构数据实时复制

如上图所示，Connector 层是数据实时同步的第一步，数据源不同，Connector 也不同。字段大小写转换、数据类型转换、清洗、计算、加工……对于不同的数据对象，在将数据推送至目标库之前，还需要进行大量处理操作。而 CDC 本质是 WAL 日志的解析方式，其实已经脱离了数据库类型的限制，是一种回归数据库日志本身的方案。

以 Oracle 为例，解析 CDC 工作原理

以数据源是 Oracle，数据目标是 MySQL 为例：如上图所示，写入 Oracle 的数据，最先会进入 Online Redo Log，即落入 Memory Buffer 中，这时就可以对这些数据进行挖掘了。刚写入就抓取，像这样基于数据库事件的挖掘，无疑是最实时的方式，比起轮询要快得多。

挖掘之后，再对这些事件进行日志解析，解析出来的日志无非就是 Undo 和 Redo 两条 SQL，分别代表 delete 和 insert。再经过数据对象转换，匹配 Oracle 与 MySQL 的数据类型，完成整个事件流的回放，成功将 Redo 日志推送到目标库。出于对数据平台集成能力的整体考量，在事件回放过程中，断点续传的能力也不容忽视。上图中的 OFFSET 就是用来记录事件偏移量的，是数据同步的准确性和正确性的重要保障。

② 最易用的数据开发体验：面向开发者、面向数据工程师

数据开发：低代码+Open API

全程可视化：面向数据工程师，支持对企业的所有数据进行托拉拽式的加工、建模、处理、合并，所见即所得，快速获取一个永久实时更新的数据模型。

首创 Fluent ETL API：面向开发者，特别针对开源社区，无需 SQL，只需要写一段程序就可以拥有数据集成能力，完成数据开发工作。

③ 中央化存储方案：DaaS

多源异构数据实时汇聚到中央化平台

为所有下游数据驱动业务提供实时、完整、准确的企业数据

中央化存储方案：DaaS

中央化存储面临的关键问题就是数据能否落地，因为落地代表着数据可复用，如果不能落地，本质就还是一个同步工具而非数据平台。为此，我们将数据落在一个集中化的管理中，而不是像一些传统方案一样直接推到目标端。这样的好处是：一方面可以将对源库的压力降到最低，另一方面更便于数据的复用。

④ 数据发布 API

数据发布 API

支持将各库各表的数据以 API 的形式发布，并作为一种资源供不同的业务方调用，在统一数据接入层的同时，也大大降低了运维的压力和工作负载。

物理架构追求：简单、低运维成本

服务	功能模块	HOST	硬件配置
Tapdata Management Tapdata API Server Tapdata Flow Engine	数据治理引擎管理模块 API 发布节点	tapdata-01 tapdata-02	CPU: 16c RAM: 64GB DISK: 100GB
MongoDB	Tapdata MetaDB	mongodb-01 mongodb-02 mongodb-03	CPU: 16c RAM: 64GB DISK: 1TB

分部/总部单点架构说明：

Tapdata Management：负责软件各模块调度和网页控制台展现

Tapdata API Server：负责数据发布及 API 网关

Tapdata Flow Engine：负责数据同步、清洗、多表关联、聚合计算等。

MongoDB：Tapdata 数据库，中间缓存结果。

2 节点可支持 负载均衡及 高可用，保证单点故障后的 任务自动接管及 断点续传

三、设想照进现实：Tapdata Live Data Platform

沿着上述技术路线， Tapdata 自研了一套完整的产品化方案—— Tapdata Live Data Platform（LDP）。

Tapdata：自带 ETL 的实时数据平台

DNA 品质：全链路实时的能力，支持 TP+AP 场景，发挥更大的数据价值

Tapdata 全程面向具有最高价值的 TP 和实时分析的 AP 场景，旨在发挥更大的实时数据价值，主要体现在三个方面：

采集实时：Tapdata 支持超 40+个数据源，支持源到目标 Any to Any 的数据实时同步对接，接下来还将通过开源的方式，在 Tapdata 主力之余，让开发者们参与共创，一起努力让数据源版图快速拓展到 100+。

传输实时：从源端到目标端，精准控制，实现了低至亚秒级的传输延迟。

计算实时：过程中需要计算时，Tapdata LDP 具有每秒数万条的实时流计算处理能力，单节点的情况下，通过并行分布式该能力还可以进一步提升。

Tapdata 最佳实践

项目背景
- 客户简介：知名黄金珠宝企业，大陆门店数量上百家，年营业超百亿
- 业务描述：与第三方电商、社交、媒体平台打通；数百家门店线上线下活动过万；业务需求旺盛，产品快速迭代适用商场

当前挑战
- 商品、订单、库存数据分布在多套系统，数据冗余
- 上新活动周期长
- 无法获得最准确的商品库存
- 已有系统过于陈旧，更新、维护困难

诉求（希望达到的目标）
- 全渠道商品中心：提供更好的客户体验
- 快速响应业务（线上线下活动）

需要的能力
- 统一数据融合平台
- 低代码快速开发数据

成功指标
- 搭建基于 MongoDB 的 DaaS 平台
- 开发主数据模型，包括：商品模型、订单库存模型
- 发布主数据 API

Tapdata 提供的整体解决方案

实时数据服务平台案例

构建底层数据链路：在最底层的数据库和 Tapdata 的中央化存储之间搭建一条数据实时同步链路

进入贴源层，构建包含企业核心业务数据的主数据层；在主数据层之上业务模型，通常是不同项目对于主数据的复用需求，这个过程中需要用到 Tapdata 的数据集成能力、数据开发能力，以及数据的中央化存储。

最终的客户核心诉求实现

支持全渠道销售业务：实时统一多套系统的库存和商品信息，从0到1支撑了全渠道营销业务

大幅提升开发效率：支撑前端的数据 API 开发上线时间从数星期降到到了 2 天

构建主数据库提高复用：数据不一致、位置凌乱的问题得到妥善解决，治理好的主数据提高了复用，减少重复成本

Tapdata：Make Your Data on Tap

以全自动化的实时数据集成能力为基础，连接并统一企业的数据孤岛，成为企业的主数据底座，为企业的数据驱动业务 "Warehouse Native" 提供全面，完整，准确的数据支撑——这便是 Tapdata 的愿景与追求。

还有更多有关实时数据集成的问题亟待解答？想要真正上手体验新一代实时数据平台？欢迎扫描上方二维码或点击这里，注册成为 Tapdata LDP 首批体验官，获取体验官专属服务。

我们期待与您共创一个更加优雅易用的新一代实时数据平台，见证实时数据的更多可能。

原文链接：https://tapdata.net/enterprise-data-status-analysis.html

微信关注我们

原文链接：https://my.oschina.net/u/5023451/blog/5569924

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

荔枝音质高保真的降噪技术实践与研究

作者：邱威简介当前直播行业愈发火热，用户通常处于不同的环境中，身边的键盘声，敲击声，空调声，喧哗声等噪声有时会对实时互动产生严重的干扰。然而传统的降噪算法针对平稳噪声有比较好的降噪效果，针对上述这一类非平稳噪声，比较难处理，收效甚微，降噪效果很差。随着近年深度学习的广泛应用，使用神经网络的降噪算法喷涌而出，而且这类算法不管是在降噪力度上，还是鲁棒性上，都要优于传统降噪，是当前处理各种不同场景噪音的首选方案。但是，在实时互动环境下，对于音频实时处理和性能要求比较高，这对于AI模型的设计和效果的平衡带来了的巨大的挑战。基于上述挑战，荔枝集团音频团队提出了一种轻量的降噪方案--LizhiAiDenoiser，该方案不仅能处理日常生活中常见的平稳和非平稳噪声，而且能很好的保留语音的音质，同时该AI降噪模型在运行时占用的内存和cpu消耗都极低，满足了全量iPhone机型以及大部分Android中低端机型。一、基本原理 LizhiAiDenoiser采用传统算法和深度学习结合的混合结构。为了可实际在移动端部署，LizhiAiDenoiser采用了比较精细的模型结构，主要使用低性能消耗的...

2022-08-26

379

courier-信使 V0.0.7 更新开源即时通讯工具

> 寻找志同道合的伙伴，有意向请通过主页联系作者信使简洁轻量的即时通讯工具 😯 演示地址 (万水千山都是情，点个 Star 行不行) 文档地址:https://www.o0o0oo.com/ 演示地址:https://chat.o0o0oo.com/ 前端地址：https://gitee.com/LiLongLong719/im-web 演示账号 a/a 仅演示目的。服务器的内容不定期清理 (作者叫礼貌，可以找我聊天哦) v0.0.7 ⚡群公告功能 🐞 设置群成员公开后未同步到其他成员的问题 🐞 其他的一些修正工作进展和计划自本周8月23日开始展开一系列性能优化为0.0.8版本的性能测试进行铺垫, 但遗憾的是,到目前为止没有任何进展,这是一个纯纯的技术问题,虽然会付出大量时间的代价但还是值得的,这是从demo级进入可用状态的必经之路,本次性能测试和优化预计15天, 这个过程可能不会有太多的功能更新未来会公布优化后的测试报告,敬请期待!!!

2022-08-26

408

发表评论

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。