大数据中台,利润中心还是成本中心?-读《云原生数据中台:架构、方法论与实践》

 

云原生数据中台:架构、方法论与实践

最开始在作业帮做实时计算的时候,我经常会类比之前的经验来指导如何做系统,比如数据如何产出、数据的规范格式、运维的基础保障(监控、报警、日志三件套)等

类比学习是最初赖以仰仗的能力,不过两年下来,值得重新以一个小白的心态去重温一遍大数据,不再通过类比,而是从大数据的背景、趋势、发展、未来思考数据中台这个概念。

同时现在公司人员,基本都熟悉了 Word、Excel 这些 Office 软件(PPT可能跟晋升机制有关),而随着数据价值越来越得到认可,大数据分析是否也是公司内越来越多人需要掌握的技能?

这是我想要读这本书的缘起。

很多书籍文章都会张口闭口闭环、生态、抓手,我会尽量用自己的理解白话文的介绍,不过受限于理解和表达能力,也难免会咬文嚼字一些。

1. 大中台 VS 大前台

大前台是一个容易自然发展成的样子,业务需求一着急,如果没有轮子,只要有人力,自己造一个是最快的,重度贴合应用场景。因为无需考虑太多适配,最大程度、最快的满足业务需求,确保业务不会等着技术评估合理性。这种现象是自然进化的优胜劣汰?还是熵增导致的无序混乱?

大中台的概念,第一次接触是在关于架构的思考 - 评《阿里巴巴中台战略思想与架构实践》这本书里。Supercell 可以快速开发一款新游戏,原因是因为研发、数据能力的快速复用,阿里借鉴了这个思路,提出了中台的概念并且受到追捧。

但我们也无法忽略当时的背景:阿里原有淘宝,又新发展了天猫,两者有很多相似之处,数据上共享能够获利、技术上沉淀能够降低人力成本,所以自然的想法是有一个基础部门统一支撑。然而事与愿违,这个部门根本做不起来,大概会有以下这些问题吧:

  1. 做谁的需求、不做谁的?优先级怎么排?
  2. 部门的核心价值就是实现需求么?哪些需求接,哪些需求不接?怎么融合用户当前需求与长期计划?
  3. 需求排期多久是合理的?业务方抱怨怎么办
  4. 人是淘宝原有的部门过来的,接需求时,怎么合理、公平的对需求而不对人

最重要的,站在业务方的角度:如果有可能不支持/支持慢,那前台为什么要通过中台?

印象特别深刻的是这张图:

o(╯□╰)o

直到聚划算出现,天猫、淘宝都纷纷要求接入,阿里决策层强势要求必须通过中台,算是给了中台一个强力的政策扶持。

所以可以得到这个结论,能否建成大中台,取决于几个条件:

  1. 多个前台的现状或者发展趋势,比如 Supercell 有多款游戏,阿里有淘宝、天猫、1688、闲鱼
  2. 决策层的支持:避免只是停留在口头上
  3. 业务抓手:避免没人跟你玩儿,中台成了空中楼台

2. 中台与平台的区别

首先中台不是一个舶来品,是阿里造出来的,为了解决烟囱式开发、孤岛、各自为战的问题。我在读那本书的时候,其中有两点印象深刻:

  1. 理想很丰满:中台是一个中场发动机,能够随时派遣出来多只先锋队,负责在各个方向开疆拓土,中台提供装备(已有的研发能力、各部门数据、统一沉淀的规范)
  2. 现实很骨感(最初):淘宝、天猫两个部门,完全不鸟中台,直到行政命令必须通过中台接入聚划算

硅谷的大数据平台基本等价于阿里宣传的中台,都是避免重复造轮子、快速迭代、数据驱动、业务驱动。 但是由于阿里运营中台的概念太成功了,所以很多文章都会介绍中台、平台的差异。

所以仅在沟通时避免混了中台、平台即可,实际上目标都一样:统一、规范、共享、复用。

3. 从数据仓库到数据中台

数据仓库是数据中台的一部分,数据中台责任更大:提供数字化运营的能力,能够指导企业下一步该怎么做,在市场竞争中获得优势,通过数据比对手更了解用户、成本更低、洞察市场等等。

然而知易行难,大家都知道这些能力的好处。但是也有很多问题:

  1. 公司现在没有那么多烟囱开发,有必要提前统一么?
  2. 我们业务的数据自给自足,开放出来浪费人力
  3. 业务自身开发排期都满了,没空配合大数据
  4. 我们并不是想要重复造轮子,只是业务部门不给数据、大数据部门也产出不了,所以只能自己再开发一遍

这几个已经超出了技术的范畴,是想法不一致、理解也不统一,单纯靠中台解决不了,就像是阿里中台最开始的窘境。

但是多想想也有好处,那就是大数据中台相比其他中台,我觉得有两点特殊性:

  1. 几乎涉及公司所有部门,以及要跟CEO、CMO、CIO、COO一起探讨如何用数据为企业产生价值。
  2. 各部门之间通过数据中台共享数据,既是数据的使用者,又是数据的提供者,既有数据需求,又有数据产出。因此不能简单的认为业务部门是需求方。 所以跟各部门的牵扯确实是更深一些。

