窥探企业数据中台的秘密-中

技术中台、业务中台和数据中台对比

前言

随着大数据时代的发展,互联网人口红利的逐渐消失,流量焦虑和数据孤岛等问题日益显著。互联网下半场已迈入深度变革的深水区,用户演变成企业商业战场上竞争的核心要素,就犹如古代战场上城池是兵家必争之地一样,行业竞争也从用户拉新转为用户使用时长和用户粘性之争。

企业更多的在思考用什么样的方式快速适应瞬息万变的市场,用什么样新的思维模式突破人口红利瓶颈,用什么样的方式能够快速响应用户需求的同时减少企业沟通的成本,提升业务协作效率,完成企业数字化转型。刚好,中台可以在某些程度上满足以上要求。

中台,一方面,通过整合汇集打通企业业务数据和用户数据,沉淀业务通用组件以及技术能力,提供支持外部前沿技术快速嫁接和转化的能力,为企业整体数字化系统建设提供基础技术支持和服务的能力,在创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的找到一个相对好的平衡点;另外一方面,通过以用户中心为基础,以科技为引领,在统一愿景下建立实时战略的机制和敏捷生态的组织,在把握企业短期利益和长期利益的博弈与厮杀中做到先发制⼈、抢占先机,促进企业在数字化转型的道路上良性的发展。

从阿里提出“大中台,小前台”战略、华为提出“让平台炮火支撑精兵作战”战略以及最近腾讯提出的“开源协同,自研上云”启动中台战略,各大巨头争先恐后的启动中台战略,到底是为什么呢?中台背后到底隐藏着什么秘密呢?中台能给企业带来什么价值呢?

为了进一步,让大家了解中台的本质。本篇按顺序介绍如下:

中台演进的过程技术中台、业务中台和数据中台的概念技术中台、业务中台和数据中台的架构技术中台、业务中台和数据中台的区别与联系。

01中台演进的过程

【美军中台的借鉴图】

中台,最早是由美军的作战体系演化而来,美军在遇到强敌时,往往能以少胜多,取得战斗的胜利。原因在于对内军队、友军间实现后勤统一,用于提高供应效率、节省成本;对外具有强大的导弹指挥系统,强大的中后台能力,先进的通讯和定位科技方便他们随时呼叫海陆空三军进行火力支援,具备支持小团队快速判断作战能力,引领战争的胜利完成。

中台,从概念层面上来说,介于前台与后台之间,提供⼀个中间层来调度适配前台与后台的配速问题,类似一个“变速⻮轮”;从技术层面上来说,中台主要是指学习部队高效、灵活和强大的指挥作战体系,是为了做资源整合、沉淀业务和产品技术能⼒,打通前台需求与后台资源的连接,提供数据能力和产品技术能力,为前台业务开展提供底层的技术、数据资源和技术能力支撑,快速响应用户需求,发挥数据应用的新创新;从价值层面上来说,将企业核心的数据和技术能力以共享服务中心的方式进行沉淀,形成“大中台,小前台“的组织和业务机制,实现场景可组合、组织可重构、管理可复用、数据可共享,促使企业能快速降低成本的同时进行业务持续性的创新。

随着企业快速的发展,组织架构变得庞大、臃肿且复杂,业务线在受市场环境、企业战略、用户需求等因素的影响下被不断细化拆分,系统不断的增加,流程变的繁琐且错综复杂。最终,导致野蛮生长的系统越来越不堪重负、越来越不可维护,每个子公司与部门都建立自己烟囱式的IT系统或者建立烟囱式独立的数据分析平台和数据仓库,造成数据的“独 - 数据烟囱式林立”、 “断 - 数据理解、认知以及分析断层”、“缺 - 缺数据、缺标准、缺治理”、“难 - 知数据难、懂数据难、要数据难”,使得新的业务在这样的情况之下不得不重复造轮子。一方面,导致企业资源和成本的浪费;另外一方面,无法沉淀业务和沉淀技术能力;必须通过“企业信息化整合”的方式来改革、来优化IT架构,以此来提升企业IT价值,促使企业信息化进入到全面数字化整合的新阶段。

