大数据技术原理题库及答案

大数据技术原理题库及答案1.数据采集阶段，常见的结构化数据与非结构化数据采集方式有哪些差异？结构化数据通常存储于关系型数据库（如MySQL、Oracle），采集方式多依赖JDBC/ODBC接口实现定时抽取或触发式同步，支持事务一致性校验；非结构化数据（如日志、文本、音视频）多通过Flume、Filebeat等日志收集工具或自定义Agent实时抓取，需处理格式解析（如JSON、CSV、日志模式匹配）和元数据提取，部分场景需结合OCR（光学字符识别）或语音转文本技术完成内容结构化转换。二者核心差异在于结构化数据有明确的Schema约束，采集时需关注字段映射与类型对齐；非结构化数据需先完成半结构化处理（如添加标签、分类），再进入存储层。2.HDFS（Hadoop分布式文件系统）的块（Block）大小默认设置为128MB，设计该参数的核心考量是什么？HDFS块大小的设计需平衡元数据管理开销与数据访问效率。默认128MB的设置基于以下原因：（1）减少NameNode内存压力：NameNode存储文件元数据（如块位置、副本信息），若块过小（如传统文件系统的4KB），大文件会被分割为海量块，导致元数据量激增，超出内存容量；（2）优化数据访问性能：HDFS的设计目标是支持大文件的流式读写，大块大小可减少寻道时间（SeekTime），提升顺序读写效率；（3）适配分布式计算框架：MapReduce等计算框架以块为单位划分任务，大块可减少任务数量，降低任务调度开销。实际生产中，块大小可根据业务需求调整（如视频存储可能设为256MB或更大），但需避免过小导致元数据膨胀或过大导致小文件存储浪费。3.简述NoSQL数据库（以HBase为例）与关系型数据库在数据模型上的核心区别。HBase基于列族（ColumnFamily）的扩展数据模型，与关系型数据库的二维表模型存在本质差异：（1）Schema灵活性：关系型数据库要求严格的表结构（SchemaOnWrite），所有行必须包含相同列；HBase采用SchemaOnRead，行可动态添加列（属于预定义的列族），不同行的列集合可不同；（2）数据存储方式：关系型数据库按行存储（Row-oriented），适合OLTP场景的随机行读写；HBase按列族存储（Column-oriented），同一列族的数据物理上连续存储，适合高并发的列范围查询（如按时间范围读取某传感器的所有观测值）；（3）数据索引机制：关系型数据库依赖主键及二级索引（B+树）支持快速查询；HBase仅支持基于RowKey的有序索引（通过RegionServer的HFile按RowKey排序存储），复杂查询需通过协处理器（Coprocessor）或Phoenix组件实现类SQL查询。4.MapReduce计算框架中，Shuffle阶段的核心作用是什么？该阶段可能面临哪些性能瓶颈？Shuffle阶段是MapReduce的“数据洗牌”过程，负责将Map任务的输出按Key分发到对应的Reduce任务。其核心作用是实现数据的分区（Partition）、排序（Sort）和归并（Combine），确保同一Key的所有Value被同一个Reduce处理。具体流程包括：（1）Map端：输出数据经分区器（默认HashPartitioner）按Key的Hash值分配到不同分区，每个分区数据先写入内存缓冲区（默认100MB），缓冲区满后溢写（Spill）到本地磁盘，溢写过程中对分区内数据按Key排序，多个溢写文件最终合并为一个大的排序文件；（2）Reduce端：通过HTTP拉取各Map任务的对应分区数据，合并后按Key再次排序（若Map端已排序则归并即可），最终输入Reduce函数处理。性能瓶颈主要包括：（1）磁盘I/O开销：Map端溢写和Reduce端拉取数据涉及大量磁盘读写，尤其在数据量极大时，磁盘成为瓶颈；（2）网络传输压力：跨节点的分区数据传输占用带宽，可能导致网络拥塞；（3）内存使用：缓冲区大小设置不当（过小导致频繁溢写，过大导致内存不足）会影响性能；（4）排序开销：两次排序（Map端溢写排序、Reduce端归并排序）的时间复杂度为O(nlogn)，数据量越大耗时越长。优化手段包括启用压缩（如Snappy压缩Map输出）、使用Combiner（在Map端提前聚合数据减少传输量）、调整分区数（避免Reduce任务数过多或过少）。5.Spark的RDD（弹性分布式数据集）具备哪些特性？这些特性如何支持容错与高效计算？RDD的核心特性包括：（1）不可变性（Immutable）：RDD创建后无法修改，所有转换操作提供新的RDD，保证数据一致性；（2）分区性（Partitioned）：数据分布在集群的多个节点上，每个分区是基本的计算单元；（3）血统（Lineage）：记录RDD的提供路径（父RDD的转换操作），用于容错时重新计算丢失分区；（4）延迟计算（LazyEvaluation）：转换操作（如map、filter）仅记录操作链，行动操作（如count、collect）触发实际计算；（5）持久化（Persistence）：支持将RDD缓存到内存或磁盘，避免重复计算。容错方面，当某节点故障导致RDD分区丢失时，Spark通过血统信息重新计算该分区（而非复制全量数据），相比HDFS的副本机制更节省存储资源；高效计算方面，分区性支持并行处理，延迟计算通过DAG（有向无环图）优化执行计划（如合并连续的map操作），持久化则减少重复读取数据源的开销，尤其在迭代计算（如机器学习）中显著提升性能。6.实时流处理框架（如Flink）中，时间窗口（TimeWindow）的常见类型有哪些？各适用于什么场景？Flink支持三种核心时间窗口类型：（1）滚动窗口（TumblingWindow）：固定大小、无重叠的窗口（如每10分钟一个窗口），适用于周期性统计（如每小时订单量），窗口触发后数据不再参与后续计算；（2）滑动窗口（SlidingWindow）：窗口大小固定但滑动步长小于窗口大小（如窗口10分钟，步长5分钟），适用于需要更细粒度统计且允许部分重叠的场景（如实时监控过去10分钟内每5分钟的平均温度）；（3）会话窗口（SessionWindow）：基于事件间隔动态划分窗口，当同一实体的事件间隔超过阈值时关闭当前窗口（如用户会话超时30分钟则结束），适用于用户行为分析（如统计单次会话内的点击次数）。此外，Flink还支持全局窗口（GlobalWindow），需配合触发器（Trigger）使用，适用于自定义聚合逻辑（如仅当特定事件触发时计算窗口结果）。时间语义上，窗口可基于事件时间（EventTime，事件实际发生时间）或处理时间（ProcessingTime，系统处理时间），事件时间需结合水印（Watermark）处理延迟数据，适用于对时序准确性要求高的场景（如金融交易分析）。7.数据仓库分层设计中，ODS、DWD、DWS、ADS层的主要职责分别是什么？各层数据有何特征？（1）ODS（操作数据层，OperationalDataStore）：直接对接数据源（如业务数据库、日志系统），存储原始数据的“镜像”，保留数据原始格式（如关系型数据库的全量/增量同步、日志的原始文本），不做任何清洗或转换，特征为“原始性”和“时效性”（通常与源系统保持高频同步）；（2）DWD（细节数据层，DataWarehouseDetail）：对ODS数据进行清洗（去重、补全缺失值）、规范（统一字段命名、类型）和轻度聚合（如按事件ID关联多表），提供“原子化”的明细数据，特征为“一致性”（统一数据口径）和“可追溯性”（保留清洗日志）；（3）DWS（汇总数据层，DataWarehouseSummary）：基于DWD层按主题（如用户、商品）和维度（如时间、地域）进行轻度汇总（如日活用户数、商品日销量），存储统计型宽表，特征为“高聚合”和“低粒度”（通常按天/小时汇总）；（4）ADS（应用数据层，ApplicationDataStore）：直接对接业务需求（如BI报表、APP接口），存储高度定制化的结果数据（如用户画像标签、实时大屏指标），特征为“场景化”（按需建模）和“高访问效率”（可能预计算或缓存）。8.数据湖（DataLake）与传统数据仓库（DataWarehouse）的核心差异体现在哪些方面？（1）数据类型：数据仓库仅支持结构化数据（需预定义Schema），数据湖可存储结构化、半结构化（如JSON）、非结构化数据（如图片、视频），采用SchemaOnRead模式；（2）存储成本：数据仓库依赖专用存储设备（如OracleExadata），成本高；数据湖基于分布式文件系统（如HDFS、云对象存储），存储成本低；（3）处理模式：数据仓库以批处理为主，支持OLAP分析；数据湖支持批流一体处理（如Flink处理实时流数据写入湖），并可集成机器学习、数据科学工具；（4）数据质量：数据仓库通过ETL流程严格保证数据质量（如完整性、一致性）；数据湖早期因Schema灵活可能存在数据杂乱问题，现代数据湖（如DeltaLake）通过ACID事务和元数据管理提升质量；（5）适用场景：数据仓库适合固定业务场景的确定性分析（如财务报表）；数据湖适合探索性分析（如机器学习特征挖掘）和多源数据融合（如结合用户行为日志与外部天气数据）。9.分布式计算中“数据倾斜”的典型表现是什么？如何检测与解决数据倾斜问题？数据倾斜表现为：（1）任务执行时间严重不均，部分Task运行超时（如99%的Task已完成，1%的Task仍在运行）；（2）个别节点内存/磁盘I/O负载过高，甚至触发OOM（内存溢出）或磁盘写失败；（3）Shuffle阶段网络传输量异常，某几个ReduceTask接收的数据量远大于其他。检测方法：（1）日志分析：查看任务日志，统计各Task处理的数据量（如MapReduce的Counter或Spark的StageMetrics）；（2）采样统计：对Key的分布进行采样（如抽取10%的数据统计Key的出现次数），识别高频Key；（3）监控工具：使用Prometheus+Grafana监控各节点的CPU、内存、网络流量，定位异常节点。解决策略：（1）预处理倾斜Key：对高频Key添加随机前缀（如将Key“user_1001”变为“user_1001_0”“user_1001_1”），分散到多个Task处理，聚合时再去除前缀；（2）调整分区策略：将默认的Hash分区改为Range分区（基于Key的分布手动划分区间），或使用自定义分区器（如按Key的出现频率动态分配分区）；（3）启用Combiner：在Map端提前聚合数据（如求和、计数），减少Shuffle传输量；（4）资源隔离：为处理倾斜Task的节点分配更多内存/CPU资源（如Spark中通过--executor-memory调整）；（5）切换计算框架：对于极倾斜场景（如某Key占比90%），可改用流处理框架（如Flink）的状态后端（StateBackend）进行增量计算，避免全量Shuffle。10.结合CAP理论，说明HBase与MySQL在分布式一致性上的选择差异及原因。CAP理论指出，分布式系统无法同时满足一致性（Consistency）、可用性（Availability）、分区容错性（PartitionTolerance），需权衡其中两项。HBase选择AP（可用性+分区容错性），MySQL（主从复制模式）选择CP（一致性+分区容错性），原因如下：HBase作为NoSQL数据库，主要面向高并发读写场景（如实时查询），设计目标是在网络分区时仍能提供服务（可用性）。其一致性模型为“最终一致性”：写入主RegionServer后异步复制到从RegionServer，客户端可能读取到旧数据，但经过复制延迟后所有副本达成一致。这种选择牺牲强一致性，换取高可用性和水平扩展能力（支持千万级并发）。MySQL主从复制模式下，主库写入后需同步到从库（同步/半同步复制），客户端读取从库时需等待同步完成（或通过中间件路由到主库），确保读操作获取最新数据（强一致性）。但网络分区时，若主从无法通信，为避免数据不一致，系统可能拒绝写入（牺牲可用性）。这种选择适用于对一致性要求高的OLTP场景（如金融交易），但扩展能力受限（主库为瓶颈）。11.大数据安全与隐私保护需关注哪些关键技术？举例说明联邦学习在隐私保护中的应用。关键技术包括：（1）数据脱敏：对敏感信息（如身份证号、手机号）进行匿名化处理（如哈希、替换、掩码），常见方法有K-匿名（保证至少K条记录不可区分）、L-多样性（同一K组内属性值多样）；（2）加密存储与传输：使用AES对称加密或RSA非对称加密保护存储数据，通过TLS协议加密网络传输；（3）访问控制：基于角色的访问控制（RBAC）或属性基访问控制（ABAC），限制不同用户对数据的操作权限；（4）隐私计算：如联邦学习、安全多方计算（MPC），在不共享原始数据的前提下完成联合建模。联邦学习（FederatedLearning）的典型应用是跨机构联合风控模型训练：银行A拥有用户基本信息（如收入、职业），银行B拥有用户信贷记录（如逾期次数），双方均无法直接共享数据。通过联邦学习，银行A和B在本地训练模型，仅交换模型参数（如