2021-05-20 11:53 浏览量:365
大数据的应用场景在前期文章“大数据除了”杀熟“还能干点啥?”有比较详细的介绍,在此不作赘述,对于重度依赖数据进行管理和决策的公司,相信很多人都经历过以下问题
运营部门和财务部门一起开会给老板汇报,微信消费用户数运营1021W,财务1000W,运营说我的数据是数据中心出的,财务说我的也是,那数据为什么不一致呢?原因数据开发A给运营出的报表,按照业务的口径以UnionID(微信唯一id)去重,数据开发B,给财务出的报表是按照memberID(注册会员id)统计,存在一个unionid绑定多个memberid的情况
指标表现异常,业务第一反应就是“是不是数据不准啊”,这时作为数据部门如何能够有底气来反驳这种DISS呢?数据业务系统同步到数仓,ETL加工,再输出到报表应用,会经过多个步骤,每一个步骤都有可能会出现任务的异常、延迟以及人为的bug,监控覆盖足够健全,业务反馈问题时,数据开发就可以自信的说,今天数据无异常(没有收到报警),而不是我先确认下。
缺少统一的数仓建设和管理规范,CaseByCase地响应业务需求,往往会导致数据的重复建设,例如,数据开发A接到产品的大盘流量报表需求,直接基于ODS的明细数据进行ETL,加工出自己的为了满足这一报表需求的APP层表,数据开发B,接到会员营销的需求,报表指标不尽相同,小A的APP层表无法直接使用,于是自己又加工了新的数据表,由此,导致相同指标多个模型出现,但又无法复用,造成重复建设
业务发展加上数据的重复建设,数据表的数量在10W+,缺少工具的指引,尤其是新用户很难找到需要的数据在哪个表里,处理逻辑是不是自己需要的
随着业务需求发展,数据处理所需要的存储和计算成本也线性或指数增长,对于DAU千万级的互联网公司,每个月大数据集群的资源成本可能也在百万~千万级,是真正的成本中心了。往往一线数据开发很多只关注新增业务,不去梳理历史任务,或者一些低效的SQL任务占据了大量的资源。
定制化的数据可视化报表开发需要数据开发、接口开发、前端开发,产品迭代、活动上线节奏非常快,都需要对应的报表监控支持,单个报表的开发周期往往在1~2周,对开发资源的依赖导致需求响应周期长,很多时候报表上线了,活动结束了。
对于无SQL的业务人员很多探索性的数据分析依赖于数据开发的SQL取数,一般SQL取数都是由数仓兼职进行,时间排期就有限,只能按照提需时间或者紧急需求的申请通道进行处理,临时取数的时效性要求更高,经常出现数据输出了,业务意见拍脑袋做完决策了。可能有人问可不可以安排全职取数,对于有个人追求的程序员,一直做SQL取数,估计很快就要离职了。
数据部门会输出很多的API接口,由于历史久远文档不完善加上业务不断调整变化,导致接口和应用链路断层,接口出问题只能由业务反馈后处理。梳理出流量小的接口要做下线,却找不到应用端的人确认,只能先下线看下,有人反馈再处理。
很多公司缺少统一的数据开发平台,数据开发人员自己基于开源工具如azkabn、airflow、quartz自己搭建任务调度平台,甚至有的一个公司不同部门采用独立的调度工具,造成人力和资源的重复投入。
精细化运营背景下,用户运营每个营销场景需要最精准的确定目标人群,比如会员生日关怀、迪士尼目标用户群体投放等,业务需要先找数据部门获取目标用户的id信息,再进行投放,数据部门的响应周期和效率制约了运营活动的投放频次,即数据每周可以处理3~7次人群调取,那运营活动肯定不能超过这个频率。
每个公司都在实践中寻找解决上述问题的方法,例如构建指标体系解决指标口径不一致的问题;建设自助取数工具,业务自助取数不求人,开发人力释放专注于数仓模型建设;开发配置化的BI可视化产品,减少可视化报表对接口开发、前端开发人力的依赖;建设精准营销(DMP)平台,业务自助圈选目标用户进行精准触达,提升运营活动频率等。所以,个人理解,数据中台概念的出现,只是提供了一套完整的解决方案和思想,把原来的不成体系的“野路子“,扣上”中台“的帽子后,成了有方法论、战略的指引和支撑正规军了。
数据中台是一种大数据生态架构,不是单一的具体产品,而是产品体系。在数据的“存”、“管”、“用”环节,提供“高复用、提效率、降成本”的解决方案。每家公司在产品落地上会有个性化差别,但各个板块基本大同小异。
数据中台产品架构
目标:以产品化的方式降低数据获取、数据分析、数据应用的成本,解决数据响应周期长、开发成本高、运营效率低问题
自助BI分析:集成数据建模、自助分析、数据可视化、数据治理、智能分析的一站式数智化决策分析平台,数据开发专注数仓模型建设,提供健全的模型、完善的资产元数据信息后,业务拖拽式、可视化的数据查询和分析,不需要数据开发介入。针对需要周期性使用的数据,可以保存成可视化Dashboard,自助进行可视化报表减少,释放接口和前端开发人力。
智能营销平台(DMP):基于大数据计算和数据挖掘技术,构建用户画像标签体系,用户圈选、精细化分层,进行差异化运营和营销触达,提升运营ROI。业务同学可基于平台实现从人群圈选、场景构建、触达投放、效果回收的闭环,同时,基于算法挖掘标签及模型推荐的人群组合,从基于人的经验运营,到基于大数据算法推荐的智能运营。
目标:API服务统一管理,建立完善的应用血缘关系,提供通用接口的配置化生成能力,降低对Java开发的依赖。
数据服务管理平台:数据中台思想下,数据服务输出是应用输出的最主要形式,数据服务管理平台一方面要具备将数据资产自助配置化输出的能力,即数仓清洗好的数据模型,数据开发或业务人员可以通过入参、出参的可视化配置生成API接口,不需要接口开发介入。同时也要把API资产化管理,API接口文档、应用调用情况做到可追踪、可监控。
没有资产的沉淀的数据中台只能叫数据平台,因为中台目标是数据的应用价值。因此,数据中台架构中,数据资产占据非常重要的地位。
数据流向
目标:提供数据资产建设、资产管理与治理的完整产品方案,通过数据资产化管理和共享流程提高数据复用性,减少重复开发成本,基于完善的监控覆盖保障数据质量,并周期性的盘点、治理资产,达到降本的目标。
数据地图:通过业务域、主题、标签、字段元数据等信息,帮助用户快速检索到目标数据,基于条件过滤或自助搜索,“逛数据”,“用数据”。
数据质量监控:围绕“准确性、一致性、及时性、唯一性、完整性”等标准维度,提供配置化的质量监控规则,对数据表数据量、字段值进行监控覆盖,从源头及时发现数据问题并加以干预,保障数据质量。
数据血缘:数据入湖到输出应用经过多个环节,上游数据问题如何快速通知下游,下游数据逻辑排查如何向上追溯,以及数据治理表或路径下线,如何评估下游的影响并通知,都依赖于全链路数据血缘的建设。可以说,完善的血缘功能,可以极大提高数据开发的工作效率
成本优化:数据有自己的生命周期,比如活动期间的数据监控报表,活动下线后,报表可以下线释放资源。成本优化提供高耗任务、小文件、冷数据等不同治理维度的指标,及治理目标,从资产健康度评估维度,指导数据开发人员主动进行成本优化、数据治理,系统层面具备治理目标检测、一键治理、数据回收、彻底删除等治理功能,并且可以基于固化的治理规则,进行系统自动化治理。
目标:提供统一的数据开发平台,数据开发只需要关注数据处理逻辑,无需关注集群资源、任务调度,通过配置化的方式进行依赖关系配置,及任务运行周期,快速进行数据回溯、任务重启、停止
离线开发平台:批数据处理,一般为T+1或小时级的准实时数据,包括任务逻辑处理、依赖配置、调度配置、任务运维等功能。
实时开发平台:流数据处理,以FlinkSQL、StreamSQL为主要计算处理框架,实时处理消息队列等各种流式数据,输出实时报表、实时接口推荐等服务
目标:提供异构数据源数据同步可视化工具,通过源和目标参数配置实现数据入湖、入仓,以及存储介质的转换,降低人肉脚本处理带来的风险和维护成本。
数据集成:业务数据库、操作日志、状态变更消息等数据源接入数据中心,如Biglog同步、MySQL库表订阅、Kakfa数据落HDFS等。数据经过实时或离线ETL后,数据集成再将数据输入CK、Hbase、ES等供业务端应用
目标:大数据集群上云,组件管理平台化,通过管理平台实现对HDFS、Kafka、Hbase等服务的在线运维管理。
云平台:Hbase管理、Kakfa管理、HDFS管理、ES管理等
从以上几个案例看,数据中台下的产品框架,为了解决面临的问题和调整提供方向指引,同样,在解决问题的实践过程所涉及的方案,也可以不断丰富数据中台产品体系,相辅相成,螺旋上升。
后续的文章将以单个产品切入,深入剖析数据中台架构下的产品解决问题的思路以及如何规划设计。
数据中台没有“凉不凉”之说,可能未来会出现新的名称取代中台,但无论如何,当企业在数据化管理或数智化转型过程遇到对应的问题时,都可以基于中台的思想和架构去解决,围绕“业务数据化,数据资产化,资产价值化”,让数据高效率、低成本地赋能业务。数据人,低调沉稳,不管中台火不火,不追求浮华的概念的炒作,从解决问题的实际出发,建设自己的产品生态才是最重要的。
来源:数据干饭人
作者:千冰仪