【传统IT系统架构 · 七宗罪图】

首先,先回顾一下,企业传统的烟囱式IT系统在建设发展的过程当中带来了很多弊端,归纳总结主要有七宗罪。

1、烟囱式:在建立数字化转型的过程当中,企业往往面临的问题不是没有系统,需要大量建设的问题,而是相关的IT系统太多,比如,用户系统、交易系统、订单系统等等,它们彼此之间的应用水平参差不齐,相互独立,不能互相集成,数据也不能共享,就像烟囱一样林立在林丛当中;

2、大笨重:企业没有统一完善的IT组织体系,没有规范的IT战略与规划,下属子公司、部门、业务线,都是根据各自的需要提出需求,进行系统开发或者各自找供应商采购自己领域上的软件,后期进行二次开发,长期以往下来,每个系统都很大、很笨、很重,可交互性相对来说不是很强;

3、数据壶:企业的上百个IT系统产生了很多的数据(内部数据 + 外部数据),由于没有做数据指标体系化、指标口径的统一和多源数据的统一 ,造成数据导出难、数据理解难,数据清洗难等问题,使得数据不能很好的被有效利用起来;

4、守旧而非创新:企业每个系统的应用水平参差不齐,不敢轻易废弃,重构怕出现新的问题,始终抱着能用就先用的心态,等出现问题的时候再去修改,导致一直下定不了决心,不敢彻底的推倒重来,不敢做大的变化,不敢做新的创新;

5、管控而非赋能:多年企业管理的制度形成的习惯,担心系统发生改变失去权力上的管控,管理者产生很多顾虑,并不是做到意义上的相互协作,更多的是短期利益上的博弈

6、占有而非链接:企业建立一支庞大的IT团队,什么事情都是自己做,而不是想通过多种方式来促进企业沉淀统一的技术能力,赋能业务;

7、领导者自我束缚:领导者管理者在互联网时代的转型过程中,心态的变化,想改变,但是由于市场环境、职位影响,固步自封,在做很多事情上面有束缚太多,魄力不够,格局不大。

以上种种情况,归结于一点,企业与人都演变成阻碍数字化转型变革的原罪因素之一,导致企业缺乏整合的IT架构的组织能力。最终使得技术能力无法快速响应用户需求,支撑内部和外部的数据运营效率。

企业信息IT系统太多的同时会产生新的各种问题。一方面,企业随着大数据时代的发展,信息爆炸式增长,数据越来越多,但是大数据中的大的相对面就是少,越是真实的业务数据,数据量就越大,可用的信息比例就越少,更多的是噪音数据,这些信息之间的关联性少,数据一致性更加难保证;另一方面,由于企业和各个业务线独立部署的系统,造成数据相互分散独立,企业需要了解的各个子公司和业务部门的经营情况,很难及时得到,领导决策层需要的数据分析和报告,很难在已有的系统中快速和准确地提供服务。

所以,企业要以业务为导向结合规范化的企业架构为出发点,推进整合IT架构,实现组织一体化、业务一体化、实现数字化应用和数据一体化、实现平台一体化, 做到服务重用、服务进化、数据累积、快速响应、降低成本、效能提升。先将烟囱式IT系统做到互联互通,才能规范应用系统的交互方式、打通企业的业务流程以及统一异构数据,最终实现技术和业务上的整合,更快的实现数字化转型。

02技术中台、业务中台和数据中台的概念

1、技术中台是将企业的技术能力进行整合和封装,比如像微服务开发框架、Dvops平台、容器云、PaaS平台以及其他应用各种技术的中间件,尽可能的过滤掉建设中繁琐的技术细节,为前台、业务中台和数据中台提供快速的发展,提供简单、易用、快捷的应用技术基础设施的能力

2、业务中台是将后台资源进行抽象包装整合,转化为前台具有可重用共享的核心能力,通过类似消息转发的方式,实现了后端业务资源到前台易用能力的转化。业务中台是数据提供者,不负责具体业务的实现,在实现多个业务线的逻辑层面上进行应用分离,通过制定标准和规范的统一方式,告诉其他业务线,让他们知道自身有哪些服务、数据和功能,用这种方式来减少沟通成本,提升协作效率,让企业的其他业务线都具备整个公司的核心产品和技术能力,为各个业务方提供敏捷快速、低成本创新能力

