这是第 164 篇不掺水的原创，想获取更多原创好文，请搜索公众号关注我们吧~ 本文首发于政采云前端博客：大数据前端团队生存指南
本文会简单介绍大数据、大数据前端团队以及可落地的演进方向。 ps.针对数据前端团队10人及以内的中小厂。
开始前问几个问题：
- 你了解大数据技术吗？
- 为什么需要大数据前端团队（和大数据有什么关联）？
- 大数据前端团队在前端团队中的定位？
浅入浅出大数据
为什么需要大数据
咱们年终述职汇报的时候，是不是有个标准套路：
使用xx工具替换了xx工具，并落地xx个团队的xx个项目，覆盖率x%，整体体积减少了x%，加载速度从x缩短到x。
那么完成上面这条简短而有力的阐述需要那几个步骤？
- 我需要哪些数据，从哪来？寻源与采集
- 收集的数据很多要怎么管理？聚合与统计
- 如何整理出可读和有用的结果？建模与分析
大数据技术在做什么
数据本身的价值——疫情防控啊，通过数据精准发现密接和次密接 数据增值的价值——电商行业根据用户消费情况做商品推荐、我的抖音里每次都是跳舞小姐姐
简单来说可以分为提供数据服务和提供数据分析。
大数据开发分了几个方向： 1.底层的基础平台开发 2.面向用户的数据产品开发 3.数据仓库开发 4.大数据分析 5.算法，数据挖掘
简化一下运作流程：
- 确定需求：要做什么
- 需求分析：沉淀需要的指标（通常是数据分析师和运营）
- 分析数据来源：埋点？业务数据库
- 数据域划分、指标&模型：原子指标的统计口径、计算逻辑（核心）
- 跑数据&结果验证
数仓平台
采用阿里的数据体系分层架构分表为：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。
| 分层 | 内容 |
|---|---|
| ODS 贴源层 | 实际业务产生的未经处理的原始数据数据 |
| DWD 明细数据表 | 以业务过程明细数据进行宽表化处理，形成明细逻辑表。 |
| DWS 汇总数据层 | 面向可复用模型公共建模，汇总成口径统一指标，完成数据加工与整合。 |
| ADS 数据应用层 | 基于指标的个性化数据 |
作为底层能力，数仓同学会根据产品诉求做抽象和分层，并建立一些内部业务的通用模型。
数据平台
除了配合分层之外，还有跑批、作业、数据集成、抽取 、回流等，这些都是 数据平台 的工作，目的是管理数据，是一个较为独立且闭环的技术产品，也是支撑数仓的能力平台。 通过平台化和gui的能力释放数仓同学的工作压力，同时更合理合规的透出到业务线。
数据应用
通常是前端的主战场，配合各种端的业务，与数据平台联调，使用一些可视化的方案完成用户诉求。
在初步介绍了大数据团队工作以后，我们回到前端。
团队成长
团队现状
内部出现的一些问题：
- 不了解公司业务、与核心业务交流少
- 与前端基建的关联性很少，导致在大前端里出头脱s节
- 交付效率不够，其中占比最重的来自于数据分析，业务消化不完
- 内部数据处理的业务都搞不清楚（业务知识壁垒高）
- .......
总结：人少活急、业务壁垒、交流不畅
结合行业分析
业界比较出名的数据可视化（排名不分先后）团队有很多，百度 Echarts 团队、阿里云 DataV 团队 、蚂蚁金服 AntV 团队 、360 企业安全集团可视化团队等。
这些团队Paas化（参考 DataV、网易数帆等）有更复杂的场景和更高的可视化要求，也能诞生很多可视化垂直赛道的专家机会。 然而大部分公司想做数字化转型，都没金力培养一个支“可视化”的前端团队 ；要么直接外采，要么成立一个数据团队，前端只要简单场景的分析展示（数据处理后台、BI、大屏、驾驶舱）。
目前公司的规模和节奏卡在两者之间，有商业化的规划但是上升期业务交付压力很大，晒一条数据—— 6 月计划需要前端的需求为 27 个，实际排入14个，其中 42% 精力投入大屏、看板的项目交付。
经过一系列梳理，决定提升人效问题并借助大数据分析能力帮助其他团队建流程、做分析，我们明确了 3 点方向：
- 做深、做宽底层能力，并使其通用化
- 提升可视化业务的交付效率
- 与个别业务进行深度合作，提供数字化运营解决方案
能力清单
底层能力-可视化物料体系
数据前端团队内部的底层能力，同时也可以成为公司的规范来保证数据展示的交付效率。 首先需要建立一套通用视化规范，然后形成可插拔的物料体系落地到业务侧。
- 基础图表组件库
- 业务视图：一些额外的自定义组件
- 3D能力（d3、three）
- 拖拽交互、流程编排（g6）
- 与搭建场景的结合，物料管理等
难点
- 可视化规范的约束与视觉创意的 balance，既要克制又要个性。
- 可视化组件库不像传统组件库，配置的复杂度容易牵一发动全身，抽象能力很重要。
方案
- 定义一套标准化方案（包含可变和约束项）结合主题来满足不同的调性；视觉负责新增的组件以及场景设计
- 充分的分类：素材、信息、控件、地图、图表、表格、业务等，其中素材、控件和业务是需要迭代的工作量
- 配套物料体系需要固定的开发脚手架、模板和物料管理
通用服务-可视化搭建平台
可视化搭建采用 NoCode，只有个别数据源处理需要前端做数据规则转换，基于物料沉淀和视觉规范做快速搭建；工作转移和共建流程放在了下面方案中。
- 大屏
- BI 驾驶舱：相比大屏的展示更重交互有可能会嵌在管理系统里
- 报表：excel
- ppt
难点
- 搭建系统本身的复杂度，可视化的配置项会比普通搭建多。
- 搭建与物料之间的规范抽象，完善的物料体系，标准的共建规则。
- 搭建的受益群体。搭建由谁来完成？如何配合共工作职责？谁是买单方？
- 搭建产品演进与日常研发的边界，哪些功能从业务中抽象，哪些功能不应该做。
方案
-
物料管理与搭建的关系、渲染加载拖拽能力、图表的数据转换统一规范
-
前面已经说过了
-
将前端搭建的流程提前提供一些搭建出来的行业解决方案模板给业务方挑选，视觉负责个性化组件和场景的设计。
- 前端需要对业务方、对应的产品、视觉进行培训
- 完全支持的场景，搭建人由业务方或视觉出，边界是是否需要视觉把控质量
- 视觉与前端的搭建人，边界在于是否可以避免视觉出设计稿以及是否有额外的全局事件代码和新组件
- 数据源的搭建人边界，是否需要前端对数据做大量转换，应尽量避免。
-
例如版本、草稿、回退、收藏，交互处理（下钻、刷新、tab等），view之外的逻辑由业务方承接
-
为了支持业务+内部基建，需要搭建产物的多样性，支持 npm、html、url 等方式交付。
数字化能力-埋点分析
难点
- 建立一套规范的产研埋点流程，从需求到前端
- 了解数据流转的流程，区分诉求是前端埋点还是后端埋点，实时还是 T+1
- 如何推动产品用起来（数据意识不够）
- 埋点标准化、可视化、无痕化、工程化
总结：横向能力 > 技术难度 方案 当然路径图（桑基）、转化率（漏斗）等高定制组件应该是在“可视化物料体系”里面的，相比之下抛开技术本身，埋点更适合有产品思维，横向和数据意识强的同学。 细节我们也沉淀了不少 【埋点能力分享】
数据中台抓手-数字化运营
使用大数据已沉淀的能力，连接业务与产研，让产研找到业务侧的技术发力点。 为什么大数据前端团队可以做数据能力的运用和推动落地？
- 埋点需要产品、运营和技术充分讨论，而前端是唯一的执行者
- 产研数据分析必定需要可视化平台承载
- 数据分析之后需要提供解决方案，前端可以从体验方向作为切入点，也可有依据的" battle需求"
数字化运营的通用方案还在路上，感兴趣的关注我，等下一篇《数字化运营在客满业务线的落地》
大数据前端是一个特殊的团队，可大可小，如何打破技术边界，渗透到业务内部还需要不断修炼。 最后，如果你正好也在这个团队，同时有些个人建议，欢迎在评论区分享。
推荐阅读
开源作品
- 政采云前端小报
开源地址 www.zoo.team/openweekly/ (小报官网首页有微信交流群)
- 商品选择 sku 插件
招贤纳士
政采云前端团队（ZooTeam），一个年轻富有激情和创造力的前端团队，隶属于政采云产品研发部，Base 在风景如画的杭州。团队现有 90 余个前端小伙伴，平均年龄 27 岁，近 4 成是全栈工程师，妥妥的青年风暴团。成员构成既有来自于阿里、网易的“老”兵，也有浙大、中科大、杭电等校的应届新人。团队在日常的业务对接之外，还在物料体系、工程平台、搭建平台、性能体验、云端应用、数据分析及可视化等方向进行技术探索和实战，推动并落地了一系列的内部技术产品，持续探索前端技术体系的新边界。
如果你想改变一直被事折腾，希望开始能折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变既定的节奏，将会是“5 年工作时间 3 年工作经验”；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊… 如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的前端团队的成长历程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 ZooTeam@cai-inc.com