从DataPhin看数据中台的另类理解

从DataPhin看数据中台的另类理解

|0x00 数据中台的另类理解

今天不讲细节,仅谈学习思路。

数据中台官网:https://dp.alibaba.com/index

OneData官网:https://dt.alibaba.com/onedata.htm

DataPhin官网:https://www.aliyun.com/product/dataphin

淘系的电商数据,做了这么多年,核心经验就是体系思维:OneData体系(OneModel、OneID、OneService)。分别从数据研发规范、数据资产管理、研发工具集、数据服务等方面入手,把体系化的经验总结了出来。

用官网上的话:数据中台 = 方法论 + 组织 + 工具。

方法论自不用说,维度建模打遍天下;组织上建立了研发、分析、产品、运营、管理的全流程体系,都是基于数据在干活;工具上就更丰富了,基于ODPS体系,搞数据的啥软件都不用装,真真正正的实现了云上工作。

数据中台该怎么理解?思路上很简单,“降本、提效”。大公司踩了这么多年的坑,把沉淀的经验,做成体系化的商业产品,再配合书籍、文章、论坛,卖给业务高速发展的中小公司,省去了自建系统的庞大支出,这都是数据中台门槛。

|0x01 从商业产品看大厂建设思路

那么为什么提到DataPhin?是为了学习建设思路。

还是从官网的文字入手,提到了产品的优点,也就是大多数数据从业者的日常工作,即:

  • 数据引入的能力;

  • 数仓规划的能力;

  • 数据建模的能力;

  • 规范定义的能力;

  • 编码开发的能力;

  • 调度运维的能力;

  • 资产管理的能力;

  • 主题服务的能力。

我画个简单的图,就更容易理解了:

这就跟我们日常工作的内容吻合了起来。

过去有个热词,叫作“一站式”,就是把数据的所有工作,能用到的工具,打包成集合,这就是“一站式”。当然,现在更热门的说法,叫作“智能化”。大厂的思路,就是把你能想到的场景,都做成工具,大家只需要Focus到业务上就行了,不必去关心复杂的技术实现细节。

学习知识,不需要跑培训机构,看看产品文档,有时候就足够了。

|0x02 DataPhin的设计和使用思路

点击DataPhin的入门详情页,基本上就能够窥探到它的设计思路:

https://help.aliyun.com/document_detail/109739.html

准备来说,就是根据场景选择技术方案。官网给了两个例子:

  • 数仓上云,Dataphin + MaxCompute

  • 主题式数据服务:Dataphin + Quick BI + MaxCompute

可以看出来,这是一种非常技术化的产品售卖思路,因为MaxCompute是做开发用的,它基本上就包括了一整套的数据开发工具集,所以这部分肯定是基础的选项。Dataphin是针对数据仓库做定制优化的方案,是在MaxCompute的基础上做集成方案的。最后的Quick BI就是一种类似于Tableau的数据可视化工具。

那么这些东西怎么用呢?官网也给出了实践案例:

https://dp.alibaba.com/exchange/article?articleId=70

这种方式从商业产品的角度来讲,非常的技术化,如果没有大公司从业经历,不容易理解复杂概念的具体内涵。但是,对于我们要学习技术的人来说,这种思路就非常的适合入门学习。

这种思路也挺适合于简历包装的:技术方案 + 应用场景,大家不妨从这种思路入手,重新设计一下自己的简历,说不定有奇效。

|0x03 多聊一点工具化

研发行为工具化、在线化,是未来互联网发展的一个新趋势,目的就是在于解决那些高速增长的年代里,大家都会普遍面的技术问题。可以说,工具化能够把一家公司从小规模发展到大规模的过程中,遇到的问题,一一都提前构思好了。

那么数据中台在发展过程中,面临的共性问题有哪些呢?

  • 数据不统一:数据不统一是多方面的,命名、指标、口径、逻辑、架构…… 等等,每一点歧义,都会增加最终的需求交付时间,对于快速响应业务而言,难度很大。可以说,数据不统一,是数据中台建设的最初痛点,也是最重要的解决问题。

  • 数据不连贯:不同部门如果是自建数据团队的话,那么数据必然就会散落到各个业务线中,而无法统一起来,为公司提供“上帝视角”的决策支持,价值也就难以得到体现。

  • 运维成本高:数据运维、数据开发、数据仓库是最常招聘的有关数据的工程师,日常的工作就是解决数据链路太长导致的各种时延、质量问题。比如上游数据出了问题,没有发现,下游就照常计算,最后引得客户投诉…… 运维成本高的本质就在于数据没有一个统一的视角,“孤岛”必然带来“冗余”。

那么工具化的作用体现在哪些阶段中呢?

  • 其一,数仓建设的自动化,比如公共层模型的命名规则、指标口径等;

  • 其二,研发模式多样化,支持生产与开发环境的隔离,这是Hadoop系列的大痛点;

  • 其三,支持权限管控,权限问题有多复杂,就不用我说了吧;

  • 其四,数据运算能力的动态扩展,在云上,“扩容就完事了”;

  • 其五,多引擎计算,例如实时开发与离线开发能够统一起来。

这些内容在官方文档里都能够找到。

|0xFF 谈谈架构自建与商业化产品

很多时候,看看别人家的文档目录,自己要做什么,似乎就一目了然了。之前每当大公司的高P跑到小公司的时候,会对现有的技术方案一顿喷…… 然后引得各种吐槽和论战。平心而论,技术无高低,只是阶段有区别。如果公司的目标是做大做强,那么早晚也会遇到与大公司一样的技术瓶颈,从发展的初期就开始避免踩坑,确实能够“降本提效”。但是吧,又有几个公司,能发展成大公司呢?这就注定了绝大多数公司,跑到技术的中游阶段,就足够应对接下来的5-10年的技术场景了,也就没必要一定要用大公司的成熟方案,因为“成本很高”。

自建的初始成本低,因为都是开源方案,但当公司飞速发展时,自建方案就需要引入大量的人才来进行升级改造,这时候的“成本”,对于领导来说,就是一件“高投入低产出”的事情了。中等规模用成熟的商用方案,确实可以解决很多问题,但如果公司继续做大,下面的问题可能就不是单纯的技术问题了,而是要掌握核心技术的政治类问题了。

小公司自建挺好的,中型公司买商业方案也不错,大公司呢,则要有自己的核心壁垒。每个阶段,都有最适合自己的技术选择。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页