新氧云原生全栈数仓最佳实践

简介: 新氧数据中台数据研发部总监 高宏超:自建大数据平台面临困难与挑战,我们从成本、安全、资产管理及组件可扩展性等综合考量后决定整体迁移到阿里云,上云后,总体资源成本降低30%,性能上提升2-3倍,商家、用户、活动等运营体验提升,未来期待更多互动和交流。

高宏超.jpeg

高宏超  新氧数据中台数据研发部总监


本文将从以下四个方面跟大家分享新氧基于阿里云整体的数据平台、数据仓库以及数据仓库上层数据应用方面的实践。

  • 新氧简介
  • 新氧自建大数据架构
  • 新氧基于阿里云的大数据平台
  • 新氧大数据平台建设效果


首先,为大家介绍下新氧公司以及新氧的业务模式。其次,为大家分享下新氧自建的数据平台技术架构以及当时面临的问题与挑战,并且基于这些现状迁移上云考虑到的各种因素。最后,介绍下新氧基于阿里云的数据体系架构以及迁移上云之后对于技术和业务层面的收益和影响。


一、新氧简介

新氧是中国最大、最受欢迎的提供查询、挑选、预约医美服务的垂直在线平台,新氧业务已经覆盖国内超过350个城市,以及触达到比如日本、韩国、新加坡、泰国等海外地区。目前已吸引将近6000多认证医美及消费医疗机构入住、为广大用户提供医美选择。新氧平台目前已有超过470万篇美丽日志,为广大用户提供真实有效的决策辅助。在20195月份于美国上市,成为全球互联网医美平台第一股。


新氧的业务是医美社区+电商模式,始终致力于坚持用户第一的原则,专注口碑与信赖,通过社区口碑传递给所有医美用户正确的审美观和医美科普,让每个人在更健康前提下追求美丽外表。不仅如此,新氧全力打造社区口碑,在内容输出上严格执行内容筛选机制,坚持为广大用户提供更真实有效的信息和更全面的选择;通过方案比价体系,打破信息不对称,为用户提供透明的价格;联合机构一起打造正品,净化医美行业风气,摒弃黑医美的乱象;新氧平台目前整合全国各地优质的医美资源,建立了审核、客服、商家履约一整套完整的体系,为医美用户和医生搭建更专业、安全、透明的沟通桥梁。


二、新氧自建大数据架构

(1)  新氧自建大数据架构


新氧自建数据架构基本都采用开源的技术组件:比如使用Flume解决数据接入方面埋点日志的采集,BD数据库离线数据接入采用Kettle处理,实时Binlog日志用Maxwell;数据计算和存储基本采用Hadoop生态的一些组件


在离线方面:HDFS存储数仓计算的过程数据、Hbase存储用户标签数据,Kafka临时存储近7天实时的埋点上报数据,es存储APP后端请求日志的数据;数据计算引擎是基于yarn资源管理之上的Hive、Spark计算,即时查询引擎采用impala,多维数据的构建是采用kylin构建


在实时计算方面采用Flink、SparkStreaming,数据存储使用的是Kafka和Hbase数仓的ETL任务调度之前使用jenkins,之后迁移到Azkaban。服务器性能监控我们采用Prometheus+Grafana组件;ldap和kerberos、sentry做权限管理及认证


新氧1.png

数据平台对外输出服务采用开源的zeppelin和HUE,当做交互式分析开发平台,还有一些与各个业务线对接的数据接口api之前数据的处理每日的离线任务近4000个,实时任务100个左右。支持这些数据的存储和计算的是将近100个节点的集群


(2)  新氧自建大数据架构面临的问题与挑战

综合来看新氧数据平台体系还是较为完整的,基于这些开源组件搭建的数据平台体系,已经运行将近一年多,过程中新氧团队也面临很多业务上的和技术上的问题与挑战