3、数据中台从后台及业务中台将数据流入,通过汇集数据的存储、计算、产品化等方式,构建全域级、可复用的数据资产中心与数据能力中心,提供干净、透明、智慧的数据资产与高效、易用的数据能力,为前台基于数据的定制化的创新和业务中台基于数据反馈的持续演进提供了强大支撑,使得业务能够快速的数字化运营

03技术中台、业务中台和数据中台的架构

【中台技术栈图】
【技术中台架构图】

中台技术是由平台化架构的发展演化而来的,延续了平台化架构的高聚合、低耦合、数据高可用、资源易集成等特性再结合微服务方式,将企业核心业务下沉至基础设施当中,基于前后端分离的模式,为企业打造一个连接一切,赋能于人,形成共享生态体。最终,以轻量、快速、高效,为企业数字化转型提供更友好的服务运行与开发环境。让平台即服务支撑到每一个应用,通过以标准而且基础的非业务功能的服务化方式,让开发人员更专注在业务功能开发上。

【业务中台架构图】

业务中台主要是为了沉淀业务通用服务能力,以服务化形式提供公共业务组件,为企业快速变化的场景化业务应用提供专业、稳定、高效、安全的共享服务,提升前端应用开发效率,快速响应实现创新需求,实现业务创新、数据共享和业务能力协同。

【数据中台架构图】

数据中台,提供数据获取与存储、数据计算与处理、数据共享与协作、数据应用与价值探索以及数据服务与服务运用等全链路一站式数据服务能力,紧密贴合业务,探索业务场景中的价值,助力企业数字化、智能化转型。

04技术中台、业务中台和数据中台的区别与联系

【技术中台、业务中台和数据中台图】

技术中台、业务中台和数据中台的区别与联系:

1、在职能层面上

业务中台是一个企业管理和运营的一体化管理平台,同时为前台提供支撑数据服务。比如用户中心,登录/注册、身份、验证等;会员中心,等级互换、积分打通、权益互换等;风控中心,黑/白名单设置、机制预警、权限设置等。这些统一的服务都来自业务中台的同一个系统的不同模块,可以分别支持多个其他业务系统对业务的管理要求,业务中台通过类似模块化、组件化、插件化、解耦等方式,当不同的业务系统需要这个模块的时候,不需要自己再去开发,直接从业务中台拿到这个功能模块,集成到需要的业务中去就可以。因此,业务中台的本质是把企业更多的业务系统连接在一起;

数据中台具有获取企业全域级的各类信息数据的能力,结合数据能力中心提供的技术能力,把业务系统的数据(内部数据 + 外部数据)汇集起来清洗干净,把获取的分析结果给到业务中台,赋能前台系统;

比如,根据业务中台提供的用户数据和行为数据,基于数据中台运算的分析能力,构建用户RFM模型,预测出用户行为偏好和用户价值;根据用户来访、互动情况、核心功能使用频率等,基于数据中台运算的分析能力,构建活跃度模型,预测出用户的活跃度等;广告精准营销,结合数据能力中心提供的技术能力,把经过数据中台算法分析的结果给到业务中台,支撑广告的实时投放和推荐

2、在数据层面上

业务中台只知道当前的业务状态,数据中台具有全域级的业务数据(当前、历史、处理数据)记录。比如A、B和C三个业务线统一的用户中心数据库放在业务中台,当登录、查询、修改发生了变化,业务的数据,会自动同步到数据中心,当用户改动了任何一个平台的数据都会有记录保留在数据中心,之后还可以通过回溯的方式查找数据流转路径

3、在目的层面上

业务中台算是中台里面的一个功能模块,目的是让业务更专注于服务业务,业务中台的数据服务中心和业务联系紧密,通过离线/实时的方式为业务线做同步支持;

数据中台建立的目的是为了沉淀数据沉淀,通过统计/分析/挖掘等方式结合业务发挥出数据的价值,将企业全域级的数据(内部数据 + 外部数据)都汇集到数

