Joker

数据仓库是⼀个各种数据的中⼼存储系统(包括历史数据和当前数据)，是BI的核⼼组件。这⾥所说的数据包括来⾃ 企业内部的各种业务数据，例如订单、库存、交易流、账⽬、客户、供应商等，同时也包括从外部获取的各种数 据，例如爬⾍通过合法⼿段爬取得数据。 一、数仓概述1.1. 数仓&BI商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出合理的、明智的经营决策的⼯具，是企业数 字化转型的关键系统。为了将数据转化为知识，需要利⽤数据仓库、联机分析处理(OLAP)⼯具和数据挖掘等技术。 1.2. OLTP vs OLAP1.2.1. OLTPOLTP(Online Transaction Process) 联机事务处理，侧重于数据库的增删查改等常⽤业务操作，强调事物和并发。 1.2.2. OLAPOLAP(Online Analytical Process) 联机分析处理，即以多维的⽅式分析数据，强调磁盘IO吞吐，⼀般采⽤分区技术、并⾏处理技术。 OLAP是⼀种软件技术，它使分析⼈员能够迅速、⼀致、交互式的从各⽅⾯观察数据，以达到深⼊理解数据的⽬ 的。从各⽅⾯观察数据，也 ...

数据湖是⼀个以原始格式(通常是对象块或⽂件)存储数据的系统或存储库。数据湖通常是所 有企业数据的单⼀存储。⽤于报告、可视化、⾼级分析和机器学习等任务。数据湖可以包括来⾃关系数据库的结构 化数据(⾏和列)、半结构化数据(CSV、⽇志、XML、JSON)、⾮结构化数据(电⼦邮件、⽂档、pdf)和⼆进制数据(图 像、⾳频、视频) 原始格式：数据不做预处理，保存数据的原始状态 单⼀存储：存储库中会汇总多种数据源，是⼀个单⼀库 ⽤于机器学习：除了 BI 、报表分析，数据湖更适⽤于机器学习 一、概述1.1. OLTP -> OLAP -> HTAP -> 数据湖 概念 场景 典型代表 主要优缺点 数据库 OLTP 三大数据库（Oracle、 MySQL、SQLServer） OLTP支持的非常好， OLAP支持弱 数据仓库 OLAP Teradata、Greenplum、 Hive+HDFS、ClickHouse、 Kylin OLAP支持非常好，OLTP 不支持或者支持的弱 混合数据库 HTAP=OLTP+OLAP Kudu(先OLAP在OLTP) ...

CDC 的全称是 Change Data Capture ，在广义的概念上，只要是能捕获数据变更的技术，我们都可以称之为 CDC 。目前通常描述的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。CDC 技术的应用场景非常广泛： 数据同步：用于备份，容灾； 数据分发：一个数据源分发给多个下游系统； 数据采集：面向数据仓库 / 数据湖的 ETL 数据集成，是非常重要的数据源。 一、CDC 概述CDC 的技术方案非常多，目前业界主流的实现机制可以分为两种： 1.1. 基于查询的 CDC 离线调度查询作业，批处理。把一张表同步到其他系统，每次通过查询去获取表中最新的数据； 无法保障数据一致性，查的过程中有可能数据已经发生了多次变更； 不保障实时性，基于离线调度存在天然的延迟。 1.2. 基于日志的 CDC： 实时消费日志，流处理，例如 MySQL 的 binlog 日志完整记录了数据库中的变更，可以把 binlog 文件当作流的数据源； 保障数据一致性，因为 binlog 文件包含了所有历史变更明细； 保障实时性，因为类似 binlog 的日志文件是可以流式 ...

Flink CDC 基于数据库日志的 Change Data Caputre 技术，实现了全量和增量的一体化读取能力，并借助 Flink 优秀的管道能力和丰富的上下游生态，支持捕获多种数据库的变更，并将这些变更实时同步到下游存储。 一、Flink CDC 介绍从广义的概念上讲，能够捕获数据变更的技术, 我们都可以称为 CDC 技术。通常我们说的 CDC 技术是一种用于捕获数据库中数据变更的技术。CDC 技术应用场景也非常广泛，包括： 数据分发，将一个数据源分发给多个下游，常用于业务解耦、微服务。 数据集成，将分散异构的数据源集成到数据仓库中，消除数据孤岛，便于后续的分析。 数据迁移，常用于数据库备份、容灾等。 目前，Flink CDC 的上游已经支持了 MySQL、MariaDB、PG、Oracle、MongoDB 等丰富的数据源，对 Oceanbase、TiDB、SQLServer 等数据库的支持也已经在社区的规划中。 Flink CDC 的下游则更加丰富，支持写入 Kafka、Pulsar 消息队列，也支持写入 Hudi、Iceberg 等数据湖，还支持写入各种数据仓 ...

中台是为了通过服务化的⽅式实现技术、资源复⽤，解决快速⽀撑业务 发展的问题。 在传统 IT 时代，无论项目如何复杂，都可分为 “前台” 和 “后台” 两部分，简单明了。 这里的前台不是我们理解的前端，而是大前端(PC、移动等)，还包括提供的各种服务。 后台指的是底层的服务，例如研发人员为了方便，自己抽取出的公共模块/方法 在传统IT时代，项⽬的发展相对稳定，并不需要像互联⽹时代那么快速的去迭代和试错，所以这种结构并⽆问题。 在互联⽹快速发展的今天，竞争越来越激烈。只有以⽤户为中⼼，快速适配⽤户的需求，不断迭代和试错，才能让 企业在竞争当中⽴于不败。以阿⾥的中台为例： 华为把作战⼩分队⽐喻为前台项⽬团队，把中台⽐喻成战地指挥部。在这个⽐喻当中，中台的作⽤就是提供资源⽀ 持：要数据给数据、要技术给技术。正是因为有了中台战略，华为才能快速孵化出华为⼿机、华为荣耀、华为云等 品牌。 一、数据中台概述1.1. 数据中台架构数据中台，⽬的总结下来⼀句话：**通过服务化的⽅式增强数据的共享能⼒以实现数据的复⽤，解决数据研 发、数据分析、数据运营时碰到的痛点问题:** 指标⼝ ...

