回到技术的解决方案上来，在明确了要解决『能使用』和『方便与业务系统之间打通』这 2 个问题后，我们发现『微前端』的解决方案其实非常适合用来解决数据报表的问题。这里的『微前端』指的并不是现在许多团队在投入的基于微前端架构的应用框架，而是能够适应各种前端框架和渲染环境的报表组件。换句话说，我们要做的不是一个可以摆放任意东西的架子，而是一个个可以放在任何架子上的实物。另外，在现有的搭建平台基本都解决了搭建页面内部组件可交互的问题后，为了实现『能使用』这一目标，我们还需要为所有搭建平台支持的组件添加一个对外的出口，让其具备可以和外界 API 进行基于 POST 请求通讯的能力。最后，虽然『微前端』听起来像是一个全新的概念，但在落地时却又很容易简单地实现为所有组件都发一个包含所有依赖的独立 NPM 包。如果给这样简单粗暴的解决方案套上一个『微前端』的概念，确实有些名不副实。个人认为『微前端』其实是对整个前端开发流程的一次挑战，需要各个前端团队跳出原来以应用为最小粒度开发的模式，转向以组件为最小粒度。这要求配套的单组件研发平台，多组件调试平台，组件发布平台和公共依赖管理平台等多方面都需要达到一定的要求，才能够真正享受到『微前端』带来的红利。否则光是公共依赖重复打包导致代码膨胀和组件/嵌入系统平行升级困难这两个问题，都会让许多团队不得不得退回到应用粒度的开发模式。
数据产品作为数据域中与传统工程应用最为接近的一种交付物，与核心的业务系统一样，对系统的稳定性和扩展性都有着很高的要求。对比传统的 C 端应用，数据产品在技术上也有其一定的特点。不同于重并发轻计算的 C 端应用，数据产品更聚焦在大数据量下的快速复杂计算。又因为在电商的场景下，数据产品服务的对象更多是商家侧，所以从服务用户的上限来讲，对系统并发的要求不及 C 端应用那么严苛。
作为一个『二进宫』的阿里人，这个月刚好是入职 Lazada 的两周年。虽然两次与阿里结缘都是在数据团队（DT），但这次从数据中台到业务前台，从个人贡献者到 TL，团队和身份的转变让我对个人的发展及未来要做的事情都有了更深入的了解和认识，这里也和大家分享一下在业务前台做数据工程的经验与思考。
作为一名前端开发出身的工程师，16 年在 DT 时对于数据团队在整个企业中扮演的角色其实是没有很深的体感的，只知道自己做的是面向淘系商家的数据产品『生意参谋』。而在 18 年加入 Lazada 数据团队后，作为当时大团队里的第一个工程同学，才第一次有机会一窥数据团队的全貌。
数据团队的组成
从最粗的粒度上来讲，数据团队可以分为 4 大部分，即数据采集，数据仓库，数据服务和数据产品。4 个部分自下而上地融通出了一条条数据管道，让通过各个渠道采集过来的明细数据最终成为了驱动业务决策和运营的数据洞见（Insight）。所以从本质上来讲，数据团队并不生产数据，因为数据其实是来源于真实用户与业务系统的日常交互（投放、浏览、点击、购买、订单、物流等）。数据团队更像是数据的搬运工，并在搬运的过程中对数据进行适当加工，让海量、零散的数据最终可以成为业务决策的关键因子来影响下一轮真实用户与业务系统的交互方式，从而形成数据闭环。
工程团队的定位
在数据采集，数据仓库，数据服务和数据产品这 4 个部分中，工程团队很显然承担的是『数据服务』这一层。数据服务作为数据工程团队的交付物，如果我们再把『服务』这个词具象化，又可以拆解为数据接口，数据报表，数据产品和数据大屏这 4 类，分别对应工程师（上下游系统）、分析师、业务运营/商家、媒体，这 4 种不同的用户。
在搞清楚了我们是谁以及我们的客户是谁这 2 个关键问题之后，下一个要解决的问题就是如何服务好他们，并在此基础上沉淀出一定的技术积累。
怎么做数据接口
数据接口作为最基础的数据流通方式，一直以来都在各个业务系统之间扮演着非常重要的角色。
在许多人眼中，数据团队不就是提供数据的吗？只要能拿到想要的数据，一张数仓中的表和一个接口之间到底有什么区别呢？其实这个问题也从一个侧面代表了我在过去两年中的很多焦虑，那就是对于一个数据团队来说，工程研发到底重不重要？数据团队是不是只需要数据研发就够了，剩下的事情都交给下游的业务团队去做是不是也可以？关于这个问题，通过过去两年的实践，答案是越来越清晰的，那就是对于数量众多的下游系统而言，数据团队能够提供一个统一、安全、易用的接口层是一件非常重要的事情。
对于工程团队而言，统一性一直都是一个非常重要的话题。在工程界，各种各样的语言、数据库、框架等层出不穷，一方面带来了繁荣的生态，但另一方面也带来了许多系统之间交互的一致性问题。从这个方面来讲，其实数据仓库是解决得更好的，不论数据生产的过程中涉及到了多少技术栈，最终产出的结果就是一张张的宽表，这大大降低了比如像算法和数据研发之间的协作成本，解决了不同系统模块之间数据流转的问题。但数仓再往下，到了数据库这层，我们就又会发现许多的不一致性。MySQL，HBase，AnalyticDB 等等这些不同的数据库解决方案分别适用于不同的业务场景，也都有各自的成本考量，很难有一个 DB 可以解决所有问题。而这也就是集团内部在数据服务层的拳头产品 OneService 所要解决的问题，那就是让所有的后端应用都可以有一个统一的能够面向各种数据库的接口层。
而我们作为业务前台的工程团队，关注更多的还是业务逻辑，基于 OneService 我们为下游的兄弟团队提供了许多如指标查询服务，商家分层查询服务，商家私域用户标签查询服务等等。这些业务属性较强的数据服务同样需要一个统一的平台来管理，让调用方式，返回格式，版本迭代等信息持续保持对下游系统透明。这就是我们在过去一年中建设的 Lazada 数据统一网关层（Data Gateway），一方面解决对下游透明的问题，另一方面也在团队内部收敛如 BUC 鉴权、请求代理、消息推送等通用的后端能力。在解决了团队内部服务管理的问题之后，今年也会全面地将统一网关层升级为 Lazada 数据开放平台（Data Open Platform），让更多还未通过具体业务需求找到我们的团队更方便地了解 Lazada 数据团队已有的数据服务能力，避免同一份数据在不同团队之间的重复建设，也让和下游团队之间签订的 SLA 可以具体落地到平台上更细粒度的监控指标上去，更好地调配日常及大促期间的机器资源，提高系统稳定性。另外，通过这样一个开放平台统一的服务注册和申请机制，数据团队也可以方便地管控所有对外暴露的数据服务，做到所有操作和调用安全可追溯。
怎么做数据报表
数据报表作为数据接口和数据产品之间承上启下的一层，在日常的业务决策中扮演着非常重要的角色。
在报表搭建这方面，集团内部是有非常成熟的解决方案的，有了这样的珠玉在前，业务前台如何能够在报表搭建方面更进一步，是我们一直在思考的问题。时间回到 2 年前，当时集团内部的搭建平台还没有彻底得国际化，对于本地的同学来讲，使用起来门槛非常高。在明确了要解决『国际化』这样一个问题之后，团队利用业务开发之外的时间研发了一款新的搭建平台，以支撑国际业务的数据产品搭建。除了平台本身的国际化外，我们还创新地提出了『搭建产品国际化』这样一个目标，希望能够做到一次搭建，支持所有语言。
除了『国际化』之外，在数据报表方面另一个我们一直在思考的问题是：数据报表和业务系统之间的边界在哪里？关于这个问题，我们给出的答案是，业务系统是可以直接使用的数据报表。
长期以来，业务系统和数据报表之间一直存在着相当的割裂，一方面是因为生产环境中运行的业务系统和每天大量新增的数据报表从数量上来讲就不在一个量级。业务系统和数据报表之间也并不存在着严格意义上的对应关系，很难有人可以明确地指出说哪几张报表是用来指导运营在某一个业务场景下做决策的。久而久之，大家更习惯地是将这样的决策链路笼统地归于行业经验的范畴，即相信业务侧的同学在看到了特定的数据后就知道去哪个业务系统里进行相应的操作。但从逻辑上来讲，这并不是一个非常站得住脚的说法，因为报表数量多本身也是一件需要去治理的事情，企业更希望的是能够在纷繁复杂的业务中抽象出统一的几张或几十张报表来长期地指导业务运营。临时的取数和分析需求，从技术的角度来讲应该收敛在自助取数/分析的平台上，而不应该形成一批数量庞大却事实上在使用过一次后就鲜有人问津的报表。
回到技术的解决方案上来，在明确了要解决『能使用』和『方便与业务系统之间打通』这 2 个问题后，我们发现『微前端』的解决方案其实非常适合用来解决数据报表的问题。这里的『微前端』指的并不是现在许多团队在投入的基于微前端架构的应用框架，而是能够适应各种前端框架和渲染环境的报表组件。换句话说，我们要做的不是一个可以摆放任意东西的架子，而是一个个可以放在任何架子上的实物。另外，在现有的搭建平台基本都解决了搭建页面内部组件可交互的问题后，为了实现『能使用』这一目标，我们还需要为所有搭建平台支持的组件添加一个对外的出口，让其具备可以和外界 API 进行基于 POST 请求通讯的能力。最后，虽然『微前端』听起来像是一个全新的概念，但在落地时却又很容易简单地实现为所有组件都发一个包含所有依赖的独立 NPM 包。如果给这样简单粗暴的解决方案套上一个『微前端』的概念，确实有些名不副实。个人认为『微前端』其实是对整个前端开发流程的一次挑战，需要各个前端团队跳出原来以应用为最小粒度开发的模式，转向以组件为最小粒度。这要求配套的单组件研发平台，多组件调试平台，组件发布平台和公共依赖管理平台等多方面都需要达到一定的要求，才能够真正享受到『微前端』带来的红利。否则光是公共依赖重复打包导致代码膨胀和组件/嵌入系统平行升级困难这两个问题，都会让许多团队不得不得退回到应用粒度的开发模式。
回到数据报表的问题上来，相信在赋予了静态数据报表『易嵌入』和『可使用』这两大新特性后，它所能带来的业务价值也一定会有质的突破。
怎么做数据产品
数据产品作为数据域中与传统工程应用最为接近的一种交付物，与核心的业务系统一样，对系统的稳定性和扩展性都有着很高的要求。对比传统的 C 端应用，数据产品在技术上也有其一定的特点。不同于重并发轻计算的 C 端应用，数据产品更聚焦在大数据量下的快速复杂计算。又因为在电商的场景下，数据产品服务的对象更多是商家侧，所以从服务用户的上限来讲，对系统并发的要求不及 C 端应用那么严苛。
谈起数据产品，就不得不提到其中最原子的组成部分：数据指标。数据指标是一切数据产品的基础，如何快速准确地计算并管理数以千计的数据指标及其衍生指标，是每一个数据工程团队首先要解决的问题。好在集团内部也已经有了较为成熟的类 FaaS 的逻辑引擎解决方案，极大地降低了团队在最初落地时的成本。
虽然前面提到了数据产品在并发方面并不像 C 端那样动辄要服务上亿的用户，但如 Lazada 生意参谋这样的数据产品，每天也有大量的商家会登录查看自己的经营数据，应用的 QPS 也随着业务的发展，从 18 年到现在翻了 10 倍不止。既然要做对外的服务，大到应用的基础架构，上下游的依赖梳理，小到应用的发布管控，页面级别的渐进式更新迭代，都是真正考验一个工程团队内功的事情。如果说过去两年，在基础架构方面我们有哪些事情做对了的话，那一定是在业务需求交付不间断的前提下，保持了前后端核心框架和库的渐进式升级。
以前端为例，在过去的两年中，团队经历了从 Class Component 到 Hooks，从 redux-saga 到 laz-fetch，从 AntD v3 到 v4 等一系列的底层依赖升级并沉淀出了团队内部状态管理、代码审核、自动发布等一整套的工具链，没有陷入到大型应用在维护了几年之后底层架构慢慢腐烂，只能推倒重来的困境里去。
一个技术团队的好坏，团队 TL 作为一号位是责无旁贷的。这里有两点经验想和大家分享，一是如何在不影响业务交付的前提下对应用进行持续的技术升级。我认为这是一个『意愿大于能力』的事情，也是对技术 TL 追求卓越的真实考验。如果一个技术团队只有做业务的能力，而不具备持续升级技术的能力，那这个技术团队注定是走不远的。第二个经验是技术 TL 应该如何看待『重复造轮子』。诚然，如上文中提到的，团队在过去两年中的技术积累一点都不 fancy，在相关领域或许也都有更成熟的解决方案。但我认为，对于一个超过 10 人的技术团队，在开发规范和工具链上是需要给予团队成员一定自由度的。一方面是因为总有些特殊的业务需求，是开源或其他团队现有工具覆盖不到的，在团队底层工具链中保持一定的自主性和灵活性，是能够更好服务业务的基础。另一方面这也可以给团队成员带来更多成长的机会，让他们有机会去造一些重复却又具有一定创新的轮子。我们反对的，是毫无新意的重复造轮子，对于面向解决具体业务域问题的重复造轮子，技术 TL 还是要给与适当的鼓励与引导，这也是在保护未来团队有机会能够做出一些自主创新的土壤。
怎么做数据大屏
讲完了数据服务，数据报表和数据产品，我们再来谈谈数据大屏。很长时间以来，人们都对数据大屏的价值有着比较深的误解，认为数据大屏不过是大促或某些特定时间拿出来炫技的东西，在业务价值方面和上面提到的这 3 种交付物之间存在着明显的差距。从我个人的角度来讲，数据大屏存在的意义其实用一个词就可以概括，那就是『讲故事』。好的数据大屏可以为企业营造出一个特殊的『场』，让其更好地向外界传达公司的愿景，使命以及在达成这些目标过程中公司的进展。诚然，这种对于人心和市场情绪的影响很难量化，但『讲故事』的能力确实在整个人类的进化历程中都扮演了非常重要的角色，而大屏恰好是对『讲故事』最好的辅助。
过去 2 年中，团队在大屏方面的投入不多，但也落地了以大航海为背景的第一块讲述东南亚电商故事的数据大屏，之后有机会可以再跟大家详细介绍。
写在最后
以上只是个人对于数据工程团队的一点粗浅的认识，实际工作中的情况要比文章中描述得复杂许多，在这里也是抛砖引玉，欢迎对数据工程感兴趣的朋友们一起讨论。