吴荣彬:分贝通大数据体系建设经验分享

吴荣彬:分贝通大数据体系建设经验分享

分享嘉宾:吴荣彬 分贝通 大数据部负责人

编辑整理:zlx

出品平台:DataFunTalk

导读:本文将介绍分贝通在大数据领域的一些建设经验。分贝通在ToB领域是一个年轻的公司,成立六年多,大数据体系刚刚建立一年多,整个团队不到二十人,整体的大数据建设处于初级和摸索的阶段。本次将总结在大数据业务上的实践和思考,希望给大家带来启发。

主要内容包括以下几方面:

  • 公司介绍

  • 大数据建设背景

  • 大数据建设方案

  • 大数据应用场景

01

公司介绍

先简单介绍一下分贝通。

我们平常公司中可能会遇到这种场景,比如出差时通过公司OA或邮件进行审批,然后去订机票、火车票、酒店等,到了目的地之后很多费用还要自己垫付,回来再通过发票报销,发票数量多且金额大,时间耗费多;同时对公司而言,因为要对接很多外部平台,对企业和员工而言都是非常麻烦的。

吴荣彬:分贝通大数据体系建设经验分享

分贝通致力于解决企业这方面的痛点,除了差旅这部分大的支出,我们也希望在所有的支出管理场景提供整体解决方案,实现企业在预算、审批、交易、报销的全流程闭环。对员工而言,所有支出都在一个平台,可以不用垫资和发票,使用非常便捷。对企业而言,可以做到事前预算管理,事中费用控制,事后自动报销,极大地减轻了财务和行政的工作量。

前提是分贝通需要提前去对接不同的供应商,比如酒店供应商、用车供应商等。在某些场景,分贝通还在建立自己的供应商体系,包括自营的酒店、自营的商城。经过六年多的发展,该模式得到了投资人和市场的认可,现在服务于数千家客户,业务增长迅速,融资的规模也比较可观,目前在企业服务领域算是独角兽的存在。

02

大数据建设背景

我们公司的大数据部门去年才成立,之前整个公司数据底层建设比较匮乏,所有数据都是通过业务研发团队去支撑,业务研发除了很多自己的产品功能迭代以外,还要排期去做数据支持。整体体验较差,一个业务上线需要一到两个月。这可能是所有ToB公司必经的一个阶段,ToB公司一开始的数据量可能不是特别大,不像ToC公司一开始就有自己的大数据团队,随着ToB公司的发展,数据量变大后,对大数据团队建设的需求是非常迫切的。

吴荣彬:分贝通大数据体系建设经验分享

这是我们去年业务部门的需求,可以看到整个团队在底层数据方面的需求处于井喷的状态,未来可能有更多更细的需求。

对于一个ToB公司来说,基本上可以把客户旅程分为六个阶段:认知、教育、选择、支付、使用、增购这是我们基于硅谷蓝图的SaaS获客模型优化后的划分,对整个国内ToB行业也有参考意义。

  • 认知当我们想谈一个客户,首先要让客户了解分贝通。我们通过广告或者电销团队去做一个初步的接触,这个叫做认知。

  • 教育:当有一定需求,客户想起分贝通这个公司,会联系你做深度的交流和拜访,这时是深度教育的阶段,让客户了解我们能够解决他的什么问题。

  • 选择:通过多家的对比选择了分贝通。

  • 使用:交付使用。

  • 增购:发现有一些其他功能还不错增加购买,或者到了使用年限后继续购买。

分贝通整体可以归为三类部门,第一是业务部门,包括销售、渠道、市场、客户成功等;第二是运产部门,即运营+产品的业务研发部门,包括商城、商旅、费控、支付;第三是职能部门,包括产研、人力、财务。这三大部门对数据的需求不太一样,对各个阶段的需求也会有区别。