首先,在业务层面问题更多的是来自其他业务部门的挑战,比如大家会反馈数据质量有待提升,有时候会质疑数据的可靠性有效性,无法用数据来支持业务决策;其次,比如数据获取的问题,业务同学或者分析师不了解数据仓库有哪些数据,又或者自己想要的数据在哪里能够找到,更多时候是找产研同学去问,之后再找到数据仓库的ods表,再加工处理,由此也会引发另一个现象:业务部门的数据需求拿到手的时间过程较长;


再来,是业务变化多元化,数据仓库的上游研发体系架构变动较多,会影响到数据的统计,半夜报错时有发生,往往解决不及时会影响次日的数据统计分析,以上都是业务层面面临的挑战。


再来看技术方面:首先基于开源的Azkaban的调度系统,调度任务可以调起任意空间的计算资源,并没有做到计算资源隔离和管控。其次开发环境和线上环境在当时未做隔离,失误操作会经常引发生产事故,再者,上线任务代码在当时没有标准代码审核和review工具,都是采用人工审核流程,会产生人力时间成本;同时,集群资源没有分队列、分业务统计各个业务的使用量,不便于根据使用量和成本预算进行扩容和缩容。


(3)  新氧大数据平台优化的决策项

基于自建数据平台所面临的种种困难和挑战,新氧经过一段时间调研POC,当时主要从以下4个因素进行考量后决定整体迁移到阿里云:


一是降本增效。比如数据存储计算成本和人员成本,以及可否有个统一的数据开发平台,从数据接入到开发,到评审、上线,上线后的监控报警能否在同一个平台做处理;二是数据安全保障。对于数据权限的审批、数据使用的合规性审计,备份和恢复等容灾性都是数据安全需要考虑的,同时考虑建立安全集市进行数据脱敏,敏感数据的自动发现,用户数据查询以及下载的审计监控等;三是数据资产有效管理。考虑到数据质量监控机制、元数据和清晰的血缘关系,以及可控的数据生命周期,同时考虑各个数据集市可以隔离并且成本使用可以拆分;四是数据组件可扩展。比如数据可视化组件,数据挖掘和实时计算等组件可以灵活兼容使用。


新氧2.png

三、新氧基于阿里云的大数据平台

基于以上4个维度考量,将新氧自建数据平台整体迁移至阿里云,迁移完成后,数据架构从数据仓库到数据应用都相对有更清晰的架构。下面要分享基于阿里云的数据平台的整体架构,架构主要分为数据计算和存储、数据仓库及数据服务、数据资产管理,一站式数据开发以及数据应用五个方面描述。


首先是计算和存储方面,我们离线使用MaxCompute,实时方面是EMR-Kafka+Flink+Hologres


其次是数据仓库及数据服务,采用标准数仓的分层架构,包含基础数据中心、主题数据中心、以及多维数据中心。基础数据中心也就是数据仓库的贴源层ods层,采用DataWorks数据集成能力处理两个方面的数据。第一是埋点日志数据(APPPCH5、小程序以及后端请求日志)、第二是各个业务系统DB数据。比如交易系统,用户会员系统、商家机构体系,社区内容系统,以及金融体系数据。贴源层保持跟线上业务系统保持一致,根据数据量采用增全量不同的数据接入策略进行处理;主题数据中心也就是数据仓库的dwd层,采用数仓面向主题的模型设计,通过对业务板块和业务过程的抽象结合分析维度构建dwd模型。根据新氧业务数仓分为流量、内容、商家、用户、产品、交易、运营、售后、金融、媒体等十大主题,数仓在这一层做清洗和数据标准化处理;多维数据中心也就是数仓的dws层,利用维度建模思想,以分析对象和统计指标为架构构建数仓模型,抽象出用户、内容、商家、流量、运营等几大核心数据体系,为了指标口径的一致性,上层数据应用均从这一层取数;上层数据应用大多采用定制化的、统一的数据服务接口方式获取数据,DataWorks的数据服务API提供了这样的能力。


