在当今互联网产品发展日新月异、业务迭代迅猛的时代；跨业务分析的需求日益增长，这种变化既为企业创造了敏捷决策、精准运营的新机遇，也带来数据割裂、价值释放滞后等严峻挑战在线课堂。特别是大型互联网企业，往往构建有复杂的多业务、多模块、多线条体系，每日持续产出海量的数据信息。这些数据的服务对象正逐步从数据研发人员扩展至更为广泛的产品相关人员，如何高效开展数据获取工作，打破数据孤岛现象，充分挖掘并释放数据驱动业务的潜力，已成为业界广泛关注和讨论的焦点议题。针对该问题，业界传统数仓常采用的是经典分层模型的数仓架构，从 ODS（Operational Data Store）>DWD（Data Warehouse Detail）>DWS（Data Warehouse Summary）>ADS（Application Data Store）逐层建模，但我们会发现，从传统固化开发的角度来看，传统经典数仓模型是比较有优势的。然而，面对当下数据需求灵活多变的时代，其局限性也日益凸显。如下图
1.2 搜索场景下的困境与挑战
搜索作为百度的核心支柱业务，涵盖通用搜索、智能搜索、阿拉丁与垂类等多元化、多模态的搜索产品，具有快速迭代、模块多元化且复杂的特性，搜索数据更是复杂多样，整体数仓规模达到数百 PB 以上在线课堂。
随着搜索业务各个模块之间的联系日益紧密，交叉分析的需求也在不断增长在线课堂。使用人员对数据获取的便捷性提出了更高的要求，其中涵盖了数据分析师、策略、业务产品经理、运营、评估等多类角色。他们的诉求期望能够跨越复杂的数据架构壁垒，以更加高效、直观、快速的方式获取到所需数据。
而传统的搜索数仓建设体系 无论从建模角度还是技术框架上，都与现阶段用户诉求背道而驰在线课堂。
建模角度：多层的传统分层建模在线课堂。往往会出现（大表数据量大、查询慢、存储冗余、口径不统一）等问题，影响业务分析效率，从而达不到数据驱动业务的效果。数据开发侧作为需求的被动承接方，根据业务侧提出的数据需求进行数据开发与交付，存在需求交付周期长、人力成本高等问题。
技术框架角度：搜索数仓过去大多是采用 UPI 框架（以 C++ MR 计算框架为主）进行 ETL 处理在线课堂。由于该框架技术陈旧，往往会出现以下问题影响数仓整体时效、稳定。从而使业务部门感知需求支持迟缓、数据产出延迟及数据质量低等一系列问题。
容易出现服务不稳定在线课堂。
处理能力薄弱：处理不了特殊字符，从而导致数据丢失或任务失败等在线课堂。
只能通过物理机远程执行的方式提交，有单节点风险在线课堂。
无法 Writer 将数据写到 Parquet 文件，需要进行特定脚本 ETLServer 框架进行转换在线课堂。
思考：如何更好的满足用户角色需求在线课堂，进一步降低数据获取的使用门槛？
破局：拥抱变化，以用户诉求为核心出发点在线课堂。 探索更适合用户的 体系化建模 来进行实质、有效的数据管理。
体系化建模：以业务产品需求驱动模型设计，以模型设计驱动和约束开发实施，防止因模型设计与业务产品割裂、开发实施缺少约束带来的无序、“烟囱式” 开发在线课堂。在机制上形成模型设计与开发实施的有效协同。
切入点：以规范 “基础数据建设”，消除因 “烟囱式” 开发给业务带来的困扰和技术上的浪费在线课堂。
由此我们探索出一套新的建模体系：大宽表 + 数据集：其核心点就是基于宽表 将之前的 "需求 - 交付" 解耦为以数据集为中心的建设，从而提升搜索内业务数据分析效率与分析深度，更好助力业务决策在线课堂。以下将从宽表建模、计算引擎架构优化、新型业务交付模式等方向为大家介绍搜索数据团队业务实践。