据中台来,借助技术中台提供的技术能力,解决企业数据独、断、缺、难四大难题,达成数据资产管理利益最大化,实现业务的价值沉淀。

4、在关系层面上

技术中台对企业的技术能力进行整合,支撑企业的业务发展,通过打通企业内部异构系统,支持业务中台;

业务中台和数据中台就好比强大的中后台炮火群,可以直接对敌人进行进攻。业务中台主要为企业的业务运营进行服务,将获取的多维度数据存储在数据库中;数据中台获取汇集数据后,借助数据中台的数据能力中心,进行数据清洗和分析,将得到的分析结果,反向赋能给业务中台,支撑到业务中台上的智能化场景的应用,智能化场景的应用经过使用产生的新数据又流转到数据中台,形成数据和业务上的闭环;

数据中台还具备可视化的模型结合算法智能分析,帮助企业管理者做数据运营决策分析。业务中台、数据中台和技术中台它们三者是相辅相成,相互协作的,没有直接或者间接的利益冲突关系。在这种关系下,企业的中台系统对数据、业务、技术能力等方面构建全量级的支撑体系,形成统一的企业的业务运营一站式管理平台。

总结一下,中台是以场景化业务为中心,具有可复用能力的有机组合,目标是为了能够快速的赋能业务进行落地实施、改造、试错、转型;意义是为了快速提升组织之间的效率,降低企业成本。

因此,企业需要结合自身的实际情况,围绕着核心业务展开数字化转型,在工具数字化、分析数字化和流程数字化加以落地,形成数据与业务上的完整闭环,打造属于自己企业独有的中台能力,把握好短期利益和长期利益来实现平台的发展,才能持续提升企业的经营效率和生产力,加快企业数字化转型的脚步,完成企业自身独有的战略目标。

数据获取的关键要素

在前面提到过数据中台的使命和愿景是让数据成为如水和电一般的资源,随需获取,敏捷自助,与业务产生更多的连接,使用更低成本,通过更高效率的方式让数据极大发挥价值,推动业务的创新与变革。随着互联网与大数据技术的不断发展,企业也渐渐意识到数据的重要性,但是由于企业每个部门都有建立了自己烟囱式的IT系统或者建立烟囱式独立的数据仓库和数据分析平台,导致数据共享难、互通难、理解难等,使得企业数据还停留在散乱的资源阶段,离数据利用、数据开发与数据变现,相对来说还是有很长的一段路要走。

为了解决企业数据“独”、“断”、“缺”、“难”四大难题,企业首先需要通过合理有效的方式为数据做资源规划,盘点出企业所有的数据,梳理清楚企业自身的数据情况。明确的知道,企业目前数据的来源、数据的存储情况、数据量的大小、数据的质量、数据的用途与数据流向等等。只有先了解企业当前数据资源的真实详细的情况之后,才有可能对数据利用和开发,发挥出数据的价值。

数据中台的初衷是为了让数据沉淀下来,产生价值,需要从最顶层的行业领域到企业的垂直领域的数据,同时需要覆盖多个领域的数据,只有先获取到全域级的数据(内部数据 + 外部数据)之后,将获取到的数据汇集到数据中台,解决企业数据孤岛的同时统一数据的规范和标准后,才有可能达成信息共享。

因此,企业建立数据中台的第一步先是进行数据获取,只有先获取到全域级的数据之后,对企业的数据进行盘点,统计数据资源的来源和确定数据资源后,才能去做数据资源规划。

如何有效的对数据进行获取呢?本篇,按顺序介绍如下:

数据在商业价值链条中的地位、数据获取之数据采集、数据获取之数据传输、数据获取之数据预处理。

01数据在商业价值链条中的地位

在DT时代的商业价值链条中,“数据即资产”的概念已经深入人心,一致认为拥有高价值数据源的企业在大数据产业链中占有至关重要的核心地位。大数据产业链发展的下半场,当整个产业链条逐渐做到打通拓宽,形成相对成熟的大数据生态之后,拥有数据源的企业将掌控数据链上游核心资源,并有可能通过数据直接变现迎来新的发展与机遇。

