秦皇岛网络公司 网站托管,服饰类电商网站建设策划,网站登陆模板,南昌做网站和微信小程序的公司在当今以数据为核心的商业环境中#xff0c;企业正面临着海量数据的处理和分析挑战。为克服传统数据仓库在处理速度、灵活性和成本效率方面的局限#xff0c;小红书数据仓库团队引入如 Apache Iceberg 等数据湖技术#xff0c;将其与数仓架构相结合#xff0c;以释放数据湖…在当今以数据为核心的商业环境中企业正面临着海量数据的处理和分析挑战。为克服传统数据仓库在处理速度、灵活性和成本效率方面的局限小红书数据仓库团队引入如 Apache Iceberg 等数据湖技术将其与数仓架构相结合以释放数据湖在查询性能、实时数据处理和成本效益方面的潜力。 小红书数据仓库团队通过一系列创新实践如 UBT 链路优化查询效率、渠道归因数据架构改造、汉姆拉比数据链路优化以及直播准实时链路提升等证明了数仓与数据湖技术的结合能带来显著的业务价值不仅提升用户体验还实现了计算和存储资源的大幅度节约同时确保了数据的高质量和一致性。 未来团队计划继续利用数据湖技术构建准实时的数据新架构以满足企业对数据时效性的多样化需求。 过去十多年Hive/Spark on HDFS 作为离线数据仓库的事实标准在实践中得到了广泛应用。然而随着业务对数据时效性和查询性能要求的提升Hive 的传统架构开始显现出其局限性。具体表现在 数据变更成本高昂即使仅变更一条记录也需要重新刷新整个分区的数据数据产出时效性差分区数据通常需要 T1 日期才能完成数据查询性能缓慢查询相关数据通常需要扫描目录中的所有文件大表查询耗时且效率低下资源利用率不足所有天级调度任务的资源消耗全部集中在调度期间容易导致多任务抢占资源影响资源使用效率。 这些性能问题严重制约了数据仓库在支持业务决策中的作用。为了应对这些挑战我们积极探索新方向力求在满足业务日益多样化的需求下总结出一些通用化、低成本的数仓架构新方案以解决上述问题。本文详细记录了我们在数仓架构和数据湖技术结合方面的深入探索和实践期待对您有帮助欢迎结合自己兴趣和相关业务自主选择阅读。 数据湖技术近年来在数据管理领域引起了广泛关注其优势在于提供了一种灵活且高效的数据存储和处理方式。一方面在 Apache Iceberg、Apache Hudi 等知名开源项目的推动下社区气氛十分活跃另一方面处于链路上下游的数仓软件和数据分析引擎也开始积极拥抱开放的数据湖格式如 Doris 系的开源数仓和 Starrocks 引擎它们能够查询 Iceberg 数据进一步证明了数据湖技术的实用性和前瞻性。 不同于原有的 Hive 数仓架构Iceberg 依托于其文件级数据追踪的技术架构展现出以下显著优势 查询性能提升Iceberg 支持异步数据重组(如 Zorder)结合动态列全局排序和索引机制大幅减少查询时的文件读取量显著提升查询效率和 shuffle 性能。增量读写能力小红书自研的 Iceberg 适配了 Spark 引擎支持 update、merge into、delete 等语义能够对指定文件进行删除和更新操作。相较于 Hive 的分区目录完全重刷可将更新成本降低至文件粒度。流批一体架构Iceberg 基于增量读写机制通过适配 Flink 等实时引擎的读写形成了“MQ Flink Iceberg”的流批一体架构。对于近实时的需求这种架构既可以提升数据产出的时效性也可以省去维护 Lambda 架构所需的人力和资源成本。成本效应显著Iceberg 底层采用 Parquet 文件格式其列存储格式和索引排序机制通过提升重复字段的压缩效率进而节约了存储成本。 UBT 日志User Behavior Tracking全称用户行为追踪日志详细记录了用户在特定平台、应用或网站上行为轨迹如页面访问、图片曝光、按钮点击等。作为流量数据的核心组成部分UBT 也是小红书数据仓库中数据量最大、查询频次最多的数据表之一。随着小红书用户基数的快速增长和使用时长的增加流量数据规模不断膨胀导致 UBT 日志查询效率低下用户体验受损。用户在进行日志查询时常常面临长时间的等待甚至在数据量过大时无法完成查询这些问题严重制约了数据驱动决策的效率和效果。 3.1 历史方案回顾 在处理 UBT 日志数据时我们曾采用一种朴素的方法将数据从主表抽取到多个分流表中以便下游业务方能够针对特定需求进行查询。这种方法在业务逻辑相对简单时能够有效减少查询的数据量提高查询效率。 然而随着业务复杂度的增加这种方法暴露出一系列问题 成本与复杂性增加随着业务规则的多样化分流表的数量迅速增长导致计算和存储成本不断攀升且难以管理。数据一致性挑战对分流规则的任何变更都需回刷大量历史数据这不仅耗时耗力还可能引入数据不一致的风险。数据冗余与维护困难个性化的分流规则缺乏通用性和排他性数据在不同规则间重复存储增加了维护的难度。 这种基于自定义规则的分流策略在面对日益增长的数据量时不仅资源消耗巨大而且难以维护严重影响了数据的实时性和查询效率。在某些情况下缺乏分流表支持的原日志查询变得异常困难。 3.2 查询性能优化 在流量数据分析中点位(埋点)作为描述用户特定行为的关键标识也是业务数仓数据加工的基础粒度。面对小红书线上近万个点位的庞大数据量我们实施了一系列查询性能优化策略以提升数据处理效率。 我们认识到通过点位限制帮助用户缩小数据范围加速后续的业务逻辑处理可有效提升查询性能。然而传统的分区策略在面对庞大的点位数量时显得力不从心Hive Metastore 难以承受巨大的分区规模。因此我们的目标转变为如何能购针对特定点位的数据进行快速定位并筛选实现数据范围的精确缩小。 从这一视角出发数据湖为我们提供了新的视角和解决方案。我们采用了全局排序的方法将相同点位的数据集中存储而将不同点位的数据分散存储在不同的文件中。这种策略不仅提升了文件过滤的效率还通过引入 Iceberg 技术将点位的 min-max 信息存储在 meta 文件中。这样在任务规划阶段查询引擎就能利用这些信息进行文件过滤显著减少了实际查询过程中需要处理的文件数量从而实现了查询性能的大幅提升。 性能优化方案如下 全局排序按照点位 ID 进行全局排序实现了自定义的数据抽样和分区划分的逻辑并且为大点位划分更多分区解决了大小点位数据倾斜问题从而提高单个点位的计算效率。另外为解决随机采样可能存在误差的问题我们借助 Spark Sql 的自动查询优化AQE功能作为兜底并开发了 bypass hash 函数以便在 Spark 中实现自定义分区根据数据生成的 partition_id 来划分分区。分区排序与去重若日志数据存在重复的情况按照传统思路需要先去重然后再排序来优化查询这会带来两次 shuffle显著增加计算成本。为了解决这一问题我们基于全局排序采取了一种创新的方法在数据按点位 ID 排序的同时直接在排序过程中识别并过滤掉重复的数据。Iceberg 视图生成为了确保与现有 Hive 生态系统的兼容性我们在 Hive 表上建立了外部 Iceberg 表级视图。这一视图通过扫描数据文件并提交文件 metric 信息使得下游系统能够基于 Iceberg 的 MinMax 提升查询性能并且能直接读取视图进行数据消费简化了数据访问流程。 通过这些优化UBT Iceberg 表的查询性能得到了显著提升用户在查询特定点位数据时的时长缩短了约 8090%极大地提高了数据处理的效率和用户体验。 3.3 新分流方案 上述性能优化提升了用户对点位的查询效率。点位是用户使用日志的基础粒度我们开始进一步考虑以点位为基础构建一套新的分流体系旨在替代原有的分流表体系。新体系的设计遵循了三个核心原则确保分流查询性能满足用户需求、最小化存储和计算开销、以及限制分流表的数量以避免无序增长。基于这些原则我们设计了以下新分流方案 分流转换功能新方案实现了在 Spark 执行计划层自动将对分流表的查询转换为对 Iceberg 表中特定点位集合的查询从而提高了查询效率。业务场景导向新分流体系以通过构建实际业务场景作为准入标准每个业务场景对应一个分流表同时通过上线流量产品注册收拢分流表的创建这样既明确了分流的业务含义也杜绝了分流数量的无限制上涨。视图封装在分流转化函数外层我们封装了分流表视图这使得下游业务方无需感知内部优化简化了数据访问流程。 新分流表不再直接存储数据也无需任务调度从而避免了计算和存储资源的消耗。更新分流表时只需调整点位集合无需回刷历史数据。得益于之前的查询性能优化新分流方案在满足业务需求的同时也保持了高效的查询性能。 相较于旧方案新分流方案每天可节省数十万 GB/Hour 的计算资源和几百 TB 的存储资源同时任务产出时效提升了约 30 分钟查询性能得到了数十倍的提升。这一改进不仅提升了数据处理效率也为未来的数据分析和业务决策提供了更坚实的基础。 渠道归因作为分析用户行为路径、埋点归因的关键工具对于社区、电商和直播等业务的流量分析至关重要。它不仅支持流量来源和转化分析还有助于深入理解用户路径。作为数据仓库的基础服务渠道归因要求具备高实效性、准确性和稳定性。 在早期的渠道归因实践中我们使用 Flink 处理 UBT 日志数据为每条数据附加用户从打开 App 到当前页面的完整跳转路径并直接写入云存储。由于小红书的 Flink 集群部署在公有云而离线数据和处理引擎位于 A 云我们通过 Discp 操作将数据从公有云迁移到 A 云。这种架构导致时效性差因为跨云同步和分区任务在离线侧完成且每天需要占用额外的存储资源增加了成本。 为了解决这些问题我们对渠道归因数据架构进行了彻底改造。我们移除了原有的离线 Discp 任务和 Spark 分流转而采用 Flink 与 Iceberg 的结合实现了在实时数据写入过程中的自动分流。这一改造不仅优化了任务处理的负载均衡还确保了分区数据文件数量的可控性从而保障了离线数据产出的时效性和查询效率。通过这些改进离线数据的产出时效提升了 90%从而尽早释放离线集群资源保障了其他离线作业的稳定性。同时实时渠道产出的数据现在也能支持交易、直播、广告等实时业务场景为企业提供更快速、更灵活的数据分析能力。 Iceberg 的实时读写能力使其成为流批一体的理想存储解决方案。然而由于实时链路和离线链路位于不同的云平台我们不得不在两个云上分别备份数据。为了解决这一问题我们设计了两条独立的数据处理链路实时业务消费实时分流任务的数据而离线侧则消费 Iceberg 数据。在新架构中渠道归因数据首先写入 Kafka然后分为实时分流作业和实时入湖作业。实时入湖作业按业务分区将数据写入 Iceberg。Iceberg 收集各分区的最新统计信息并根据这些信息重新分配业务分区的并发处理确保整体处理均衡。离线侧通过定期轮询 Iceberg 的元信息监听当前处理的数据时间触发下游的小时级或天级任务调度。这一改造显著提升了数据处理的灵活性和效率。 小红书的反爬虫日志由于接入了整个公司的反爬场景 Scenarioid 导致整体数据量庞大。它作为反爬虫日志的核心其庞大的数据量在生产过程中消耗了大量计算和存储资源。特别是不同云之间的跨云文件传输过程每天传输数百 TB 数据占据了 20% 的带宽资源尤其是在业务高峰期时对跨云传输服务造成巨大的负载压力从而严重影响跨云传输服务的稳定性。 解决该问题的核心难点在于在大数据量及有限时间内的条件下如何有效降低跨云传输的文件大小。为了有效降低跨云传输的数据量我们结合数据湖团队的流批一体工具链对汉姆拉比数据链路进行了优化采取以下策略 数据同步策略调整不再直接同步公有云上的 Agent-smith 日志而是通过 Kafka2Iceberg 任务将汉姆拉比 Kafka 数据同步到公有云上的 Iceberg 表Iceberg 底层基于 Parquet 文件格式其列存储格式和索引排序机制可以提升重复字段的压缩效率因此最终跨云同步的对象变成了经过压缩的 Iceberg 表从而极大提升了同步效率。数据压缩与批量处理在 Kafka 中我们针对场景 Scenarioid 字段进行 shuffle并通过每 5 分钟 checkpoint 机制批量导入数据到Iceberg 表同时在导入过程中对文件进行 Parquet 压缩。这种 shuffle 和 压缩的结合显著提高了数据的压缩率。 优化后成果显著新链路的数据到岗时间比老链路提前了约 85 分钟专线带宽节省了 83%存储空间也减少了 83%。这些改进不仅提高了数据处理效率还为公司节省了宝贵的资源确保了数据链路的高效运行。 为了提升直播业务的数据处理能力我们基于数据湖技术对直播实时链路进行了全面改造实现了流批一体的数据处理架构。这一架构不仅在交易实时数仓领域得到了成功应用还显著提升了直播间入口曝光和点击行为事实明细表的数据处理效率。 如下图所示直播入口曝光点击流量经分流后进入直播处理链路此时会写入数据湖作为历史数据回溯使用而 Kafka 链路则基于 Flink 任务加工生成实时离线一致的 DWD 层同步入湖和 Kafka满足实时、近实时、离线的直播下游使用需求。 通过采用 Flink 与 AWS Iceberg 的结合以及多个用户自定义函数UDF我们成功地将原有的 UBT 链路切换至新的架构。这一转变不仅还原了大部分字段还确保了数据校验的一致性。目前新链路已稳定运行显示出以下显著优势 流批一体实时和离线逻辑的统一确保了数据的一致性。字段解析和逻辑处理集中在实时处理中避免一点改动涉及多张表的问题。统一数据源实时和离线分析使用相同的数据源进一步保障了实时与离线指标的一致性。维护成本降低公共层的人力维护成本大幅减少迭代和开发工作现在只需单一人员完成。 此外数据湖技术还显著提升了直播数仓的实时开发效率和数据质量。例如AWS Iceberg 支持离线任务调度实现流批一体而相对便宜的 COS Iceberg 提供了成本效益更高的数据入湖存储适用于日常的数据校验、Kafka 即时查询和 Case 排查等需求。 COS Iceberg 的引入解决了 Kafka 数据存储时间短和即时查询不便的问题使得实时开发更加便捷。实时写入任务如 Starrocks、Redkv、ES 等都会同时写入 COS Iceberg便于问题排查和数据校验。Iceberg 中存储的分区、Offset等元信息对于排查字段状态、乱序等问题尤为有用。 数据湖技术的 upsert 能力为数仓架构带来了显著的升级。对于日志表等 Append 类型表实现流批一体相对容易但对于需要更新操作的 Upsert 表数据湖必须具备相应的能力。为此数据湖团队早期开发并上线了 Iceberg v10 表该表支持 upsert 功能。如下图所示在这一架构下数仓团队已成功应用于域内和域外订单表通过 Package_id 和 Sku_id 的联合主键进行更新使得表既可以作为增量表也可以作为全量表使用。此外基于 As Of Time 的时间切片查询功能全量表仅需存储一份数据这不仅方便了实时离线数据的对齐和历史状态查询还弥补了离线链路数据归档后状态回溯更新成本高的问题。 展望未来数据湖团队将继续开发和迭代 Apache Paimon数仓也将采用 Paimon 来构建支持 upsert 场景的流批一体架构进一步提升数据处理的灵活性和效率。这将为实时分析和历史数据管理提供更加强大和灵活的工具确保数据湖技术在数仓架构中的全面应用和持续优化。 结合数仓与数据湖技术的相关实践从落地效果上看我们已经在三个关键领域实现了显著的收益 产出时效通过准实时链路的改造我们显著提升了数据处理的时效性。ODS 和 DWD 层的数据时效提升了 50%。同时 0-2 点为资源空闲时间段提前产出能够留给下游任务更多的空间提升空闲时间段的资源利用率。成本收益主要分为存储成本收益、计算资源成本收益和人力成本收益。例如“汉姆拉比数据链路”优化后新链路节省了 83% 的存储空间。在计算资源方面 UBT 链路优化查询效率提升项目每天节省了数十万 GB/Hour 的计算资源和几百 TB 的存储资源。人力成本方面流批一体架构的实现减少了公共层的维护和开发工作如直播准实时链路提升项目现在仅需一人即可完成迭代和开发。数据质量通过 MQ Flink Iceberg 的流批一体架构我们确保了实时和离线数据的一致性有效解决了数据不一致的问题从而提升了数据质量。这在渠道归因数据链路架构和直播准实时链路提升项目中得到了验证。 数据湖技术为数仓提供了一种高效、低成本且响应迅速的解决方案有效满足了公司对数据时效性日益增长的需求。 展望未来我们计划在数据引擎团队的支持下利用数据湖技术大规模构建低成本的次实时数据解决方案。这些方案将针对那些不需要极快速响应的业务场景旨在成为实时分析的首选。通过这种方式实现开发效率和资源成本的双重优化。 此外我们还将探索“数据湖 OLAP 引擎”的组合策略以构建新的业务交付标准。这种策略将结合数据湖的灵活性和 OLAP 引擎的高性能为数仓提供更强大的数据处理能力支持更复杂的分析需求提高数据迭代的效率同时保持成本效益。我们致力于通过这些创新推动数仓技术的持续进步为公司的数据分析和决策提供更坚实的支持。诚挚邀请您的加入一起探索数仓和数据湖技术的无限可能。 马尔科(吴浩亮) 小红书数据解决方案专家现负责小红书用户增长、搜推、基础流量、电商、直播等多个业务领域数仓建设。孙武(施裕豪) 小红书数据仓库工程师毕业于东南大学现负责用户行为分析产品和社区流量数据建设。黄猿(吴筱琦)小红书数据仓库工程师毕业于南京大学现负责渠道归因和数据任务性能优化。沈默(王有凯)小红书数据仓库工程师毕业于北京邮电大学现负责流量实时离线数据仓库基础层建设。捡子(薛夏磊)小红书数据仓库工程师毕业于复旦大学现负责交易直播实时数据建设。 数据仓库专家-基础方向 工作职责 参与公司流量日志数据仓库设计、建设和治理工作对海量用户日志数据链路进行架构规划、建设管理协同平台产品团队迭代流量分析产品工具参与公司核心数据应用项目开发建设推动数据驱动的业务决策。 相关要求 拥有实时、离线数据链路开发经验具有大厂流量域 PB 级日志流量数据处理经验熟悉数据仓库领域知识和技能具备一定的代码开发能力 (如 Java、Scala 等)参与过流量域产品开发经验、有数据治理、数据质量体系建设、数据监控告警体系相关搭建经验加分 欢迎感兴趣的同学发送简历至 REDtechxiaohongshu.com并抄送至 shiyuhaoxiaohongshu.com、marcoxiaohongshu.com。
