基于Apache doris怎么构建数据中台(一)-什么是数据中台

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 这是数据中台系列的第一篇文章,主要阐述数据中台概念,从技术和业务视觉看数据中台及数据中台要解决的问题

这是数据中台系列的第一篇文章,主要阐述数据中台概念,从技术和业务视觉看数据中台及数据中台要解决的问题


1.什么是数据中台


数据是从业务系统产生的,而业务系统也需要数据分析的结果,那么是否可以把业务系统的数据存储和计算能力抽离,由单独的数据处理平台提供存储和计算能力?这样不仅可以简化业务系统的复杂性,还可以让各个系统采用更合适的技术,专注做本身擅长的事。这个专用的数据处理平台即数据中台。


数据中台是一个用技术连接大数据计算存储能力,用业务连接数据应用场景能力的平台。

“连接能力”是数据中台的精髓。作为一个处在中间层的能力平台,“连接”是其根本任务。在业务层面需要尽可能连接各种数据源作为其生产资料;同时,由于生产数据的场景越来越多,覆盖了线上线下等多渠道,各数据生产资料之间也需要进行连接,才能形成全域的数据;数据在数据中台这个平台上按照标准的模型进行规范加工处理后需要服务于多种场景,同样需要我们提供标准的数据服务接口将数据与应用场景连接起来。因此,连接是数据中台的根本能力,也是数据中台的价值所在。


数据中台通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。


数据中台把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而为客户提供高效服务。这些服务跟企业的业务有较强关联性,是这个企业独有且能复用的


2.数据中台解决什么问题


1、效率问题:为什么应用开发增加一个报表,就要十几天时间?为什么不能实时获得用户推荐清单?当业务人员对数据产生一点疑问的时候,需要花费很长的时间,结果发现是数据源的数据变了,最终影响上线时间。


2、协作问题:当业务应用开发的时候,虽然和别的项目需求大致差不多,但因为是别的项目组维护的,所以数据还是要自己再开发一遍。


3、能力问题:数据的处理和维护是一个相对独立的技术,需要相当专业的人来完成,但是很多时候,我们有一大把的应用开发人员,而数据开发人员很少。


3.数据中台和数据仓库、数据平台的区别


1、数据中台是企业级的逻辑概念,体现企业 D2V(Data to Value)的能力,为业务提供服务的主要方式是数据 API;


2、数据仓库是一个相对具体的功能概念,是存储和管理一个或多个主题数据的集合,为业务提供服务的方式主要是分析报表;


3、数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台,为业务提供服务的方式主要是直接提供数据集;


4、数据中台距离业务更近,为业务提供速度更快的服务;


5、数据仓库是为了支持管理决策分析,而数据中台则是将数据服务化之后提供给业务系统,不仅限于分析型场景,也适用于交易型场景;


6、数据中台可以建立在数据仓库和数据平台之上,是加速企业从数据到业务价值的过程的中间层。


4.技术视觉的数据中台


数据从生产到应用的整体流程是任何一个数据从业者都绕不开的主题,即便是非数据领域的产品和运营同学,同样也应该对业务中数据的流向有个初步的认识。要展开描述,我们必须从数据的技术视角思考两个问题:


需要解决的问题是什么?


如何保证数据流中不同阶段的最优解?


4.1. 需要解决的问题是什么?


数据供给:提供便捷的数据生产方案,以数据产生为起点,规范数据整个主体的供给,为夯实数据平台的基础提供保障;


数据产出:保证数据在产出层面的普遍适用性。该阶段包括分析报表,自动化分析工具,查询入口等的建设;


过程管理:保证数据的完整性、准确性、时效性,实现数据从产生到应用全流程的高效管理。


4.2. 数据流的不同阶段如何解决


不同企业所处的业务发展阶段不同,所面对的问题会不一样。同样,业务本身特性及企业对数据建设的资源倾斜程度不同,也会直接影响数据全流程处理的差异。最重要的还是立足于现状,站在更高的战略视角去思考整体的解决方案。下面从技术视角来看我们数据中台做什么:


