从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年的技术场景了，也就没必要一定要用大公司的成熟方案，因为“成本很高”。

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

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