基于阿里云 MaxCompute 构建企业云数据仓库CDW的最佳实践建议

简介： 通过我们背后的指导思想和我们给出的技术解决方案，希望与大家能够一起探索一些新的基于云上的数据仓库构建的最佳实践，从而尽量避免走弯路。这就是我今天想跟大家分享的内容与目的。

在本文中阿里云资深产品专家云郎分享了基于阿里云 MaxCompute 构建企业云数据仓库CDW的最佳实践建议。

本文内容根据演讲视频以及PPT整理而成。

大家下午好，我是云郎，之前在甲骨文做企业架构师8年，目前是MaxCompute产品经理。

在这么长的客户工作过程中，作为产品PD，一定是跟客户在一起的。我经常被一些问题挑战:云郎，我们现在要建数据仓库，我该怎么去规划？云郎，我现在这边是大数据的建设团队，好像数据团队不怎么理我，什么情况？云郎，我们这边现在建了一个平台，现在性能好像有问题，是不是我们哪些地方设计的有问题，还是考虑的不够？可以看到，不同的客户在不同的阶段有不同的问题，在这么多的客户问题里，背后到底隐藏了什么规律？在这里面有没有一些最佳实践，我们可以总结出来，让大家去少走一些弯路，这是我的出发点。

既然谈到最佳实践，你一定要知道哪些不是最佳实践，就像医生一定要看过很多病人以后，才更容易判断是不是健康。

我的客户从哪里来呢？
第一，是阿里巴巴本身有很多个BU，刚才我们也谈到了阿里巴巴所有的数据都是运行在MaxCompute，去做数据仓库，去做加工处理。也许你会挑战我，你解决阿里的问题，我们碰不到，没错，我也确实发现这个问题，即使我们能解决阿里的问题，但是不一定能解决客户的问题。
第二，我们碰到的问题，也不一定能代表客户的问题，因为你的规模和我不一样、你的现状和我不一样、你的能力和我不一样、你的目标和我不一样。MaxCompute也在云上提供服务，我们云上有很多客户，在座的很多朋友都是MaxCompute的用户。所以我把客户的范围进一步纳入到我目前已有的这些客户里面。也许你还会问，你说你是最佳实践，那是基于你自己产品的最佳实践，难道他不用你的产品，你就不能再去分析吗？
所以，我又分析了第三类客户，在中国，有很多企业使用了非阿里的技术，那么他们在这大数据方面又碰到了哪些问题？我相信在座各位也做过很多分享，例如A公司的大数据实践经验， B公司的大数据演进历程，那么我们也会基于这样的案例做出分析。
第四，在阿里这样的一个生态里，收购了很多公司，在外界公司和阿里内部公司融合迁移的过程中，又有哪些最佳实践？
所以我们把这四类客户统一起来看，从现象到本质，这是今天我想要跟大家分享的内容。

大家都在谈大数据，最早在2013年开始在甲骨文做信息解决方案，当时已经研究出了大数据。我在之前是做DB的，Data Base。后来发现转了个身，转成了BD，Big Data。在这个过程中，技术好像做了个变化，就翻了个身，关涛讲了很多，大家很有体会。那这些技术在过程中怎么去用？方法有没有发生变化？客户经常问我一个问题，云郎，我要拿MaxCompute来干什么？我说了不算，后来我就做了很多分析。我发现不管去做什么应用，客户在MaxCompute之上，他首先主要都是在构建他的数据仓库，现在我们把它叫作Cloud Data Warehouse，大家知道数据仓库，它既是一套数据体系，同时它也是一个工程过程，要更多的从工程的角度来看，我们看到这是现在目前业界非常典型的数据仓库实时的生命周期流程。我们发现技术从Data Base，DB转到了BD，但是这张图很多还被广泛的应用，当我跟很多客户的架构师，大数据负责人或者开发人员去沟通的时候，我们发现他背后的思路都是沿着这张设计的生命周期而产生的。那我们可以看到从这个数据仓库，当碰到Cloud Native，再到我们说转到Big Data以后，那么怎么真的去做Cloud Native这样一个Data Warehouse，我们看到在这个过程中，从项目的工程规划到业务需求，到最终我们看到一个小的迭代维护，数仓开发完成，交付大家去使用。

在这个过程中，我们可以看到传统的DB时代，是以建设为中心的一个项目。那么到了大数据，建了是生下来，养才是关键。养之道在于什么呢？在于运营。所以整个环节中，我们可以看缺失了大数据的精髓所在。