业务部门对数据的需求非常强烈。在建立大数据团队之前,销售去挖目标线索的时候是非常散没有体系的,大数据能够提供市场上潜在客户的信息,并刻画出哪些客户的购买意愿更高,这样就能更好的进行营销。另一个场景是客户签约,客户购买了很多应用场景的模块,有些模块用得很好,有些模块用得很差,客户成功团队希望知道哪些应用场景重点在用,哪些开通了也不用,还有哪些用户在流失等,这些都是对数据的需求。

运产部门对数据的核心要求在整个业务过程中存在卡点,希望我们通过数据去告诉它。

对于职能部门,产研关心的是产品上线后是否有人在用,用的怎样,是否能做ABtest。人力关心的是现在的员工关注的点是哪些,是薪酬还是福利。财务关注的是现在的财务报表,数据的准确性如何,跟流水是否对得上,需要很明确的被告知,以上这些都是公司对数据的需求,各种各样且非常强烈。        

吴荣彬:分贝通大数据体系建设经验分享

基于以上业务背景,我们需要选择合适的技术来满足业务的需求,从业务和技术两个角度来考虑。首先,从业务方面考虑,当时团队刚刚组建,人手比较匮乏,创业公司对人才的吸引力有限,因此我们的架构的应用成本要特别低,功能尽量简单,这样才能更多地进行业务思考和数据赋能。同时,由于业务已经发展到一定阶段了,对数据的需求已经比较迫切了,因此我们要快速的拿到结果。另外,从技术上考虑,原有技术数据已经上云,因此我们必须选择云端的解决方案,这样有利于数据的传输。同时,我们有很多的数据来源表,但是数据量还比较小,数据量在TB规模,对实时的要求没有那么高。

在不考虑自建IDC的前提下,当时摆在我们面前有三个选择:

第一个是比较成熟的云端的组建,阿里的MaxCompute+Hologres+实时计算Flink版+大数据开发治理平台DataWork,第二个是云上开源的组建EMR,第三个是什么都不用,在云上自建Hadoop集群。这三个方案各有优缺点,第一个方案的好处是应用成本嫁接给阿里云,但应用成本较高。第二个方案是比较折中的方案,有一定的灵活性,但是在运维上也需要一定的专业性。第三个方案需要招聘非常专业的应用团队来组建自己的Hadoop集群,这在当时来看不太可行。

最后综合来看,我们选择了方案一。

03

大数据建设方案

吴荣彬:分贝通大数据体系建设经验分享

技术架构选型结束后,我们开始从内部梳理大数据建设的整体体系,逐步进行大数据建设。与大多数大数据体系架构类似,底层是多源数据连接,往上做数据清洗,再往上进行离线和实时的数据存储与计算,到数据仓库的建设,再到上面的应用层的建设,左边是组织流程规范的一些保障。

其中一些实践方面的细节和总结值得分享。比如数据分析,对于ToB的公司来说是很大的一个模块,这里的数据分析是指对外的数据分析,希望对现有的数据进行深入的分析。在组织架构上我们将数仓和数据分析分成两个团队,数仓团队负责整个ODS和DWD层的建设,数据分析团队负责上层的DWS层和ADS层的建设,这是横向的切分。这样做的好处是,数仓团队可以更好地关注底层数据的质量,需要更多地跟研发打交道,数据分析团队只需要对数据分析负责,而数据分析师可以更加关注整个数据的应用和业务的应用。这两个团队有着完全不一样的技能,而且可以互相监督。除此之外,实时和离线不分开的好处是对于大家的技术发展而言,技术栈比较完整。

在流程和规范方面,我们当时面临的挑战是内部的业务线特别多,有十几个业务线,不仅多,并且复杂,比如用车业务线,与滴滴的业务线相似。每个业务线的表很多,每个业务之间又是独立开发的,规范需要统一,数据质量也有很大差异,是非常棘手的问题。但是同时我们也有先发优势——从零开始建设,所以我们当时确定一个原则,一定要边建设边治理而不是先建设后治理。我们摸索出了一套从业务需求到开发到上线的标准的动作,也就是所谓的SOP。比如将每周二、每周四作为固定的评审时间,评审的内容都是按照自己的内容自己的模板准备好,每次评审都有记录,上线的时候根据评审记录来看它是否完成是否需要修改,保证流程规范治理好。

