分贝通SAAS企业大数据体系建设经验分享

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

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

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

●        公司介绍

●        大数据建设背景

●        大数据建设方案

●        大数据应用场景

 公司介绍

先简单介绍一下分贝通。

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

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

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

大数据建设背景

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

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

   对于一个ToB公司来说，基本上可以把客户旅程分为六个阶段：认知、教育、选择、支付、使用、增购。这是我们基于硅谷蓝图的SaaS获客模型优化后的划分，对整个国内ToB行业也有参考意义。认知：当我们想谈一个客户，首先要让客户了解分贝通。我们通过广告或者电销团队去做一个初步的接触，这个叫做认知。教育：当有一定需求，客户想起分贝通这个公司，会联系你做深度的交流和拜访，这时是深度教育的阶段，让客户了解我们能够解决他的什么问题。选择：通过多家的对比选择了分贝通。使用：交付使用。增购：发现有一些其他功能还不错增加购买，或者到了使用年限后继续购买。

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

  业务部门对数据的需求是非常强烈的。其中一个场景是客户签约，客户购买了很多应用场景的模块，有些模块用得很好，有些模块用得很差，客户成功团队希望知道哪些应用场景重点在用，哪些开通了也不用，还有哪些用户在流失等等，这些都是对数据的需求。

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

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

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

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

大数据建设方案

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

其中一些实践方面的细节和总结值得分享。比如数据分析，对于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等进行数据的处理、特征的处理。模型的训练阶段先做一个模型的转化，离线的模型转化成实时的模型，然后进行训练评估，最后挂到线上去训练和替换，这里跟刚才的离线是不太一样的。

ToB企业与ToC企业的技术选型区别

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

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

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

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

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

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