根据《2018全球大数据发展分析报告》显示,中国凭借近几年在“互联网+”与“大数据+”的融合创新,积累了丰富的数据资源,目前中国的大数据产业相关人才数量占比全球最高,达59.5%。其次为美国,占比22.4%。一方面,说明随着云计算建设的深入,大数据理念被用户认可,用户逐渐感受到新技术带来的便利和价值,促进大环境下及早地完善大数据采集的良心发展,避免造成有价值的数据流失;另外一方面,收集了海量的数据管理难度巨大,随之带来数据隐私和数据安全问题,在大数据时代孕育着很多商业机遇的时候,当数据被过度泛滥使用,必将对用户带来巨大的伤害。

【大数据资源SWOT分析图】

所以说,随着大数据市场的快速发展,数据资源丰富的同时挑战和机遇是共同存在。为了企业更好的利用大数据赋能业务快速成长,一方面,需要树立正确的数据价值观,对数据要怀有敬畏之心,在保证收集回来数据的安全性和隐私性前提下,合理的存储,不要企图利用数据去作恶;另外一方面,从业务出发合理使用数据,不做数据的独裁者;只有这样才有机会获取新一轮互联网数字化-智能化竞争制高点的“半张船票”

02数据获取之数据采集

企业启动中台战略同样是置身在大数据商业世界中的重要考量,一定不是学术界里的撒野。数据中台的建设离不开数据,数据就是数据中台的粮食,只有获取积累足够多的数据,才可能发挥出数据的价值。

【数据价值演变过程图】

数据演变成价值,是以数字化的形式先将信息聚合起来,通过记忆、存储的方式变成数据,然后通过数据分析与挖掘的方式变成知识,最后与业务相互结合发挥出商业价值。

【通用数据保护条例图】

在做数据采集之前,先和大家来谈谈数据安全与数据隐私问题。2018年5月25日,欧洲联盟正式出台《通用数据保护条例》,GDPR生效后,数据安全与数据隐私问题将成为企业必须重视的运营问题。企业必须明确满足数据主体的信息权、获取权、纠正权、限制处理权、反对权、删除权和数据可移动权等。

只有先在数据安全与数据隐私的前提之下,严格按照GDPR的基本原则来收集数据。企业再去明确数据从哪里来,有那些数据,数据存储在什么地方,数据用在什么地方,形成一个完整的数据流向闭环,对每一个信息进行分类,为企业提供一个360度全景的数据地图,才能确保企业能够快速定位、评估和监控所有的数据。

【数据资源分类管理图】

企业一般会从数据产生方式、数据来源途径、数据存储形式和数据使用用途四个方面对数据进行数据资源分类管理。

从个人实践经验来看,在做数据采集的过程中,规范和流程比设计采集方案更加重要。笔者在做数据采集之前一般都会先问自己四个问题

数据模型:日志的数据模型是什么,采集回来的数据怎么做数据归类;

寻找数据:数据从哪里来;

元素采集:需要采集的元素有什么;

采集方式:需要通过什么样的方式收集哪些日志;收集的数据怎么存储,存储在什么地方。

以上四点这些才是数据获取的关键,只有先收集到数据,最后去质量检验把数据看成矩阵,有矩阵才有输入的模式,才可能获取到相对质量更好的数据。

1、数据模型

数据模型,即数据归类。当企业业务线越多,产品变的复杂,产生的数据也就越多。如果还是按照之前烟囱式的IT系统的方式一样,一个数据来源一个数据来源地去对待的话,短期内来说还是可以的,但是长期以往效率就变得低下,需要把要收集的数据归入到模型当中去,当面对不同的数据场景化应用,采取的数据策略不一样,才能促进数据模型的良性发展。

【数据模型&数据归类图】

一般来说,业内场景化应用无非收集的数据有以下四种:用户属性数据、物品属性数据、事件数据和关系属性。当有了数据模型后,就可以很好地去梳理的数据,看看每一种数据归类是什么样子。

