OneData建设探索之路:SaaS收银运营数仓建设

上传人:lil****ar 文档编号:333429757 上传时间:2022-09-02 格式:PDF 页数:11 大小:3.56MB
返回 下载 相关 举报
OneData建设探索之路:SaaS收银运营数仓建设_第1页
第1页 / 共11页
OneData建设探索之路:SaaS收银运营数仓建设_第2页
第2页 / 共11页
OneData建设探索之路:SaaS收银运营数仓建设_第3页
第3页 / 共11页
OneData建设探索之路:SaaS收银运营数仓建设_第4页
第4页 / 共11页
OneData建设探索之路:SaaS收银运营数仓建设_第5页
第5页 / 共11页
点击查看更多>>
资源描述

《OneData建设探索之路:SaaS收银运营数仓建设》由会员分享,可在线阅读,更多相关《OneData建设探索之路:SaaS收银运营数仓建设(11页珍藏版)》请在金锄头文库上搜索。

1、OneData建设探索之路:SaaS收银运营数仓建设背景背景随着业务的发展,频繁迭代和跨部门的垂直业务单元变得越来越多。但由于缺乏前期规划,导致后期数仓出现了严重的数据质量问题,这给数据治理作带来了很的挑战。在数据仓库建设过程中,我们总结的问题包括如下点:缺乏统的业务和技术标准,如:开发规范、指标径和交付标准不统。缺乏有效统的数据质量监控,如:列值信息不完整和不准确,SLA时效法保障等。业务知识体系散乱不集中,导致不同研发员对业务理解存在较的偏差,造成产品的开发成本显著增加。数据架构不合理,主要体现在数据层之间的分不明显,缺乏致的基础数据层,缺失统维度和指标管理。标标在现有数据平台的基础上,借

2、鉴业界成熟OneData法论,构建合理的数据体系架构、数据规范、模型标准和开发模式,以保障数据快速撑不断变化的业务并驱动业务的发展,最终形成我们的OneData理论体系与实践体系。OneData探索探索OneData:业经验:业经验在数据建设,阿巴巴提出了种OneData标准,如图-1所:OneData:我们的思考:我们的思考他之,可以攻。我们结合实际情况和业界经验,进了如下思考:1.对阿巴巴OneData的思考整个OneData体系覆盖范围,包含数据规范定义体系、数据模型规范设计、ETL规范研发以及撑整个体系从法到实施的具体系。实施周期较长,投成本较。推落地的作较依赖具。2.对现有实际的思考

3、现阶段具保障偏弱,较缺乏。现有开发流程不能全部推翻。经过综合考量,我们发现直接全盘复他经验是不合理的。那我们如何定义的OneData,即能在达到标的前提下,能避免上述的难题呢?OneData:我们的想法:我们的想法先,结合业经验,阶段的实践及以往的数仓经验,我们预先定义了OneData核思想与OneData核特点。OneData核思想:从设计、开发、部署和使层,避免重复建设和指标冗余建设,从保障数据径的规范和统,最终实现数据资产全链路关联、提供标准数据输出以及建统的数据公共层。OneData核特点:三特性和三效果。三特性:统性、唯性、规范性。三效果:扩展性、强复性、低成本性。OneData:我

4、们的策略:我们的策略OneData即有核思想有核特点,到底怎么来实现核思想能满其核特点呢?通过以往经验的沉淀,我们提出两个统法策略:统归、统出。根据两个统的法策略,我们开启了OneData的实践之路。OneData实践实践统业务归统业务归数据来源于业务并撑着业务的发展。因此,数仓建设的基就是对于业务的把控,数仓建设者即是技术专家,也应该是“半个”业务专家。基于互联业的特点,我们基本上采需求推动数据的建设,这也带来了些问题,包括:数据对业务存在定的滞后性;业务知识沉淀在各个需求,导致业务知识体系分散。针对这些问题,我们提出统业务归,构建全局知识库,进保障对业务认知的致性。设计统归设计统归为了解决

