大数据前端团队生存指南

2022-12-01 11:20:32 浏览数 (1)

大数据前端团队生存指南 http://zoo.zhengcaiyun.cn/blog/article/big-data

本文会简单介绍大数据、大数据前端团队以及可落地的演进方向。ps: 针对数据前端团队 10 人及以内的中小厂。

开始前问几个问题：

  1. 你了解大数据技术吗？
  2. 为什么需要大数据前端团队（和大数据有什么关联）？
  3. 大数据前端团队在前端团队中的定位？

浅入浅出大数据

为什么需要大数据

咱们年终述职汇报的时候，是不是有个标准套路：

“使用 xx 工具替换了 xx 工具，并落地 xx 个团队的 xx 个项目，覆盖率 x%，整体体积减少了 x%，加载速度从 x 缩短到 x。

那么完成上面这条简短而有力的阐述需要那几个步骤？

  1. 我需要哪些数据，从哪来？寻源与采集
  2. 收集的数据很多要怎么管理？聚合与统计
  3. 如何整理出可读和有用的结果？建模与分析

大数据技术在做什么

数据本身的价值——疫情防控啊，通过数据精准发现密接和次密接 数据增值的价值——电商行业根据用户消费情况做商品推荐、我的抖音里每次都是跳舞小姐姐

“简单来说可以分为提供数据服务和提供数据分析。

大数据开发分了几个方向：

1. 底层的基础平台开发

2. 面向用户的数据产品开发

3. 数据仓库开发

4. 大数据分析

5. 算法，数据挖掘

简化一下运作流程：

  1. 确定需求：要做什么
  2. 需求分析：沉淀需要的指标（通常是数据分析师和运营）
  3. 分析数据来源：埋点？业务数据库
  4. 数据域划分、指标&模型：原子指标的统计口径、计算逻辑（核心）
  5. 跑数据&结果验证

数仓平台

采用阿里的数据体系分层架构分表为：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。

分层

内容

ODS 贴源层

实际业务产生的未经处理的原始数据数据

DWD 明细数据表

以业务过程明细数据进行宽表化处理，形成明细逻辑表。

DWS 汇总数据层

面向可复用模型公共建模，汇总成口径统一指标，完成数据加工与整合。

ADS 数据应用层

基于指标的个性化数据

作为底层能力，数仓同学会根据产品诉求做抽象和分层，并建立一些内部业务的通用模型。

数据平台

除了配合分层之外，还有跑批、作业、数据集成、抽取 、回流等，这些都是 数据平台 的工作，目的是管理数据，是一个较为独立且闭环的技术产品，也是支撑数仓的能力平台。通过平台化和GUI的能力释放数仓同学的工作压力，同时更合理合规的透出到业务线。

数据应用

通常是前端的主战场，配合各种端的业务，与数据平台联调，使用一些可视化的方案完成用户诉求。

在初步介绍了大数据团队工作以后，我们回到前端。

团队成长

团队现状

内部出现的一些问题：

  1. 不了解公司业务、与核心业务交流少
  2. 与前端基建的关联性很少，导致在大前端里出头脱节
  3. 交付效率不够，其中占比最重的来自于数据分析，业务消化不完
  4. 内部数据处理的业务都搞不清楚（业务知识壁垒高）
  5. .......

总结：人少活急、业务壁垒、交流不畅

结合行业分析

业界比较出名的数据可视化（排名不分先后）团队有很多，百度 Echarts 团队、阿里云 DataV 团队 、蚂蚁金服 AntV 团队 、360 企业安全集团可视化团队等。

这些团队 Paas 化（参考 DataV、网易数帆等）有更复杂的场景和更高的可视化要求，也能诞生很多可视化垂直赛道的专家机会。然而大部分公司想做数字化转型，都没金力培养一个支“可视化”的前端团队 ；要么直接外采，要么成立一个数据团队，前端只要简单场景的分析展示（数据处理后台、BI、大屏、驾驶舱）。

目前公司的规模和节奏卡在两者之间，有商业化的规划但是上升期业务交付压力很大，晒一条数据——6 月计划需要前端的需求为 27 个，实际排入 14 个，其中 42% 精力投入大屏、看板的项目交付。

经过一系列梳理，决定提升人效问题并借助大数据分析能力帮助其他团队建流程、做分析，我们明确了 3 点方向：

  1. 做深、做宽底层能力，并使其通用化
  2. 提升可视化业务的交付效率
  3. 与个别业务进行深度合作，提供数字化运营解决方案

能力清单

底层能力-可视化物料体系