所以,建立数据模型的目的一方面是为了帮助产品梳理数据来源、数据日志、归类存储,以方便在使用时随需获取;另外一方面是为了让使用数据的人员更加透彻的理解业务。在做数据模型的时候,需要提前考虑到模型的延展性、拓展性和解耦性。

2、寻找数据

收集数据,就是把与企业业务、经营等相关的数据都汇集起来。企业获取内外部数据资源可以通过不同的方式和渠道来获取。从广义的层面上划分,主要来自两种,一种是内部数据资源;另外一种是外部数据资源。

内部数据资源:一般是通过企业内部的业务系统和应用系统的数据库直接产生,这类型的数据是业务运转必须要记录存储的数据记录,通常都是结构化存储的数据;常用同步方式有全量同步和增量同步。

外部数据资源:主要通过数据埋点、爬虫等技术手段来获取,数据通常都是非结构化和半结构化的数据。

埋点数据:通过App或web埋点方式来采集用户行为数据。从技术手段来划分,分为SDK埋点、可视化埋点、无埋点三种;从收集数据的位置来划分,又分为前端埋点和后端埋点。常用的应用场景有用户行为分析,搜索/推荐/广告投放分析等;

爬虫数据:使用爬虫技术获取第三方系统或网站的数据。从技术层面上来说,爬虫工作流程相对简单,是将种子URL放入队列,从队列中获取URL,抓取内容,然后解析抓取内容,将需要进一步抓取的URL放入工作队列,存储解析后的内容,但是实际过程中各大系统与网站反爬策略,这就涉及到技术与安全上的攻与防;从爬虫策略上说,常用的抓取策略有深度优先、广度优先 、大站优先、PageRank等方式;从爬虫质量来说,一般通过分布式、可伸缩性、性能和有效性、质量、 新鲜性、 更新、可扩展性等维度来判断爬虫数据质量的标准。常用的应用场景有网络舆情监测分析和价格趋势监测分析等;

日志数据:借助日志采集工具采集机器和应用产生的日志数据,常用的应用场景有系统服务异常监控,企业内部安全合规审计等。

但是,在做获取数据来说真相往往让人难以接受,获取内部数据资源比获取外部数据资源更难,需要的时间周期更长。获取内部数据资源最大的困境在于人,获取外部数据资源的困境在于技术。有时候往往解决技术的困境程度远远小于人带来的因素。至于为什么,话点到为止,大家意会。

3、元素采集

先确定,数据采集的规范和流程后,基于业务确定数据采集方案,然后遵循优先在后端收集数据。元素采集尽量遵循两个基本原一是全面;二是细致

先从后端收集事件数据中梳理出需要从业务服务器打印日志是什么,确定需要搜集什么信息才算是一条完整的时间信息数据?个人经验,一般需要包含下面的几类元素。

用户 ID,用户身份的唯一标识

物品 ID,物品的唯一标识。通过物品ID去区分辨别物品两个或者多个不同物品的本身

事件名称,每一个行为一个名字。用来记录的用户行为或业务过程,比如用户注册账号、登录、点赞,评论,分享、关注等等

事件发生时间,时间非常重要。需要明确事件在何时何地发生的事件。

以上是最基本的内容,如果能再收集到以下数据就更好。

事件发生时的设备信息和地理位置信息等;

从什么事件而来;

从什么页面而来;

事件发生时用户的相关属性;

事件发生时物品的相关属性

只有当搜集的数据越丰富就越可能通过细腻的方式和手段还原出用户当时使用的场景。

4采集方式

企业建立数据中台需要获取到全域级的数据,主要的数据来源于业务,业务场景越多很多,获取的数据源就越具有复杂的多样性,数据采集的形式随之变的多样。

提升数据价值,降低数据成本,保证数据质量,是企业数字化转型的希望。毕竟,巧妇难为无米之炊,质量好的数据胜似黄金,质量低的数据价值不高,如果收集到错误的数据即带来存储和传输成本的浪费,还无法创造出数据的真正价值。

数据采集的目的一方面可以了解与提升业务运营情况;另一方面,积累的海量数据,可以为后续场景化业务的数据分析与挖掘应用探索提供支撑能力。