我们看分别是哪些情况呢？

第一，我相信很多人来自于互联网公司，如果你来自央企、政府部门，恭喜你，你可能没有这个痛苦，因为你有足够的时间去规划，给你半年时间，给你500万，你帮我做规划咨询出来。但你如果是互联网公司，对不起，今天上岗，明天帮我把数据拿出来，好不好？所以我们是没有那么多时间的。那我们在这里面需要做到什么呢？轻量化，我们从数据仓库整 3ff7 个生命周期上，我们要的是敏捷数仓。那软件工程，我们要的是敏捷开发，数据仓库。

第二，对于需求的问题，为什么你能做规划？因为你能知道后面会发生什么，你的业务基本上是固定的，你能知道政府部门后面要干什么、你能知道央企后面要干什么，但如果你是互联网公司，你到明年存不存在都还不一定，也就是说你可能还没规划完，就要转型了，业务要转型了，需求非常不明确，那你能不能做到明确，挑战非常大。

第三，如果我们规划出来一个非常完美复杂的技术方案，它的落地周期会给我们带来挑战，所以我们需要技术上能否简化？要快速才是王道。

第四，关于数据建模，你一开始就想把这些模型都建立起来，其实这是很多数据工程师经常碰到的问题，我有这么多数据，我全部都能把它灌进来，把这个模型固化下来。我们发现掉到这个井里以后，带来的后果是什么呢？你长长久久的是技术自己关在门里边，结果业务在门外边，他敲你的门，永远敲不开，因为我还在做数据模型的事情，我还在做我自己的事情。

我们可以看到关于数仓的应用，你建了大数据，绝对不是传统的把DB转成BD，你就仍然去做报表，你的场景绝不是这么简单。在这里一定还有机器学习，人工智能、预测等众多的应用，它才能发挥价值。这是一个迭代的过程。可能按月都是对这个模型比较赞美的，因为往往可能三个月是一个周期，从提出一个需求，到最后实现，在传统里，可能需要月的时间。今天按小时、按天帮我实现，我的数据仓库要发生变化，你怎么去构造？

还有就是运维这一侧，开发人员和运维人员能做到咱们今天的所谓的DevOps，如果你是数据开发人员，怎么样能做到整个大数据平台的DevOps，这是很大一个挑战。

在以项目管理为中心、以建设为中心这样的背景下，我们可以看到真正的数据运营是被忽视的，所以这是我们今天整个要引出的话题，就是数据的价值一定要通过运营才能得以呈现。运营又是什么概念呢？ 

企业大数据计算平台的建设，跟我们人的发展一样，刚开始，谈恋爱，蜜月期非常好，其实很多锅碗瓢盆的问题是不用考虑的。但随着建设的发展，结婚，生小孩，锅碗瓢盆的问题一定要考虑的，所以不同的问题，其实考虑的痛苦点不一样。

我们看到这样一个时间轴，横轴，以时间来推动，第一个月，六到十二个月，十二个到十八个月，到第二十四个月，在分析了上百家的企业客户后，我们看到在这样一个周期里，分别会碰到什么样的问题，技术方案不一样，但痛苦是一样的，风险是一样的，这是横轴。

纵轴，业务规模是这条黄色的线，风险是蓝色线。业务在这里面能包出来的半径就是我们所谓的价值，蓝线包起的面积就是我们的风险，刚才关涛也谈到了，说我们的业务面积和风险面积，哪一个更大，这就决定了我们的成败。我们看到这样一张图，在第一个月是蜜月期，大部分客户都可以快速的通过定制化方案，快速启动数据仓库，因为是蜜月期，非常快，这个时候有热情、有投资、有人手，我们快速一个月搞起来了。到了半年到十二个月，业务上来了、规模上来了，这个时候要搭火箭了，要快速成长了，进入青春期了，青春期这个地方是有一个火箭的，这个火箭跟小孩子的成长一样，到青春期有两个方面，你管得好，他就是一个人才，管得不好，他可能就变成了一个混混。那这个火箭就在于往哪条线上走。

随着业务大规模的扩展，数据量、计算量急速增长，这个时候就给我们的性能、成本带来了巨大的挑战和要求，系统能不能解决持续的发展矛盾，就成本、性能、数据安全和分析效率里面的矛盾随着我们业务的发展，我们现在碰到这些问题，该怎么去解决？在整个风险上升的过程中，我们看到这条线是说风险在上升的。上升了以后，有很多公司，包括我们的客户，可以看到在这个之后就会启动一轮治理和优化，包括性能的优化、成本的优化，通过阶段性的优化，达到好的效果。