一件事情做到60分很简单,比如数仓的建立比较简单,但是要做到极致,真正做出一个90分的好数仓其实是一件很难的事情。

吴荣彬:分贝通大数据体系建设经验分享

有了对于大数据整体体系的流程与思路以后,落地就需要工具的支持,下面介绍一下数据建模的工具。

现在我们用的是阿里云的DataWorks智能数据建模,我们去年底参加了他们的公测,今年开始正式使用。DataWorks智能数据建模最大的好处是,我们会把整个数仓的规划和最终模型的产出做一个强关联,模型可以直接生成物理表,发布成功后也可以直接生成简单的ETL代码。之前我们在应用开发环境之前用SQL去建模,结果大家之间的标准不统一,就是一个人治的过程。有了DataWorks以后我们就变成了法治,通过工具实现了对整个数据的强治理,与原来相比,我们建模的便利性可能会差一些,比如想建一个数据汇总表,首先要建一个原始指标才能建立派生指标,然后搭建表模型,再关联数据标准,这个流程相对而言会变长,刚开始的时候大家会不太习惯。虽然单个点的流程变长,但是整体效率提升了,数仓团队都非常接受这种规范。对数据仓库的长期建设而言,一些标准与规范的事前投入是非常有必要的,往往可以起到事半功倍的效果。

吴荣彬:分贝通大数据体系建设经验分享

上图是数仓整体架构。

在技术架构方面,现在仍然是非常典型的一个lambda架构,离线与实时是分开的,结果在Hologres做了一层汇聚,有用到一些辅助的数据库如MySQL和ES来存储业务和标签的数据。这里有一些基于我们业务场景的使用建议,数据应用链Hologres与MaxCompute有离线实时一体化的能力,Hologres存在两种表存储的方法,一个是数据不导出,直接加载MaxCompute表作为外表,一个是数据导入Hologres成为内表。我们BI报表的业务场景是对外的,对我们来说是非常重要的,数据的稳定性是需要首要保证的,所以我们更多地采用Hologres内表方式去访问ODS的数据而不是外表方式,这样做的好处是一旦不小心将表的结果变更,如果是外表,BI工具只有在客户访问的时候才暴露出这种问题,但是采用内表的方式在推数的时候就会发现问题,就可以避免线下稳定性的问题。另外,我们每天都需要数据更新,我们不是每天都更新整个Hologres里面的表数据,因为这样效率会比较低,可能引起服务中断。我们的方案是建立一个临时的外表,生成临时的内表去替代线上表,这样速度是非常快的,因为整个Hologres做了线路的优化,效率非常高,直接去替代线上表,这样对线上几乎没有影响。

吴荣彬:分贝通大数据体系建设经验分享

再来介绍一下算法方面的经验。

先说一下Batch Mode的离线模型,我们目前使用的是阿里云的机器学习PAI来满足日常的建模场景,这个图是非常典型的数据流过程。首先样本经过实景化到ODS上面,在MaxCompute上进行清洗和加工,最后也会实景化到一些表,在模型训练阶段去开发、训练整个模型,训练完后有两种选择,一是不需要线上部署,只需要做一些离线的大表预测,可以通过Designer去做一些数据的部署数据湖到整个ODS的table里。第二是如果想做模型的线上服务,同样可以把模型输入到OSS层上面,通过EAS组件进行服务,这个是我们现在用的比较多的离线模型的数据流程。

吴荣彬:分贝通大数据体系建设经验分享