4.2.1 数据产生


数据产生,这个阶段是最适合向业务方宣灌数据生产应用流程的阶段,因为该阶段的优劣将会直接影响之后的各环节。该阶段的关键字是数据规范录入,需要给数据上游的业务方提供可行的数据埋点规范。


4.2.2 数据采集


数据采集:这是最被动的一个环节,也是最出力不讨好的环节,最容易被甩锅和背锅的环节,


数据部门会提供给业务方不同场景下的模块日志采集方案清单,业务方只需按照现有清单选择模块上报,数据部门会自动收集;


数据部门会提供模块日志注册系统,形成良性注册机制,让数据部门提前感知,自动化收集模块数据。


4.2.3 数据处理


数据处理、清洗是数据输入到仓库的前置阶段,该阶段最主要的是规则,目的是建立符合业务需要的数据清洗方案。比如什么格式的数据该被过滤;哪些用户是要被过滤掉等。


4.2.4 数据仓库


数据仓库面向应用而生,为了保证数据的普遍适用性及拓展性,会对仓库进行分层,通常分为:ODS、DW、DWS、ADS。常见数据仓库模型为“星型模型”,我们在进行维度建模的时候会建一张事实表,这个事实表就是星型模型的中心,然后会有一堆维度表,这些维度表就是向外发散的星星。


4.2.5 数据计算


数据计算是数据变活的过程,主要分为离线和实时计算。会按照不同业务单元的需要,设计数据指标,并按照不同场景中的业务逻辑确定统计规则,最终由系统实现例行计算。


4.2.6 数据应用


数据的应用是数据最终产生价值的部分,基于数据流前面的流程处理,该环节最终会提供给应用方业务报表、数据访问、自动化工具、统计模型等应用;


在数据应用方面我们应当关注的问题:


是否能提供完善的业务分析指标体系,是否能提供完善的精细化运营工具;


现有数据是否足够支撑业务分析,是否能依据现有数据发现更多的业务问题,是否能洞察潜在的商业机会


4.2.7元数据管理


元数据管理贯穿整个数据流程始终,是一个较为宽泛的概念,元数据治理的好坏将直接决定了整个数据平台的品质。元数据管理主要分为两部分:技术元数据、业务元数据


5.业务视觉的数据中台


基于立场的不同,导致了从业务视角与从技术视角看到的表现层内容会不一样,但究其本质是相通的。无论数据在应用层面以何种方案最终呈现,最终都是为了解决问题而存在,

为什么需要数据团队解决?


需要解决的问题是什么?


该通过什么方式解决?


5.1 为什么需要数据团队解决?


业务技术团队的定位是服务于业务一线,数据团队的定位是提供专业性的数据解决方案,二者分工上的差异性决定了解决问题的最佳路径。如下列举了需要数据团队解决几类问题:


数据类型:数据产生场景复杂、数据类型多(订单、客户、商品,仓储,物流等),数据结构复杂(结构化/非结构化/半结构化数据);


数据量级:存储量级大,传统关系型数据库不能解决;


数据处理:清洗规则多,计算任务流程长,计算血缘关系复杂等;


数据应用:行为分析,多维交叉分析,实时多维分析,丰富的可视化等。


5.2需要解决的问题是什么?


(1)业务是什么


不同业务单元依据自身业务属性,需要数据团队解决的数据问题也不一样。如市场团队关注应用市场投放相关的数据,客户端团队关注设备/应用版本/用户转化相关的属性数据,运营团队关注活动相关数据,风控团队关注风控相关数据等。


(2)如何衡量它们


团队属性的不同,也决定了量化到数据指标的衡量标注不同。各业务团队拥有自己的关键唯一指标和对应拆解/下钻的指标体系。


(3)如何让数据驱动业务