书里给了一套方法论,按照我的理解介绍一下:

  1. 业务驱动、快速落地:能让业务尝到甜头、感受到大数据的技术深度和解决问题的能力,这个有点一线实践智慧的感觉。
  2. 顶层架构设计及数据规范:架构即流程,数据怎么流转,用哪些技术栈;规范即条文,数据怎么定义,类型、名字、注释等等。但是我们面对的是一个变化的环境,可能有些数据最开始很难判断是否要沉淀到数据中台,怎么办?要有流程支撑,比如Twitter通过自身的数据架构委员会来衡量哪些数据能力可以复用
  3. 平台管理:底层的平台和工具要好用,这是最起码的立身之本。比如实时、离线计算平台;任务调度平台;监控报警通知等,避免人为操作,大家用了都觉得省事省力省心
  4. 权责明确:牵扯方众多,先明后不争,事前说好,别事后甩锅埋坑推诿,搞的大家不痛快
  5. 安全、高效、稳定、可扩展:老生常谈了

如果要定义数据中台的话:

数据中台是企业数字化运营的统一数据能力平台,能够按照规范汇聚和治理全局数据,为各个业务部门提供标准的数据能力和数据工具,同时在公司层面管理数据能力的抽象、共享和复用。

4. 数据中台的例子

书里介绍了 Airbnb、Twitter 的例子,重点说下 Uber。Uber 开源了非常多的优秀框架,比如我们在最开始做 SQL 实时计算平台的时候,就参考了 AthenaX1

摘抄部分 Uber 大数据平台的演进历程2:

uber-bigdata-v2

上图为第二代架构,通过引入 Hadoop 生态,所有数据服务都支持横向扩展,能够支持到数百 PB 的数据量。

uber-bigdata-v3

上图 2017 年开始搭建的第三代架构,主要解决的不足:

  1. HDFS 可扩展性:大量小文件、数据量逐渐增大(50~100PB),虽然有一些简单方案可以解决这个限制。
  2. Hadoop 中的数据的时效性:T+1不能满足时效性需求
  3. Hadoop 和 Parquet 中的数据如何更新:如果不支持,就只能 T + 1 merge 一次。(3 其实是分析问题 2 之后的原因之一?)
  4. 更快的 ETL + 建模:为了降低延迟,因此引入增量模式

其中核心点在于引入了Hudi(Hadoop Upserts anD Incremental)

5. 选型:自研、开源、云原生

如何选型考虑的因素非常多,所以经常看到同一个问题不同公司的不同解法。

自研主要是提供个性化的支持,例如对接公司的 passport/代码库,审计的需求、使用习惯等等。

开源比较适合项目初期,稳定性要求不高,个性化需求也不多,主要用来快速构建,甚至不用读代码,看看 ReadMe 就能搭建一个服务出来。但是出来混,迟早要还的。项目有 case,性能要提升,还是得去深入了解。所以开源软件并不是“万应灵药”,也有很多问题和陷阱,我们经常会看到“(开源)×××实战蹚坑”之类的文章。硅谷的很多大数据公司,如Confluent(Kafka)、Cloudera(Hadoop)、Databricks(Spark),都是建立在为用户解决此类问题的商业模式上的

很多开源软件的模式是让不付费的用户使用,在这个过程中由社区不断完善软件,付费用户向开源软件公司购买高质量和高保证的服务,实现三赢。但是,开源软件不等于免费软件,不付费用户实际上也付出了一定的成本:决策风险、机会成本、人力成本、管理风险、运行风险等等

进一步的,我觉得另外一个隐藏的风险点,就是即使使用了付费版,可能能够解决稳定性兜底、性能提升的问题,但是:

  1. 付费版是统一版本,能够适配到现有的使用习惯么?比如是否接入 LDAP、如何对接公司其他自建平台
  2. 对方支持的力度有多大

很多成熟的开源软件,已经被大公司主导,主要是:

  1. 从 issue、discussion、code review 都需要已有的 commiter/PMC 参与以控制代码质量,而很多 commiter 本身是云厂商的人
  2. 云厂商已经支持了一些付费功能,这些逐渐的、部分的释放到开源社区里,本身是需要也是受欢迎的 所以这种共赢的方式,为云厂商构建了一层越来越坚实的技术壁垒。

云原生架构是一种利用云计算优势来构建和运行应用程序的方法。它是一个技术和方法论的集合,包含4个要素:微服务、容器、DevOps、持续集成和持续交付(CI/CD)。

当面临自研、开源的难题时,云原生似乎成了一个绝佳的选择,但是也要考虑好,面对大数据的众多组件时,这三者不应该是只选其一的关系。

6. 参考资料

  1. AthenaX
  2. Uber 大数据平台的演进(2014~2019)