【及时数仓架构】方法论

笔者不是专业的及时数仓架构，这是笔者从其他人经验和网上资料整理而来，仅供参考。写此文章意义，加深对及时数仓明确。
一、及时数仓架构技术演进

1.1 四种架构演进

1）离线大数据架构
  一种批处理离线数据分析架构，通过采用Hadoop技术栈，采用任务调度工具+小时/分钟级别调度任务方式，到达小时/分钟级别的及时数据分析。
2）Lambda架构
  一种以批处理为主的离线数据分析架构，它将数据处理分为及时和离线两部分，此中离线部分通过批量计算来处理数据，及时部分则通过增量追加方式将数据合并到批处理效果中。

上风：满意及时处理低耽误需要，数据修正计算资源消耗少。
劣势：同样的需求需要开发两套一样的代码。后期维护困难，数据同等性得不到保证。
3）Kappa架构
  一种以流处理为主的及时数据分析框架，它将及时数据直接存储在Kafka等消息队列中，并通过流处理器将数据转换为目的数据模子。

上风：架构简单，避免了维护两套体系还需要保持效果同等的问题，也很好解决了数据订正问题。
劣势：在 Kappa 架构中，需求修改或汗青数据重新处理都通过上游重放完成。Kappa 架构最大的问题是流式重新处理汗青的吞吐能力会低于批处理。消息中间件缓存的数据量和回溯数据有性能瓶颈。
4）数据湖架构
  一种存算分离为主的同一存储（数据湖格式满意ACID）、多样化计算引擎的数据分析架构，它将及时数据的明细、中间、效果写入同一存储，供多样化计算引擎及时查询和访问。

上风：hudi、 iceberg 本身提供了ACID属性，这些特性可以解决数据回溯本钱高，OLAP引擎结合困难的问题。
劣势：采用Copy-on-Wite （COW）会造成写放大，影响写入的性能；采用Merge-on-Read(MOR)会造成读放大，影响及时数据的查询分析性能：而湖格式存储，通常采用COW或者MOR，不可两者兼得，会造成性能不敷以满意实行业务需求，通常存在分钟级别或者是小时级别的耽误。
1.2 架构能力对比

技术组件和实效性对比
离线大数据Lambda架构Kappa架构数据湖架构典型技术组合离线：Hadoop+Spark；
调度工具：Azkaban；
OLAP引擎：Impala/presto；
数据服务：HBase离线：Hadoop+Hive/Spark 流处理；
Flink OLAP引擎：ClickHouse；
数据服务：HBase流处理：Flink；
OLAP引擎：Doris；
数据服务：HBase湖格式：Hudi/iceberg/Delta on HDFS；
流处理：Flink；
OLAP引擎：Impala/Pretsto；
数据服务：HBase数据源结构化/半结构化结构化/半结构化结构化/半结构化结构化/半结构化、非结构化及时处理技术栈无典型代表：Spark Streaming、Flink典型代表：Flink典型代表：Flink及时性小时/分秒/毫秒秒/毫秒小时/分 及时数据分析对比
离线大数据Lambda架构Kappa架构数据湖架构及时数据存储HDFS，且OLAP&HBase基于HDFS离线数据：HDFS；
及时数据：CK+HDFS（HBase底层存储）OLAP引擎：DorisHDFS及时数据更新能力HDFS: OverwriteHDFS: Overwrite；
CK：更新能力不美满；
HBase: UpsertDoris: UpsertHudi/Iceberg/Delta : Upsert及时查询DWD、DWS中间层效果支持查询中间效果一般不写入OLAP引擎；
写入HDFS，则支持查询中间效果存储Kafka，不支持查询支持查询及时性小时/分秒/毫秒秒/毫秒小时/分OLAP引擎Impala/presto查询性能弱，适合联邦查询CK适合单表聚合，多表Join能力差Doris单表和多表Join查询能力较好湖格式有相干索引能力，查询性能优Impala/Presto on HDFS数据服务利用HBase，支持高并发，离线及时数据都可查利用HBase，支持高并发，只能查及时数据利用HBase，支持高并发，只能查及时数据利用HBase，支持高并发，离线及时数据都可查及时AI分析基于Spark ML/TF/PyTorch离线训练和推理基于Flink ML/TF/PyTorch及时训练和推理基于Flink MLTF/PyTorch及时训练和推理基于Flink MLTF/PyTorch及时训练和推理 管理对比
离线大数据Lambda架构Kappa架构数据湖架构运维本钱维护一套代码，难度较小维护两套代码，难度较小维护一套代码，难度较小维护一套代码，难度较小数据孤岛离线及时数据在同一个存储介质离线及时数据在差异存储介质离线及时数据在同一个存储介质离线及时数据在同一个存储介质数据同等性离线、及时数据和指标不同等概率小离线、及时数据和指标不同等概率大离线、及时数据和指标不同等概率小，少量修正离线、及时数据和指标不同等概率小，少量修正 1.3 及时数仓