数据前端团队内部的底层能力，同时也可以成为公司的规范来保证数据展示的交付效率。首先需要建立一套通用视化规范，然后形成可插拔的物料体系落地到业务侧。

  1. 基础图表组件库
  2. 业务视图：一些额外的自定义组件
  3. 3D 能力（d3、three）
  4. 拖拽交互、流程编排（g6）
  5. 与搭建场景的结合，物料管理等

难点

  1. 可视化规范的约束与视觉创意的 balance，既要克制又要个性。
  2. 可视化组件库不像传统组件库，配置的复杂度容易牵一发动全身，抽象能力很重要。

方案

  1. 定义一套标准化方案（包含可变和约束项）结合主题来满足不同的调性；视觉负责新增的组件以及场景设计
  2. 充分的分类：素材、信息、控件、地图、图表、表格、业务等，其中素材、控件和业务是需要迭代的工作量
  3. 配套物料体系需要固定的开发脚手架、模板和物料管理

【鲁班数据源管理方案】(https://juejin.cn/post/7122240814108901406)

【低代码平台远程组件加载方案】(https://juejin.cn/post/7127440050937151525)

通用服务-可视化搭建平台

可视化搭建采用 NoCode，只有个别数据源处理需要前端做数据规则转换，基于物料沉淀和视觉规范做快速搭建；工作转移和共建流程放在了下面方案中。

  1. 大屏
  2. BI 驾驶舱：相比大屏的展示更重交互有可能会嵌在管理系统里
  3. 报表：excel
  4. ppt
  5. pdf

难点

  1. 搭建系统本身的复杂度，可视化的配置项会比普通搭建多。
  2. 搭建与物料之间的规范抽象，完善的物料体系，标准的共建规则。
  3. 搭建的受益群体。搭建由谁来完成？如何配合共工作职责？谁是买单方？
  4. 搭建产品演进与日常研发的边界，哪些功能从业务中抽象，哪些功能不应该做。

方案

  1. 物料管理与搭建的关系、渲染加载拖拽能力、图表的数据转换统一规范
  2. 前面已经说过了
  3. 将前端搭建的流程提前提供一些搭建出来的行业解决方案模板给业务方挑选，视觉负责个性化组件和场景的设计。
    1. 前端需要对业务方、对应的产品、视觉进行培训
    2. 完全支持的场景，搭建人由业务方或视觉出，边界是是否需要视觉把控质量
    3. 视觉与前端的搭建人，边界在于是否可以避免视觉出设计稿以及是否有额外的全局事件代码和新组件
    4. 数据源的搭建人边界，是否需要前端对数据做大量转换，应尽量避免。
  4. 例如版本、草稿、回退、收藏，交互处理（下钻、刷新、tab等），view之外的逻辑由业务方承接
  5. 为了支持业务 内部基建，需要搭建产物的多样性，支持 npm、html、url 等方式交付。

【低代码平台远程组件加载方案】(https://juejin.cn/post/7127440050937151525)

【探索组件在线预览和调试】(https://juejin.cn/post/7145604963593355277)

数字化能力-埋点分析

难点

  1. 建立一套规范的产研埋点流程，从需求到前端
  2. 了解数据流转的流程，区分诉求是前端埋点还是后端埋点，实时还是 T 1
  3. 如何推动产品用起来（数据意识不够）
  4. 埋点标准化、可视化、无痕化、工程化

总结：横向能力 > 技术难度方案

当然路径图（桑基）、转化率（漏斗）等高定制组件应该是在“可视化物料体系”里面的，相比之下抛开技术本身，埋点更适合有产品思维，横向和数据意识强的同学。细节我们也沉淀了不少

【埋点能力分享】(https://juejin.cn/post/7114450860335169543)

数据中台抓手-数字化运营

使用大数据已沉淀的能力，连接业务与产研，让产研找到业务侧的技术发力点。为什么大数据前端团队可以做数据能力的运用和推动落地？

  1. 埋点需要产品、运营和技术充分讨论，而前端是唯一的执行者
  2. 产研数据分析必定需要可视化平台承载
  3. 数据分析之后需要提供解决方案，前端可以从体验方向作为切入点，也可有依据的" battle需求"

数字化运营的通用方案还在路上，感兴趣的关注我，等下一篇《数字化运营在客满业务线的落地》

大数据前端是一个特殊的团队，可大可小，如何打破技术边界，渗透到业务内部还需要不断修炼。最后，如果你正好也在这个团队，同时有些个人建议，欢迎在评论区分享。

大数据 数据处理 网站 数据分析 https

0 人点赞