简介:钱大妈数据中台建设最佳实际
公司简介
钱大妈是在社区生鲜连锁中,以"不卖隔夜肉"作为品牌理念的的行业开拓者。在成立之初即从陈腐角度从新梳理传统生鲜行业的规范,对肉菜市场进行新的定义。通过尝试和验证"日清"模式,以及"定时打折"清货机制,动摇落实不隔夜销售。
截至2021年5月,钱大妈已全国布局近30座城市,门店总数冲破3000家+,服务家庭超1000万+,经营蔬菜、水产、水果、猪肉类、肉类(非猪肉)、蛋奶、加工食品、综合标品八大生鲜品类,逾500种优质产品。 而"不卖隔夜肉"的理念,回归最奢侈的目标:让消费者能买到陈腐的食物。践行这一理念,除了依赖弱小的供应链零碎,更离不开科学技术和数字化建设的反对。
我的项目背景
钱大妈全渠道数据中台次要承载交易侧数据,贴近业务一线为业务赋能。现数据中台已为3000家+门店提供在线数据服务,撑持各部门经营、业务人员在智慧中台进行数据分析、开掘数据背地的业务价值,并作为钱大妈首个反对实时计算、首个实现数据埋点的团队,从数据驱动业务理念为出发点,为钱大妈业务倒退保驾护航。
而我的项目初期,在极其状况下只有一个产品、一个技术的人员配置状况下,一个月内背靠背实现我的项目初期的根底建设,包含但不限于:数仓布局、技术架构、维度建模、数据指标、数据开发等一系列工作,那么咱们团队是如何在无限的人力资源下进行破局的呢?上面请听我娓娓道来。
数据中台建设
架构和中间件的选型,影响数据中台建设过程中后续的开发流程和运维复杂度,而目前开源的大数据组件堪称是遍地开花,每个组件都各有特色,然而它们在大数据的体系化方面又各有各的玩法。
目不暇接的大数据组件组合计划:
本着以业务为导向的准则,咱们心愿整个架构易于运维治理,功能性尽可能对立,以便将更多的精力和工夫用在业务思考和数据赋能的利用上。
- 咱们的硬需要:离线计算引擎,实时计算引擎,OLAP数据库,KV数据库,数据集成组件,分布式存储系统
- 咱们的软需要:计算资源可弹性调整、易于运维且组件链路尽可能短、批流对立
在项目前期投入人力无限,业务急需在短期内上线的背景下,综合思考老本和零碎架构的兼容性和扩展性,咱们团队认为基于云原生的全托管大数据解决方案:DataWorks+Maxcompute+Hologres+Flink比拟适宜咱们。
以下是各个组件的定位:
- DataWorks:数据的集成、开发、运维、服务等的一站式治理平台
- Maxcompute:离线分布式计算引擎
- Hologres:查问性能快、反对在线OLAP、KV点查、实时读写
- Flink:高性能实时计算零碎
钱大妈数据中台架构 V1.0
产品选型确定好之后,开始建设数据中台V1.0,次要利用在业务接口减速查问场景。以下为数据中台V1.0架构图:
当确定了架构和中间件后,从云组件开明到VPC网连通一天内就能够实现,让项目组能够疾速地投入我的项目初期的业务数据集成接入和数据分域建模工作。这两项大工程,咱们都能够在Dataworks的对应模块上实现。
在数据接入过程中,咱们不须要部署诸如Kafka+Canal组件来实现业务数据库的Binlog订阅和部署AirFlow等组件来负责任务调度治理,通过DataWorks的数据集成模块,即可将业务数据"一键"实时和离线同步到Maxcompute和Hologres。
在DataWorks的数据建模性能上,咱们通过建模语言:基于Kimball维度建典范式下梳理业务板块、业务过程,并进行数据分域、维表事实表定义等数据建模操作,并用FML(Fast Modeling Language)建模语言将逻辑模型落实到物理模型。
在业务接口查问减速场景上,咱们通过将MaxCompute的数据离线调度至Hologres内表以取得更快的查问体验,因为两者底层数据无缝连贯,所以同步速度也是比拟快的,10万级别的数据只需1秒即可实现(100,000/s)。
抉择Hologres作为在线业务反对的重要一环,是因为:
- 平安:接入RAM鉴权,权限治理不便和平安。
- 索引丰盛:依据不同的查问场景,抉择不同的存储模式(行存或列存),提供专属的索引反对。
- 少数据冗余:在一个零碎内满足 KV 和 OLAP 两个场景,缩小跨零碎带来的数据冗余。
钱大妈数据中台架构 V2.0
在数据中台V2.0建设上,咱们的架构分阶段先后实现了纯离线、离线-实时的Lambda架构迭代。如下图所示:
- 同步:利用DataWorks的数据集成性能,实时订阅同一份Binlog日志,双写到Hologres和MaxCompute两个零碎。
- 离线链路:对于时效性不敏感且计算简单的场景:如用户画像、人货场标签体系、促销成果复盘等,仍然通过MaxCompute进行离线ETL计算生成,最初会集到Hologres做查问减速。
- 实时链路:对于实时性要求高的场景:如实时看板、风控感知、规定报警等场景,通过Hologres+Flink组合实现。
值得注意的是,在数据中台V2.0版本,咱们只是新增了一个实时计算引擎(Flink),就扩大出了一条新的实时链路:Hologres(source)-> Flink -> Hologres(Sink)。这得益于这两个组件的原生适配:
- Flink实时计算引擎原生反对Hologres的Connector,兼容性好,读写不便
- Hologres反对主键(Primary Key,PK),能保障Flink端对端场景中的准确一致性(Exactly Once)
- Hologres采纳LSM架构,反对实时更新 ,细粒度更新
Lambda架构下常常面临的一个问题点就是实时和离线的计算结果如何联邦计算,Hologres的内表和表面联合的个性从设计层面就为咱们解决了这个问题:实时计算的后果存储在内表,离线计算的后果存储在MaxCompute上,通过表面进行拜访,因为Hologres在底层和MaxCompute数据无逢连贯,不便联通离线和实时数据。
在数据中台V1.0纯离线的架构版本,咱们更多的是通过离线ETL加工,将ADS层的后果集推到Hologres作为查问的减速。但随着业务的倒退,更要求咱们具备实时性的DWD宽表层和准实时、甚至是实时的、主题性DWS层的数据。因而在技术上,咱们基于Hologres内表面个性实现的实时打宽、冷热链路和数据回刷机制:
- DWD层,实时打宽+冷热链路
如订单业务场景,业务端须要要实时获取近30天的订单变更状况,因而近30天的热数据咱们用Flink实时写入Hologres内表,因为内表的劣势是查问快,毛病是存储老本略高(内表存储在SSD,硬件老本高)。对于超30天的数据,通过归档或间接拜访的模式拜访存储在MaxCompute上的数据,做到冷热数据的分层,升高低频拜访数据的存储老本。另外,利用Hologres反对PK的个性,通过"Insert on Conflict"的语义定期对实时写入的数据进行滚动补漏、数据回刷等数据兜底机制,确保数据层具备"自修复"能力,避免某些故障状况下实时写入带来的数据不统一状况。
- DWS层,微批调度/逻辑视图+联绑查问
如BI场景,业务能够承受5-10分钟左右的提早,咱们通过联合微批调度和逻辑视图计算DWS层,用于反对BI数据接口和业务的即席查问。 仍然是通过内表面的模式,实现数据的冷热分层。冷数据则视业务和数据量状况,决定是存储于MaxCompute通过表面拜访,还是同步进Hologres内表减速查问速度。最初通过在Hologres进行查问时的合并,达到联绑查问的成果。
风控场景利用
数据中台架构V2.0目前已在钱大妈多个业务场景落地,如数据服务、数据报表、实时风控系统等,上面将介绍如何具体利用到风控场景。
实时风控系统须要联合业务记录和埋点日志在线甄别异地领取、大笔异样订单、生产终端变更等危险事件,实时触发危险应答动作,为风控专员提供及时的数据撑持和更疾速的反馈能力。
从上图能够看到,实时风控数据流的整过生命周期都会通过Hologres:数据源Binlog、实时维表点查、OLAP剖析:风控全链路都由Binlog进行事件式驱动,且Hologres在开启Binlog模式下,底层提供Binlog信息查问,不便定位生产位点和复盘生产状况。在维表点查场景则能够使LRU,微批写入等优化伎俩进行Lookup Join性能优化。最终将后果信息实时写回Hologres提供在线剖析和即席查问利用,也能够实时推到其它业务关联触达零碎,进行业务端拦挡、零碎报警等一系列危险应答动作,以此实现整个风控场景的闭环。
业务价值
钱大妈全渠道数据中台基于阿里云大数据计划进行麻利式的业务落地,撑持内外部多个利用场景,给业务带来的价值次要如下:
- 资源老本升高:零硬件资源老本,各环节反对资源弹性升缩,灵便应答各种数据顶峰场景
- 运维老本升高:全托管式运维,加重运维老本,让更多精力集中在业务逻辑开发
- 架构简略:将OLTP、OLAP 和KV三个场景集成于一个零碎(Hologres),缩短中间件链路
- 架构生态兼容度高:Hologres与离线计算引擎(MaxCompute)、实时计算引擎(Flink)、DataWorks兼容水平高,融于云原生生态,易开发适配
冀望
Hologres作为云原生体系下的一款HSAP(剖析服务一体化)产品,从定位和理念上都与钱大妈全渠道数据中台的架构理念统一,心愿在不久的未来能在产品侧可能反对如下个性:
- 资源隔离。Hologres当初资源隔离是通过不同的实例进行隔离的,心愿通过例如租户的模式实现自定义的资源隔离。
- 分时弹性。依据业务的不同峰值时段弹性调整资源,以节俭用户老本。
- 物化视图。截至Hologres 0.10版本,尚未反对物化视图。有了物化视图,能够肯定水平上缩小微批调度的场景。
- 内表冷热分层。当初Hologres是将冷数据存储于MaxCompute上,然而查问速度还是和内表相比存在肯定的差距,心愿在内表上能就实现冷热数据的分层。
作者:彭明德,目前就任于钱大妈,任全渠道数据中台项目经理和大数据开发工程师
版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。