接下来是实时模型的流程,比如推荐等模型场景,对模型的实时性要求比较高。有一些比较通用的组件,比如Flink、kafka等进行数据的处理、特征的处理。模型的训练阶段先做一个模型的转化,离线的模型转化成实时的模型,然后进行训练评估,最后挂到线上去训练和替换,这里跟刚才的离线是不太一样的。

04

大数据应用场景

随着大数据平台的搭建,大数据在整个公司中逐渐开始驱动业务创新,这里选取了两个特别好的数据创新的例子。

吴荣彬:分贝通大数据体系建设经验分享

第一个是很多人了解的CDP(customer data platform,中文称客户数据平台),这个平台的重要性体现在它是整个公司的大脑,有了它以后可以指导很多业务的活动和创新。

在分贝通我们有一些公开的公域数据,以及一些私域的线上和线下处理的数据,通常这些数据会以数据孤岛的形式存在,格式完全不一样,使用起来非常不方便,我们每次统计市场部一次活动的效果都非常麻烦,因为会在不同的渠道投放,最后要求指标的汇总。

第一步就是要把所有数据放在数仓里做清洗与构建,去构建我们的CDP,从这个逻辑上我们把它分为了四个层次。统一ID的建设非常关键,一旦ID合并错了那上面所有的信息基本上都是错误的。

有了统一的ID后(有统一的客户标识ToB、统一的用户标识ToC),就可以得到客户的基本信息,我们可以把客户的相关信息都汇总在一起。客户信息可以分为三类,第一类是静态信息,比如客户名称、所属的行业类型、性别等;第二类是半动态信息,比如企业融资的状态,相对来说变化没那么快,或者用户的喜好等;第三类是用户的行为信息,比如用户的浏览等。

信息层上面为标签层,标签层可以分为三类:基础、规则、挖掘。基础标签比较简单,不需要过多的逻辑就可以得到,比如用户的性别。规则标签需要一些统计规则去汇总出来,比如该用户是否富有。挖掘标签则需要一些算法,包括深度学习的算法去挖掘出来,最后根据标签产生簇群,再对簇群做一些运算和分析。

CDP是一个偏数据中台的平台,与业务松耦合。有了CDP,下游就是连接的各种业务平台,可以是智能化、精细化的营销或运营的平台,我们可以根据运营做广告的投放、互动、内容推荐等,可以很方便调用个体信息,再做个性化的工作,因此CDP是非常重要的。

吴荣彬:分贝通大数据体系建设经验分享

第二个场景是我们在做的CEM,客户体验管理,内部叫VOC(voice of customer)。CEM分为三个阶段,首先是收集客户的反馈,反馈渠道很多,包括客户的投诉、工单、CRM、CSM、交付群等,所有用户的数据都可以收集起来,与以前不一样的是很多非结构化的数据,包括语音文本,需要去做处理。第二阶段,有了这些数据之后,我们需要通过一些AI的手段,包括ASR、NLP等,对这些数据做分析,来判断公司的产品服务的哪些环节存在问题,问题的严重程度如何。第三阶段是有了量化的标准后我们会对每个环节进行评分,来衡量各部门各环节的表现,有了这些评分后我们可以为一线产品经理、客服人员、运营等提供自动化的分析工具、CTA等。

这与我们之前做产品很不一样,之前做产品的设计产品经理去抽样、调研客户的需求,很主观认为这些需求就是所有客户的需求,这是很典型的小数据时代的思维,以样本来代替全量的思维,CEM是典型的大数据时代的思维,跟大家比较熟悉的数据埋点一样,我们不需要知道他们的爽点在哪、痛点在哪,他们在埋点里面可能会告诉我们一些答案。CEM跟埋点不一样的地方在于搜集的范围更加广泛,埋点思维是一些结构化的数据,CEM包括非结构化的语言、文本,对技术的要求越来越高,它是AI时代的产品。目前分贝通按照这个流程去落地,但是需要人工投入的地方还有很多,我们希望有更多AI的手段去支持整个CEM的过程。

吴荣彬:分贝通大数据体系建设经验分享

