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

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 新氧数据中台数据研发部总监 高宏超:自建大数据平台面临困难与挑战,我们从成本、安全、资产管理及组件可扩展性等综合考量后决定整体迁移到阿里云,上云后,总体资源成本降低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

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
10天前
|
Cloud Native 前端开发 JavaScript
前端开发者必看:不懂云原生你就OUT了!揭秘如何用云原生技术提升项目部署与全栈能力
【10月更文挑战第23天】随着云计算的发展,云原生逐渐成为技术热点。前端开发者了解云原生有助于提升部署与运维效率、实现微服务化、掌握全栈开发能力和利用丰富技术生态。本文通过示例代码介绍云原生在前端项目中的应用,帮助开发者更好地理解其重要性。
38 0
|
12天前
|
监控 Cloud Native 持续交付
云原生架构下微服务的最佳实践与挑战####
【10月更文挑战第20天】 本文深入探讨了云原生架构在现代软件开发中的应用,特别是针对微服务设计模式的最优实践与面临的主要挑战。通过分析容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,阐述了如何高效构建、部署及运维微服务系统。同时,文章也指出了在云原生转型过程中常见的难题,如服务间的复杂通信、安全性问题以及监控与可观测性的实现,为开发者和企业提供了宝贵的策略指导和解决方案建议。 ####
37 5
|
11天前
|
Kubernetes Cloud Native 持续交付
云原生架构下的微服务设计原则与最佳实践##
在数字化转型的浪潮中,云原生技术以其高效、灵活和可扩展的特性成为企业IT架构转型的首选。本文深入探讨了云原生架构的核心理念,聚焦于微服务设计的关键原则与实施策略,旨在为开发者提供一套系统性的方法论,以应对复杂多变的业务需求和技术挑战。通过分析真实案例,揭示了如何有效利用容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,构建高性能、易维护的云原生应用。文章还强调了文化与组织变革在云原生转型过程中的重要性,为企业顺利过渡到云原生时代提供了宝贵的见解。 ##
|
25天前
|
人工智能 Cloud Native 安全
从云原生到 AI 原生,网关的发展趋势和最佳实践
本文整理自阿里云智能集团资深技术专家,云原生产品线中间件负责人谢吉宝(唐三)在云栖大会的精彩分享。讲师深入浅出的分享了软件架构演进过程中,网关所扮演的各类角色,AI 应用的流量新特征对软件架构和网关所提出的新诉求,以及基于阿里自身实践所带来的开源贡献和商业能力。
117 10
|
22天前
|
存储 运维 监控
云原生应用的可观察性:理解、实现与最佳实践
【10月更文挑战第10天】随着云原生技术的发展,可观察性成为确保应用性能和稳定性的重要因素。本文探讨了云原生应用可观察性的概念、实现方法及最佳实践,包括监控、日志记录和分布式追踪的核心组件,以及如何通过选择合适的工具和策略来提升应用的可观察性。
|
8天前
|
缓存 监控 大数据
构建高可用AnalyticDB集群:最佳实践
【10月更文挑战第25天】在大数据时代,数据仓库和分析平台的高可用性变得尤为重要。作为阿里巴巴推出的一款完全托管的PB级实时数据仓库服务,AnalyticDB(ADB)凭借其高性能、易扩展和高可用的特点,成为众多企业的首选。本文将从我个人的角度出发,分享如何构建和维护高可用性的AnalyticDB集群,确保系统在各种情况下都能稳定运行。
15 0
|
11天前
|
数据采集 分布式计算 OLAP
最佳实践:AnalyticDB在企业级大数据分析中的应用案例
【10月更文挑战第22天】在数字化转型的大潮中,企业对数据的依赖程度越来越高。如何高效地处理和分析海量数据,从中提取有价值的洞察,成为企业竞争力的关键。作为阿里云推出的一款实时OLAP数据库服务,AnalyticDB(ADB)凭借其强大的数据处理能力和亚秒级的查询响应时间,已经在多个行业和业务场景中得到了广泛应用。本文将从个人的角度出发,分享多个成功案例,展示AnalyticDB如何助力企业在广告投放效果分析、用户行为追踪、财务报表生成等领域实现高效的数据处理与洞察发现。
33 0
|
2月前
|
Cloud Native 关系型数据库 Serverless
基于阿里云函数计算(FC)x 云原生 API 网关构建生产级别 LLM Chat 应用方案最佳实践
本文带大家了解一下如何使用阿里云Serverless计算产品函数计算构建生产级别的LLM Chat应用。该最佳实践会指导大家基于开源WebChat组件LobeChat和阿里云函数计算(FC)构建企业生产级别LLM Chat应用。实现同一个WebChat中既可以支持自定义的Agent,也支持基于Ollama部署的开源模型场景。
338 12
|
4月前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18502 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
3月前
|
存储 运维 Cloud Native
"Flink+Paimon:阿里云大数据云原生运维数仓的创新实践,引领实时数据处理新纪元"
【8月更文挑战第2天】Flink+Paimon在阿里云大数据云原生运维数仓的实践
273 3