网易云音乐从 2018 年开始搭建实时计算平台，经过几年的发展已经渗透到云音乐的各个业务当中。本文是大愚老师的一篇实践分享，将从一个日常运维问题出发，带领大家了解云音乐实时计算平台的一些工作进展和未来规划。主要内容为: 平台功能 流批一体 未来规划 网易云音乐实时数仓平台上线以后，经过一年半的发展，整体实时数仓已经初具规模，我们已有实时数仓表 300+，运行中的任务数有 1200+。其中 1000 左右的任务是 SQL 任务， Kafka 总出口流量达到到 18GB/S，总用户数达到了 200+。 数据量和用户的增长也给数据平台的易用性以及稳定性带来了了越来越多的挑战，包含 Kafka 的稳定性、集群的稳定性、运维工作的挑战以及很多早期的技术债；业务的增长，暴露出了基建的薄弱，也给我们积累了很多平台建设和运维的经验。 1. 平台功能我们平台整体的的功能大家可以参考《云音乐实时数仓技术改造以及未来的一些规划》，这里将主要介绍我们最新的一些工作： “我的任务延迟了，怎么扩容都不行，这是为什么？” 在日常运维工作中这是我们经常遇到的问题，往往也是比较耗费时间的问题。导致这种这种问题的 ...

本文主要介绍顺丰在数据仓库的数据实时化、数据库 CDC、Hudi on Flink 上的实践应用及产品化经验。文章主要分为以下几部分： 2020-12-30 顺丰业务介绍 Hudi on Flink 产品化支持 后续计划 一、顺丰业务1.1 顺丰大数据的应用先来看一下顺丰大数据业务的全景图。 大数据平台，中间的基础部分是大数据平台，这块是顺丰结合开源组件自行搭建的。与之相关的是大数据分析与人工智能，顺丰有一个非常强的地面部队，就是线下的快递小哥以及运输车辆，需要使用 AI 以及大数据分析来辅助管理，提升整体效率。 区块链，顺丰对接了很多客户与商家，对于商家来说，首先需要确保快件是可信的能够做货物的交易与交换。这块涉及的基本上都是品牌商家，溯源与存证的业务顺丰也有涉及。 IoT，就像之前提及到的，因为顺丰地面部队较多，相应需要采集的数据也会比较多。我们的部分包裹中是有传感器的，车辆也有相关的传感器，如车辆的摄像头，以及快递小哥的手环（包含地理位置、员工的健康状态，对应做一些关怀的举动）。同时，还有一些工作场景既有叉车，也有分拣设备，这些就需要大数据平台来做一些联动， ...

Hudi 内部对每个表都维护了一个Timeline，这个Timeline是由一组作用在某个表上的Instant对象组成。Instant表示在某个时间点对表进行操作的，从而达到某一个状态的表示 Instant 包含 Instant Action，Instant Time 和 Instant State 这三个内容，它们的含义如下所示: Instant Action: 对Hudi表执行的操作类型，目前包括 COMMITS CLEANS DELTA_COMMIT COMPACTION ROLLBACK SAVEPOINT 这6种操作类型。 Instant Time: 表示一个时间戳，这个时间戳必须是按照 Instant Action 开始执行的时间顺序单调递增的。 Instant State: 表示在指定的时间点(Instant Time)对Hudi表执行操作(Instant Action)后，表所处的状态，目前包括REQUESTED(已调度但未初始化)、INFLIGHT(当前正在执行)、COMPLETED(操作执行完成)这3种状态。 根据官网给出的一个例子来理解一下 T ...

Apache Hudi 依赖于 HDFS 做底层的存储，所以可存储的数据规模是巨大的，同时基于以下两个原语，Hudi 可以将流批一体的存储问题。 Update/Delete 记录: Hudi 支持更新/删除记录，使用文件/记录级别索引，同时对写操作提供事务保证。查询可获取最新提交的快照来产生结果。 Change Streams: 支持增量获取表中所有更新/插入/删除的记录，从指定时间点开始进行增量查询，可以实现类似 Kafka 的增量消费机制。 1. Copy-On-Write 表1.1. 什么是 copy-on-writeCopy-On-Write 是一种较为普遍和通用的存储优化策略，它在 Linux 和 JDK 中都有使用，可以翻译为写时拷贝 如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently） 简 ...

数据处理现状：当前基于Hive的离线数据仓库已经非常成熟，数据中台体系也基本上是围绕离线数仓进行建设。但是随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直聚焦并探索于两个相关的热点问题：实时数仓建设和大数据架构的批流一体建设。 一. 实时数仓建设: 实时数仓1.0传统意义上我们通常将数据处理分为离线数据处理和实时数据处理。对于实时处理场景，我们一般又可以分为两类，一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；另一类诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可以接受。 对于第一类实时数据场景来说，业界通常的做法比较简单粗暴，一般也不需要非常仔细地进行数据分层，数据直接通过Flink计算或者聚合之后将结果写入MySQL/ES/HBASE/Druid/Kudu等，直接提供应用查询或者多维分析。如下所示： 而对于后者来说，通常做法会按照数仓结构进行设计，我们称后者这种应用场景为实时数仓，将作为本篇文章讨论的重点。从业界情况来看，当前主流的实时数仓架构基本都是基于Kafka+Flink的架构（ ...