小公司往往数据量较小，几万用户可能都是一个比较成熟的产品了，在这种情况下还需要做大数据？
作为小团队的开发人员，小的表还没问题，大的表怎么优化也查不动，但是大数据？也太遥远了吧。

无论多与少，数据本质是公司的核心资产，和客户、市场或技术壁垒类似，良好使用的数据也是核心竞争力的一部分。用好了用户数据，电商公司可以有效的优化供应链，外卖和物流公司可以把调度效率优化到极致，广告公司按点击收费，可以推送非常精准的数据给潜在客户。如果这些数据只是放在数据库里作为记录，没有用起来，对于商业公司而言，是多大的浪费。

本文面向的对象是小公司的管理、开发、运营和产品。相比慢查询的优化，运营和产品更依赖数据进行决策，但是考虑到公司比较小，开发多数都忙于项目进度，这样的需求一般也就“等闲了再说”。

小公司也需要大数据？

没错，就那几万行的数据，查起来也不慢，但是如果有以下需求，2c8g的mysql（阿里云的最低配，小公司的常见配置）能支撑吗？

1. 用户生命周期lvt。简单来说就是获取某一天（或某一细分渠道）的注册用户在今后每一天的转化情况。通常还要进行不同周期（天或细分渠道）的对比。例如1月5日和6日的注册用户，在3月和4月的消费情况，或列出在3月每一天的消费情况。
2. 在上面消费的基础上再叠加点击或加购（电商常见场景），由注册-》购买的维度增加到注册-》点击-》加购-》购买甚至更多。
3. 在上面的基础上再计算所有渠道的用户在今天消费情况，按每分钟的滚动更新。

这是比较常见的lvt计算需求，是不是感觉2c8g的mysql有点力不从心了。通常而言每次查询会关联5-8张表一起查询，就算表只有几百行的情况下也会引起系统cpu飙升，影响线上业务，查询也不快。

大数据的成熟度模型

话说回来。对于小公司的多数业务来说，2c8g的mysql是够了的，如果不够先别考虑升级，先考虑缓存和查询是否合理，数据库架构是否合理，是否引入了代理和主从。
如果查询复杂度上升，就不能使用简单的tp类型数据库了。
在大数据体系中，对大数据的成熟度模型有以下几个等级：

1. 统计分析
   数据需求最先产生的部分就是统计，例如上个月销售额、日活等基础数据。
2. 决策支撑
   大方向上对各个业务线的财务指标、业务指标及战略总数据进行实时分析。
3. 数据驱动
   数据分析已经不能满足业务的需要，数据的量越来越大越来越精细，可以直接产生价值了。智能推荐和客服的应用提升了业务的能力，进一步提升了人效。
4. 运营优化阶段
   对数据的运营和优化，产生知识图谱，直接指导战略规划

小公司怎么做大数据

很简单：成立一支40人的大数据团队，再买几百台服务器。
概念讲起来比较苍白，看看真实的故事是怎样的。

1. 混沌
   一开始，我们最直观的数据就是订单。获取到订单信息，存放在关系型数据库中做分析。
   由于数据量不算非常大，我们使用普通mysql服务器进行数据存储，利用索引和分表来提高性能。
   由于数据比较单一，我们自建了内部的系统用于数据简单的分析和展示。这套系统使用了半年左右，从无到有搭建了数据体系，能满足当时基本的运营需求。
   当我们开始横向扩展数据类型的时候，出现了一些问题，总结起来大概有：

• 命名不统一
  其他的数据类型，对于同一字段可能有不同的描述，比如对于微博id，在一个表中描述为uid，在另一个表中，即使按照统一的标准，因为上下文变更了，可能描述为account。这个问题造成了一定程度的混乱。这是因为没有统一的规划造成的。
• 监控困难
  由于没有统一的集成监控环境，对数据的正确率也缺乏监控
• 数据冗余严重
  给每个业务部门做的需求，按照需求本身做成了独立的数据体系，彼此之间并没有打通，有的数据存了多份在不同位置，没有办法查找和统一使用。