1.3.1 及时数仓定义

  遵循数据仓库的建立规范，一种支持事件发生后立刻或不久对事件数据进行处理和分析的解决方案，数据及时收罗、写入、加工、分析、应用都是连续，提供数据产生到应用的端到端秒级相应能力，以最小的耽误产出数据见解驱动业务举措。
1.3.2 及时数仓特点

1、毫米级耽误
低耽误重要体现三方面：
  1）整体链路：端到端毫秒耽误；
  2）数仓层级：层级毫秒级耽误；
  3）数仓数据：及时写入/更新/可见/可查，数据毫米级耽误。
2、高吞吐写和高QPS度
3、智能化
  及时数仓能够做到智能自适应，根据业务数据波峰波谷，自动调用计算资源；统计数据访问频次，自动完成冷热数据切换，兼顾性能、本钱、自运维。
4、高可用架构
  及时数仓应该具备高可用，通过架构摆设或者产物能力实现从集群、负载格力、服务主备等本领，避免单一故障，有应急体系可切换利用，服务不断。
5、高水平数据管理
  及时数仓需要建立美满的数据资产管理，包括但不限于源数据管理、数据安全、数据脱敏、数据备份、数据血缘、数据目录等，实现数据可查、能用、可用、好用。
6、支持混淆负载
  及时数仓盼望能多种类型的混淆负载一体化支持，差异负载能够做到相互隔离不干扰，即一个引擎支持多种场景，简化架构、保证数据同等性。
1.4 及时数仓典型业务场景

  通常来讲，企业构建及时数仓，有以下几大类业务场景和技术需求。
1.4.1 六类场景

1）及时描述类：
  场景描述：通过数据及时反馈业务正在发生什么，协助管理层第一时间做出业务决策。
  教育行业场景-数据看板：收罗企业的B段业务数据，包含生意业务、教学、人员等数据，按照差异的条件和学习层级等，形成营收、教学等及时报表。
  核心技术需求：及时预计算分析、离线及时数据关联分析
2）及时运营类
  场景描述：通过数据及时诊断业务为什么发生，找到差异性和根因，协助执行层及时决策和及时调控相干策略。
  电商行业场景-精准营销：产出及时用户标签数据，然后做人群圈选、用户画像分析、对差异的人群、差异的活动策略做AB测试，及时评估活动效果和差异性，及时调整人群包和营销活动。
  核心技术需求：OLAP分析、多维分析、即时分析、标签护具高效分析。
3）及时监控类
  场景描述：通过数据及时识别业务正在发生的风险，及时预警供相干人及时干预。
  行业场景-链路监控：直播行业的网络异常监控，及时处理较少投诉率。物流行业及时整合多源数据，结合出入库、仓库作业等及时数据协助小二日常物流订单分析、订单派送。
  核心技术需求：高QPS的在线数据服务、及时规则引擎、及时复杂时间处理
4）及时预测类
  场景描述：通过数据及时预测业务未来可能发生的风险或者举动，提前干预降低风险本钱，促进业务规模化增长。
  行业场景-及时推荐：在搜刮、推荐、广告行业，及时收罗用户举动数据，计算及时特征，预测用户点击率/转化率，然后做个性化推荐，提拔业务效果。
  核心技术需求：及时特征/样本计算、及时AI、高QPS的在线数据服务、向量召回。
5）及时自动决策类
  场景描述：通过对市场的及时势件的数据分析，快速相应市场变化，自动完成相干生意业务和价格调整。
  金融行业场景-金融量化投资：基于提前建立的生意业务模子实现生意业务执行的自动化，通过对市场数据的及时监控和分析，快速相应市场变化，减少人为干扰和误操作，提高生意业务效率和准确率。
  核心技术需求：及时特征/样本计算、及时AI、高QPS的在线数据服务
6）及时用户增长类
  场景描述：通过对用户及时举动数据，在用户拉新、促活、流失、召回环节及时决策，实现日活、月活用户量的增长。
  游戏行业场景-游戏发现：基于用户及时举动数据，通过广告只能投放优化买量，提拔用户拉新ROI。通过及时个性化推荐，促活。其他等。
  核心技术需求：及时特征/标签计算、OLAP分析、高QPS在线数据服务、向量召回、高效的留存/漏斗分析函数。
1.4.2 及时看板/大屏

  此类需求在技术上，常需要业务生意业务数据，设计高层管理人群关注的核心指标，基于及时数据计算毫秒级计算指标值，存储是OLAP引擎中，最终在展示工具设计出数据看板和大屏访问。
1.4.3 及时OLAP分析

  此类需求在技术上，需要查询业务总体情况，发现差异，然后基于数据立方体能力，从多维度、多指标对比分析，找到差异缘故原由，反向指导业务的运作。
