【珍藏版】数仓平台、推荐系统架构选型及解决⽅案
持续输出 敬请关注
大数据架构 湖仓一体化 流批一体 离线+实时数仓
各种大数据解决方案 各种大数据新技术实践
持续输出 敬请关注
【好文推荐】【好文推荐】【好文推荐】【好文推荐】【好文推荐】
⼤数据平台基础架构及解决⽅案_大数据研习社的博客-CSDN博客
https://blog.csdn.net/dajiangtai007/article/details/123473705?spm=1001.2014.3001.5501新⼀代USDP开源套件，可替代CDH的免费大数据套件平台及架构选型_大数据研习社的博客-CSDN博客持续输出 敬请关注大数据架构 湖仓一体化 流批一体 离线+实时数仓各种大数据解决方案 各种大数据新技术实践持续输出 敬请关注https://blog.csdn.net/dajiangtai007/article/details/123525688?spm=1001.2014.3001.5501【珍藏版】⼤数据中台架构及解决⽅案_大数据研习社的博客-CSDN博客_数据中台开源持续输出 敬请关注大数据架构 湖仓一体化 流批一体 离线+实时数仓各种大数据解决方案 各种大数据新技术实践持续输出 敬请关注https://blog.csdn.net/dajiangtai007/article/details/123692199?spm=1001.2014.3001.5501
一、数仓架构
1.1 数仓相关概述
1.1.1 数据仓库(Data Warehouse)
1.1.2 商业智能(Business Intelligence)
1.1.3 OLTP vs OLAP
1.1.4 行存储与列存储
1.1.5 典型数仓数据流
1.2 数仓架构演变概览
1.3 离线大数据数仓架构
1.3.1 离线大数据架构
1.3.2 离线数仓分层
1.3.3 典型架构/案例
1.4 Lambda架构
1.4.1 Lambda架构
1.4.2 Lambda架构典型案例
1.4.3 Lambda架构的缺陷
1.5 Kappa架构
1.5.1 Kappa架构
1.5.2 Kappa架构典型案例
1.5.3 Kappa架构重处理过程
1.5.4 Lambda vs Kappa架构
1.6 实时数仓与离线数仓
1.7 数仓发展趋势
1.8 架构选择
二、推荐系统架构及解决方案
2.1 推荐系统是什么
2.1.1 推荐系统的概念
2.1.2 推荐系统解决了什么问题
2.1.3 学习推荐系统的必要性
2.2 推荐主逻辑
2.3 项目核心模块
2.3.1 召回模块
2.3.2 排序模块
2.3.3 调整模块
2.3.4 常⻅召回路径
2.4 推荐系统典型架构
2.4.1 Netflix经典推荐系统架构
2.4.2 推荐系统通⽤架构
2.4.3 推荐系统架构Flink版
三、补充： Flink+Alink当大数据遇见机器学习
3.1 基于Spark的机器学习架构
3.2 从FlinkML到Alink
3.2.1 Flink1.9之前
3.2.2 Flink1.9之后
3.3 基于Flink+Alink的机器学习架构
3.3.1 Flink在⼤数据架构中的位置
3.3.2 认识Alink
3.3.3 典型架构
3.4 Flink+其他主流⼈⼯智能框架
一、数仓架构
1.1 数仓相关概述
1.1.1 数据仓库(Data Warehouse)
数据仓库是⼀个各种数据的中心存储系统(包括历史数据和当前数据)，是BI的核⼼组件。这⾥所说的数据包括来⾃企业内部的各种业务数据，例如订单、库存、交易流水、账⽬、客户、供应商等，同时也包括从外部获取的各种数据，例如通过爬虫等合法⼿段爬取的数据。
1.1.2 商业智能(Business Intelligence)
商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出合理的、明智的经营决策的⼯具，是企业数字化转型的关键系统。为了将数据转化为知识，需要利⽤数据仓库、联机分析处理(OLAP)⼯具和数据挖掘等技术。
1.1.3 OLTP vs OLAP
（1）OLTP(Online Transaction Process)-事务驱动
联机事务处理，侧重于数据库的增删改查等常⽤业务操作，强调事物和并发。
（2）OLAP(Online Analytical Process)-分析驱动
联机分析处理，即以多维的⽅式分析数据，强调磁盘IO吞吐，⼀般采⽤分区技术、并⾏处理技术。
OLAP是⼀种软件技术，它使分析⼈员能够迅速、⼀致、交互式的从各⽅⾯观察数据，以达到深⼊理解数据的⽬的。从各⽅⾯观察数据，也就是从不同纬度分析数据，因此也成为多维分析。
1.1.4 行存储与列存储
下⾯两张图是⾏式存储和列式存储的示意图：
⼀般来说OLTP数据库使用行式存储， OLAP数据库使⽤列式存储：
上图中，在查询某些列的数据时，行存储需要把整行数据读出来再过滤。
如上图，列存储不同列的数据分开存储在不同文件，⾯对分析查询(只涉及部分列)可以⼤幅降低IO，因此列式存储相对于行式存储在OLAP场景下的优势可以这么来理解：
1. 对于分析查询，⼀般只需要⽤到少量的列，在列式存储中，只需要读取所需的数据列即可。 例如，如果您需要100列中的5列，则I / O减少20倍。
2. 按列分开存储，按数据包读取时因此更易于压缩。 列中的数据具有相同特征也更易于压缩， 这样可以进⼀步减少I / O量。
3. 由于减少了I / O，因此更多数据可以容纳在系统缓存中，进⼀步提⾼分析性能。
1.1.5 典型数仓数据流
1.2 数仓架构演变概览
1.3 离线大数据数仓架构
1.3.1 离线大数据架构
1.3.2 离线数仓分层
1.3.3 典型架构/案例
1.4 Lambda架构
1.4.1 Lambda架构
1.4.2 Lambda架构典型案例
下图是有赞⼴告的数据平台架构(基于Druid)：
1.4.3 Lambda架构的缺陷
（1）同样的需求需要开发两套⼀样的代码
这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，⼀个在批处理引擎上实现，⼀个在流处理引擎上实现，还要分别构造数据测试保证两者结果⼀致），后期维护更加困难，⽐如需求变更后需要分别更改两套代码，独⽴测试结果，且两个作业需要同步上线。
（2）资源占⽤增多
同样的逻辑计算两次，整体资源占⽤会增多（多出实时计算这部分）。
（3）实时链路和离线链路数据差异容易让业务⽅困惑
例如业务方会发现，次日看到的数据比昨晚看到的要少。原因在于：数据在被放入Result Database时,⾛了两条线的计算⽅式：⼀条线是ETL按照某个⼝径“跑”过来，得到更为准确的批量处理结果;另⼀条线是通过Streaming“跑”过来，依靠一些算法得出的实时性结果。当然它牺牲了部分的准确性。可见，这两个来⾃批量的和实时的数据结果是对不上的，因此⼤家觉得很困惑。
注意：对于⽇志、⽤户⾏为这种不变的数据是不会造成误解的，但是这种情况⼜不太需要lambda架构。
1.5 Kappa架构
1.5.1 Kappa架构
1.5.2 Kappa架构典型案例
Kappa架构来构建数仓是妥妥的实时数仓，每个需求都⾃⼰开发流处理代码，⽐较繁琐，⼀个较好的办法是借助OLAP引擎，主流的引擎如下(个别的严格意义上来说不是OLAP引擎，但是具备相应功能)：
Kylin3.0本身是Kappa架构，但是⽀持Lambda架构:
1.5.3 Kappa架构重处理过程
在Kappa架构中，即使流处理引擎再健壮，由于上游数据原因，仍然存在数据重新处理的需求。修改数据或历史数据重新处理都通过上游重放完成(从数据源拉取数据重新计算⼀次)。
Kappa架构最大的问题是流式重新处理历史数据的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
重新处理是⼈们对Kappa架构最担⼼的点，但实际上并不复杂：
1. 选择⼀个具有重放功能的、能够保存历史数据并⽀持多消费者的消息队列，根据需求设置历史数据保存的时⻓，比如Kafka，可以保存全部历史数据。
2. 当某个或某些指标有重新处理的需求时，按照新逻辑写⼀个新作业，然后从上游消息队列的最开始重新消费，把结果写到⼀个新的下游表中。
3. 当新作业赶上进度后，应⽤切换数据源，读取2中产⽣的新结果表。
4. 停止老的作业，删除老的结果表。
1.5.4 Lambda vs Kappa架构
1.6 实时数仓与离线数仓
1.7 数仓发展趋势
（1）实时数据仓库：满⾜实时化&⾃动化决策需求
（2）结合数据湖：⽀持海量、复杂数据类型（⽂本、图像、视频、⾳频）
1.8 架构选择
（1）看具体业务需求，适合需求的架构才是最合适，离线⼤数据架构在很多公司仍然⽐较实⽤(性价⽐⾼)
（2）在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如⼤部分实时指标使⽤Kappa架构完成计算，少量关键指标（⽐如金额相关）使⽤Lambda架构⽤批处理重新计算，增加⼀次校对过程。
（3）为了应对更⼴泛的场景，大多数公司采用混合架构
1> 从架构层⾯来看是Lambda架构和Kappa架构混合
2>从数仓形态来说是离线数仓和实时数仓混合
3>通俗来讲：离线和实时数据链路都存在，根据每个业务需求选择在合适的链路上来实现
二、推荐系统架构及解决方案
2.1 推荐系统是什么
2.1.1 推荐系统的概念
定义：根据⽤户的历史⾏为和基本信息，向⽤户推荐他感兴趣的内容，做到千⼈前⾯（个性化定制）。
2.1.2 推荐系统解决了什么问题
（1）解决信息过载问题
京东、天猫、拼多多、头条、抖⾳等互联⽹公司的商品、资讯、⽂章、视频基本都是⼏百上千万，甚⾄上亿，在这种信息过载的情况下，需要解决如下问题：
<1>⽤户侧：怎么样找到感兴趣的物品？
<2>系统侧：怎么样展示海量物品给⽤户已达到商业⽬的？
（2）挖掘⻓尾
<1>⼤多数冷⻔物品⽆法呈现给⽤户，但他们的价值可能超过热⻔物品
<2>举例：亚⻢逊图书类⽬57%的收⼊来⾃⻓尾冷⻔书籍
⻓尾理论：由于成本和效率的因素，当商品储存、流通、展示的场地和渠道⾜够宽⼴，商品⽣产成本急剧下降以⾄于个⼈都可以进⾏⽣产，并且商品的销售成本急剧降低时，⼏乎任何以前看似需求极低的产品，只要有卖，都会有⼈买。这些需求和销量不⾼的产品所占据的共同市场份额，可以和主流产品的市场份额相当，甚⾄更⼤。
（3）提⾼⽤户体验
搜索：⽬标明确⼀般直接采⽤搜索引擎，好的搜索结果可以提⾼⽤户体验
推荐：当⽤户需求不明确时，推荐系统可以推荐⽤户感兴趣的物品
推荐系统可以推荐⽤户感兴趣但很难在海量物品中⾃⼰发现的物品，例如：我们经常在各⼤电商买了⾃⼰感兴趣但是⾮必须的商品，这就是推荐系统的功劳。
2.1.3 学习推荐系统的必要性
有必要，但要量力而行，找准⾃⼰的⽅向，⼤多数⼈不适合做算法，不要硬上，容易⾛⽕⼊魔。
2.2 推荐主逻辑
挑战：从海量物品或者内容中挑选出感兴趣的条⽬，并满⾜50ms~300ms的低延迟要求（ 99%的请求在300ms内返回 )。
2.3 项目核心模块
推荐系统的核心就是要在庞⼤的商品、⽂章、好友等⼈或物中找出⽬标⼈或者⼈群喜欢的⼈或者物，要完成这项⼯作整体流程是⽐较⻓的，⼀般按照先后顺序分为如下⼏个核⼼模块，下⾯是各模块的职责及说明：
2.3.1 召回模块
召回模块的意义在于从海量的物品中找出⽤户可能感兴趣的⼩部分物品，不⾄于推荐的数量太多。因为要在原始的海量物品上进⾏召回，所以召回的规则、算法或者说模型不能太复杂，否则计算量成指数倍增⻓根本不可能实现。
常⻅的召回⼿段有如下⼀些：
2.3.2 排序模块
排序是推荐系统的第⼆阶段，从召回阶段获得少量的物品/内容交给排序阶段，排序阶段可以融⼊较多特征，使⽤复杂模型，来精准地做个性化推荐。排序所强调的是快和准，快指的是⾼效的反馈结果，准指的是推荐结果准确性⾼。
排序模块常⻅的⼿段有如下⼀些：
2.3.3 调整模块
经过召回阶段的初步筛选和排序阶段的精细化筛选剩下的物品/内容已经⾮常少了且更接近于⽤户的真实喜好，但是这些物品/内容还不能直接推荐给⽤户，⼀般来说根据业务需求还需要对推荐结果进⾏调整。常⻅的调整策略往往跟业务场景紧密挂钩，以电商为例，有如下策略：
1. 过滤掉⽤户已经购买过的物品
2. 过滤掉不适合公开展示的物品，⽐如成⼈⽤品
3. 去掉重复推荐的物品/内容
4. 去掉⽤户评分过低物品/内容
5. 去掉单独宣传的爆款商品避免曝光浪费
6. 替换成同型号利润率⾼的物品
注意：召回和排序阶段往往需要⼤量的运算，所以调整阶段的策略往往都不会放在召回和排序阶段去做，这也是调整模块独⽴出来的原因。
2.3.4 常⻅召回路径
推荐系统中常⻅的名词，如i2i、 u2i、 u2i2i、 u2u2i、 u2tag2i，它们指的是召回路径或者叫召回流派。这⾥通过⼀个图来给⼤家解释下召回路径：
2.4 推荐系统典型架构
2.4.1 Netflix经典推荐系统架构
（1）在线层：
特点：既能处理海量数据，⼜能及时响应⽤户请求
优点：快速响应，使⽤最新输⼊数据，⽐如200ms
缺点：不能使⽤复杂算法，只能是简单算法(逻辑回归)
（2）离线层：
特点：⼤部分计算包括模型训练都在这⼀层完成
优点：⽀持复杂算法、可对海量数据进⾏计算
缺点：不能对最新情景和最新数据做出实时响应，只能按⼩时或者天粒度
（3）近线层：
特点：离线和在线的这种，⼀般将结果存⼊⾼速缓存
优点：能使⽤到⼏乎所有最新数据，延迟10秒~1分钟级别，允许更复杂算法，加载查询更多数据
（4）综合使⽤：
天粒度：离线层做矩阵分解，得到⽤户向量和物品向量，存储到MySQL（为什么不提前把每个⽤户的推荐列表计算出来并存起来？太⼤）
10秒：近线层根据⽤户⾏为，查询topn物品相似列表存⼊Cassandra
200毫秒：在线层查询第⼆步的结果，更新推荐列表
2.4.2 推荐系统通⽤架构
2.4.3 推荐系统架构Flink版
（1）核⼼架构如下图：
（2）项⽬应⽤：
三、补充： Flink+Alink当大数据遇见机器学习
⼤数据技术深度结合⼈⼯智能(AI)将是未来发展的⼀个重要⽅向，⽽机器学习是⼈⼯智能的重要分⽀和最流⾏的实现⽅式。
3.1 基于Spark的机器学习架构
以往在⾯对⼤数据下的机器学习场景时，⼤家往往想到的是SparkMLlib，架构如下：
3.2 从FlinkML到Alink
3.2.1 Flink1.9之前
3.2.2 Flink1.9之后
（ 1）部署层
Flink⽀持本地（ Local）模式、集群（ Cluster）模式等。
（ 2）执⾏引擎层
执⾏引擎层是核⼼API的底层实现，位于最低层。执⾏引擎层提供了⽀持Flink计算的全部核⼼实现。
执⾏引擎层的主要功能如下。
<1>分布式流处理。
<2>从作业图（ JobGraph）到执⾏图（ ExecutionGraph）的映射、调度等。
<3>为上层的API层提供基础服务。
<4>构建新的组件或算⼦。
执⾏引擎层的特点包括以下⼏点：灵活性⾼，但开发⽐较复杂；表达性强，可以操作状态、 Time等。
（ 3）核⼼API层
核⼼API层主要对⽆界数据流和有界数据流进⾏处理，包括DataStream API和DataSet API，以及实现了更加抽象但表现⼒稍差的Table API、 SQL。
<1>DataStream API：⽤于处理⽆界数据，或者以流处理⽅式来处理有界数据。
<2>DataSet API：⽤于对有界数据进⾏批处理。⽤户可以⾮常⽅便地使⽤Flink提供的各种算⼦对分布式数据集进⾏处理。 DataStream API和DataSet API是流处理应⽤程序和批处理应⽤程序的接⼝，程序在编译时⽣成作业图。在编译完成之后， Flink的优化器会⽣成不同的执⾏计划。根据部署⽅式的不同，优化之后的作业图将被提交给执⾏器执⾏。
<3>Table API、 SQL：⽤于对结构化数据进⾏查询，将结构化数据抽象成关系表，然后通过其提供的类SQL语⾔的DSL对关系表进⾏各种查询。
（ 4） 领域库层
Flink还提供了⽤于特定领域的库，这些库通常被嵌⼊在API中，但不完全独⽴于API。这些库也因此可以继承API的所有特性，并与其他库集成。
在API层之上构建的满⾜特定应⽤的实现计算框架（库），分别对应⾯向流处理和⾯向批处理这两类。
<1>⾯向流处理⽀持： CEP（复杂事件处理）、基于SQL-like的操作（基于Table的关系操作）。
<2>⾯向批处理⽀持： FlinkML（机器学习库）、 Alink（新开源的机器学习库） 、 Gelly（图计算）。
Flink背后的商业公司Data Artisans被阿⾥收购之后，从Flink1.9开始FlinkML模块已经没有了，⼀直在重构，⾄今还没有正式回归；阿⾥开源的Alink（新开源的机器学习库）已经⾮常成熟。
3.3 基于Flink+Alink的机器学习架构
3.3.1 Flink在⼤数据架构中的位置
3.3.2 认识Alink
Alink是阿⾥巴巴计算平台事业部PAI团队研发的基于Flink的机器学习框架。
Alink于2019年11⽉正式开源。
Alink提供了丰富的算法组件，是业界⾸个同时⽀持批/流算法的机器学习框架。
开发者利⽤Alink可以⼀键搭建覆盖数据处理、特征⼯程、模型训练、模型预测的算法模型开发的全流程。
Alink的名称取⾃相关名称（ Alibaba、 Algorithm、 AI、 Flink、 Blink）的结合。
https://gitee.com/mirrors/Alink
3.3.3 典型架构
3.4 Flink+其他主流⼈⼯智能框架
Flink+⽬前主流的⼈⼯智能框架（如PyTorch、 TensorFlow、 Kubeflow），可替代Alink，亦可与Alink互补，多为互补。