市场团队通过衡量不同渠道来源用户的质量,评估渠道ROI,优化投放策略;客户端团队通过观察不同产品方案的转化效果,改进注册及其他核心行为发生的主流程设计;运营团队通过用户细分,评估不同用户群在活动对的转化效果,进行精细化运营等。


5.3 通过什么方式解决?


以下从业务视角来看数据中台产品解决方案:


实时监控


专注于关键核心指标的实时表现,如客户、商品、订单,仓储,运输等。视具体情况会将关键指标维度下钻后进行实时监控


离线分析


核心看板:核心看板着重关注公司战略层核心指标在核心维度上的趋势及构成表现


业务看板:业务看板服务于不同业务团队,亦可视作各业务单元的核心看板


客户分析及画像:客户构成、客户留存、客户转化、行为、生命周期等场景的分析、


商品分析:商品构成、库存、售出、质量、商品生命周期等场景的分析


精细化运营工具


留存分析:按照留存模型,起始行为精分客户群体,依据精分客户群交易行为、频次、额度等的表现,观测各层客户的留存


画像分群:按照不同主体拆分属性,通过属性组合,筛选目标分群,进行精细化运营

交易分析:分析客户的订单行为


SQL查询控制台:可视化SQL查询


预警及分析


实时异常分析:实时异常分析基于历史数据,获取当前时间点的可能数值范围,当实际值在该范围以外时,即认为数据异常。关键要求是及时和准确


智能分析:具体策略是对关键核心指标进行维度拆解,寻找出影响核心指标波动中不同维值的“贡献度”,最终定位问题


  1. 平台建设目的


大数据时代的到来,让越来越多的企业看到了数据资产的价值。将数据视为企业的重要资产,已经成为业界的一种共识,企业也在快速探索应用场景和商业模式,并开始建设技术平台。


为了解决企业业务在实际中存在的以下问题:


各个业务数据重复开发浪费存储与计算资源


数据标准不统一,存在数据质量问题,数据使用成本高


业务数据孤岛问题严重业务协同能力弱,数据利用效率低


缺乏精准模型支撑,数据分析能力不足,数据应用价值不高


基于四个统一,统一数据采集,统一数据处理,统一数据存储,统一数据服务,基于计算及存储基座,提供标准统一、可连接萃取的数据中台,包含数据采集与研发、数据连接与萃取、数据资产管理及统一数据服务,服务于上层业务,如经营分析、消费者营销洞察等场景


在实际数据开发应用中存在,不知数据在什么地方,数据是什么意思,拿到一个报表怎么开发,数据怎么获取,最后数据怎么能快速的可视化呈现出来这五个难题,我们建设这个数据中台就是要解决:找数据,理解数据、问题评估、取数及可视化展现这五个问题,整个平台的故事也是围绕这个五个点。从根本上解决:


找数:数据从什么地方来到什么地方去,将数据和业务过程结合起来,实现数据的快速查询


理解数据:通过数据的血缘关系,数据关联关系及数据的说明信息,让数据开发人员,业务人员快速理解数据


问题评估:数据分析人员拿到需求,可以通过该平台实现问题的自动评估,大大提高数据分析效率


取数:用户可以不再关心数据的来源,不再担心数据的一致性,不再依赖RD的排期开发。通过所选即所得的方式,满足了用户对业务核心指标的二次加工、报表和取数诉求


数据可视化:依托于我们的BI可视化系统和数据中台的打通,数据分析人员可以快速的将数据中台创建的数据模型快速的转换成可视化报表。