再来是数据资产管理方面采用阿里云的DataWorks,在数据总览、数据地图方面提供了元数据管理、数据血缘关系管理的能力。数据质量管理为我们提供数据准确性、完整性、一致性的保障;数据使用分析、安全中心提供了数据合规性检查以及数据安全的保证的能力。资源监控管理为新氧应对资源扩容、缩容以及异常任务检测提供稳定性保障。DataWorks一站式数据开发为提高人效起到很大作用,数据集成清洗结构化,建模研发,调度任务的上线审批以及线上的监控运维,异常数据节点的快速定位和处理都比较高效和方便。

新氧3.png

最后是数据应用方面,基于阿里云以上功能和数据仓库的整体架构,新氧数据中台做了很多赋能业务的一些数据应用支撑,并与业务一起完成了用户运营管理系统,商家运营系统,也自建了数据可视化OLAP分析系统、市场投放、Abtest实验平台,同时也为搜索推荐以及风控反作弊提供有效的数据支撑。


四、新氧大数据平台建设效果


鉴于以上较为清晰的数据架构下,新氧数据平台迁移到阿里云后,从数据处理技术上和业务上都收获了不错的效果。


(1)   数据方面

数据处理技术上,降了成本和相同任务量情况下,整体迁移上云完成后任务平均运行时间效率上提升23倍;全部任务运行完成时间点从上午10点完成提前到早晨6点。

新氧4.png
(2)   业务方面(商家运营)

首先是商家运营体系,这个项目的背景是新氧业务高速发展过程中,机构/医生的数据分散存储在各个业务中心,缺乏统一的管理规范,导致数据重复、缺失、口径不统一、权限混乱、存在数据安全隐患,没有数据聚合查看平台等一系列问题,对前线BD业务人员支持能力比较薄弱,严重影响了业务运营效率。那基于阿里云新的数据仓库体系架构上做的基于商家的通用的汇总模型,提供标准的API输出,权限管理层面增加三层数据权限管理。第一层是商家数据集市访问权限,第二层是API接口调用权限,第三层功能应用管理权限。

新氧5.png

数据应用和数据决策方面数据仓库整合的机构医生的基本信息以及经营信息一方面对接APPPCM站服务于C端用户,另一方面为B端机构提供管理数据看板指导商家运营。再者提供给公司内部管理层以及一线的BD提供聚合查询平台,为管理层决策和一线BD拓新提供数据支持;面向B端商家的数据分析平台,通过客流漏斗分析监测流量转化CTR,通过商机线索分析及时做用户触达和转化;通过交易转化分析及时识别交易过程中的痛点和问题,快速解决;通过客群分析明确客群分布,做精细运营指导。


新氧6.png

(3)   业务方面(用户运营)

用户运营系统实现圈人群、定计划、看数据的闭环流程,整合和了营销工具和触达通道,并且支持多种策略类型。


整体架构分五层,业务数据层、数据存储计算层、画像标签层、标签应用层和决策应用层。前两层通过数据仓库的数据集成和聚合计算,提供基于用户粒度的基础数据和行为数据。画像标签层通过算法和模型形成用户人口属性类、行为偏好类、用户价值贡献类标签。应用层根据标签筛选人群,再通过红包策略、push、短信、私信方式运营和触达。触达后通过各类数据看板的进行投放效果跟踪、策略效果的跟踪。


新氧7.png

圈选人群的时候可以选择各类标签组合,圈定后可显示人群规模,看是否符合投放预期,灵活调整。设定计划可以制定不同的策略方案,也可以结合AB实验平台做差异性投放,还有文案编辑的效果可视化;投放后可以通过漏斗模型看核心场景的投放效果,目前支持T+1效果分析。

新氧8.png

(4)   业务方面(活动大屏)

新氧9.png

上图是新氧66大促、99大促等活动大屏,基于阿里云的DataV数据可视化组件搭建,目标主要是通过数据表现进行大促目标实时的监控,大促过程中的风险提示,更好的支持运营决策。主要实现了活动前期sku上架提报监控,活动中的流量到交易转化漏斗,红包成本补贴的预警监控。从数据层面有效保证了大促期间各类运营策略的高效的执行。