接下来业务还在不断发展，我们可以看到在这两条线里面又会走向风险失控的过程中，也就是说我们的系统在这个时候变成了成本中心。我们过去因为有钱有想法，开发了很多定制化的系统，这个时候你的人员开始流动了，你所有定制化的系统就变成了什么？黑盒子，你碰都不敢碰，就放在这儿等，等SOS，这是风险演变的过程。

对于我们而言，最佳实践显然是不能走这条路的，我们要避免这样一条弯路。

再进一步的思考，对我们做的这样一个平台经过治理和优化还不够。如果我们能转型再造，其实可以回到一个好的状态，健康最佳实践的状态。那这个转型再造，以阿里大数据平台来说，有两个重要的转型再造，第一个是技术的转型再造，大家也知道，我们是最早使用云梯一Hadoop，我们从技术的转型再造就是变成我们的备胎MaxCompute，其实在2013年在阿里内部早就转正了，最近备胎很火，它在最初是备胎。转型再造由自己的技术来替换升级。

接下来，就是业务，阿里这样的规模，我们内部的技术可以输出到阿里云上，来进行业务的转型。我们获得了这样新生的过程，可以看到在整个风险转移过程中，大家是在哪一个位置，我们要有清晰的认识。我们期望的是我们的技术和业务都可持续发展。在这个里面的核心点，要解决的是成本可控和性能的不断提升。数据越多，不是变慢，而一定要更快。数据既要安全，还要共享。大家知道数据进来，谁都不能碰，是没有用的，要让数据价值要得到充分体现。

所以我们看到整个建设数据平台的阶段性风险，在这个里面，大家都会栽跟头，包括我们都会碰到很多困难。运用《三体》的一句话：“在这些拐点上，毁灭你，与你无关。”，真的是等不及的。对这样一些客户的实质性的洞察，我提出一个新的方法论，不知大家有没有钓过鱼，有没有钓过大鱼？钓小鱼时，是把鱼钩和鱼绳是直接拴在一起的，因为小鱼的力量不会那么猛。但如果你做过海钓，钓大鱼的时候，你有没有发现，如果你的鱼钩和鱼绳是直接拴在一起的，那个鱼咬了饵以后，把钩挂住以后，它会突然有一个很大的力，你的鱼绳是直的，所以它会把你的鱼绳直接崩掉，造成系统崩溃，在这个里面就会出现这样的问题，钓过鱼的人就会有这样的经验。

但是这里面是有解决方案的，鱼绳上大家都知道是有一个8字环绕线法，把这个线绕得比较虚一点，当这个鱼咬到我的钩，拉的时候，它不会直接拉后面的鱼绳，它会用力用到8字环缓冲的这一段线，它突然间把这一段线拉紧了，那一段线是多股绕在一起的，会有更大的抗击力，这时候大鱼上钩以后，这个线就不会断了。

平台和数据有没有这样一种过程？我们的平台和数据，刚才那一个过程是完全独立的，我只考虑建设平台，不考虑数据。但是我们看到在更多的企业里面，平台是一个团队，数据是一个团队，或者平台有很多拨人，数据有很多拨人，但不管怎样，平台就是平台，数据就是数据，我们说平台和数据的关系就是我中间画的一个阴阳图。所以在这里面可以看到，我们不是简单的把平台和数据的工作拼在一起，它就是8字环。我们可以看到8字环的奥妙在于从平台的策略与规划、设计与实现，这是两步。你有了最初的原型以后，有了基础平台以后，马上要进入数据运营。大家可以看到第三步，要在这个里面，有简单的数据要去发现，让数据人员去分析理解、要去探索、要去资产化、要去运营，到了这一步之后，再回到我们的平台侧去进行开发运维，再进行优化治理。

平台和数据是对立的，还是说平台孕育了数据，数据也孕育了平台，在这里面，我们树立了什么样的观点？我觉得是大家要去好好思考的。如果你是数据，你去想想你跟平台的关系。如果你是平台，你去想想你跟数据的关系是什么？这样的关系处理不好以后，基本上是不会有最佳实践的.......

想看更多文章内容：点击这里

原文出处：阿里云大学开发者社区