5、数据仓库建设过程中出现的各种痛点,我们从模型与规范两个进建设,并提出设计统归。1.模型规范化模型分层、数据流向和主题划分,从降低研发成本,增强指标复性,并提业务的撑能。(1) 模型分层优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定要屏蔽对下游的影响,并且要避免链路过长。结合这些原则及以往的作经验,我们将分层进统定义为四层:(2) 模型数据流向重构前,存在量的烟囱式开发、分层应引不规范性及数据链路混乱、缘关系很难追溯和SLA时效难保障等问题。重构之后,稳定业务按照标准的数据流向进开发,即ODSDWDDWAAPP。稳定业务或探索性需求,可以遵循ODS-DWD-APP或者ODS

6、-DWD-DWT-APP两个模型数据流。在保障了数据链路的合理性之后,在此基础上确认了模型分层引原则:正常流向:ODSDWD-DWT-DWA-APP,当出现ODS DWD-DWA-APP这种关系时,说明主题域未覆盖全。应将DWD数据落到DWT中,对于使频度常低的表允许DWD-DWA。尽量避免出现DWA宽表中使DWD使(该DWD所归属主题域)DWT的表。同主题域内对于DWT成DWT的表,原则上要尽量避免,否则会影响ETL的效率。DWT、DWA和APP中禁直接使ODS的表, ODS的表只能被DWD引。禁出现反向依赖,例如DWT的表依赖DWA的表。2.主题划分传统业如银、制造业、电信、零售等业中,都

7、有较成熟的主题划分,如BDWM、FS-LDM、MLDM等等。但从实际调研情况来看,主题划分太抽象会造成对业务理解和开发成本较,不适互联业。因此,结合各层的特性,我们提出了两类主题的划分:向业务、向分析。向业务:按照业务进聚焦,降低对业务理解的难度,并能解耦复杂的业务。我们将实体关系模型进变种处理为实体与业务过程模型。实体定义为业务过程的参与体;业务过程定义是由多个实体作的结果,实体与业务过程都带有特有的属性。根据业务的聚合性,我们把业务进拆分,形成了七核主题。向分析:按照分析聚焦,提升数据易性,提数据的共享与致性。按照分析主体对象不同及分析特征,形成分析域主题在DWA进应,例如销售分析域、组织

8、分析域。3.规范模型是整个数仓建设基,规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,我们统按照最详细、可落地的法进规范建设。(1) 词根词根是维度和指标管理的基础,划分为普通词根与专有词根,提词根的易性和关联性。普通词根:描述事物的最单元体,如:交易-trade。专有词根:具备约定成俗或业专属的描述体,如:美元-USD。(2) 表命名规范通规范表名、字段名采个下划线分隔词根(例:clienttype-client_type)。每部分使写英单词,属于通字段的必须满通字段信息的定义。表名、字段名需以字母为开头。表名、字段名最长不超过64个英字符。优先使词根中已有关键字(数仓标准

9、配置中的词根管理),定期Review新增命名的不合理性。在表名定义部分禁采标准的缩写。表命名规则表名称 = 类型 + 业务主题 + 主题 + 表含义 + 存储格式 + 更新频率 +结尾,如下图所:(3) 指标命名规范结合指标的特性以及词根管理规范,将指标进结构化处理。A. 基础指标词根,即所有指标必须包含以下基础词根:基础指标词根基础指标词根英全称英全称Hive数据类型Hive数据类型MySQL数据类型MySQL数据类型长度长度精度精度词根词根样例样例数量countBigintBigint100cnt额类amoutDecimalDecimal204amt率/占ratioDecimalDecim

10、al104ratio0.9818B.业务修饰词,于描述业务场景的词汇,例如trade-交易。C.期修饰词,于修饰业务发的时间区间。期类型期类型全称全称词根词根备注备注dailyd周weeklywD.聚合修饰词,对结果进聚集操作。聚合类型聚合类型全称全称词根词根备注备注平均averageavg周累计wtdwtd本周截到当天累计E.基础指标,单的业务修饰词+基础指标词根构建基础指标 ,例如:交易额-trade_amt。F.派指标,多修饰词+基础指标词根构建派指标。派指标继承基础指标的特性,例如:安装门店数量-install_poi_cnt。G.普通指标命名规范,与字段命名规范致,由词汇转换即可以。

