云集技术学社 | 主流大数据架构及适用场景

7月22日，深信服大数据负责人Letian在信服云《云集技术学社》系列直播课上进行了《主流大数据架构及适用场景》的分享，对典型大数据的分析场景进行了总结，归纳了大数据新架构及适用应用场景，从大数据开发的视角来分析大数据开发过程以及如何简化开发。以下是他分享内容摘要，想要了解更多可以点击这里观看直播回放。

“

看点一：

大数据分析典型应用场景

对于大部分用户来说，对大数据只有一个模糊的概念，不了解特别具象化的应用场景。数据分析是大数据的核心场景，依据对于分析效率和方式的不同，基本上可以分为批处理、交互式分析、实时分析、分析预测、智能决策等场景。

一、大数据分析的主要应用场景有五个

一是离线分析场景，应用于用户需要贴合业务形成的报表中，常见的是对静态数据的批处理。离线分析场景往往需要对于海量数据处理几个小时甚至几天才能得到贴合业务需求的结果报表。

二是交互式分析场景，应用于仪表盘或自助分析。它的特点是表与表之间的关联关系不确定，分析维度不确定，查询度量不确定，通过即席查询满足秒级～分钟级的分析需求。

三是实时分析场景，通常应用在交易风险预警、实时反欺诈、交易特征分析中，它的特点是表与表之间的关联关系确定，分析维度不确定，查询度量不确定，通过数据立方（Cube）技术提前预设数据模型，满足从既定的多层次多维度的亚秒～秒级的分析需求。

四是流处理场景，流处理是指对如传感器信号、日志、时空轨迹、网购、交易等连续的、没有边界的、快速随时间不断变化的数据项（又称“流式数据“）进行过滤、转化、复杂逻辑等操作，主要应用在公安缉查布控、套牌车分析、互联网实时推荐系统中。

五是综合检索，即从海量的结构化、半/非结构化数据中快速抓取到符合要求的信息。通常应用在站内搜索引擎、知识库以及高并发精准查询等通过关键字检索快速获得信息的使用场景中。

“

看点二：

大数据新架构及适用场景

信息技术的发展催生了大数据新架构的不断升级迭代与创新，在本次课程中，Letian介绍了不同类型的大数据新架构及适用场景。

（1）存算分离

基于IO与CPU（含内存）的诉求可能出现不对等情况，人们意识到Hadoop发明之初强调存算融合，利用局部性让计算跟着数据跑的局部性原理带来的硬件节省，不如存储和计算分别扩容带来的节省硬件收益。对于企业而言，可以实现计算和存储按需灵活扩容，降本增效。一般来说，数据量超过300TB，且大数据服务器总数量超过20台时，用户可以考虑采用存算分离架构。当分析时延要求极低且不具备缓存/RDMA能力时则不考虑采用存算分离架构。

（2）Lambda架构

Lambda架构是一个实时大数据处理框架，通过Batch Layer和Speed Layer的分层设计来实现在一个系统内同时支持流处理和批处理。

Lambda（λ）架构的数据流采用基于不可变日志的分布式消息系统Kafka，数据进入Kafka后，一部分进行批处理，一部分进行流处理。批处理通常使用MR或Spark进行Batch View的预计算， Batch View自身结果数据的存储采用HBase（查询大量的历史结果数据）。Speed Layer（流处理）增量数据的处理可选用Flink，Realtime View增量结果数据集为了满足实时更新的效率，选用Redis。Lambda架构满足了高容错、低延时和可扩展等实时数据处理需求。

（3）批流融合

除了Lambda（λ）架构这种批流分离的架构外，批流融合也是十分流行的架构。批流融合支持ACID的upsert、delete、insert等可以实现流处理和批处理一体，确保统一的原始视图（ODS），数据直接进入大数据数仓，计算口径统一。批流融合不再采用消息队列，其作用可以被流引擎部分替换，可以内部自动合并小文件，对上屏蔽小文件的处理复杂性，还可以让用户查询给定时间点的快照或回滚错误更新到之前正确的数据。

