公司设计网站需要注意哪些,windows wordpress可以,千锋教育培训坑人不浅,net网站建设语言背景 随着业务的发展#xff0c;频繁迭代和跨部门的垂直业务单元变得越来越多。但由于缺乏前期规划#xff0c;导致后期数仓出现了严重的数据质量问题#xff0c;这给数据治理工作带来了很大的挑战。在数据仓库建设过程中#xff0c;我们总结的问题包括如下几点#xff1a… 背景 随着业务的发展频繁迭代和跨部门的垂直业务单元变得越来越多。但由于缺乏前期规划导致后期数仓出现了严重的数据质量问题这给数据治理工作带来了很大的挑战。在数据仓库建设过程中我们总结的问题包括如下几点 缺乏统一的业务和技术标准如开发规范、指标口径和交付标准不统一。缺乏有效统一的数据质量监控如列值信息不完整和不准确SLA时效无法保障等。业务知识体系散乱不集中导致不同研发人员对业务理解存在较大的偏差造成产品的开发成本显著增加。数据架构不合理主要体现在数据层之间的分工不明显缺乏一致的基础数据层缺失统一维度和指标管理。目标 在现有大数据平台的基础上借鉴业界成熟OneData方法论构建合理的数据体系架构、数据规范、模型标准和开发模式以保障数据快速支撑不断变化的业务并驱动业务的发展最终形成我们自己的OneData理论体系与实践体系。 OneData探索 OneData行业经验 在数据建设方面阿里巴巴提出了一种OneData标准如图-1所示 OneData我们的思考 他山之石可以攻玉。我们结合实际情况和业界经验进行了如下思考 1.对阿里巴巴OneData的思考 整个OneData体系覆盖范围广包含数据规范定义体系、数据模型规范设计、ETL规范研发以及支撑整个体系从方法到实施的工具体系。实施周期较长人力投入成本较高。推广落地的工作比较依赖工具。2.对现有实际的思考 现阶段工具保障方面偏弱人力比较缺乏。现有开发流程不能全部推翻。经过综合考量我们发现直接全盘复用他人经验是不合理的。那我们如何定义自己的OneData即能在达到目标的前提下又能避免上述的难题呢 OneData我们的想法 首先结合行业经验自身阶段的实践及以往的数仓经验我们预先定义了OneData核心思想与OneData核心特点。 OneData核心思想从设计、开发、部署和使用层面避免重复建设和指标冗余建设从而保障数据口径的规范和统一最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。 OneData核心特点三特性和三效果。 三特性统一性、唯一性、规范性。三效果高扩展性、强复用性、低成本性。 OneData我们的策略 OneData即有核心思想又有核心特点到底怎么来实现核心思想又能满足其核心特点呢通过以往经验的沉淀我们提出两个统一方法策略统一归口、统一出口。 根据两个统一的方法策略我们开启了OneData的实践之路。 OneData实践 统一业务归口 数据来源于业务并支撑着业务的发展。因此数仓建设的基石就是对于业务的把控数仓建设者即是技术专家也应该是“大半个”业务专家。基于互联网行业的特点我们基本上采用需求推动数据的建设这也带来了一些问题包括数据对业务存在一定的滞后性业务知识沉淀在各个需求里导致业务知识体系分散。针对这些问题我们提出统一业务归口构建全局知识库进而保障对业务认知的一致性。 设计统一归口 为了解决数据仓库建设过程中出现的各种痛点我们从模型与规范两个方面进行建设并提出设计统一归口。 1.模型 规范化模型分层、数据流向和主题划分从而降低研发成本增强指标复用性并提高业务的支撑能力。 (1) 模型分层 优秀可靠的数仓体系往往需要清晰的数据分层结构即要保证数据层的稳定又要屏蔽对下游的影响并且要避免链路过长。结合这些原则及以往的工作经验我们将分层进行统一定义为四层 (2) 模型数据流向 重构前存在大量的烟囱式开发、分层应引用不规范性及数据链路混乱、血缘关系很难追溯和SLA时效难保障等问题。 重构之后稳定业务按照标准的数据流向进行开发即ODS–DWD–DWA–APP。非稳定业务或探索性需求可以遵循ODS-DWD-APP或者ODS-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.主题划分 传统行业如银行、制造业、电信、零售等行业中都有比较成熟的主题划分如BDWM、FS-LDM、MLDM等等。但从实际调研情况来看主题划分太抽象会造成对业务理解和开发成本较高不适用互联网行业。因此结合各层的特性我们提出了两类主题的划分面向业务、面向分析。 面向业务按照业务进行聚焦降低对业务理解的难度并能解耦复杂的业务。我们将实体关系模型进行变种处理为实体与业务过程模型。实体定义为业务过程的参与体业务过程定义是由多个实体作用的结果实体与业务过程都带有自己特有的属性。根据业务的聚合性我们把业务进行拆分形成了七大核心主题。面向分析按照分析聚焦提升数据易用性提高数据的共享与一致性。按照分析主体对象不同及分析特征形成分析域主题在DWA进行应用例如销售分析域、组织分析域。3.规范 模型是整个数仓建设基石规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况我们统一按照最详细、可落地的方法进行规范建设。 (1) 词根 词根是维度和指标管理的基础划分为普通词根与专有词根提高词根的易用性和关联性。 普通词根描述事物的最小单元体如交易-trade。专有词根具备约定成俗或行业专属的描述体如美元-USD。(2) 表命名规范 通用规范 表名、字段名采用一个下划线分隔词根示例clienttype-client_type。每部分使用小写英文单词属于通用字段的必须满足通用字段信息的定义。表名、字段名需以字母为开头。表名、字段名最长不超过64个英文字符。优先使用词根中已有关键字数仓标准配置中的词根管理定期Review新增命名的不合理性。在表名自定义部分禁止采用非标准的缩写。表命名规则 表名称 类型 业务主题 子主题 表含义 存储格式 更新频率 结尾如下图所示 (3) 指标命名规范 结合指标的特性以及词根管理规范将指标进行结构化处理。 A. 基础指标词根即所有指标必须包含以下基础词根 基础指标词根英文全称Hive数据类型MySQL数据类型长度精度词根样例数量countBigintBigint100cnt金额类amoutDecimalDecimal204amt比率/占比ratioDecimalDecimal104ratio0.9818…………………………B.业务修饰词用于描述业务场景的词汇例如trade-交易。 C.日期修饰词用于修饰业务发生的时间区间。 日期类型全称词根备注日dailyd周weeklyw………………D.聚合修饰词对结果进行聚集操作。 聚合类型全称词根备注平均averageavg周累计wtdwtd本周一截止到当天累计………………E.基础指标单一的业务修饰词基础指标词根构建基础指标 例如交易金额-trade_amt。 F.派生指标多修饰词基础指标词根构建派生指标。派生指标继承基础指标的特性例如安装门店数量-install_poi_cnt。 G.普通指标命名规范与字段命名规范一致由词汇转换即可以。 H.日期类型指标命名规范命名时要遵循业务修饰词基础指标词根日期修饰词/聚合修饰词。将日期后缀加到名称后面如下图所示 I.聚合类型指标命名时要遵循业务修饰词基础指标词根聚合类型日期修饰词。将累积标记加到名称后面如下图所示 (4) 清洗规范 确认了字段命名和指标命名之后根据指标与字段的部分特性我们整理出了整个数仓可预知的24条清洗规范 数据类型数据类别Hive类型MySQL类型长度精度词根格式说明备注日期类型字符日期类stringvarchar10dateYYYY-MM-DD日期清洗为相应的格式数据类型数量类bigintbigint100cnt活跃门店数量…………………………………………结合模型与规范形成模型设计及模型评审两者的工作职责如下图所示 统一应用归口 在对原有的应用支持流程进行梳理的时候我们发现整个研发过程是烟囱式。如果不进行改善就会导致前面的建设”毁于一旦“所以需对原有应用支持流程进行改造如下图所示 从图中可以看出重构前一个应用存在多次迭代每次迭代都各自维护自己的文档。烟囱式开发会导致业务信息混乱、应用无法与文档对齐、知识传递成本、维护成本和迭代成本大大增加等问题。重构后应用与知识库相对应保证一个应用只对应一份文档且应用统一要求在一份文档上进行迭代从根源上改变应用支持流程。同时针对核心业务细节和所支撑的数据信息进行了全局调研并归纳到知识库。综合统一的知识库降低了知识传递、理解、维护和迭代成本。 统一归口策略包含业务归口统一、设计归口统一和应用归口统一从底层保证了数仓建设的三特性和三效果。 统一数据出口 数仓建设不仅仅是为了数据内容而建设同时也为了提高交付的数据质量与数据使用的便利性。如何保证数据质量以及推广数据的使用我们提出了统一数据出口策略。在进行数据资产管理和统一数据出口之前必须高质量地保障输出的数据质量从而树立OneData数据服务体系的权威性。 1.交付标准化 如何保证数据质量满足什么样的数据才是可交付的是数据建设者一直探索的问题。为了保证交付的严谨性在具体化测试方案之前我们结合数仓的特点明确了数据交付标准的五个特性如下图所示 《交付标准化》完善了整个交付细节从根本上保证了数据的质量如业务测试保障数据的合理性、一致性技术测试保障数据的唯一性、准确性数据平台的稳定性和后期人工维护保障数据的及时性。 2.数据资产管理 针对如何解决数据质量中维度与指标一致性以及如何提高数据易用性的问题我们提出数据资产的概念借助公司内部平台工具“起源数据平台”实现了整个数据资产管理它的功能如下图所示 借用起源数据平台我们实现了 统一指标管理保证了指标定义、计算口径、数据来源的一致性。统一维度管理保证了维度定义、维度值的一致性。统一数据出口实现了维度和指标元数据信息的唯一出口维值和指标数据的唯一出口。通过交付标准化和数据资产管理保证了数据质量与数据的易用性同时我们也构建出OneData数据体系中数据指标管理的核心。 实践的成果 流程改善 我们对开发过程进行梳理服务于整个OneData体系。对需求分析、指标管理、模型设计、数据验证进行了改善并结合OneData模型策略改善了数仓管理流程。 数仓全景图 基于OneData主题建设我们采用面向业务、面向分析的建设策略形成数仓全景图如下图所示 资产管理列表 基于起源数据平台形成的资产管理体系如下图所示 项目收益 基于OneData建设成果我们结合实际项目建设样例对比以前未进行OneData建设时的收益。如下图所示 总结和展望 我们结合了OneData核心思想与特点构建一种稳定、可靠的基础数据仓库从底层保障了数据质量同时完成OneData实践形成自有的OneData理论体系。未来我们还将在技术上引入实时数据仓库满足灵活多样、低延时的数据需求在业务层面会横向拓展其他业务领域不间断地支撑核心业务的决策与分析。下一步我们将为企业级One Entity数据中台以Data As a Service为理念提供强有力的数据支撑。在后续数仓维护过程中不断地发现问题、解决问题和总结问题保障数据稳定性、一致性和有效性为核心业务构建价值链最终形成企业级的数据资产。 作者 禄平周成黄浪健平高谦美团数据研发工程师。