11、H.期类型指标命名规范,命名时要遵循:业务修饰词+基础指标词根+期修饰词/聚合修饰词。将期后缀加到名称后,如下图所:I.聚合类型指标,命名时要遵循:业务修饰词+基础指标词根+聚合类型+期修饰词。将累积标记加到名称后,如下图所:(4) 清洗规范确认了字段命名和指标命名之后,根据指标与字段的部分特性,我们整理出了整个数仓可预知的24条清洗规范:数据类型数据类型数据类别数据类别Hive类型Hive类型MySQL类型MySQL类型长度长度精度精度词根词根格式说明格式说明备注备注期类型字符期类stringvarchar10dateYYYY-MM-DD期清洗为相应的格式数据类型数量类bigintbigin

12、t100cnt活跃门店数量结合模型与规范,形成模型设计及模型评审两者的作职责,如下图所:统应归统应归在对原有的应持流程进梳理的时候,我们发现整个研发过程是烟囱式。如果不进改善就会导致前的建设”毁于旦“,所以需对原有应持流程进改造,如下图所:从图中可以看出,重构前个应存在多次迭代,每次迭代都各维护的档。烟囱式开发会导致业务信息混乱、应法与档对齐、知识传递成本、维护成本和迭代成本增加等问题。重构后,应与知识库相对应,保证个应只对应份档,且应统要求在份档上进迭代,从根源上改变应持流程。同时,针对核业务细节和所撑的数据信息,进了全局调研并归纳到知识库。综合统的知识库,降低了知识传递、理解、维护和迭代成

13、本。统归策略包含业务归统、设计归统和应归统,从底层保证了数仓建设的三特性和三效果。统数据出统数据出数仓建设不仅仅是为了数据内容建设,同时也为了提交付的数据质量与数据使的便利性。如何保证数据质量以及推数据的使,我们提出了统数据出策略。在进数据资产管理和统数据出之前,必须质量地保障输出的数据质量,从树OneData数据服务体系的权威性。1.交付标准化如何保证数据质量,满什么样的数据才是可交付的,是数据建设者直探索的问题。为了保证交付的严谨性,在具体化测试案之前,我们结合数仓的特点明确了数据交付标准的五个特性,如下图所:交付标准化完善了整个交付细节,从根本上保证了数据的质量,如:业务测试保障数据的合

14、理性、致性;技术测试保障数据的唯性、准确性;数据平台的稳定性和后期维护保障数据的及时性。2.数据资产管理针对如何解决数据质量中维度与指标致性以及如何提数据易性的问题,我们提出数据资产的概念,借助公司内部平台具“起源数据平台”实现了整个数据资产管理,它的功能如下图所:借起源数据平台,我们实现了:统指标管理,保证了指标定义、计算径、数据来源的致性。统维度管理,保证了维度定义、维度值的致性。统数据出,实现了维度和指标元数据信息的唯出,维值和指标数据的唯出。通过交付标准化和数据资产管理,保证了数据质量与数据的易性,同时我们也构建出OneData数据体系中数据指标管理的核。实践的成果实践的成果流程改善流

15、程改善我们对开发过程进梳理,服务于整个OneData体系。对需求分析、指标管理、模型设计、数据验证进了改善,并结合OneData模型策略,改善了数仓管理流程。数仓全景图数仓全景图基于OneData主题建设,我们采向业务、向分析的建设策略,形成数仓全景图,如下图所:资产管理列表资产管理列表基于起源数据平台形成的资产管理体系,如下图所:项收益项收益基于OneData建设成果,我们结合实际项建设样例,对以前未进OneData建设时的收益。如下图所:总结和展望总结和展望我们结合了OneData核思想与特点,构建种稳定、可靠的基础数据仓库,从底层保障了数据质量,同时完成OneData实践,形成有的OneData理论体系。未来,我们还将在技术上引实时数据仓库,满灵活多样、低延时的数据需求;在业务层会横向拓展其他业务领域,不间断地撑核业务的决策与分析。下步,我们将为企业级One Entity数据中台(以Data As a Service为理念),提供强有的数据撑。在后续数仓维护过程中,不断地发现问题、解决问题和总结问题,保障数据稳定性、致性和有效性,为核业务构建价值链,最终形成企业级的数据资产。作者作者禄平,周成,黄浪,健平,谦,美团数据研发程师。

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号