目录
一、离线开发
1.1 概述
离线开发套件封装了大数据相关的技术，包括数据加工、数据分析、在线查询、即席分析等能力，同时将任务的调度、发布、运维、监控、告警等进行整合，让开发者可以直接通过浏览器访问，不再需要安装任何服务，也不用关心底层技术的实现，只需专注于业务的开发，帮助企业快速构建数据服务，赋能业务。
将数据汇聚到中台后需要对其进行进一步加工处理，一般来说，企业有60%～80%的场景需要用到离线批处理的能力，这个过程就像一条数据的生产流水线，让采集和汇聚起来的原始数据经过离线加工的各个环节和相应的数据处理模型，形成有价值的数据资产。在这个过程中，离线开发套件需要一些核心功能（如作业调度的策略机制、对于数据生产时效的基线控制、企业当前信息化架构下各类异构数据源的适配、数据权限的管控等）来保障数据加工的过程易用、可控。
1.2 作业调度
在数据开发过程中，经常需要配置作业的上游依赖作业，这样作业之间便会组成一个有向无环图(DAG)，同时会配置作业的开始调度时间。
例如，对于下图中的作业B来说，其父作业是作业为A和C，调度开始时间设置为05:00。
- ❑依赖调度：在所有父作业运行完成后，当前作业才能开始运行。例如，上图中的作业B，只有在父作业A和C运行完成后，才能开始被调度。
- ❑时间调度：可指定作业的调度开始时间。例如，上图中的作业B，只有到达05:00后才能开始被调度。如果一个节点既有父作业又有调度时间约束，那么在调度过程中只有同时满足两种约束条件，才能开始被调度。
1.3 基线控制
在大数据离线计算中，由于作业执行时间较长，经常会遇到急着用数据却发现数据还没出来的情形。重新跑数据需要几个小时，时间已然来不及。因此本书提出一种基线控制方法，用于统一管理数据处理作业的完成时间、优先级、告警策略，保障数据加工按时完成。调度模块会根据最先到达、最短执行时间原则，动态调整资源分配及作业的优先级，让资源利用效率最大化。同时采用算法对作业完成时间进行智能预测。根据预测，当作业无法正常产出且动态调整无法完成时，调度中心会及时通过监控告警通知运维值班人员提前介入处理，为大数据作业执行留出充裕的时间。
1.4 异构存储
当前，企业内部的计算存储引擎呈现多元化趋势。例如，国内某大型企业同时使用Oracle、IQ、HANA、Hadoop、LibrA等多种数据库，涉及关系型DB、MPP、大数据数仓等多种类型。其离线开发中心会针对每种类型的计算引擎开发不同的组件，例如，针对Oracle开发Oracle插件，针对Hadoop体系开发出Hive、Spark、MapReduce等插件。用户只需要新建各种类型的作业，例如Oracle、IQ、HANA、Hive、Spark、LibrA等，在执行时自动根据作业的类型寻找相应插件来运行作业。
1.5 代码校验
在离线任务的开发过程中，会涉及各种各样的任务类型。对于常见的SQL任务类型，SQL检查器会做好严格的管控，做到事前发现问题，避免代码在周期调度过程中或运行完成后才发现问题。校验分为语法校验和规则校验。
- ❑语法校验是对SQL的语法进行校验。不同类型的SQL语法是不一样的，如常用的Hive、Spark、Phoenix等；相同类型而不同版本的SQL语法也不一样，如Spark 1.x、Spark 2.x等。
- ❑规则校验是指SQL检查器根据规则库提供的规则，对SQL进行校验。校验的规则是可以动态添加和扩展维护的，比如可以包含代码规范校验、代码质量校验、代码安全校验等。
1.6 多环境级联
可以通过环境级联的方式灵活支持企业的各类环境需求，方便对资源、权限进行控制和隔离。例如在新建项目时，企业可根据自身需求配置各种环境和级联方式，每个环境拥有独立的Hive数据库、Yarn调度队列，甚至不同的Hadoop集群。
常见环境如下：
- ❑单一环境：只有一个生产环境，内部管理简单。
- ❑经典环境：开发环境中存放脱敏数据，供开发测试使用，上生产走发布流程，用于真实数据生产。
- ❑复杂环境：企业有外部人员和内部人员时，会给外部人员提供一个脱敏管控的环境，外部人员开发完的数据模型经过测试后发布到内部开发环境，由内部员工检查确认及内部测试验证流程，完成确认后发布。在内部生产、内部开发、外部开发等环境中，数据样本也会根据面向的群体不同，进行不同等级的加密和脱敏处理。
在新建项目时，一般会创建开发和生产两个环境，开发环境用于用户开发、任务调试，生产环境即线上环境，系统默认会按天进行周期调度以执行任务。生产环境不允许用户直接操作任务、资源和函数，用户必须在开发环境下进行新建、修改或删除，在经过提交、创建发布包、同意发布三个操作后，才可将发布包同步到生产环境。
1.7 推荐依赖
随着业务的不断深入，企业对工作流和作业与业务结合的理解越来越深，数据开发人员需要开发的作业会不断累加，峰值时，一个工作流下会挂成千上万个作业。这会让工作流任务的人工维护非常艰难。如何从上千个作业中找到需要依赖的上游作业？如何保证选定了上游作业后，不会因形成环路而导致调度失败？这时候就需要一把能自动推荐上游作业的利器，既能保证准确找到需要定位的上游作业，又能保证不会形成环路。可以看下图所示的节点依赖：
已知表A、B、C、D、E、F、G及其依赖关系，现开发了两个新的作业H和L，需要为其设置上游依赖信息。
智能推荐依赖的工作原理如下：
- ❑获取推荐依赖的核心原理在于上下游作业输入和输出的表级血缘依赖图；
- ❑通过血缘分析当前作业的输入和输出，找到合适的上游作业；
- ❑对合适的作业进行环路检测，剔除存在闭环的作业；
- ❑返回合适的节点列表。
通过上图中的关系，可以智能推荐出H节点的上游作业为D、G，L节点的上游作业为E、G。
1.8 数据权限
由于企业内部计算引擎的多样化，数据权限的管理会面临如下问题。
1）部分引擎拥有独立的权限管理系统（例如Oracle、IQ、HANA、LibrA），导致权限申请需要到每一种引擎上单独操作，让使用变得复杂。
对于同一种计算引擎，不同厂商的权限系统有多种。例如，Hadoop自身无数据权限系统，由不同厂商各自实现，目前主要有以下两种策略。
- ❑RBAC（Role-Based Access Control，基于角色的访问控制）：比如Cloudera用的是Sentry，华为的FusionInsight也是用的类似的机制。
- ❑PBAC（Policy-Based Access Control，基于策略的访问控制）：比如Horton-works用的是Ranger。
2）数据权限是由大数据集群或数据库运维人员管理的，开发人员无法直接操作或者接触，所有的权限申请都需要运维人员审批，造成运维人员负担过重。在实际开发中，一般需要运维人员把整个库的权限授权给某个开发负责人，由其负责库里的表、字段、函数的权限管理。
3）缺乏一套能同时支持多种计算引擎的权限申请、审批、管理系统。本书提出的数据权限管理目标就是构建统一的数据权限管理中心来支持多种引擎，可以直接在此中心上进行各种引擎的权限申请、审批和管理，无须接触底层引擎的权限管理系统。在适配不同引擎时，仍旧采用插件化的设计思路，针对每种权限管理系统开发一种插件，并支持用户通过二次开发来扩展插件。
数据权限管理中心提供界面化操作。数据申请方直接在页面上进行各种权限的申请，数据管理方在界面上审核权限，执行同意或拒绝操作。同时，所有权限的申请、审批都会有记录，便于进行权限审计。在统一数据权限服务中，会对接底层的各种权限管理系统，例如Sentry、Ranger、Oracle，同时对数据权限管理中心提供服务，执行权限的申请、授权、撤销等操作。
二、实时开发
2.1 概述
随着数据的应用场景越来越丰富，企业对于数据价值反馈到业务中的时效性要求越来越高，很早就有人提出过一个观点：数据的价值在于数据的在线化。实时开发套件是对流计算能力的产品封装。实时计算起源于对数据加工时效性的严苛需求：数据的业务价值随着时间的流逝会迅速降低，因此在数据产生后必须尽快对其进行计算和处理。
2.2 实时计算的特点
2.2.1 实时且无界(unbounded)的数据流
实时计算面对的计算是实时的、流式的，流数据是按照时间的先后顺序被实时计算订阅和消费的。并且，由于数据产生的持续性，数据流将长久且持续地集成到实时计算系统中。
2.2.2 持续且高效的计算
实时计算是一种“事件触发”的计算模式，触发源就是上述的无界流数据。一旦有新的流数据进入实时计算，实时计算立刻发起并进行一次计算任务，因此整个实时计算是持续进行的高效计算。
2.2.3 流式且实时的数据集成
流数据触发一次实时计算的计算结果，可以被直接写入目标存储中，例如，将计算后的报表数据直接写入MySQL进行报表展示。因此，流数据的计算结果可以类似流数据一样持续写入目标存储中。
2.3 元数据管理
实时开发的元数据管理包括各类Flink的流表和静态表（以下简称Flink表）以及流计算相关的消息队列中数据的数据格式。Flink表由多种数据库类型的表组成，格式多样；而消息中间件中的数据往往是没有格式约束的，导致后面进行实时计算时无法直接将消息流映射为结构化对象来进行SQL加工。统一元数据管理可以指定统一的catalog类型，将Flink表和Topic中相应的元数据信息统一维护到元数据注册中心，将数据和元数据进行解耦。在进行流计算和实时采集时，采集组件会通过数据表自动获取数据变化，并根据Topic自动寻找对应的元数据信息进而形成数据流，以便进行后续的实时计算。实际场景中，巨量的数据加工对存储及网络带宽都会带来一定的压力，选择特殊存储格式和压缩尤为必要。因此，元数据管理还支持配置各种数据存储格式，例如JSON、Avro、Protobuf。
2.4 SQL驱动式开发
可以将流计算当作动态数据表中的持续查询，将动态变动的视图看作变动的数据流。鉴于SQL的普适性，流计算SQL化可以大大减少开发人员的工作量，提高其开发效率。将变动的实时数据（如Kafka中不断推送的消息）、较少变动的维度表（如HBase、kudu表数据、CSV文件、MySQL表）等加载到流中，注册为临时视图。同时，加工的中间结果也可以注册为视图，这样在视图上就可以做SQL化的转换处理，最后写入结果表中。
2.5 组件化开发及监控告警
为了更便捷地开发流计算任务，需要将流计算的输入源、转换逻辑、UDF（用户自定义函数）、结果的持久化等封装为组件。开发人员可以通过拖曳相关组件来进行简单的配置和SQL逻辑编写等，将任务具体化为流计算的加工拓扑图，由平台负责任务的调度、解析及运行。在流计算中，基于窗口的计算往往需要基于时间维度划分计算窗口。而在实际业务场景中，eventTime的数据来源各式各样，业务时间可能来自某些时间戳、字符类型的字段、多字段中日期与时间的组合，而时间格式也可能不同，因此统一eventTime尤为必要。简单选择或组合字段、日期格式后，由流计算平台进行统一eventTime处理，以利于后续基于窗口的加工计算。
对数据流中的加工数据可以配置延迟告警信息。当数据积压超过阈值时，可发出延迟告警，同时会触发流计算的backPressure机制，使输入流的速度变慢，从而不至于使整个流计算任务意外终止。对流计算中各组件的吞吐量、流速（读取、加工及写入的速率）等指标做统计分析，能帮助用户更加直观地分析计算瓶颈，进而准确地定位问题并进行优化。
2.6 实时开发应用-实时数仓
传统意义上的数据仓库主要处理T+1的数据，而实时数仓一般是分钟级甚至秒级的ETL方案。准确地说，实时数仓要让数仓中的数据全实时地流动起来，而不是以微批(mini-batch)的方式流动。Flink的发展，可以让流计算真正实现端到端全链路实时化分析能力，通过Flink的流批一体能力和Flink CDC，可以让数据先进行全量的历史数据处理，再无缝对接增量数据，并且可以通过检查点(checkpoint/savepoint)进行断点续传。在实时数仓的构建中，用户可以自己选择数据是否需要中间落地。
同时，数据湖的发展，将数据仓库的数据结构和管理功能与数据湖的低成本存储和灵活性相结合，为企业提供一个统一、可共享的数据底座，同时解决了大数据存储下数据的upsert、事务ACID、存算分离以及元数据管理问题。避免传统的数据湖、数据仓库之间的数据移动，将原始数据、加工清洗数据、模型化数据共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据和实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务，即“湖仓一体”。
实时数仓主要采用Kappa架构如下图：
好了，本次内容就分享到这，欢迎大家关注《数据中台》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
标签：作业,离线,实时,开发,中台,计算,权限,数据 From： https://blog.csdn.net/qq_25409421/article/details/141227663