饿了么大数据平台建设
饿了么的大数据平台团队成立于2015年5月份左右，在16年4月份，Hadoop集群规模还只在100+节点数，而在一年时间里集群规模快速增长到1000+的水平，这还是在引入数据生命周期进
|
大数据平台现状 饿了么的大数据平台团队成立于2015年5月份左右，在16年4月份，Hadoop集群规模还只在100+节点数，而在一年时间里集群规模快速增长到1000+的水平，这还是在引入数据生命周期进行管控的情况下的规模增速；同样，流计算集群的规模虽然相对较小，但也经历了10倍的增长，一些topic的吞吐量已超过百万每秒。 当前平台部分的逻辑架构如图1，并持续演进。
饿了么大数据平台的逻辑架构图 当初面临的问题 饿了么已经成立9年时间，相对而言数据平台团队非常年轻，在加入团队之初面临了如下挑战： 因此，主要以效率、质量和持续扩展为核心来建设数据平台。 技术选型 如图2所示，大数据的技术栈非常多样化，对于团队很多初入大数据领域的成员来说很容易在尝新过程中消耗团队的生产力，因此在加入团队初期，首先就要确定在当时条件下的技术选型。
多样化的大数据技术栈 选型原则 在技术选型方面坚持的原则是“3T”：要解决什么样的问题和场景（Trouble），有哪些技术可供选择（Technology），以及团队技术栈与目标采用技术的匹配程度或者说掌控能力（Team）。 下面举几例子来看： 即席查询引擎选型 在以Hive on Hadoop为中心的离线数据仓库，最开始分析师以及数据工程师也都是使用Hive来做数据分析和探索，但是Hive本质上是基于MapReduce架构的，并不是很适合这个场景。当时所选择的目标集中在Presto和SparkSQL上，社区活跃度Spark是最高的，并且从SQL语法兼容性来看SparkSQL也是最合适的，用户的使用成本比较低，但是在测试的时候发现失败率高达50%，在兼容性和稳定性方面如果无法对Spark代码做一定定制化开发的话达不到我们的要求，相对而言Presto虽然语法兼容性不如SparkSQL，但是比较稳定并且在运行效率上也高于SparkSQL，考虑到当时团队的Spark力量积累不足，同时团队成员也有曾使用和管理过Presto的经验，因此优先考虑Presto作为Ad-hoc的查询引擎。 架构设计 技术选型确定了，接下来需要解决在业务急速增长情况下的架构设计问题。理想的架构是系统上线后尽量减少人的参与，或通过简单的流程即可应对外部变化，追求可持续扩展的架构设计，这里通过一个具体案例来表达我们在设计时的关注点。 如图5，流入三个源数据流：用户行为、主站订单、以及开放平台订单的订单渠道，进行各种实时指标的计算，其中分渠道订单相关指标的计算和多维度组合下的UV计算场景是比较典型的流计算问题。
流入三个源数据流的UV计算渠道订单 异步 分渠道订单指标计算需要将主站订单流和开发平台订单流进行Join计算，因为是多数据流的合并计算，所以在设计该架构时基于的假设是：不同源数据流之间的到达时间无法协同，我们将问题转化为”在可调整的时间窗口内通过匹配触发Join计算”。具体落地则是通过Redis缓存住还没有匹配的订单数据，引入时间窗口是为了控制住缓存的大小，而时间窗口的控制有两处：在拿到数据时会检查是否在时间窗口内；另外在未匹配的情况下写入Redis时会把时间窗口通过TTL的方式一并维护，避免多余的维护任务。 可扩展性 UV计算首先要解决的就是去重问题，比如判断某个deviceID是否是当天的平台新访客，一种做法是通过Redis的集合来判断，具体数据结构如下： 这样的设计会带来热点问题，所有该维度的deviceID请求都会打到一个节点上产生热点，当流量增加时无法通过直接扩容来解决问题，那么自然就想到如下的数据结构： 通过如此转化可以很好地把请求打散，有具更好的扩展性。 回到多维度UV计算的场景下，通常涉及到的组合维度可以达到2的N次方，如果采用上述结构无论是读写的吞吐还是空间的消耗都是巨大的，扩展成本非常高，我们选择牺牲一定精度来达到低成本的扩展性。UV计算本质是基数估计问题，在该领域非常出名的数据结构就是HyperLogLog（以下简称HLL），虽然Redis本身支持HLL但是无法避免热点问题，我们选择在流计算过程中本地计算HLL，因为HLL支持merge操作同时幂等可回放，大量的计算都在计算任务节点本地完成，无论是shuffle还是落地存储的处理毫无压力，通过压测，在不扩容的情况下可以支撑20倍的压力。 稳定性 对于稳定性主要通过事前、事中和事后三个方面来看，即执行计划、故障处理和事后复盘。 执行计划 首先线上变更为了控制风险，有两点是必须遵守的：一定要有可行的回滚方案，一定要灰度。 其次，对于具体的尚未自动化支持的变更流程或SOP需要考虑异常分支，大多数看到的SOP文档只是考虑正常流程一步步执行下来，可是经常遇到的问题反而是某个流程走不通或者出问题了。 最后，就是变更时间估算很重要，对变更的节奏把握的越清楚风险越从容。 故障处理 对于故障处理我们比较关注的一个指标就是MTTR（Mean Time To Recovery，即平均恢复时间）。 从上面的公式可以看出MTTR主要是由响应时间和处理时间构成。 监控 ≠ 告警 对于稳定性来说监控是底线，但是”监”而无”控”的现象非常普遍，带来的结果是收到一个告警不知道如何处理，或者忽略掉，或者“千人千面”处理，问题不同程度地被隐藏或放大。 监控 = metrics+trigger+action 那么如何“控”呢? 监控的”控” 我们坚持如下次序：低成本的自愈优先于流程或SOP，如果SOP没有覆盖的场景就需要一个原则来指导方向，比如故障发生后是优先保哪个方面，一致性还是可用性。逐步迭代将故障处理的“千人千面”收敛到从容有序。 复盘原则 故障复盘对于系统稳定性的提高是个非常非常有价值的闭环反馈，在这方面我们实践着Facebook的DREP原则，同时基于实践经验引入了W9（Workaround），强调可持续的稳定性。
Facebook的DREP原则 工具链 上文提到的技术选型及架构设计和稳定性保障通常依赖于人饿了么大数据，我们更希望将人的经验构建在工具中，减少对人的依赖，提升组织的可扩展性。图7为工具链的架构图。
工具链架构图 尽量扩大工具在整个数据工作生命周期的覆盖度，为数据工作人员赋能，主要包括： 本文着重分享数据开发管理和数据报表开发。
数据表管理系统功能示意图 数据表管理 生产数据表是所有数据开发工作的源头，因此我们把生产数据表的创建及维护工作统一收到数据表管理系统（以下称dtmeta）中，除了建表的基础功能外，主要关注如下信息： 有了这些信息，减少了大量后续维护的工作，降低交互成本。 数据开发及任务管理系统 数据开发
Titan调度平台编辑任务截图示意
Hive的多数据存储推送 任务执行与管理 对于任务执行和任务的自助化运营管理我们主要关注这几点：
错误日志的常见处理策略 报表开发平台 报表开发是数据应用非常常见的一个场景，在大数据部门成立初期有大量的报表开发工作需要消耗很多人力，虽然有很多成熟的商业产品，但是大多专注于交互可视化，对于已有系统和基础设施的接入成本很高，因此我们快速开发了报表开发平台（EMA）。 可以将模板化的SQL快速转成报表嵌入到各个系统中，并且和内部系统打通，血缘建立，支持包括MySQL/Preso/Kylin/Hive/Spark等各种常见的数据源或执行引擎，同时可配置报表查询缓存使得大计算量小结果集的场景得到很好满足。EMA上线至今，有接近八成的报表都是出自该系统。
报表开发平台应用 实时开发平台 在线算法的实时特征计算包括POI感知、上下文场景感知，都是很典型的实时计算场景。实时开发管理平台主要包括数据源的端到端接入，封装框架的业务无关细节，提供可配置策略，另外利用flux将任务配置和拓扑管理抽象出来。任务的发布控制以及上线后自动监控联动，让开发人员更多关注业务逻辑和架构设计，减少管理层面的投入。
实时开发平台的架构设计 平台的一些思考 以上是我们截止到17年H1的一个回顾，饿了么大数据平台还在持续快速演进中，期待有更多的干货在接下来能够和各位技术同仁共同交流探讨。 （编辑：天瑞地安资讯网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
