在编程魔术师-01里面，大致提及了数仓的发展以及半结构化实时计算引擎。
简单回顾以一下，其中主要分为以下几点：
- 半结构化引擎:
引入了SQL on lambda以及transducer流式复合技术 - 存储模式与计算分离:
通过[云存储]保障数据的可用性以及快速恢复数据，通过[云计算平台]进行水平扩展，克服传统数仓数据量过大备份后快速恢复难题。 - 实时引擎:
非明细累积计算需要实时引擎
大量的批量引擎可以迁移到实时引擎 - 批量引擎:
SQL On lambda后续会成为引导半结构化的先锋。
批量引擎更加侧重于多次迭代性的算法性功能。
感觉还没写过瘾，今天给大家带来重磅杀器: 响应式数据仓库架构！
半结构化，实时，响应式？这是啥数据仓库？能不能讲清楚点？
半结构化是数仓的[数据模式]，实时半结构化是数仓的[计算引擎]。
也就是数据结构+算法。那响应式呢?
响应式是架构！架构涉及了一个生态的构建。
我们简单介绍一下基础知识:
- 血缘分析系统:
讲血缘分析听起来很高级，其实是啥呢？就是依赖关系！
依赖个啥呢？
[调度系统-依赖] on [元数据管理系统-数据模式] - 元数据管理系统-catalog+SQL
数据模式catalog源自于设计，
一般过程是 主题层(业务需求)-> 逻辑层(度量维度矩阵)->物理层(catalog+SQL)
这个属于技术外的话题，就不展开讨论。
这里catalog是属于物理层，也是我们需要关心的一层。
而sql呢，则是catalog暴露给调度系统的作业接口。 - 数据服务系统-catalog外部依赖
调度系统根据catalog的SQL作业依赖接口进行调度。
catalog的上下游依赖又到哪里去了呢?
catalog的数据入口始入服务，数据出口也终于服务。
常见的服务有DB, SFTP/FTP, HttpRest。。。 - 调度系统-依赖dependency
现在整 个过程大致上很清楚了。
[数据服务系统]提供系统源数据，进入[元数据管理系统(catalog + SQL)], 最终又输出到[数据服务系统]。而[调度系统]则是根据整个模式的依赖转换调度SQL以及数据服务接口，最终完成了整 个数仓的批量。
SQL是一种数据模式的推导转换，将一种模式转换为另一种数据模式 - 数据质量监控系统-验证:
调度系统进行调度后，我们要进行验证。所以这个属于优化阶段任务，很多系统前期发展会非常 不完善。但是越来后期，随着系统扩展以及各种维护性要求，其重要性不言而喻！
OK，这些东西太基础了，都懂了，没问题！
现实生活中是怎么运行的呢？
x. 元数据管理系统由Excel充当，生成catalog + SQL。
x. 数据服务系统由FTP文件担当， 接入文件，输出文件
x. 调度系统动态根据作业依赖扫描每个作业，检查是否满足依赖后触发
x. 数据质量监控系统根据条件运行作业，发出报警
x. 血缘分析系统根据元数据管理系统以及依赖关系进行信息的读取诊断分析。
没有图，不直观，好吧，来个高级版本的后文介绍的架构图！
architecture
附上相关项目的github地址 ：
- 血缘分析:
[haskell] oracle/mysql/postgresql解析: https://github.com/JakeWheat/simple-sql-parser
[haskell] hive/presto/vertica解析:https://github.com/uber/queryparser - 作业调度:
[python] airflow调度器: https://github.com/apache/incubator-airflow - 数据服务平台:
[cpp] 分布式存储ceph: https://github.com/ceph/ceph
[go] 云计算k8s: https://github.com/kubernetes/kubernetes
[go] 函数即服务fnproject: https://github.com/fnproject/fn - 批量引擎:
[scala] spark: https://github.com/apache/spark
[c] postgres-XL: https://github.com/Postgres-XL/Postgres-XL - 实时引擎:
[java] ksql: https://github.com/confluentinc/ksql
好了，相关的参考资放在这里了。
那么我们要开始今天的主题了！响应式数据仓库架构
- 什么是响应式数据仓库，有何好处?
- 响应式数据仓库的挑战
- 响应式数据仓库解决方案!
1. 什么是响应式数据仓库?
响应式架构目前用得越来越多，简单来说，响应式就是按需执行，事件驱动。
最终达到的效果就是，无状态，状态以事件进行传递。
顺带提一下多骨诺米牌，大家应该会理解更容易一点。
a. 对于数据服务平台服务入口来说:
当外部文件到达时，它是不做任何处理的，仅仅作为一个存储服务, 数据仓库自己来取。
====> 而响应式架构则不一样
当外部文件到达时，数据服务平台发送watch/notify事件，下游系统可以订阅，进行按执行！传统的文件系统以及分布式ceph系统均支持notify接口。
b. 对于数据服务平台服务出口来说:
当接收外部的服务请求的时候，我们正常是启动服务进程等待客户端发起请求进行处理。
====> 如果以响应式架构来说
我们不应该没事去启动服务，而是当客户端真正请求的时候，我们才去加载函数进行处理，达到无服务效果。也就是现在开始流行的函数即服务架构faas。
c. 对于元数据管理系统来说:
正常的元数据是用户配置生成的。一般来说通过静态配置元数据动态生成catalog及sql是一种非常好的想法，毕竟是一种配置驱动的方案。但是这种方案问题很多，静态元数据的灵活度太差，并不能完全统一性的表达业务逻辑。所以代码生产器没有一个能成功占领市场的，比如informatica之类的工作必然替代不了SQL! 当静态元数据生产模块之后，模块逻辑辑满足不了必然要按需修改，这样生成的catalog+sql的信息度是远远高于业务静态元数据的，元数据管理系统的效果也会大大折扣！
====> 那么对于响应式架构来说，应该怎么处理呢?
当然应该去追踪变化，真正的变化来自于哪里？那就是实际的catalog跟sql，而不是用户配置元数据！但是实时的catalog跟sql差异变化极大。所以现在大部分的现状是构建一套标准的接口去动态获得各种类型，进行定制化修改，当然这在响应式是行不通的！响应式则采取完全相同的行为，通过追踪实际的catalog以及sql，进一步生成标准化元数据管理接口。信息是从细粒度按需暴露出相关视角，可以自由定制，自由 扩展。通过追踪低层的物理 层变化 ，最终达到了：敌动我动的响应式效果。
d. 对于调度系统来说:
传统的调度系统就是周期性地扫描所有作业，如果作业依赖全部满足，则进行触发。模型非常简单，但是隐患也非常大，如果里面的信息在周期扫描间发生了变更，多次扫描之间的副作用之间很有可能会有相互影响，导致调试成本极高。那么响应式架构是如何的呢？调度分为两块，一块是触发，一块是依赖解析。触发一般是时间触发，如果是外部系统触发，则可以采用数据服务平台的watch机制达到响应式。对于时间触发，传统的做法都是按间隔扫描。
====>响应式如何做到呢？
响应式调度则是将事件顺序排好序，需要调整的地方进行事件调用完成。比如现在有1点，3点，5点三个触发器，那么排好队[1点,3点,5点], 调度器然后罢干sleep到1点再按需干活。突然间，到了1点的时候，突然有个4点的触发器到达了，这时调度器被事件唤醒重新排好队[3点, 4点, 5点]。触发这块已经是响应式了，那么依赖解析呢？依赖解析也比较简单，就是构建一个依赖图，一个作业完成后检查触发下一个作业。最终以触发器作为源头，通过事件传播依赖完成整个批量的运行！
e. 对于数据质量监控系统来说:
传统的数据质量监控系统仅仅是定时触发。定时触发就是整体上验证正确性，毕竟整体上正确了，各部分也大致是正确的，对于异常情况，可以追加额外的验证！
====> 响应式架构则不一样
响应式架构有两种触发器，一种是时间 触发器，一种是作业触发器，这些都是调度系统自带的，所以对于响应式模式来说，数据质量监控仅仅是调度系统上的一个watch验证功能。通过watch特定时间, watch特定任务进行响应式验证。当然这是响应式验证的基本功能，响应式可以完成更加复杂的功能，也就是故障追踪。一旦发生故障，验证可以建立验证依赖树，每个叶子watch任务。当验证依赖树发生失败的时候，可以轻易获取叶子节点的状态进行追踪！
讲了这么多，响应式数据仓库有啥 好处呢？
好处得慢慢体会，这里不太细说。。。
a. 按需执行，节省资源，便于调试维护
b. 事件驱动，快速响应，减少系统交互的延迟
c. 依赖触发，方便统一进行事件追踪，方便进行外部扩展
2. 响应式数据仓库挑战! 请注意, 前方高能!
响应式数据仓库似乎看起来挺简单的嘛? 是吗?
呵呵，来点刺激的? 好戏开始上演。。。
a. 血缘分析逆向解析问题。
据前面所述，传统的数据仓库，元数据管理系统为配置驱动型开发，以静态元数据生成 catalog以及sql后进行定制，进一步加入元数据依赖配置构成配置型血缘关系。
由于静态元数据的标准化形式，很容易推导出不同数据仓库系统catalog及sql方言。
但是在响应式世界里面，我们是从sql跟catalog方言倒推标准形式，自动构建元数据以及作业依赖物理视图。技术难度大大提升。
响应式的好处自然就是无须人工干预，血缘分析系统追踪物理层数据自动生成作业依赖及元数据。从而进一步避免了需要手工配置作业依赖以及元数据逻辑层与物理层不兼容的情况。
b. 乱序执行问题。
传统的数据仓库一般是按天跑批，当然进一步发展可以按日期范围跑批。
按日期范围跑批也是极好的，因为可以将历史补批与单日跑批建立在统一的层次上。
如果是响应式跑批，我们可以达到更大的灵活性，直接突破传统模式。即我们可以任意时间跑批，任意顺序跑批，甚至任意不同日期组合跑批！
当然这个难度也是有所提升，不过可以面对日益复杂的环境。
毕竟数据部分延迟导致整个批量[数据周期不同步]，[历史日期数据缺失或损坏]多日后进行数据修复及补批的现象随着源系统的数量暴发而会日益普遍。
并且对于响应式数据仓库来说，调度系统与数据无关。调度系统按照日期及数据服务接口触发进行依赖关系检查后进行依赖游走执行批量，与其相关的是系统日期，而非批量日期！而对于调度[元数据系统数据模式推导关系SQL]来说，SQL仅关心数据日期及批量日期，而不关心系统日期。
传统的调度系统，将系统日期与数据日期混为一谈，实则是技术水平不成熟的表现！
所以调度系统应该没有日期，系统日期只是作业的元数据而已！
而响应式数据仓库采用增量事件触发进行依赖游走，进行完成数据的响应式转换。
c. 依赖游走问题。
既然现在调度没有日期了，并且数据方面会有乱序情况且周期不同步的情况产生。
这时候必然会产生依赖游走的计算规则。
依赖游走有二种增量传播形式:一种是无序并行，另一种是有序依赖
比如每天的交易量，就是无序并行依赖，也就是说每个批量之间相互没有影响。，
比如快照，新的数据优先级较低优先级高，或者 新的数据一定依赖于先前的数据日期批量，这种情况就是有序依赖。
依赖游走对于依赖关系绑定也有两种形式: 一种是被动触发，一种是主动触发。
正常情况下是被动触发，也就是由依赖游走自然进行增量传播。对于新加入的SQL，或者有数据保护特征功能的可以开启主动触发。何为主动触发，是根据自身与依赖对象的距离进行自我修复。比如依赖历史数据已经有了一年，对于第一次作业运行，自然是0，跑批模式是按天去跑，被动触发是一天的增量，而主动触发则是0到依赖历史数据距离一年的周期，所以可以轻松完成补批功能。而对于数据重跑，主动触发计算距离的时候距离并不做改变，所以不做任务处理，从而完成了数据的保护性。当触发一个数据时间段修复事件的时间 ，主动触发根据新的距离重新拉取最新的准确数据。
d. 监控自愈问题。
对于传统的数据仓库，数据质量监控报错之后是跟批量没有半点关系的，这时候需要人工干预。而对于响应式数据仓库架构来说，数据质量监控是调度系统的一个扩展，可以有效地进行故障追踪，以及批量自动修复。当数据质量监控系统捕获到异常后，数据质量系统首先进行多级别的故障追踪，接着定位故障点，对于故障点进行修复后，重提批量，完成自动化修复。
故障点检测技术也分为两种模式，一种是阻塞模式，另一种是贪心回弹模式。
阻塞模式相当简单，就是监测作业运行开始前或者运行完成后，进行数据质量检测脚本的运行，如果运行失败后就阻塞整个批量，等待数据修复事件的到来。而对于贪心回弹模式来说，数据运行完成后，异步进行数据质量检测，防止阻塞批量，正常情况下批量正常运行，数据质量临控可以慢悠悠地低优先级完成 。查是一旦发现异常情况点，数据质量监控回弹整个批量至故障点，阻塞批量等待数据修复事件出现。
网友评论