什么叫网站优化,怎么用vs做网站开发,wordpress中英文网站,怎么帮公司做网站建设背景 美团点评作为全球最大的生活服务平台#xff0c;承接超过千万的POI#xff0c;服务于数量庞大的活跃用户。在海量数据的前提下#xff0c;定位运营业务、准确找到需要数据的位置#xff0c;并快速提供正确、一致、易读的数据就变得异常困难#xff0c;这些困难主要体… 背景 美团点评作为全球最大的生活服务平台承接超过千万的POI服务于数量庞大的活跃用户。在海量数据的前提下定位运营业务、准确找到需要数据的位置并快速提供正确、一致、易读的数据就变得异常困难这些困难主要体现在以下方面 取数门槛高找不到切合的数据口径复杂不易计算对运营人员有一定的技能要求人力成本增大数据处理非常耗时缺少底层离线数仓模型建设和预计算支撑Ad-hoc平台查询缓慢数据不一致不同渠道口径不一致缺少对杂乱指标的统一管理数据反馈形式不友好缺少数据可视化的形式无法呈现趋势继而影响业务人员对多维、降维、对比等情况的进一步分析操作。因此团队提出将运营专题数据产品化首先分析面临的一些问题和挑战。 挑战 ① 服务业务能力 数据模式是需求驱动导向这就导致数据最初只支持了少数团队而更多有个性化需求的业务团队就无法被支持。 ② 存储、计算、研发成本 没有统一的规范标准管理造成了重复计算的资源浪费数据的层次和粒度不清晰使得重复存储严重同时工程师需要了解研发流程的整个细节对研发的时间和精力成本造成浪费。 ③ 数据标准不统一 业务指标繁杂即使同样的命名但定义口径也会不一致。例如支付用户数就有多种定义由此带来的问题是都是支付用户数应该用哪个为什么数据都不一样 ④ 业务分析响应能力 即使拥有健壮的数仓模型支撑但最终能否快速响应多维计算进行对比分析同时做到数据可读都是对产品交互和服务能力的一种挑战。 针对以上的问题和挑战开始制定建设方案。 方案 首先构建了一个针对境内旅游运营侧全域的公共底层数据将不同平台促销系统的数据按业务整合到一起同时划分不同活动主题按事件再向上聚合做专题的数据支撑统一数据出口。然后通过多维预计算引擎对事实数据进行预计算构建数仓与应用的管道从而节省计算成本并且提升了数据互通和消费的效率最后建设统一的数据服务中台搭配不同端的Web应用。通过丰富的可视化效果及多样的分析对比操作快速、全面地支撑运营业务。 以下为整个产品的功能模块图 如图所示运营专题数据的产品化根据需要解决的问题划分了多个不同的层次每一层除其需要面对的核心问题外还有其领域内其它功能模块的抽象和扩展下面将会按照层次划分逐一介绍各个模块。 数据仓库层 数据生产和消费的基础平台是整个数据产品化过程中最核心的角色。数据仓库的模型建设不但影响产品化的难易程度及可行性更是数据一致性等关键问题的直接因素所以为降低使用门槛、统一数据标准、支撑上层更合理的架构模型的选取就变得尤为重要。 领域内常见的建模方法 ① 3NF模型 3NF模型又叫“范式模型”是数据仓库之父Inmon提出的它用实体加关系的数据模型描述业务架构在范式理论上符合3NF是站在全局角度面向主题的抽象。它更多的是面向数据的一致性治理。 3NF模型最基本的要素是实体、属性和关系 实体相同特征和性质的属性抽象用抽象的实体名和属性名集合共同刻画的逻辑实体关系实体之间的关系属性实体的某种特性一般实体具有多个属性。② 维度模型 维度模型是Kimball提出的。维度模型多为分析和决策提供服务因此它重点解决快速完成分析同时提供大规模复杂查询的响应性能预聚合更直接地面向业务。例如熟知的星形模型以及特殊场景的雪花模型。 维度建模最基本的要素是事实和维度 事实表一般由两部分组成纬度和指标通常理解为“某人在某时间某地点通过某手段做了什么事情”的事实记录它体现了业务流程的核心内容维度表看待事实的角度用以描述和还原事实发生的场景比如通过地址、时间等维度还原业务场景。③ DV模型DataVault DataVault是Dan Linstedt发起的是一种介于3NF和维度建模之间的建模方法。它的设计主要是满足灵活性、可扩展性、一致性和对需求的适应性。它强调建立一个可审计的基础数据层主要包括Hub核心实体、Link关系、Satellite实体属性三个要素。 ④ Anchor模型 Anchor模型由Lars. Rönnbäck提出是DataVault模型的进一步范式化处理核心思想是只添加、不修改的可扩展模型Anchor模型构建的表极窄类似于K-V结构化模型。它主要包括Anchors实体且只有主键Atributes属性Ties关系Knots公用枚举属性)。Anchor是应用中比较少的建模方法只有传统企业和少数几家互联网公司有应用例如蚂蜂窝等。 运营专题数据如何构建 随着促销系统不断发展平台趋于稳定再结合各活动类型及对需求的整理和进一步产品化选择了3NF维度建模为基础的模型方法论对数据进行合理划分和整合构建了运营专题数据体系。 ① 数据规范制定 数据规范的制定也是指标字典和服务层规则引擎抽象的基础。首先同业务达成共识制定数据一致性标准统一口径。同时将核心指标和个性化指标进行抽象抽取统一规范定义例如月初到月末的整体交易类GMV和补贴类GMV其原子指标是GMV其它要素都属于指标的修饰。 ② 数仓模型架构 将数据分为ODS层、BAS层、FACT层、TOPIC层。 ODS层主要功能 从分布式消息队列中消费Binlog和Click-log并对埋点数据进行清洗和业务库数据还原并根据需要增量或全量同步到Hive同时积累历史数据并保存。 BAS层主要功能 采用3NF建模方法对整体业务进行概念抽象及适当冗余在保证数据一致的同时将同属性实体归纳整合到同一逻辑域。BAS层主要是为了减少数据的不一致减少存储空间响应业务系统的变化避免更新异常。 FACT层主要功能 采用维度建模方法根据活动特点及事实场景对代金券、现金券、促销等的事件进一步整合。经过对维度的预处理在使用信息的时候不但减少时间成本、提高数据的提取效率又为用户在Ad-Hoc平台查询提供很好的支撑同时它成为了上层数据应用的关键出口。 TOPIC层主要功能 该层建设不是必须的是针对业务中个性化诉求根据需要建设专题数据。服务小范围业务群体和用户用来支撑核心业务指标外的某一块个性化指标和应用。 如图所示数仓模型整体架构图。通过构建运营专题的底层数据针对数据一致性等问题在数仓层面上得到了很好的解决同时在数据提取效率上有很大的提升。数仓建设为接下来的业务支撑打好了充分的基础。 多维预计算层 预计算层是连接数据和应用之间的管道是应用层垂直模块的专项支持。它是在Fact层数据之上的预聚合强依赖于数仓模型中事实和维度的构建以及预关联。预计算采用Kylin引擎构建Cube聚合组来解决取数门槛和数据处理耗时等问题同是提供多维分析的能力不但提供了新的Ad-Hoc(Query Engine)平台在提高查询响应的同时又能为产品带来更流畅的交互增强用户体验。例如创建一个交易数据cube它包含日期datakey、用户userid、付款方式paytype、购买城市city。为满足不同消费方式在不同城市的应用情况和查看用户在不同城市的消费行为建立以下两个聚合组包含的维度和方式如图所示 中台服务层 数据预计算之后需要分别对PC和移动端提供计算和装载并且要针对不同端的特定模块做特定的开发为了应对多变的业务逻辑以及未来的可扩展能力需要提供可插拔的、统一的服务层该层主要可以解决如下问题 服务与预计算数据同步数据模型的修改只影响到预计算层同时服务层还可以完全感知预计算数据的变化不需要对服务做开发调整实现数据变更的同步响应服务与端解耦针对不同端产品提供统一数据服务避免重复开发同时产品的迭代升级与服务层隔离应对多变的业务发展和增长服务扩展能力增强支持服务的横向扩展不影响正常业务的同时提高服务能力同时在该层实现可抽象通用操作以及规范管理。总体架构 整个服务由独立的Web应用端发起请求通过权限验证后对中台发起调用然后读取配置中心的配置由计算引擎对数据进行并行计算同时规则引擎按业务线和指标修饰词等生产衍生指标然后将引擎完成的数据按周期进行快照存入备忘录同时关联指标字典将数据与文案返回前台最后按功能再对数据做可视化处理。下面分别对服务中交互的几个模块做简单的介绍。 配置中心 把系统的各类资源比如数据库、服务地址、缓存等以及多个环境和具体业务逻辑比如业务线、平台、指标类型按功能特性抽取出公共的控制的线头在需要调整的时候人为的控制系统。 如图所示用户通过单独的配置入口将系统配置、优化条件判断、业务线个性化指标配置等信息提交到Server运行时Client会到Server拉取配置放入缓存并定时持久化到本地文件方便异常中断或重启时手动或自动重新加载配置。 指标字典 公司中的很多运营部门指标定义不清晰或不尽相同但叫法相同文案又或者叫法相同指标口径不同出现一些对指标的理解不一致含义不清等问题。基于指标字典不但是指标命名的规范和明确也是统一计算口径的落地接入规则引擎后生成关联衍生指标即可自助完成查询和分析。可见指标字典的建立是数据服务平台的基础。 如图所示基于数仓中对数据规范的制定将指标按业务线、类型、基础、衍生等划分为不同类别并对指标名称、别名、口径等信息落地入库进行持久化存储。 规则引擎 运营业务的特点是运营活动规则的多变需要很多个性化配置。为解决复杂和复合的计算问题维度和事实的交叉并降低维护成本将逻辑从“硬编码”中将规则抽离然后根据不同业务线特点按修饰词进行隔离提高应用灵活性简化架构。 ① 数据准备规则 在应用数据计算之前把外部数据引入作为规则匹配运算的算子或数据集例如某活动针对全部用户做发红包活动而在活动中针对新用户发x面额的红包而针对老用户发y面值的红包。其规则条件为红包金额大于小于等于且使用地点为上海北京全部 ② 数据计算规则 实现对业务规则的变量和参数化按指标字典中的指标定义转化为计算表达式使得规则执行的结果作为其他规则条件的计算因子生成衍生指标。 计算引擎 计算引擎core模块在对数据进行处理时对数据进行了分片分桶等优化操作在面对多维度大范围数据查询时一定程度上提升了查询性能计算模块的抽取实现了与业务逻辑的解耦它只负责任务的处理和执行可仅对性能进行维护和升级甚至可以维护不同处理方式的多个计算引擎无需关心业务逻辑。 如图所示当引擎接收一个时间跨度较大维度较多的数据时会先按照时间进行横向切分然后将切分的数据按维度组合进行纵向切割每一组都交由一个线程进行处理并对该结果数据进行tag标记然后根据标记在前台进行整合。 备忘录 备忘录是按时间周期对数据计算完成装载后状态的快照历史是对值和计算规则的持久化。通过备忘录可以为用户提供横向纵向等对比分析功能帮助用户分析趋势。简化示意图如下 数据可视化 面对冰冷的数字如何将数据组织起来使其既有吸引力又易于理解 可视化是解决问题的一种高效的手段数据是强大的如果能真正理解其中的内容。 运营专题产品采用了开源的Echarts通过定制化开发的可视化数据帮助用户将数据转化为可以付诸行动的见解在提供可视化数据的同时又为专题数据特定模块提供特定的降维对比等线上分析操作。 趋势对比 通过维度的筛选切换业务不同视角的核心指标趋势一目了然不仅提供不同时间粒度同环比的纵向比对还提供同级指标的横向比对努力做到多角度、全方位的数据呈现。 降维操作 为更好的认识和理解数据降低复杂度缓解“信息丰富、知识贫乏”现状提供了降维操作让原本稀疏分布在各维度的特征聚敛将某类特性更直接的表现出来。 指标对比 将业务人员的线下热操作简移到线上通过将维度压扁拉伸成纵向指标进行多维指标的对比并提供明细。 多维查询 为支持更好的OLAP分析发挥预计算层的作用还提供了关键指标解析和多维查询的功能是产品对常规性分析的功能补充。 总结 在运营专题数据产品化的过程中将技术转化为价值提炼数据内容、为业务赋能是真正的发力点为发挥数据的最大价值以及带给用户更好的体验投入了大量的思考与实践最终产品的生产投入为现阶段带来了以下收益 数据标准统一数据指标口径一致各种场景下看到的数据一致性得到保障支撑多个团队极大扩展性服务了内部全运营业务团队满足不同团队的个性化需求统一服务建立了统一的数据服务和中台服务支持灵活配置计算、存储、研发成本增强了指标的复用、模型分层、粒度清晰精简了数据表的落地量通过数据分域、模型分层节省了研发的时间和精力业务支持丰富的可视化数据提供多维、降维、对比等多样的分析操作多方位全角度支撑业务。作者简介 吉喆美团点评系统开发工程师曾就职于新浪美团阿里巴巴从事系统开发及数据开发工作2017年加入美团点评负责数据仓库建设和产品开发相关工作。招聘信息 团队长期招聘数据仓库、数据开发工程师欢迎对大数据领域感兴趣的同学投递简历到yangguang09#meituan.com期待您的加入。