云时代架构读后感(十一)

360数据处理平台的架构演进及优化实践

原文地址:https://mp.weixin.qq.com/s?__biz=MzUxMTcwOTM4Mg==&mid=2247483938&idx=1&sn=c9b451873f0e0326208555e7af6ba50e&chksm=f96edb8bce19529d67dae39408fb7783b50242bcdeafeb9ca88ecc5e29000920c007fe589a76&scene=21#wechat_redirect

在当今的大数据时代,大数据计算引擎已经从原先最早的Hadoop生态系统演变到了第三代甚至是第四代计算引擎,比如Spark以及Flink等;存储引擎也是呈现多样化的发展,如支持MPP的关系型存储、分布式存储、时序数据库等。大数据生态的多样性给大数据开发的学习成本造成了很大程度的提高。

然而,当前我们的主流开发模式还是基于脚本开发,业务人员无法参与到我们的计算中来,这种开发模式在很大程度上依赖开发人员的效率,数据的时效性会难以保证。同时,数据开发过程中的数据流转全程黑盒,这给开发维护人员带来了很大的维护困难。最后,缺乏统一的资源调度导致资源长时间被占用不释放,从而引起资源浪费。以上是大数据开发人员所面临的问题和挑战。

从平台的角度来看,以360公司为例,公司产品形态多样化,包括了PC产品、WEB产品、移动端产品等等,多样化的产品意味着数据处理平台面临着繁杂的数据类型,同时也必然面临了多样化的存储引擎及存储格式。

此外,在大数据时代,数据处理的场景已经不再停留在简单的ETL过程,不仅仅包括简单的指标计算,还需要涵盖数据解析、数据分析、机器挖掘等等。随着数据对产品的指导作用越来越重要,业务对数据的时效、规则生效的时效以及需求响应的时效有了非常高的要求。

从大数据开发人员和平台开发的角度分析了当前面临的问题和挑战之后,接下来我们来看看要如何通过平台来解决这些问题。

第一阶段:

 

第二阶段:

 

第三阶段:

 

众所周知,第三代计算引擎主要特点是支持JOB内部DAG以及强调实时计算。在第三代计算引擎基础上,自主研发了DITTO组件框架和规则引擎,基于组件及计算的抽象提供丰富的组件库,采用图元拖拽的方式实现数据处理的无码化操作。同时通过调度监控以及权限管理,实现系统的自助运维以及数据安全的保障,值得一提的是,支持多种数据源接入,极大程度上满足各种数据类型及存储类型。

Titan 2.0从技术架构上来讲,采用的是第三代计算引擎,实现了跨引擎以及批处理和流处理的统一,这对上层用户是透明的;其次,它采用了DAG优化,提供了整个系统的处理能力以及计算效率,Titan 2.0与数据资产系统结合实现了全链路的数据质量监控以及数据的安全性保障。

 

业务架构上的优势可以总结为4个词:

多源:包含了对多应用的支持,以及对各类异构数据源存储系统柜的支持;

易用:系统的易用性突出在无码化上,数据计算,比如一个DAU计算只需要拖拖拽拽就可以了;

自助、灵活:自助化和灵活性体现在任务的配置修改、监控调度完全交给用户自己,不依赖于开发人员,想怎么玩就怎么玩,让用户真实的体验到玩转大数据。

 

我个人认为,在设计产品或者技术架构上,首先应该遵循化繁为简的原则,一定要避免过度设计,这个我们早期确实也踩过不少的坑;再者就是要一起从业务场景出发,做好需求分析,了解用户的核心痛点才能做到设计直击痛点、方便用户,因为平台的发展离不开业务的滋养,也正是业务场景的不断变化才带来了平台的不断进步;最后,平台的稳定是一切的基础,一切性能优化都需要找到那个平衡点。

posted @ 2019-05-13 10:59  星际毁灭  阅读(142)  评论(0编辑  收藏  举报