（4）实时数仓

据Gartner统计实时数据规模在未来三年内会达到25%，数据规模高速增长带来了强劲的数据分析需求，由此实时数仓应运而生，它可以进行内存级、细粒度的实时预计算。将cube的构建分为内存部分和磁盘部分，磁盘部分对应于传统的预计算，内存部分对应于实时场景。在实时预计算系统中，用户预先设置好需要在线分析的统计方法（度量及指标）。对实时产生的数据，实时数仓以极细的时间粒度（segment）进行计算和汇总；实时数仓收到用户查询请求（query）时，如果计算结果处于内存中（realtime-node）中，则直接从内存中获取结果。实时数仓广泛应用于用户画像分析、点击流分析、网络流量分析等场景中。

（5）数据湖

企业在持续发展，企业的数据也不断堆积，在数据存储层面上，“含金量”最高的数据已经存在数据库和数仓里，支撑着企业的运转。但是，企业希望把生产经营中的所有相关数据，历史的、实时的，在线的、离线的，内部的、外部的，结构化的、非结构化的，都能完整保存下来，方便未来“沙中淘金”。因此，数据湖诞生，它由数据存储架构、数据管理工具、数据探索和开发工具三要素构建。

（6）湖仓一体方案

数据湖起步成本很低，但随着数据体量增大，TCO成本会加速飙升，数仓则恰恰相反，前期建设要小心地处理数据，开支很大。一个后期成本高，一个前期成本高，对于既想修湖、又想建仓的用户来说，既然都是拿数据为业务服务，数据湖和数仓作为两大“数据集散地”，能不能彼此整合一下？于是数仓一体方案出现，让一套架构里面具备数据湖灵活性，兼有数据仓库的成长性。

“

看点三：

如何简化大数据的开发

大数据的开发过程受工具及开发流程的影响，开发团队的使用门槛高，上手难度大。对于项目交付而言，一是大数据分析的定制需求多，需要专业团队才能交付；二是实施阶段问题多，全阶段都需要研发投入；三是项目成本中大数据占比高，验证阶段压力大。这三重问题使得项目交付的成本高。其次，大数据复杂的架构就意味着技术栈复杂，寻找复合型人才难度大，人力成本高。由此可见，大数据的开发亟需降本增效，那么如何简化大数据的开发，提高研发人员的开发效率呢？ Letian给出了如下建议：

一、通过外部工具将可视化展示内迁应用到大数据上。可视化是大数据分析的最后环节，针对离线分析场景可以通过配置SQL/SPL 编写图/表的代码，或者选择预置的图或表模板实现从立方体到交叉表（中国式复杂报表）的展示。针对交互式分析场景可以通过敏捷BI（Tableau、Kibana-Lens）进行拖拽实时自动地生成图或表实现交互式分析可视化展示。

二、通过数仓开发工具简化流程。数仓开发是大数据开发的主要场景，针对数仓开发可以通过工具或者可视化平台减少需要反复的过程。在数据进行清洗后，数仓可以进入可视化平台开发免除繁琐的代码编写，在原始数据中加载数据可以有可视化操作，通过拖拽构建数仓模型，从中提取指标并设置加速机制自动进行预计算，设置上线定时周期脚本让模型在固定时间关联、运行、验证。

三、流计算开发工具。在流处理场景中，可以通过可视化工具进行辅助开发。通过可视化开发画布，进行数据来源配置、触发条件配置和数据目的配置，省去流计算中的代码编写。

四、调度开发工具。大数据的开发需要不同代码的编写，各个代码之间可以通过可视化调度开发工具实现管理、调度和依赖关系的处置。

感谢分享，有助于工作，学习学习

感谢分享，有助于工作，学习学习

楼主分析的很详细，不错的实战经验，小白用户一看就懂，非常好的技术干货帖，顶一个！

感谢分享，有助于工作，学习学习