【数据采集架构图】

从上图,可以衍生在实际数据采集落地工程当中,产品与技术团队会遇到以下几方面的问题:

问题一:产品团队不知道需要采集什么数据

数据采集的最最最基本两大原则:一是全面;二是细致。全面的意思就是需要把可能涉及到业务运转的数据都收集起来,而不只是App端和web端的数据收集;细致的意思就是尽可能多维度收集数据,把事件发生的一系列维度信息,尽量多的记录下来,方便后续做数据分析与挖掘。尽可能的把日志记录想象成一个 Live 快照,当收集的内容越多就越能还原出用户当时使用的场景。

作为产品团队的数据PM,在做需求埋点规划时,一定需要带有目的方式去思考问题,明确知道现阶段数据采集的目的是什么,明白收集数据的目的是做报表统计,是做数据分析还是做机器学习,再基于业务梳理出需要采集数据矩阵是何种形态。只有先明确目标,才能正式开始设计埋点文档。

问题二:产品团队设计的需求埋点混乱,导致出现错埋、漏埋、多埋等的情况

基于业务目标梳理出数据埋点文档,定制好规范和流程笔者上面说的数据采集的四要素可以入药,在此不多做赘述。

问题三:技术团队不知道通过什么技术手段去采集数据“更好”

好与坏是相对的,没有绝对。无论是采用后端埋点还是前端埋点,都会出现丢包的情况,只能说团队可接受度的范围是多少,心理的阈值是多少,只有先确保埋点数据的完整性、一致性、及时性、准确性等因素,基于业务目的去分析、去平衡要获取什么样的数据,采用什么样的方式去做采集。

另外,有时候不是埋点多就好,这是一个矛盾点。在大数据时代,大数据中的大的对立面就是少,越是真实的业务数据,数据量就越大,可用的信息比例就越少,更多的是噪音数据,如果拟合了噪音数据,那就被数据绑架了。

所以,通过什么技术手段去采集数据“更好”本身就是一个伪命题只有适合业务目标的采集技术才是相对较好的。同样情况下,无论是产品或者是使用数据的相关人员去做数据分析与挖掘的时候,不要只看数据,更多地从业务本身去思考一下;要活用数据,不要被数据绑架。

问题四:技术团队在数据采集阶段,当做增量同步的时候,遇到可修改、可删除的数据源,如何处理

当在无法确定数据源的情况下,通常会采用:放弃同步,采用直接连接的方式;放弃增量同步,选用全量同步;编写一个定时跑的Job程序,扫描数据源以获得Delta Data,然后对Delta Data进行增量同步三种方式来做数据同步。

但是这三种选择方式其实都算不上最优的选择。如果当数据源的源头可以控制,可以采用监听数据源的变更,然后通过定时跑的Job程序来更新采集的数据,同步存储在数据库中,又有会牵涉到数据存储的选型。

为了更高效地提升数据采集的质量,一般会将整个采集流程切分成多个阶段,在细分的阶段中可以采用多种并行的方式执行。在这个过程中,会涉及到Job的创建、编写、提交与分发,采集流程的规划,数据格式的转换与传输以及数据丢包的容错处理等。

问题五:技术团队,数据采集回来要如何进行合理的存储

根据数据采集获取的日志的时间属性进行合理的存储。通常做法把日志按照日期分区,存储日志在HDFS 中,目的是为了后续抽取方便快速。在存储时,按照前面介绍的数据模型分库分表进行存储,方便后续做数据分析与数据挖掘时准备数据

问题六:产品团队和技术团队需要如何配合

如何在博弈中找到平衡点,达到双赢?数据的事情无论是采用自上而下或者自下而上去的方式都可以,当然老板直推的话会好很多,如果平行部门去做数据推动的事情,就会遇到各种不可控的情况。自上而下和自下而上策略的最关键区别在于,前者是一种分解策略而后者是一种合成策略。前者从一般性的问题出发,发问题分解成可控的部分;后者从可控的部分出发,去构造一个通用的方案。

Tips(仅供参考)

