滴滴快的大数据架构演进_17页_960kb

滴滴算法大赛总结

核心内容

滴滴算法大赛即将在五月举行，旨在通过提供十万美金的独家数据，吸引科学狂人参与，推动算法创新与应用。该大赛不仅是一个技术竞赛平台，更是一个探索大数据架构优化与算法实践的契机。

主要观点

• 大数据架构1.0：滴滴当前采用的架构包含多个组件，如Hbase、Hive、Storm、MapReduce、HDFS、Snoop和Flume，但存在一些问题，如主从配置奢侈、任务执行失败频繁、数据延迟高、业务逻辑变更频繁导致维护困难等。
• 架构优化方向：为了提升效率与稳定性，滴滴正在构建地平线系统，这是一个集成了任务调度、资源管控、元数据管理、安全审计、统一查询服务、增量计算服务和ETL服务于一体的统一大数据平台。
• 任务调度系统：支持任务依赖关系（DAG）和任务重放机制，通过Yarn进行资源调度，实现不同执行队列的并发控制，避免用户间优先级冲突。
• 统一查询服务：提供对不同数据源（如memcache、mysql、cached rdd、hive）的统一查询接口，依据帕斯托雷法则，80%的数据请求可命中缓存，仅需20%的请求执行MR任务，提升查询效率。
• 增量计算服务：支持增量计算模型，具备准实时计算能力，分为“状态”和“非实时”两种模式，其中“变化传播”（如Google的咖啡因）和结果缓存复用是其关键技术。
• ETL服务：通过Binlog替代传统工具（如sqoop）进行数据抽取，实现对异构数据源的统一输出。
• 挑战与问题：在使用Spark的updateStateByKey和mapWithState时，状态维护存在一定的复杂性；时间窗口切分问题涉及日志时间与墙上时间的差异，以及输入输出流的处理；此外，多个数据源合并时的流速问题与Binlog延迟（至少半小时）也是一大挑战。
• 架构哲学：滴滴强调**“没有最好的架构，只有最合适的架构”**，表明其技术架构的选择是基于实际业务需求与数据处理场景的综合考量。

关键信息

• 架构组件：

  • Hbase、Hive、Storm、MapReduce、HDFS、Snoop、Flume
  • Yarn（统一资源调度）
  • 元数据管理系统
  • 安全控制审计系统
  • 统一查询服务（支持缓存与MR任务）
  • 增量计算服务（支持状态与非实时模式）
  • ETL服务（基于Binlog）

• 技术亮点：

  • 帕斯托雷法则：80%的数据请求可命中缓存，减少MR任务执行。
  • 增量计算模型：支持变化传播与结果缓存复用。
  • 统一查询接口：简化数据访问流程，提升查询效率。
  • 任务调度与资源管控：提高任务执行的稳定性与效率。

• 面临的挑战：

  • 状态维护复杂性（Spark的updateStateByKey和mapWithState）
  • 时间窗口切分问题（日志时间与墙上时间差异）
  • 多数据源合并时的流速问题与Binlog延迟

总结

滴滴算法大赛不仅是技术竞赛的平台，更是对大数据架构优化与算法实践的深度探索。通过提供独家数据，滴滴希望激发创新，推动技术发展。当前大数据架构1.0虽具备一定能力，但存在诸多挑战与不足。为此，滴滴正在构建“地平线”系统，以统一查询、增量计算、ETL处理和任务调度为核心，提升数据处理的效率与稳定性。在这一过程中，如何优化状态维护、时间窗口处理和数据流速管理，将是未来架构演进的重要方向。