作者 | chris
指导。在大数据时代，基于海量数据分析和挖掘高价值信息，用于引导和驱动业务的快速发展，是数据建设的基本能力和价值体现。为提升生产运输端的数据观察、分析、决策效率，支撑业务快速迭代，移动生态数据研发部对数据仓库建模和BI工具进行了升级，采用宽表建模与TDA平台相结合的解决方案，一站式解决数据应用需求。 在这个过程中，数据交付模式发生了变化，从研发定制开发到生产运输的自助采集，业务端的数据采集变得更加方便、快捷、准确。
全文3540字，预计阅读时间9分钟。
数据驱动的业务，一方面要求我们构建一个全面、准确、及时、易用的数据仓库，另一方面也需要构建一个统一的数据可视化平台，集成了ADHOC查询、数据分析、数据上报等应用能力，让业务高效、便捷、精准地获取数据， 并促进业务增长。
在行业中，通常采用分层模型构建数据仓库，从ODS>DWD>DWS>ADS逐层构建，定制ADS层开发，以满足业务侧的需求。 在这种模式下，复杂多变的业务场景需要数据研发的参与，数据采集时间取决于开发端调度，定制结果不够灵活，需要频繁迭代，ADS层占据的数据研发时间占比相对较高。 随着业务增长越来越快，对数据的需求急剧增加，导致劳动力成本增加，交付效率降低。 因此，有必要探索新的数据开发和交付模式，完成从研发定制开发到生产运输自助获取的转变。
考虑到数据应用从研发到生产运输的转变，数据使用门槛需要进一步降低，对数据仓库和数据可视化平台的用户体验有更高的要求。
使用数据仓库的经验体现在直接交互的宽表层上，理想的宽表应满足以下要求：
1. 全面：覆盖多种场景，满足业务需求。
2.准确：逻辑统一收敛，口径简洁明了，在业务使用上没有歧义。
3.及时：解决上游时效差异化带来的桶效应，批量生产田地。
4.易于使用：需求场景可以通过单个宽表获取，避免了多个表的关联。
数据平台需要考虑用户差异化的SQL能力、分析习惯、分析方法，在数据可视化和数据计算性能方面满足用户体验
1. 可视化：拖拽式施工，丰富的算子和风格。
2. 计算性能：查询时间以秒为单位。
基于上述思路，本文探讨了用宽表建模替代分层建模的方法，并介绍了TDA平台，通过数据仓库模型和数据可视化平台的结合，支持自动获取所需数据。
为了平衡数据的时效性和易用性，构建了500+DWD、DWS、ADS表，存在表亲缘关系复杂、中间表冗余、数据口径不一致、SQL复杂度高等问题。
针对上述问题，提出一种宽表建模方案：根据产品功能和业务场景划分主题，明确主题和所有业务流程的最细粒度，直接构建基于ODS表的宽表层，覆盖业务所需的所有字段，支持即席分析、报表查询等所有数据应用场景。
数据仓库建模的演变
由于宽表中上行数据源多，数据量大，当多个上行数据没有为相同数量的数据做好准备时，宽表的输出时间会产生桶状效应。 此外，为了尽可能覆盖所有业务需求，封装了大量的处理逻辑和相关计算，比较复杂，维护成本和回溯成本非常高。 为了解决上述问题，探索并实现了一种多版本的宽表建模方案。 根据数据时限的差异，将宽表拆分为多个计算任务，每个任务生成宽表的一些字段，并根据配置对数据进行合并，最终生成一个完整的宽表。
为了提高宽表的整体时效性，需要在数据生成后尽快将各个版本的数据合并到宽表中，合并后需要为下游提供依赖检查机制，感知到版本的字段已经生成。
为了保证每个版本的数据在输出后尽快合并到宽表中，避免两个合并任务在同一分区同时运行导致数据混乱的问题，引入了分布式锁服务，通过抢占成功来判断是否需要合并。 整体流程图如下：
多版本合并流程
锁定的维度是表名和日期分区，根据锁状态、任务状态和过期时间确定是否成功添加锁
1.锁不被占用，表示没有其他合并任务，且任务锁定成功。
2. 锁定占用如果任务状态异常，则当前合并任务失败，任务被强制解锁锁定。
3. 锁占用任务被杀死后，任务被强制解锁，锁被成功锁定。
在多版本合并方案中，为了提高宽表合并任务的通用性，提取了通用的合并逻辑，基于配置文件将版本化数据生成的文件合并到宽表中。 配置文件包含多组文件地址、关联条件、关联类型和字段信息。 每个文件地址都是由一个独立的任务生成的，该任务负责数据源的逻辑，数据口径的更改只需要更改相应的任务，维护成本低。
多版本宽表中的字段是根据时效的差异逐版输出的，因此需要提供依赖检查机制，以便下游能够及时使用准备好的字段，以满足高时效数据的应用场景。 有三种不同的方法可以检查方案中的依赖项：
1. 任务组依赖关系：对调度平台的任务名称进行依赖检查，支持工厂内的pingo和TDS调度平台。
2. AFS文件依赖：将一个版本合并到宽表中后，会生成一个AFS标识文件，其中包含该版本的成功任务，可用于检查与下游的依赖关系。
3.现场输出检测服务：对于数据应用平台（如Yimai、TDA），平台无法识别查询到的字段是否通过任务组和AFS文件生成。 针对这些场景，提供字段检测服务，将某个版本合并到宽表后，检测服务中该版本相关字段的输出标识符会更新，数据应用平台会调用API接口，判断本次查询中的字段是否在查询时间范围内准备就绪，以保证数据的可用性。
现场探测服务
成本方面数据仓库中的表数量减少 60%，数据仓库中的存储量减少 30%。 此外，表任务的减少减少了数据任务，数据查询从多个DWD和DWS表的关联优化到宽表，避免了大量的随机操作，将即席查询时间从几分钟缩短到几秒钟，节省计算资源20%。
质量方面宽表的领域非常丰富，达到上千个，尽可能覆盖主题的所有业务场景，因此应用层的数据可以完全收敛到宽表层，消除了分层数据仓库中表冗余、逻辑下沉不完全导致口径不一致的问题， 而产品端基于宽广的表面管理指标口径，沟通更顺畅，数据准确度更高。
效率方面：宽表模型非常好用，单个宽表即可满足复杂的需求，并且通过基本的SQL能力即可获取所有数据，业务体验非常好。
常见的数据需求分为三类：临时数据收集、报表开发和数据分析。 针对临时增数场景，宽表模型提供业务覆盖全面、数据采集方便，可支持生产运输端通过简单的SQL拼写获取数据。 对于报表开发场景，仍然需要数据开发，构建ADS层应用表，同步到OLAP存储，并使用Sugar等报表平台进行配置。 对于数据分析场景，生产运输方可以基于宽表获取分析数据，但需要保存灵活多变的分析结果并直观展示，体验较差。
宽表模型大大简化了数据查询的复杂度，为自助数据采集提供了基础能力，报表和数据分析所需的数据可视化能力成为生产运输自助数据采集的障碍。 在此，引入TDA数据可视化平台，支持仪表盘的数据分析和拖拽构建，丰富的数据处理分析能力，一站式解决数据应用需求。
自助式思维
在这种模式下，数据研发学生负责主题宽表查询性能的构建、同步、优化，数据产品学生负责数据集的配置，操作学生负责基于数据集的可视化分析和仪表盘配置，从而实现数据应用的自助服务。
宽表构造：基于宽表建模的思想构造宽表。
数据同步：从HDFS同步数据到ClickHouse，在数据仓库宽表的每个版本生成后启动同步任务，在数据同步阶段对不同查询场景的密钥进行洗牌。
性能优化：为了优化查询时间，引入了缓存和自动滚动两种机制。 缓存包括两种情况：用户首次查询并缓存查询结果; 根据用户的查询历史，在离线任务模式下通过轮询模拟用户查询，并将查询结果更新到缓存中。 根据用户历史查询记录的特征，对高频维度进行投影聚合自动上传。 目前，对于数千万级的数据查询场景，查询时间需要秒级。
缓存 + 自动汇总机制
通过数据仓库宽表模型与数据可视化平台的结合，完成了数据需求从研发定制开发到生产运输自动化采集的转变，数据分析的灵活性和效率大大提高，人工成本降低。
1、研发需求下降57%，其中数据应用需求占比从60%下降到10%。
所需数量
2、可视化分析场景日PV4000+，整体数据需求自助服务率达到92%。
3. 单次查询所需时间从几分钟缩短到几秒钟。
4.报告开发周期从几天缩短到几小时。
end – 推荐阅读。 搜索 Exgraph Graph Execution Engine Design & Practice.
搜索与金融：构建高时效性和高可用性的分布式数据传输系统。
经验分享：SWIFT 语言实施实践。
在账户系统中实行移动防截图录制技术。
AI原生工程：AI交互技术在APP中的实践。
优质作者名单