1.4.4 及时风险监测

  该场景下，起首及时收罗装备、生意业务数据、结合生意业务数据，其次通过及时规则+AI算饭的智能识别，将风险、故障灯举动数据和用户，汇总推到相干人群做后续执举措作，完成风险识别、推送、执行的闭环链路。
1.4.5 及时推荐

  及时推荐场景下，起首收罗用户举动数据进消息队列，其次基于及时数据计算完成及时特征计算，结合静态(离线)特征一起存储，即用户标签和画像，此时及时推荐的推理服务即可利用及时+离线特征进行物品推荐。更进一步，会结合及时特征+明细举动数据，基于Base离线模子，周期训一个及时模子，然后跟已经上线模子做对比，效果优则上线，此时完成及时推荐AI模子的更新。

---

二、需求分析

2.1 功能性需求

这些需求通常是可以明确的，可以被度量。重要包含以下几个方面：
1、及时数据收罗
  1）离线数据同步
  2）及时数据同步：基于消息中间件的数据及时入仓；基于CDC数据及时入仓。
2、及时数据计算
3、及时数据存储
4、及时数据分析服务
5、及时数据接口
6、数据资产管理
2.2 非功能性需求

1、可用性
   1）服务可用性；2）容灾备份
2、安全性
   1）体系安全：比如账号认证、账号授权、日记审计
  2）数据安全：比如安全认证及尺度、存储加密、传输加密、数据脱敏
  3）网络安全：比如底层服务网络安全、网络隔离、白名单
3、高性能
  1）数据耽误性能；2）数据及时收罗性能；3）数据及时计算性能；4）及时数据存储性能；5）分析服务性能
4、本钱可控
  1）显性本钱：比如产物组件的脊梁、产物组件的利用、资源分层利用策略
  2）隐性陈本：产物利用本钱、产物运维本钱、产物技术升级本钱
5、可观测性
  1）体系层面可观测：比如集群指标消耗、数据库监控、资源监控
  2）任务层面可观测
2.3 针对未的需求

  基于是及时业务场景、及时数仓架构明确和未来预测，我们认为及时数仓，数据分析服务需要支持ES倒排索引、离线ETL需求。
  1）ES倒排索引：及时分析服务查询，常涉及多字段匹配然后聚合，或者基于别的一张表去关联明细表然后聚合，包含基于分词的前后含糊、包含于等查询。这种场景下，ES擅长信息检索不擅长聚合查询，常常返回耗时长，无法满意。及时数仓擅长OLAP聚合分析，如果能支持倒排索引，即能擅长信息检索又擅长聚合查询，满意客户需求。已有产物已实现。
  2）离线ETL：及时数仓不可避免处理离线批处理，一方面是修正及时数据效果，另一方面是为了实现离线和及时计算同一引擎，更近一步是为了流任务和批任务同一，维护一套代码，因此我们认为未来及时数仓需要具备离线跑批能力，优化离线跑批性能，规划离线资源池不影响数据分析和线上服务。
三、架构总览

3.1 逻辑架构

架构图如下：

及时数据收罗层
  两种方式：业务数据保存在关系数据库中，可通过CDC的技术收罗Binlog到消息引擎中；日记通过各种收罗工具收罗到消息引擎。
及时数据计算层
  包含以下几种分析方式：统计分析、关联分析、CEP分析、AI分析
及时数据存储层
为了支持数据分析服务，需要满意以下能力：分层存储、及时更新、冷热存储
及时数据分析服务层
  包含以下几种功能：多维分析、KV查询、向量计算
数据资产管理层
  包含这几类：元数据、用户认证、数据脱敏、数据血缘、 数据安全
3.2 架构决策

  及时数仓体系重点是及时数据收罗、及时计算、及时数据存储、及时数据分析服务四部分，此中每个部分都会面临相干的架构决策，各部分关键决策如下：
及时数据收罗决策
  需要及时收罗具有多种数据源插件支持、高效的开发收罗同步作业。所以往往需要对数据收罗的方式、效率、操作便利性、任务监控等能力进行决策。
及时数据计算决策
  需要对及时计算的一站式开发、计算性能、资源弹性、任务规复、资源弹性等关键能力进行决策，以下为一个典型的及时数据计算决策分析。
及时数据存储决策
  以需要对及时存储的及时写入/更新能力、延时多久可访问、支持Binlog捕获要更数据、存储容量等关键能力进行决策。
及时数据服务决策
  需要对支持OLAP分析/KV查询、资源隔离、查询OPS、跟离线数据联邦查询等关键能力进行决策。
四、操作模子

4.1 稳定性

稳定性一般包含：高可用、容灾备份、同城容灾、异地容灾、数据备份和规复、资源隔离。
4.2 安全性

及时数仓需要从网络安全、体系安全、数据安全（传输、存储、利用）、安全认证四方面综合考虑，全方位保证数据安全可靠的存储和利用。
4.3 高性能

包含两部分：Benchmark(基准测试)、性能优化。
4.4 本钱可控

这属于阿里云计费方式，不在这里具体描述。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。