相关实践学习
阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
通过该实验体验在阿里云百炼中构建企业专属知识库构建及应用全流程。同时体验使用ADB-PG向量检索引擎提供专属安全存储,保障企业数据隐私安全。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
目录
相关文章
|
12天前
|
存储 SQL Apache
Apache Doris 创始人:何为“现代化”的数据仓库?
3.0 版本是 Apache Doris 研发路程中的重要里程碑,他将这一进展总结为“实时之路”、“统一之路”和“弹性之路”,详细介绍了所对应的核心特性的设计思考与应用价值,揭晓了 2025 年社区发展蓝图
Apache Doris 创始人:何为“现代化”的数据仓库?
|
14天前
|
SQL 存储 数据处理
别让你的CPU打盹儿:Apache Doris并行执行原理大揭秘!
别让你的CPU打盹儿:Apache Doris并行执行原理大揭秘!
58 1
别让你的CPU打盹儿:Apache Doris并行执行原理大揭秘!
|
4天前
|
存储 SQL 监控
计算效率提升 10 倍,存储成本降低 60%,灵犀科技基于 Apache Doris 建设统一数据服务平台
灵犀科技早期基于 Hadoop 构建大数据平台,在战略调整和需求的持续扩增下,数据处理效率、查询性能、资源成本问题随之出现。为此,引入 [Apache Doris](https://doris.apache.org/) 替换了复杂技术栈,升级为集存储、加工、服务为一体的统一架构,实现存储成本下降 60%,计算效率提升超 10 倍的显著成效。
计算效率提升 10 倍,存储成本降低 60%,灵犀科技基于 Apache Doris 建设统一数据服务平台
|
2月前
|
存储 消息中间件 分布式计算
Cisco WebEx 数据平台:统一 Trino、Pinot、Iceberg 及 Kyuubi,探索 Apache Doris 在 Cisco 的改造实践
Cisco WebEx 早期数据平台采用了多系统架构(包括 Trino、Pinot、Iceberg 、 Kyuubi 等),面临架构复杂、数据冗余存储、运维困难、资源利用率低、数据时效性差等问题。因此,引入 Apache Doris 替换了 Trino、Pinot 、 Iceberg 及 Kyuubi 技术栈,依赖于 Doris 的实时数据湖能力及高性能 OLAP 分析能力,统一数据湖仓及查询分析引擎,显著提升了查询性能及系统稳定性,同时实现资源成本降低 30%。
Cisco WebEx 数据平台:统一 Trino、Pinot、Iceberg 及 Kyuubi,探索 Apache Doris 在 Cisco 的改造实践
|
29天前
|
SQL 存储 Apache
Apache Doris 3.0.3 版本正式发布
亲爱的社区小伙伴们,Apache Doris 3.0.3 版本已于 2024 年 12 月 02 日正式发布。该版本进一步提升了系统的性能及稳定性,欢迎大家下载体验。
|
22天前
|
弹性计算 自然语言处理 数据库
通过阿里云Milvus和LangChain快速构建LLM问答系统
本文介绍如何通过整合阿里云Milvus、阿里云DashScope Embedding模型与阿里云PAI(EAS)模型服务,构建一个由LLM(大型语言模型)驱动的问题解答应用,并着重演示了如何搭建基于这些技术的RAG对话系统。
|
2月前
|
消息中间件 Java Kafka
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
58 1
|
25天前
|
存储 人工智能 大数据
The Past, Present and Future of Apache Flink
本文整理自阿里云开源大数据负责人王峰(莫问)在 Flink Forward Asia 2024 上海站主论坛开场的分享,今年正值 Flink 开源项目诞生的第 10 周年,借此时机,王峰回顾了 Flink 在过去 10 年的发展历程以及 Flink社区当前最新的技术成果,最后展望下一个十年 Flink 路向何方。
313 33
The Past, Present and Future of Apache Flink
|
3月前
|
SQL Java API
Apache Flink 2.0-preview released
Apache Flink 社区正积极筹备 Flink 2.0 的发布,这是自 Flink 1.0 发布以来的首个重大更新。Flink 2.0 将引入多项激动人心的功能和改进,包括存算分离状态管理、物化表、批作业自适应执行等,同时也包含了一些不兼容的变更。目前提供的预览版旨在让用户提前尝试新功能并收集反馈,但不建议在生产环境中使用。
895 13
Apache Flink 2.0-preview released
|
3月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
114 3

推荐镜像

更多