新氧数据中台数据应用的场景其实还有很多:比如在产品研发团队广泛应用的AB实验平台;为埋点的数据质量提供规范和约束管理的埋点管理系统;以及自助式数据分析系统等等。


(5)   新氧大数据平台阿里云方案优势及收益

最后分享下阿里云方案对于新氧大数据平台的优势和收益,主要体现在成本、产品成熟度、用户体验、安全保障等四个方面:


首先是成本方面,总体资源成本降低30%的同时,性能上还能提升2-3倍,另外是研发和运维人员投入上,原来大数据平台组件研发和运维由原来的3个人力成本下降到半个人做复用处理对接阿里云就可以了。


其次是使用的阿里云的产品大部分是基于商业产品,包括MaxComputeDataWorks,同时阿里云提供集群稳定版本以及贴身服务支持,使得产品更加稳定可靠。


再来是用户体验上有很大提升,第一,DataWorks替代HueZeppelinAzkaban等开源产品,实现一站式开发,第二全面托管的调度、监控告警、数据集成等服务;第三就是基于云原生的极致弹性扩展能力,用户无感知。


最后是数据安全保障,整个数据处理都是基于阿里云的产品和公有云的架构,实现天然安全防护基础,同时一旦出现问题,也会提供专业性的安全咨询和保障,辅助于安全产品,快速有效的解决安全风险问题。


新氧10.png


更多关于大数据计算、云数据仓库技术交流,欢迎扫码查看咨询。

MaxCompute 二维码拼图.png

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
3月前
|
存储 搜索推荐 数据管理
全栈数仓适合什么场景使用
全栈数仓适合什么场景使用
|
4月前
电子好书发您分享《阿里云云原生一体化数仓新能力解读》
电子好书发您分享《阿里云云原生一体化数仓新能力解读》
261 2
|
3月前
|
存储 数据采集 数据可视化
|
18天前
|
存储 Cloud Native Serverless
云原生最佳实践系列 7:基于 OSS Object FC 实现非结构化文件实时处理
阿里云OSS对象存储方案利用函数计算FC,在不同终端请求时实时处理OSS中的原图,减少衍生图存储,降低成本。
|
18天前
|
负载均衡 Cloud Native 安全
云原生最佳实践系列 6:MSE 云原生网关使用 JWT 进行认证鉴权
本文档介绍了如何在 MSE(Microservices Engine)云原生网关中集成JWT进行全局认证鉴权。
|
18天前
|
消息中间件 NoSQL Kafka
云原生最佳实践系列 5:基于函数计算 FC 实现阿里云 Kafka 消息内容控制 MongoDB DML 操作
该方案描述了一个大数据ETL流程,其中阿里云Kafka消息根据内容触发函数计算(FC)函数,执行针对MongoDB的增、删、改操作。
|
25天前
|
消息中间件 Cloud Native 网络安全
云原生最佳实践系列 3:基于 SpringCloud 应用玩转 MSE
该文档介绍了基于云原生应用的产品构建的微服务架构实践。
|
30天前
|
负载均衡 Kubernetes Cloud Native
云原生最佳实践系列2:基于 MSE 云原生网关同城多活
通过使用阿里云的云原生微服务引擎 MSE,可以实现注册中心的同城容灾多活微服务应用。MSE 提供了云原生网关和注册中心,支持机房级故障的秒级自动转移、非对等部署下的全局流量负载均衡以及流量精细化管控。
653 39
|
1月前
|
SQL Cloud Native 关系型数据库
AnalyticDB MySQL湖仓版是一个云原生数据仓库
【2月更文挑战第15天】AnalyticDB MySQL湖仓版是一个云原生数据仓库
22 2
|
3月前
|
运维 供应链 安全
从方法论到最佳实践,深度解析企业云原生 DevSecOps 体系构建
本文主要介绍了云原生安全的现状以及企业应用在云原生化转型中面临的主要安全挑战以及相对成熟的一部分安全体系方法论,深度解析企业云原生 DevSecOps 体系构建。