在认知上,运用大数据小场景的方式,改变数据相关人员原有的思维模式,知道数据的重要性,重视数据,把数据的优先级提升,改变拍脑袋做决策逐步走向以数据驱动做决策的思维转变;

在沟通上,理性分析问题,把握问题核心痛点,明确跨部门沟通的痛点,先解决主要矛盾,降低双方理解沟通的成本;

从资源上,盘点资源后在合理的时间内安排好双方工作的范围和职责边界。

03数据获取之数据传输

到底什么是数据传输?按照维基百科的定义:指的是依照适当的规程,经过一条或多条链路,在数据源和数据宿之间传送数据的过程。也表示借助信道上的信号将数据从一处送往另一处的操作。

原始数据采集之后必须将其传送到临时存储数据的基础中心等待下一步处理。数据传输过程可以分为两个阶段,IP骨干网传输和数据中心传输。

【数据预处理之数据传输图】  
【数据传输服务图】

数据传输的过程当中,在保证系统的高可用性与数据源动态适配能力的前提下,系统还需要具备数据同步、高性能传输、可视化操作、任务设置简单、故障自动恢复五大能力

保证系统高可用性:在数据传输服务内部的过程当中,保证每个模块都具有主备架构,保证系统高可用性。在容灾系统中对每个节点的健康状况实时监测,当监测到某个节点发生异常情况的时候,会将链路进行秒级切换到其他节点上去

数据源地址具有动态适配的能力:对于数据订阅MQ和数据同步链路,容灾系统对数据源的连接地址切换进行实时监测,当监测到数据源的连接地址发生变更,就会动态适配数据源生产新的连接方式,保证当数据源在发生变更的情况下,数据同步链路的稳定性

【数据传输的五大特性图】


04数据获取之数据预处理

在工程实践当中,获取到的数据会存在有缺失值、重复值等,在使用之前需要进行数据预处理。数据预处理其实没有统一标准的流程,视情况而定对不同的任务和数据集属性采用不同的处理策略。数据预处理的一般步骤为:数据集成 → 数据清洗 → 数据规约 → 数据转换 

1、数据集成

数据集成是一个数据整合的过程,通过汇集各种类型的数据源,将拥有不同结构、不同属性的数据进行归纳整合在一起

【数据集成图】

2、数据清洗

数据清洗目的为了解决数据质量问题,让数据更适合做数据分析与挖掘

【数据清洗图】

3、数据规约

数据集成与数据清洗后,数据集的规模是无法改变的,所以需要通过做数据规约来减少数据分析与挖掘所需的数据集规模

【数据规约图】

4、数据转换

数据转换需要通过标准化、离散化与分层化让数据变得更加透明、更加一致,更加容易被模型所理解

【数据转换图】

总结

数据中台的建设离不开数据,在数据获取之前需要先要盘点出企业所有的数据,梳理清楚企业自身的数据情况,制定好流程与规范再设计数据获取方案。数据是数据中台的粮食,因为获取不到数据就没有任何数据场景化应用的落地,发挥不出企业数据的价值,所以说数据获取是一个非常重要的工作。

另外,还介绍了数据埋点的方法、数据采集的架构图以及在工程落地中会遇到的问题,更多是想和你一起来探讨做数据获取时运用到的思维模式,而不是直接给你数据埋点文档、数据清洗方案等

数据获取是一个持续进行的过程,希望大家在数据获取的过程中更多的从业务的角度去思考问题,平衡好短期利益和长期利益的关系。毕竟企业建立数据中台,是一种让数据持续赋能业务的机制它不是一个产品,是一个战略和体系,以数据驱动业务发展为主,让『一切业务数据化,一切数据业务化』

最后,希望企业能够在认知上,建立数据人员正确的数据价值观,对数据要怀有敬畏之心,在保证数据的安全和隐私的前提下,合理的存储,不要企图利用数据去作恶;在使用上,更多的基于业务本身去思考问题活用数据,不要被数据绑架

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,772评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,458评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,610评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,640评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,657评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,590评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,962评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,631评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,870评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,611评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,704评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,386评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,969评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,944评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,179评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,742评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,440评论 2 342