在大数据时代，更为核心的不是如何采集数据，而是应该聚焦在“数据应用”上，数据产品的根源应该是业务。本文作者根据自身的经验，对数据时代面临的困境和突破口做了分析总结，一起来看一下吧。
停更很久了，近期临近年度大考双十一，忙碌之前突发奇想对自己也对整个部门一路走过的经历做个总结。换句话说对我们2022年做个年度总结，也希望分享一些实际业务历程中遇到的问题场景，及面对问题该如何思考，如何落地，如何做效果评估等。
文章开始前再补充下背景，笔者所在的公司所处互联网行业，性质为toB，产品面向企业服务，首先感谢您的阅读，让我们开始吧。
一、面临的处境笔者目前所处的部门成立于2020年，部门定位是基础数据服务部门，所谓基础数据服务也就是职能属性，例如销售部门所属直接产能部门。对于我们当初搭建时的初衷则和大多数数据产品成立的愿景一样：“用数据赋能业务”，只有真正从事数据服务相关工作的同学才能明白这短短7个字的含义。
DT时代以来，大数据杀熟，数据冗余，海量的数据已经让使用者应接不暇。拥有数据从来不是可以使用好数据的理由，只是基础，当然我不是指数据采集不重要，只是在大数据时代我理解更为核心的并不是如何采集数据，目光更应该聚焦在“数据应用”，再庞大的数据中台，数据产品的根源也应该是业务，抛开业务数据只是DB中的一行明细，它并不能为公司，为业务带来增益。
整个公司的业务涉及到面对上下游的海量企业商家，同时也面临着商家所使用的第三方平台，如上游平台：阿里，字节，拼多多等；如下游物流：顺丰、京东、三通一达等。我们需要为商家提供资源管理能力，这部分资源包含但不限于交易数据、成本数据、进销存数据等，这时首单其中的问题则是系统打通，单从国内市场来看需要接入的平台数量超过100，物流服务商也有大几十，总结下来就是我们需要承担数据的“进出口”，“进出口”进行业务拆解可以分为以下。
1. 数据定义根据业务定义所需的数据源为哪些，如电商平台交易单、物流承运商快递单、商品成本数据。
2. 数据采集
- 根据数据渠道定义属性，如交易类、商品类、成本类、库存类。
- 根据属性定义数据指标如交易单量、发货量、上行成功率、业务渗透率。
明确数据源后如何获取，如开放式API，私有数据交互协议等。
3. 数据转换数据源的多样性造就数据格式的复杂性、数据形态的多样性，需定义属于我们的标准数据结构。
4. 数据存储海量数据如何选择存储方式：
5. 数据分析
- 数据格式考虑：结构化数据 or 非结构化数据；行存储 or 列存储
- 性能考虑：批插，读写等性能指标（可以以业务容忍度定义,如响应需控制在50ms）
- 成本考虑：预估数据量大小，是否需要持久化存储，能否建立归档库，归档数据保留时间等
6. 数据应用
- 根据多维度定义分析模型，定义算法对数据做加工解析，得到可产生业务价值的指导数据
- 根据业务属性建立分析模型，可定时定量输出分析结果
- 稳定性，易用性分析等
用数据引导业务，反哺业务，诠释业务价值，协助业务做效果评估。
7. 数据治理
海量的数据需约定规范，建立数据血缘关系；打造可持续发展的生态，才能打下扎实基础，未来承载更多的业务量。
8. 数据开放可复用、易用的数据如何打造生态，对外赋能更多的商家，赋能更多业务域。
以上为职能的简易拆解，拆解思路基本为按人员划分（团队人员搭建的目标也是按以上节点进行组成）。说完了职能描述再来看下每种职能背后所面对的真实问题，结合实际场景才能让读者身临其境，通过冰冷的文字感觉到价值或思路。
1）数据定义
这一步骤分为两阶段，一阶段是团队搭建初期，数据需求则是企业需求，驱动力完全来源于使用者，企业需要什么数据我们就去接入什么数据，截止到2022年11月已接入了371家上游平台100余家下游服务商（快递公司、货代）为企业获取到他们分布在各个渠道的交易数据、商品数据、库存数据、价格数据、成交数据等等。
第二阶段则为本年度的状态，驱动力更多地倾向于团队自身、功能迭代、性能调优、存储降本、引入流式计算等存储&计算引擎来提高我们自身系统的健壮性、稳定性、及时性等。
关于所谓的数据定义还是比较好理解，背后隐晦的问题在于如何降低维护成本，做过接口开发的同学应该清楚维护接口的成本，特别是接入的外部系统数量增长到某个程度后接口参数发生微调，或字段语义的不确定性就会到自身业务造成不可逆的影响。
2）数据采集
采集面临的问题是渠道多样性，数据格式多样性等；渠道及格式多样性意味着需要固定人力长期维护，关注数据完整度，及时性等核心关键指标。
3）数据转换
ETL中比较复杂耗时的节点，初期人力有限的情况下接入一个渠道获取一个渠道的数据，再针对该渠道数据做相对应的转换，转换为所需的业务格式。
4）数据存储
相信每一家互联网公司的同学多少遇到过存储相关的问题（有可能在您公司当前阶段并未暴露出来）公司起步初期，数据量小、多样化少，不会遇到太大的写入读取压力。
在当前阶段保留固定的数据入口及出口反而更能提高效率（针对每一种接入数据做相对应的转换，向指定DB进行存储，向指定DB进行统一读取），相信这个阶段也并不会遇到成本压力，一开始我们便是采取这种方式，伴随市场发展及拓张，在20-21年面临数据量爆发式增长。
为了迎合市场产研部门按照不同的需求商家做了不同的数据源接入，多样性已经接近无法管理，多业务向DB进行的读写也面临着各种性能压力，保证读写时序又做了大批量加锁的行为导致各种表死锁情况，年度成本数千万。
5）数据分析
缺少分析经验，面对格式不一的数据更是无从下手，数据存储量高到惊人，可惜都是冷数据，长期以来并未让数据产生与之对应的价值。
6）数据应用
缺少了分析的过程也就无从得知应用，团队成本也并未养成“用数据说话”的习惯，更多业务决策更多的依赖人员的经验，也就是所谓的“闭门造车”。很频繁地听到各位同学脱口而出“我认为xxxx”“我认为客户应该xxxxx”，要善于用数据辅助我们做决策。
7）数据治理
多数互联网企业可能并未经历过数据治理的过程，没有体会过数据治理所带来的价值，也并未理解为什么要投入大量的人力财力去做数据治理。“治理”顾名思义是一种通过某种途径做调节的机制，日常作业中可能会出现各种“数据不知道往哪里存”“数据不知道从哪里取”“这份数据谁在用”“改动此数据的影响评估无法做”等等问题。
8）数据开放
这一步可能聊的比较不切实际了，多数公司基本数据内驱，在内部做循环，能使自身业务做增量已经是比较理想的情况。距离做生态、治理生态还有一些距离，在自身已产生价值的情况下可以考虑将数据包装后丰富自身的开放生态，赋能更多的协同或上下游，完善整个行业。
9）价值
这一步算补充条款了，上面并没有提及到，相信这一节也能引起很多朋友的共鸣，要知道基础数据服务部门应该都存在这个共性问题“如何做价值”无论是业务决策性产品或数据产品，难道我们只能被动接受来自业务部门的数据需求吗？
总是一味地听从别人的“你把xxx数据转换为xxxx输出给我”“我要xxxx 你需要清洗好提供给我”，数据的价值并非止步于此，在不冲突的情况下，我们有没有突破口去做出价值，或许在清洗数据提供给业务部门后我们也能提供到数据角度的效果评估？这份评估结果也可以表现为一种价值，一种左右业务方向的价值。
二、如何思考解决方案面临上述遇到的问题后，需要解决的问题也比较多，涉及到的业务域跨度比较广。人力有限的情况下没有办法齐头并进，只能对改造点做了列举，列出优先级和影响范围划定了整个部门Q1-Q4的目标。这些任务多为内驱，同时需要保持来自业务团队的需求任务，所以部门讨论后得到了60%外部需求40%自驱的节奏。
这里罗列下简易的拆解过程：
拆解过程简单分为五步
简单概述为痛点，或者可以理解为核心目标，比较迫切在中短期内解决或完善的内容（居多的围绕部门职能及核心价值），如我们属于数据基础部门，因而指标多为数据相关。比较典型的就是数据几个特性：稳定性、及时性、完整性、易用性、成本。
1. 稳定性这里描述的是集群稳定性，规模庞大的商家群体意味着会存在规模庞大的数据链路，为了减免宕机等稳定因素对业务产生不可逆的影响，也是业务的基石。
集群分布也可以拆解为web集群（B/S架构的网页）和任务集群（Job调度集群），在云资源逐步增加的基础上对集群做一定的“资源瘦身”。web集群比较好理解主要是监控高并发的请求，及一些核心业务操作的稳定性（如订单操作，报表操作多为DB增删改查操作），加入监控体系。这也是我们搭建的第一组监控系统，凌驾于整个部门所涉及的全业务之上，这里想到了监控系统设计的几个核心：
- 报警的触达应当是紧急的、重要的、可执行的、真实的。
- 规则应当表示为服务处于过程中或者即将发生的问题。
- 为了保持报警项的精确、有效，宁可过度移除报警噪音，因为过度监控比监控不足更难解决。
- 你应该总是能够将问题分为以下几种：基本功能的可用性问题；延迟；正确性（数据的完整性、新鲜性和持久性）；以及特定功能问题。
- 规则描述症狀是更好的方法，可以更轻松、更全面、更可靠地捕获更多的问题。
- 在基于症状的页面或仪表板中包含基于原因的信息，但要避免直接针对原因发出警报。
- 报警越往上层的服务走，在一个报警规则中可以抓住的明显问题就越多。但不要走得太远，无法充分区分发生了什么。
- 如果你想在值班时，报警系统保持安静, 那么需要有一套系统和标准化的流程能够自动处理那些需要被尽快处理的事情，但不至于让你半夜三点钟爬起来上线的情况。
这里简单说下监控系统搭建的心路历程。预警的目的不是为了预警，所以预警内容必须具备紧急且可执行的特性，这个指标很重要，很多监控系统的设计从最初就开始拆解各个业务指标，往往几十个指标，报警一大堆，处理人员没有头绪无从下手。
宁可过渡移除报警噪音这一点也需多多关注，报警并不是越多越好，也并不一定是越细越好，将最重要的内容在合适的时间报向正确的人才是合理的；报警规则尽量贴近业务，脱离现实的报警只会让你增加无尽的烦恼。
最后一条相信搭建过监控系统的同学都感同身受（报警滴滴响，时间长了人员也开始疲劳，疏忽落实报警内容）这时就引出了配套能力之一：值守系统，何谓值守（自动化值班）可以抽出统一的数据交互错误格式，也就是标准异常码，参与过接口开发的同学应该比较清楚一个接口的响应信息一般都存在两层（code，msg）msg即消息主体，code即描述码；
如code = 200即成功 code = 500001 即业务错误，再进行细分的话可以做到二级code，如code = 500001 & sub_code = 9999 等于系统宕机，需要调度系统重试，这就是抽象出code映射关系后就可以建立自动化值守系统，根据code定义的决策结果进行自动化不间歇的”值班”从一定程度上释放了产研人员的压力。
此处可以深挖的细节还有很多，例如可以根据code搭配AI机器人，从移动端接收产研人员的操作指令，完成权限分配、OA流程审批、资源购置等。亦或者根据预设code完成线程分配，调整任务集群步频、步长、步幅等动作。
有了监控 值守后当然少不了预警系统，也就是所谓的消息分发系统，经过值守系统自动化处置后依然有一些关键性异常是系统无法自动消化的，需要人为介入，那这时需要用到分发系统。
可以与多种消息渠道打通，如企业微信、钉钉、飞书、短信，更甚至可以电话，可根据预警等级推送至可执行的人员或组里（需提前按照职责划分对应的接收组或接收人）预警通知需要建立固定的处理流程，个别高优异常需建立驻留时间达到xx时问题上升，让更多更专业的同学参与进来协助处理。
2. 及时性做数据基础服务避免不了的就是降低数据交互耗时，内外部系统交互的RT值，需要把整体数据链路的耗时降下来。那么在调度资源不变的情况下需要如何做到，思路也比较明确，“让资源在合适的时间用到合适的地方”服务器资源会存在高负载及低负载的时间段，如高频计算的白天，多条数据链路需公用资源，那我们可以将资源量化后区分业务或商家的优先级，将更多的资源分配至更高优的业务链路。
在凌晨负载降下来以后可以去执行一些海量数据的离线计算服务，如日报、归档、大规模业务数据重算等操作，可以在这些时间点做一些兜底的业务策略，一些数据稽核的过程可以放置于此，一方面资源没有浪费，一方面也可以提升整体链路的健壮性，另一方面提高响应。
降低耗时的另一个思路就是“瘦身”，这个瘦身不止在资源上，对业务也一样，一些涉及到与存储介质交互的业务，例如对数据库的读写操作，是否可以支持批量，是否会出现表锁行锁等情况，业务代码是否会出现大量的逐条循环逐条更新的操作等等；扣业务细节，通过各种细节做持续的优化以达到一个良性循环。
3. 完整性这一步的背景是这样的，在存在大量的数据入口时，很多数据来自于上下游系统、服务商。数据口径不同不易维护，外部数据字典发生变更会影响到我们自身业务，如反序列化等步骤，这时为了保证业务可以获得完整且结构明确的数据，我们可以封装统一的数据模型校验能力，根据我们抽象出的业务模型（符合业务预期的）对实时数据做校验。
如果担心对性能有压力可以选择性将一些比对工作做成异步操作，保证主链路顺畅的同时如果比对出一些边角数据可以通过第二步的预警体系完成回流，人工介入去确认情况，更及时有效的感知数据变更，从而降低对业务系统的影响。
4. 易用性这一步更多的需要用到工程思维，在业务沉淀的过程中更多的考虑如何抽象，如何封装统一方法、接口让内外部的协同更好更高效地使用数据。现在微服务的概念越来越普及，很多模块化、碎片化、服务化的系统更利于后期的业务拓展、业务重构。
通过封装统一数据接口的方式降低数据的使用门槛，通过抽象模块，服务的设计使得系统得到高可用的后期空间。在此基础上，业务系统需要使用数据时，可以更多地把目光放在赋能业务上而不需要过多考虑数据使用问题。
在此基础上建立数据治理系统，对数据血缘关系做完整链路记载，便于后续我们做追溯，更多的服务化也使得业务耦合度降低，降低迭代所带来的影响范围及灰度成本。
5. 成本最后这一段有关成本，归根到底降本增效这条路是需要持续走下去。特别是互联网行业，除去人力这一最昂贵的成本之外，资源成本也让人头痛，各种技术栈所带来的成本数不胜数。
存储成本如服务器资源成本，DB、数仓的存储成本，中间件及计算引擎所带来的计算成本等都是大头，对于这个问题，我们初步的方案是在调度分配的策略优化基础上，对底层存储结构做了调整，即分库分表规则，将数据&资源流量合理的分配后可以压缩出更多的使用空间，将低负载的集群都合理分配到更多的业务，减少集群闲置的频率。
当然机器的使用空间不单单只是我们自身的业务，在亚马逊云初期的时候就是因为自身庞大的集群闲置了很多资源，才想到对外租赁一部分云资源并提供一系列的云服务，这些高效的存储、算力都可以为一些中小企业提供很好的基础，半托管&全托管的服务也随之而来，总之合理利用现有资源来达成更多的业务目的就是关键。
说了这么多，也简单画了个草图，描述了下当前我们的一套系统架构图，内容不是很全面，不过也概括了目前基本的分布情况。
从上至下可分为一层接口层，采用API、导入、数据推送等技术手段完成对外部数据的采集。
二层为模型转换层，数据格式校验、模型校验等皆在于此。
三层多为一些中间件服务，如消息队列、集中式&分布式缓存、流失数据计算引擎、即席查询报表等。
四层为业务层，按业务域做了拆分，如交易、商品、库存、财务等；按服务做了拆分，如交易服务：多为处理交易数据，对交易数据做清洗等，商品服务、发货服务等。伴随着业务则会有规则类服务进行辅助，完成更多业务的限制，如绑赠规则、风控策略等。规则服务之外会有业务系统权限管理，这里的权限类则做了抽象，是可以对业务层的上下游提供能力。
五层为基础数据存储层，如关系型数据库Mysql，非关系型数据库MongoDB、数据仓库等。
在1-5层的基础上提供了内部网关，多用于承载内部业务接口，做一些流控策略、风控策略、鉴权策略等，保障业务的稳定性及安全性。
在五层之外贯穿整体系统的有外部网关，即内部数据对外的网关，可通过外部开发者身份进驻在我们平台之内，完成一些自研系统的开发数据获取工作。
调度中心即自行搭建的基于主从关系（Master-Slave）的调度集群，掌管着系统内外部一些资源调度及分配。可结合后续的日志服务及监控中心完成一些健康度检测，心跳检测等自我健康策略，保证系统的核心足够的稳定。
监控中心及日志服务则满足绝大多数环节的可植入性，通过封装内部接口使得全业务域均可低成本完成日志写入，包括业务日志、用户操作日志、用户行为日志，更能使业务低成本地完成业务埋点，并指定分析策略完成后续的数据复盘，及提供迭代的数据支持。
三、效果评估及思路了解了以上众多问题后的解决思路后，我们来看一下效果评估部分，说了再说没有收益那也等于白干，在基于上述架构的系统上我们当前日处理交易单量近亿，每日产生的日志数据量达到EB级别。
对于之前经常遇到的机器高负载也有了明显的改善，超过95%以上的调度集群全天保持稳定水位。成本方面较为明显，在原有的近千台机器搭建的集群规模下完成了近80%的瘦身，成本方面每年节省的费用可达数百万。最后对于现有的服务化设计使得我们产研成本极具降低，有利于我们做快速的版本迭代，及时感知市场的变化。
也提供一些数据价值的思路，如车品觉老师的5类数据价值：
1）识别和串联价值
- 账号和cookie-通过账号，全站啡一锁定同一个用户
- 手机号、身份证号、银行卡，邮箱等-可以把PC/手机/PAD等设备串联
- 设备号-可以把设备上不同的APP串联起来
2）描述价值
①企业
②用户
③商品或服务
3）时间价值
①历史分析
- 通过对用户历史的行为分析，可以得到用户在场景下的偏好
- 有了历史数据，数据挖掘和机器学习才有可能
②即时分析
4）预测价值
①用户预测
②单品预测
5）产出数据的价值
①电商店铺的评分系统
好评数、好评率、描述相符、物流速度等。
②金融的征信评分模型
四、结尾聊到最后也很想抛出一个共识问题，做基础数据服务的价值上限在哪里？坦白说做了这么几年也并没有找到明确的答案，但是实践证明，我们做好自身的数据规范并持续向业务输出价值并不是终点。
随着DT时代的到来，越来越多成熟的技术栈、数据产品出现，ETL不再是麻烦的事，我们都会面临“数据爆炸”的现实，云计算、元宇宙、人工智能等领域的不断扩张也给我们带来了很多挑战，当前这个时代每年的数据量增长超过50%，麦肯锡曾提出一句话：
数据已渗透到今天的每个行业和业务功能领域，并已成为重要的生产要素。随着新一轮的生产力增长和消费者盈余浪潮的到来，海量数据的挖掘和使用预示着 “大数据”已经存在于物理学、生物学、环境生态学等领域以及军事、金融、通信等行业，但是由于近年来互联网的发展，信息产业的发展才引起了人们的关注。
让我们抛开所谓的大数据杀熟，大数据已是未来等名词着手看眼前，数据已不再匮乏，在多数互联网行业的技术永远也不会成为业务壁垒，越来越多即开即用的技术产品可以为我们所用，数据分析模型早已随处可见，我们可以很低成本且高效地获取到我们想要的数据。
那么问题来了，价值何在？有数据不代表会用，会用不代表用得好，用得好不代表可以用的出众！希望大家可以共勉，抛开充斥在生活中的一些低效内容，找到最适合自己业务的分析方式和数据，去获得预期的结果及找到自身的“壁垒”才是核心。
增长也很难是一朝一夕可以改变的，现象级产品的确在现阶段饱和式的用户心智中很难诞生，也希望大家能在自己的岗位上发光发热，热爱这个行业，拿到自己想要的结果。
本文由 @清醒 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
,
