大数据架构
2021-11-01 11:30:13 2 举报AI智能生成
大数据演变及架构大全
作者其他创作
大纲/内容
数据湖
定义
数据湖是一个以原始格式(通常是对象块或文件)存储数据的系统或存储库
数据湖通常是所有企业数据的单一存储。用于报告、可视化、高级分析和机器学习等任务
说明
原始格式
数据不做预处理，保存数据的原始状态
单一存储
存储库中会汇总多种数据源，是一个单一库
用于机器学习
除了 BI 、报表分析，数据湖更适用于机器学习
包含数据
关系数据库的结构化数据(行和列)
半结构化数据(CSV、日志、XML、JSON)
非结构化数据(电子邮件、文档、pdf)
二进制数据(图像、音频、视频)
与数据仓库对比
分支主题
数据湖的应用场景主要在于机器学习，并且在用的时候再建 Schema 更加灵活
数据湖能够解决企业中机器学习应用方面的数据诉求，可以与数据仓库团队解耦。但并不意味着数据湖可以取代数据仓库，数据仓库在高效的报表和可视化分析中仍有优势
云厂家解决方案
阿里云
Data Lake Analytics
通过标准JDBC直接对阿里云OSS，TableStore，RDS，MongoDB等不同数据源中存储的数据进行查询和分析
DLA 无缝集成各类商业分析工具，提供便捷的数据可视化
阿里云OSS 可以存储各种结构化、半结构化、非结构化的数据，可以当做一个数据湖的存储库
DLA 使用前需要创建 Schema 、定义表，再进行后续分析。
架构图
分支主题
说明
（1）数据存储：采用OSS作为数据湖的集中存储，可以支撑EB规模的数据湖，客户无需考虑存储量扩容，各类型数据可以统一存储
（2）数据湖管理：面对 OSS 数据开放性带来的管理及入湖困难，DLA的Formation组件具备元数据发现和一键建湖的能力，DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理，无论数据是在“湖中”还是在“湖外”，比如利用元数据爬取功能，可以一键创建 OSS 上的元数据信息，轻松自动识别 CSV/JSON/Parquet 等格式，建立好库表信息，方便后续计算引擎使用
（3）数据分析和计算：DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎，都和Meta data catalog深度集成，能方便的获取元数据信息。基于Spark的能力，DLA解决方案支持批处理、流计算和机器学习等计算模式
（4）在数据集成和开发上：阿里云的数据湖解决方案提供两种选择：一种是采用dataworks完成；另一种是采用DMS来完成。无论是选择哪种，都能对外提供可视化的流程编排、任务调度、任务管理能力。在数据生命周期管理上，dataworks的数据地图能力相对更加成熟。
华为云
DLI Serverless
架构图
分支主题
分支主题
亚马逊
Lake Formation
可以识别 S3 或关系数据库和 NoSQL 数据库中存储的现有数据，并将数据移动到 S3 数据湖中
使用 EMR for Apache Spark（测试版）、Redshift 或 Athena 进行分析
支持的数据源跟阿里云差不多
微软Azure
Azure Data Lake Storage
基于 Azure Blob 存储构建的高度可缩放的安全 Data Lake 功能
通过 Azure Databricks 对数据湖中的数据进行处理、分析
开源解决方案
kylo
基本上与云厂商的解决方案一致
支持多种数据源，分析时创建 Schema
架构演变
分支主题
传统行业四代架构
第一代：EDW架构
架构图
分支主题
说明
在第一代的数据仓库中，清晰地定义了数据仓库 (Data Warehouse) 是一个面向主题的 (Subject Oriented) 、集成的 ( Integrate ) 、相对稳定的 (Non -Volatile ) 、反映历史变化 ( Time Variant) 的数据集合，用于支持管理决策（ Decision Marking Support）。
第二代：大集市架构
分支主题
说明
Ralph kilmball 的大集市的架构，基本可以成为总线型架构，从业务或部门入手，设计面向业务或部门主题数据集市
Kilmball 的这种构建方式可以不用考虑其它正在进行的数据类项目实施，只要快速满足当前部门的需求即可，这种实施的好处是阻力较小且路径很短。
主要核心
一致的维度，以进行集成和全面支持。一致的维度具有一致的描述性属性名称、值和含义。
一致的事实是一致定义的；如果不是一致的业务规则，那么将为其指定一个独特的名称。业务中相似的名词、不同系统的枚举值、相似的业务规则都需要做统一命名。
建模方式：星型模型、雪花模型
第三代：汇总维度集市&CIF2.0数仓结构
架构图
汇总维度集市的标准数仓结构
分支主题
CIF2.0架构(归一化的数仓和维数据层仓库的混合)
分支主题
说明
CIF 的这种架构总结了前面提到的两种架构的同时，又把架构的不同层次定义得非常明确。
这个经典的架构在后来 2006 年~2012 年进入到这个领域的从业者，乃至现在有些互联网企业的数据平台架构也是相似的。
包含部件
集成转换层（Integrated and Transformation Layer）
操作数据存储（Operational Data Store）
数据仓库（Enterprise Data Warehouse）
数据集市（Data Mart）
后台（Back Room）
负责数据准备工作，称为数据准备区（Staging Area）
前台（Front Room）
负责数据展示工作，称为数据集市（Data Mart）
探索仓库（Exploration Warehouse）
第四代：OPDM 操作实时数仓
架构图
分支主题
简介
Opdm 操作型数据集市（仓库）是实时数据仓库的一种，他更多的是面向操作型数据而非历史数据查询与分析
比如财务系统、CRM 系统、营销系统生产系统，通过某一种机制实时的把这些数据在各数据孤岛按照业务的某个层次有机的自动化整合在一起，提供业务监控与指导。
互联网六大架构
第一代：离线统计分析技术架构
与传统三代相似与区别
分支主题
简介
这代架构定位是为了解决传统 BI 的问题
数据分析的业务没有发生任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升级改造，此类架构便是为了解决这个问题。
架构图
分支主题
分层说明
应用数据层(ADS)
存放数据产品个性化的统计指标数据，主要面向前端展示
汇总数据层(DWS)
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表采用更多的宽表化手段，构建公共指标数据层
轻度汇总层(DWM)
是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据)
明细数据层(DWD)
采用维度退化的方法，将维度退化到实时表中，减少事实表和维度表的关联，提高明细表偶读易用性
操作数据层(ODS)
存储所有基础数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后(诸如去噪、去重、字段重命名等)，装入本层
预处理层(STAGING)
存储每天的增量数据，表和ods层表一直
维表层(DIM)
高基数维度数据
一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别
低基数维度数据
一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万
数据来源层
业务数据
埋点数据
日志数据
其他
优点
简单易懂，对BI系统基本思想没变，变得仅仅是技术选型，用大数据架构替换掉BI组件
缺点
对大数据来说，没有BI下完备的CUBE架构，虽有kylin，但较局限，故对业务支持灵活度不够，对存在大量报表或复杂的场景，需要太多的手工定制化，同时该架构依旧以批处理为主，缺乏实时的支撑
适用场景
数据分析需求依旧以BI场景为主，但是因为数据量性能问题无法满足日常使用
第二代：流式架构
架构图
分支主题
简介
流式的应用场景非常广泛， 比如搜索、推荐、信息流等都是在线化的，对数据实时性的要求变更高，自然计算与使用是同步进行的
随着业务的复杂化，数据的处理逻辑更加复杂，比如各种维度交叉、关联、聚类，以及需要更多算法或机器学习
与第一代的大数据处理框架相比，去掉了原有的 ETL 过程，数据流过数据通道时得到处理，处理结果通过消息的方式推送数据消费者
流式计算框架舍弃了大数据离线批量处理模式，只有很少的数据存储，所以数据保存周期非常短。如果有历史数据场景或很复杂历史数据参与计算的场景，实现起来难度就比较大
优点
没有臃肿的ETL过程，数据的实效性非常高
缺点
不存在批处理，因此对数据的重播和历史统计无法很好的支撑，对于离线分析进支撑窗口之内的分析
应用场景
事件流、持续计算。事件流，就是业务相对固定，只是数据在业务的规则下不断的变化。
持续计算，适合购物网站等场景
预警、监控、对数据有实时性要求的场景
第三代：Lambda 大数据架构
架构图
分支主题
分支主题
简介
Lambda 架构是由 Twitter 工程师南森·马茨（Nathan Marz）提出的，是一种经典的、实施广泛的技术架构。后来出现的其他大数据处理架构也是 Lambda 架构的优化或升级版
Lambda 架构的两条数据链路
批量离线处理流在构建时大部分还是采用一些经典的大数据统计分析方法论，在保证数据一致性、完整性的同时还会对数据按照不同应用场景进行分层。
实时流式处理主要是增量计算，也会跑一些机器学习模型等。为了保证数据的一致性， 实时流处理结果与批量处理结果会有一个合并动作
Lambda 架构主要的组成
批处理层 (Bathchlayer) ：
Lambda 架构核心层之一，批处理接收过来的数据，并保存到相应的数据模型中，这一层的数据主题、模型设计的方法论是继承面向统计分析离线大数据中的。而且一般都会按照比较经典的 ODS、DWD、DWB、ST/ADM 的层次结构来划分。
流式处理层 (Speed Layer) ：
Lambda 另一个核心层，为了解决比如各场景下数据需要一边计算一边应用以及各种维度交叉、关联的事件流与持续计算的问题，计算结果在最后与批处理层的结果做合并。
服务层 ( Serving layer) ：
这是 Lambda 架构的最后一层，服务层的职责是获取批处理和流处理的结果，向用户提供统一查询视图服务。
优点
既有实时又有离线，对数据分析场景涵盖的非常到位
缺点
1、数据口径不一致问题
因为离线和实时计算走的是两个完全不同的代码，算出来的结果往往不同，可能会当天看到一个结果数据，第二天发现数据变成了
2、T+1离线严重超时
像新浪微博这种体量的公司，每天有400TB+的数据写入大数据平台，而且数据在不断地增加。我们经常会发现在夜间3-4个小时内，离线程序执行不完，不能保证数据在上班之前准时生成。尤其是在夜间发生故障之后，白天的数据产出时间更加难以把控。
3、需要维护两套代码
每次数据源有变化，或者业务方有新的需求。都要修改两次业务逻辑代码，既要修改离线的ETL任务，又要修改流式任务，开发周期很长（工作量是双倍），人力成本比较大。
适用场景
同时存在实时和离线需求的情况
第四代：Kappa 大数据架构
架构图
分支主题
与lambda架构对比
分支主题
OLAP主流引擎
分支主题
简介
解决在 Lamadba 架构下需要维护两套的代码的问题
Kappa 架构核心是通过改进流式计算架构的计算、存储部分来解决全量的问题，使得实时计算、批处理可以共用一套代码
Kappa 架构认为对于历史数据的重复计算几率是很小的，即使需要，可以通过启用不同的实例的方式来做重复计算
核心思想
用 Kafka 或者类似 MQ 队列系统收集各种各样的数据，需要几天的数据量就保存几天。
当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
当新的实例做完后，停止老的流计算实例，并把一些老的结果删除。
优点
解决了lambda架构的冗余部分，以数据可重播的超凡脱俗的死刑进行了设计，整个架构非常简洁
缺点
Lambda 架构需要维护两套跑在批处理和实时流上的代码，两个结果还需要做 merge， Kappa 架构下只维护一套代码，在需要时候才跑全量数据。
Kappa 架构下可以同时启动很多实例来做重复计算，有利于算法模型调整优化与结果对比，Lamabda 架构下，代码调整比较复杂。所以 kappa 架构下，技术人员只需要维护一个框架就可以，成本很小。
kappa 每次接入新的数据类型格式是需要定制开发接入程序，接入周期会变长。
Kappa 这种架构过度依赖于 Redis、Hbase 服务，两种存储结构又不是满足全量数据存储的，用来做全量存储会显得浪费资源。
适用场景
同lambda
第五代：Unified 大数据架构
架构图
分支主题
简介
以上的这些架构都围绕大数据处理为主，Unifield 架构则更激进，将机器学习和数据处理整合为一体
Unifield 在 Lambda 基础上进行升级，在流处理层新增了机器学习层
数据经过数据通道进入数据湖，新增了模型训练部分，并且将其在流式层进行使用，同时流式层不单使用模型，也包含着对模型的持续训练
优点
提供一套数据分析和机器学习结合的机构方案，非常好的解决了机器学习如何与数据平台进行结合的问题
缺点
实施复杂度更高，对于机器学习架构来说，从软件包到硬件部署都和数据分析平台有非常大的差别，实施难度系数更高
使用场景
有着大量数据需要分析，同时对机器学习方便又有非常大的需求或者规划
第六代：IOTA 架构
简介
这个概念由易观于 2018 年首次提出，IOTA 大数据架构是一种基于 AI 生态下的、全新的数据架构模式
IOTA 的整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用各种 Ad-hoc Query 来查询底层数据
特点
去 ETL 化：
ETL 和相关开发一直是大数据处理的痛点，IOTA 架构通过 Common Data Model 的设计，专注在某一个具体领域的数据计算，从而可以从 SDK 端开始计算，中央端只做采集、建立索引和查询，提高整体数据分析的效率。
Ad-hoc 即时查询:
鉴于整体的计算流程机制，在手机端、智能 IOT 事件发生之时，就可以直接传送到云端进入 real time data 区，可以被前端的 Query Engine 来查询。此时用户可以使用各种各样的查询，直接查到前几秒发生的事件，而不用在等待 ETL 或者 Streaming 的数据研发和处理。
边缘计算：
将过去统一到中央进行整体计算，分散到数据产生、存储和查询端，数据产生既符合 Common Data Model。同时，也给与 Realtime model feedback，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。
优点
去ETL话、支持ad-hoc即时查询和边缘计算
缺点
代码漏洞较多，通过收费方式向社区提供漏洞修复代码
适用场景
用于物联网设备，实现万物互联，系统自治
大数据处理技术栈
分支主题
职业：暂无
0 条评论
下一页