半年后，最初的数据展示已经不能满足多样化数据运营的需求了，开始设计构建全功能的数据中台。
由于从数据中看到了价值，我们没有把数据中台作为一项支撑业务来做，从一开始就有详细的规划。在最初的规划中，我们总结了我们理想中的数据中台的几个特点：
数据中台是一项战略规划而非项目，必须在全公司以战略项目宣贯执行。最终要实现以业务价值为核心，能够支撑战略从规划到落地，能够覆盖整个战略周期。
这句话看起来非常的概念，但实际就是要把数据真正用起来。

1. 正式开始

调研：

• 业务分类
  公司的业务类型，简单来说就是收入来源的分类。
• 数据域定义
  每个业务类型会产生什么样的数据？例如销售和招商虽然都含有产品和订单，但是其实是完全不一样的概念。
• 总线架构
  选一个贯穿各业务类型的数据类型，作为总线。整个数据的定义就从这里开始

设计：

• 指标
  为了避免不同部门对同一个数据产生理解不一致的情况，需要重新定义数据指标。
  

• 维度表
  有些数据是唯一的，这是数据的基础，一团乱麻中的头。
  

• 事实表
  业务和事实表会发生多对多的关系，所以在设计的开始，就尽力避免这种状况。
  

因为团队比较小，就一个半后端在做这些事情，因此元数据这些都没有做。如果大家有条件，应该把元数据定义也做了。

1. 开发
   使用开源或托管的bi可以极大的降低成本。开源的有Apache Superset，各云厂商也有托管产品。
   不能再使用业务的mysql作为数据源了，大型查询会影响业务，另外bi自动生成出来的sql一般性能会更差。所以引入了mpp架构的实时计算列存数据库。在现在有很多选择，开源的有Apache Doris、tidb的tiflash（单表不要超过1亿）、clickhouse，托管的有阿里云的adb、holegress，腾讯云的tdsql-a等。
   架构层面采用中间件去订阅mysql的bin log同步数据到ap数据库中。按照之前设计好的事实表对原表做聚合做物化视图（有的引擎叫rollup）。
   有了mpp架构的这些ap引擎后，全都是t+0，全都是sql一把梭，简单粗暴。什么spark，什么hive，统统不要。（但sql会比较复杂）
   有了多维度报表后（而且是实时的哦），运营的效率得到了很大的提升。运营可以通过实时报表的进行产品追踪，如果某个产品销量突然出现大幅增加，就迅速跟进对该产品进行分析。
   因为之前的报表都是自定义开发的，开发周期比较长，对业务不能够及时进行支撑。使用了BI之后，会写sql的发布sql（甚至是有的产品），就可以在业务线上对运营进行有力支撑。数据需求的满足时间由过去的2-3天降低到2小时。

大盘

转化大盘，可以看到最早还是grafana做的

大家都改变了过去拍脑门的习惯，因为每个部门都知道了整体公司的情况及其他部门的数据，对自己内部的决策精准度增加了很多。

1. 提升
   除了更多更大型的报表以外，还有以下新的领域

• 推荐
  可以接入推荐算法了。
  有了ap引擎，我们每10秒刷新一次推荐缓存。仅仅推荐算法一项，落地页转化率从过去的13.5%上升到了41.9%，长尾效应非常明显。
• 精准营销
  可以精确计算每个客户的购买记录，通过dsp直接发布精准广告。例如3月1日买过洗衣液的用户，在5月1日会推荐打折洗衣液给他，这类推荐的成交概率最高达到了71%。
• 标签
  给产品和用户双向打标，用来做各种广告、统计等各类内容统计、筛选、推荐等逻辑。

上面说的这些内容，除了最后的算法、推荐等内容专门立项去做了项目。其他的内容其实只用了一个半的后端人力就完成了。全部买了托管的服务器也没有运维成本，ap引擎+bi的成本大概每个月不到1w，比一个程序员便宜多了。

就这样的成本，只要用对了方法，就能达到一整个大数据团队的效果，直接提升公司业务业绩。

总结

总体来说，就3步：

1. 梳理+设计
2. 做bi，写sql
3. 再接入系统，做些过去不敢想的事

过程中注意其他部门的配合，业务梳理和报表在使用过程中的优化。有可能的情况下，把这件事加入其他部门okr。

更多精彩内容：

想认识我吗？来我的公众号「迷路idea」找我玩吧～