分贝通是典型的ToB企业。ToB和ToC企业存在一些差异,可以从三个方面来了解。首先是用户群体,对于ToB来说,购买决策和使用性都是不一样的,买一个软件可能是财务的决策、KP的决策,但是员工在用。ToB企业的用户粘性更高,一般按年签约,公司已购买员工必须使用,同时对用户有很强的专业性要求,针对不同的企业、角色,整个系统的设计是完全不同的,甚至相同行业相同岗位的需求也是完全不同的。ToC的采购决策者是个人,用户不满意可以放弃使用,粘性相对较低,用户群体相对公众化,用户对软件的需求有非常多的共性。

在应用场景方面,ToB的场景非常丰富,我们做的只能解决客户在生产过程当中某一个环节的问题,无法覆盖它所有方面的问题,因为专业性太强,一个问题的处理流程往往会很长,ToB在国内还没有千亿美金的互联网公司。ToC比较简单,满足大家日常生活中的需求,例如吃、穿、住、行、玩,很容易在这一领域诞生千亿美金的独角兽互联网公司,这决定了这两个企业的企业规模。

在业务流程方面, ToB领域业务流程都很长,通常申请审批交易结算等,一次交易涉及到很多环节,但是ToC相对简单,例如网购下单仅需几秒钟,非常简单。

以上就是ToB和ToC企业的区别,也就决定了以下的技术特点:

ToB的数据量相对较小,在做数字化转型的时候,包括我们自己,数据量还是TB级别,处于中小规模,但是业务相对复杂,对数仓的建模能力要求较高,需要了解业务后才能更好地去建模。整个作业的处理时间会比较短,我们现在的作业基本在分钟级别,因此我们的容错恢复很快,对于技术框架的选型要求会低一些,选错了后面还有翻盘的机会。但对于ToC来说,基础架构完全不一样,一旦选错了或版本需要升级,代价会非常高昂,这是在做数仓这两种模型的区别。

吴荣彬:分贝通大数据体系建设经验分享

未来展望可以分为两个方面,一个是业务方面,希望可以识别公司更多的数字化转型场景,我们希望通过产品化和平台化更好地帮助公司去做业务化、智能化的事情;同时推进业务的BP机制,推动业务的紧密合作,数据中台也要深入到业务中去,去了解业务内在的东西而不是等着业务提需求。现在更多的是报表类的支撑,希望未来发展为报告、智能化产品的支撑。虽然分贝通是企业支付的场景,但更多的是差旅方面,差旅是很复杂的过程,比如说出一次差,要做很多的决策,我们希望探索更加智能的用户体验,降低决策成本。

在技术层面,随着技术和数据的不断积累,对实时的数据要求越来越高,我们在实时与HTAP这块,会做一些深度的探索。现在的业务比较流行湖仓一体化,之前没有这种需求,现在我们需要管理语音、文本等大量数据,需要去解决非结构化数据储存和管理。第三是批流一体化,我们使用的是lambda架构,应用比较精简但是存在开发和运维上成本的重复,我们希望在这些方面继续探索来统一整个数仓,真正实现存储和数仓统一的架构,减少额外的成本,这将是我们未来探索的几个方向。

今天的分享就到这里,谢谢大家。


在文末分享、点赞、在看,给个3连击呗~


01/分享嘉宾

吴荣彬:分贝通大数据体系建设经验分享

吴荣彬

分贝通大数据部负责人


硕士毕业于北京大学,有十年以上的大数据从业经验,曾在京东科技负责过大数据智能数据平台体系建设,目前在分贝通担任大数据部负责人,负责企业级数据中台建设。

0 0 投票数
文章评分

本文转载自吴荣彬 DataFunTalk ,原文链接:https://mp.weixin.qq.com/s/Ky-c2oqbOI_CwxHshxQd6w。

(1)
上一篇 2022-07-27 11:21
下一篇 2022-07-27 19:16

相关推荐

订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请您发表评论x