企业网站备案需要哪些资料,网站开发主要参考文献,中国建设银行手机银行,wordpress建手机网站在本文中阿里云资深产品专家云郎分享了基于阿里云 MaxCompute 构建企业云数据仓库CDW的最佳实践建议。
本文内容根据演讲视频以及PPT整理而成。 大家下午好#xff0c;我是云郎#xff0c;之前在甲骨文做企业架构师8年#xff0c;目前是MaxCompute产品经理。 在这么长的客户…在本文中阿里云资深产品专家云郎分享了基于阿里云 MaxCompute 构建企业云数据仓库CDW的最佳实践建议。
本文内容根据演讲视频以及PPT整理而成。 大家下午好我是云郎之前在甲骨文做企业架构师8年目前是MaxCompute产品经理。 在这么长的客户工作过程中作为产品PD一定是跟客户在一起的。我经常被一些问题挑战:云郎我们现在要建数据仓库我该怎么去规划云郎我现在这边是大数据的建设团队好像数据团队不怎么理我什么情况云郎我们这边现在建了一个平台现在性能好像有问题是不是我们哪些地方设计的有问题还是考虑的不够可以看到不同的客户在不同的阶段有不同的问题在这么多的客户问题里背后到底隐藏了什么规律在这里面有没有一些最佳实践我们可以总结出来让大家去少走一些弯路这是我的出发点。 既然谈到最佳实践你一定要知道哪些不是最佳实践就像医生一定要看过很多病人以后才更容易判断是不是健康。 我的客户从哪里来呢 第一是阿里巴巴本身有很多个BU刚才我们也谈到了阿里巴巴所有的数据都是运行在MaxCompute去做数据仓库去做加工处理。也许你会挑战我你解决阿里的问题我们碰不到没错我也确实发现这个问题即使我们能解决阿里的问题但是不一定能解决客户的问题。 第二我们碰到的问题也不一定能代表客户的问题因为你的规模和我不一样、你的现状和我不一样、你的能力和我不一样、你的目标和我不一样。MaxCompute也在云上提供服务我们云上有很多客户在座的很多朋友都是MaxCompute的用户。所以我把客户的范围进一步纳入到我目前已有的这些客户里面。也许你还会问你说你是最佳实践那是基于你自己产品的最佳实践难道他不用你的产品你就不能再去分析吗 所以我又分析了第三类客户在中国有很多企业使用了非阿里的技术那么他们在这大数据方面又碰到了哪些问题我相信在座各位也做过很多分享例如A公司的大数据实践经验 B公司的大数据演进历程那么我们也会基于这样的案例做出分析。 第四在阿里这样的一个生态里收购了很多公司在外界公司和阿里内部公司融合迁移的过程中又有哪些最佳实践 所以我们把这四类客户统一起来看从现象到本质这是今天我想要跟大家分享的内容。 大家都在谈大数据最早在2013年开始在甲骨文做信息解决方案当时已经研究出了大数据。我在之前是做DB的Data Base。后来发现转了个身转成了BDBig Data。在这个过程中技术好像做了个变化就翻了个身关涛讲了很多大家很有体会。那这些技术在过程中怎么去用方法有没有发生变化客户经常问我一个问题云郎我要拿MaxCompute来干什么我说了不算后来我就做了很多分析。我发现不管去做什么应用客户在MaxCompute之上他首先主要都是在构建他的数据仓库现在我们把它叫作Cloud Data Warehouse大家知道数据仓库它既是一套数据体系同时它也是一个工程过程要更多的从工程的角度来看我们看到这是现在目前业界非常典型的数据仓库实时的生命周期流程。我们发现技术从Data BaseDB转到了BD但是这张图很多还被广泛的应用当我跟很多客户的架构师大数据负责人或者开发人员去沟通的时候我们发现他背后的思路都是沿着这张设计的生命周期而产生的。那我们可以看到从这个数据仓库当碰到Cloud Native再到我们说转到Big Data以后那么怎么真的去做Cloud Native这样一个Data Warehouse我们看到在这个过程中从项目的工程规划到业务需求到最终我们看到一个小的迭代维护数仓开发完成交付大家去使用。 在这个过程中我们可以看到传统的DB时代是以建设为中心的一个项目。那么到了大数据建了是生下来养才是关键。养之道在于什么呢在于运营。所以整个环节中我们可以看缺失了大数据的精髓所在。 我们看分别是哪些情况呢
第一我相信很多人来自于互联网公司如果你来自央企、政府部门恭喜你你可能没有这个痛苦因为你有足够的时间去规划给你半年时间给你500万你帮我做规划咨询出来。但你如果是互联网公司对不起今天上岗明天帮我把数据拿出来好不好所以我们是没有那么多时间的。那我们在这里面需要做到什么呢轻量化我们从数据仓库整个生命周期上我们要的是敏捷数仓。那软件工程我们要的是敏捷开发数据仓库。 第二对于需求的问题为什么你能做规划因为你能知道后面会发生什么你的业务基本上是固定的你能知道政府部门后面要干什么、你能知道央企后面要干什么但如果你是互联网公司你到明年存不存在都还不一定也就是说你可能还没规划完就要转型了业务要转型了需求非常不明确那你能不能做到明确挑战非常大。 第三如果我们规划出来一个非常完美复杂的技术方案它的落地周期会给我们带来挑战所以我们需要技术上能否简化要快速才是王道。 第四关于数据建模你一开始就想把这些模型都建立起来其实这是很多数据工程师经常碰到的问题我有这么多数据我全部都能把它灌进来把这个模型固化下来。我们发现掉到这个井里以后带来的后果是什么呢你长长久久的是技术自己关在门里边结果业务在门外边他敲你的门永远敲不开因为我还在做数据模型的事情我还在做我自己的事情。 我们可以看到关于数仓的应用你建了大数据绝对不是传统的把DB转成BD你就仍然去做报表你的场景绝不是这么简单。在这里一定还有机器学习人工智能、预测等众多的应用它才能发挥价值。这是一个迭代的过程。可能按月都是对这个模型比较赞美的因为往往可能三个月是一个周期从提出一个需求到最后实现在传统里可能需要月的时间。今天按小时、按天帮我实现我的数据仓库要发生变化你怎么去构造 还有就是运维这一侧开发人员和运维人员能做到咱们今天的所谓的DevOps如果你是数据开发人员怎么样能做到整个大数据平台的DevOps这是很大一个挑战。 在以项目管理为中心、以建设为中心这样的背景下我们可以看到真正的数据运营是被忽视的所以这是我们今天整个要引出的话题就是数据的价值一定要通过运营才能得以呈现。运营又是什么概念呢 企业大数据计算平台的建设跟我们人的发展一样刚开始谈恋爱蜜月期非常好其实很多锅碗瓢盆的问题是不用考虑的。但随着建设的发展结婚生小孩锅碗瓢盆的问题一定要考虑的所以不同的问题其实考虑的痛苦点不一样。
我们看到这样一个时间轴横轴以时间来推动第一个月六到十二个月十二个到十八个月到第二十四个月在分析了上百家的企业客户后我们看到在这样一个周期里分别会碰到什么样的问题技术方案不一样但痛苦是一样的风险是一样的这是横轴。 纵轴业务规模是这条黄色的线风险是蓝色线。业务在这里面能包出来的半径就是我们所谓的价值蓝线包起的面积就是我们的风险刚才关涛也谈到了说我们的业务面积和风险面积哪一个更大这就决定了我们的成败。我们看到这样一张图在第一个月是蜜月期大部分客户都可以快速的通过定制化方案快速启动数据仓库因为是蜜月期非常快这个时候有热情、有投资、有人手我们快速一个月搞起来了。到了半年到十二个月业务上来了、规模上来了这个时候要搭火箭了要快速成长了进入青春期了青春期这个地方是有一个火箭的这个火箭跟小孩子的成长一样到青春期有两个方面你管得好他就是一个人才管得不好他可能就变成了一个混混。那这个火箭就在于往哪条线上走。 随着业务大规模的扩展数据量、计算量急速增长这个时候就给我们的性能、成本带来了巨大的挑战和要求系统能不能解决持续的发展矛盾就成本、性能、数据安全和分析效率里面的矛盾随着我们业务的发展我们现在碰到这些问题该怎么去解决在整个风险上升的过程中我们看到这条线是说风险在上升的。上升了以后有很多公司包括我们的客户可以看到在这个之后就会启动一轮治理和优化包括性能的优化、成本的优化通过阶段性的优化达到好的效果。 接下来业务还在不断发展我们可以看到在这两条线里面又会走向风险失控的过程中也就是说我们的系统在这个时候变成了成本中心。我们过去因为有钱有想法开发了很多定制化的系统这个时候你的人员开始流动了你所有定制化的系统就变成了什么黑盒子你碰都不敢碰就放在这儿等等SOS这是风险演变的过程。 对于我们而言最佳实践显然是不能走这条路的我们要避免这样一条弯路。 再进一步的思考对我们做的这样一个平台经过治理和优化还不够。如果我们能转型再造其实可以回到一个好的状态健康最佳实践的状态。那这个转型再造以阿里大数据平台来说有两个重要的转型再造第一个是技术的转型再造大家也知道我们是最早使用云梯一Hadoop我们从技术的转型再造就是变成我们的备胎MaxCompute其实在2013年在阿里内部早就转正了最近备胎很火它在最初是备胎。转型再造由自己的技术来替换升级。 接下来就是业务阿里这样的规模我们内部的技术可以输出到阿里云上来进行业务的转型。我们获得了这样新生的过程可以看到在整个风险转移过程中大家是在哪一个位置我们要有清晰的认识。我们期望的是我们的技术和业务都可持续发展。在这个里面的核心点要解决的是成本可控和性能的不断提升。数据越多不是变慢而一定要更快。数据既要安全还要共享。大家知道数据进来谁都不能碰是没有用的要让数据价值要得到充分体现。 所以我们看到整个建设数据平台的阶段性风险在这个里面大家都会栽跟头包括我们都会碰到很多困难。运用《三体》的一句话“在这些拐点上毁灭你与你无关。”真的是等不及的。对这样一些客户的实质性的洞察我提出一个新的方法论不知大家有没有钓过鱼有没有钓过大鱼钓小鱼时是把鱼钩和鱼绳是直接拴在一起的因为小鱼的力量不会那么猛。但如果你做过海钓钓大鱼的时候你有没有发现如果你的鱼钩和鱼绳是直接拴在一起的那个鱼咬了饵以后把钩挂住以后它会突然有一个很大的力你的鱼绳是直的所以它会把你的鱼绳直接崩掉造成系统崩溃在这个里面就会出现这样的问题钓过鱼的人就会有这样的经验。 但是这里面是有解决方案的鱼绳上大家都知道是有一个8字环绕线法把这个线绕得比较虚一点当这个鱼咬到我的钩拉的时候它不会直接拉后面的鱼绳它会用力用到8字环缓冲的这一段线它突然间把这一段线拉紧了那一段线是多股绕在一起的会有更大的抗击力这时候大鱼上钩以后这个线就不会断了。 平台和数据有没有这样一种过程我们的平台和数据刚才那一个过程是完全独立的我只考虑建设平台不考虑数据。但是我们看到在更多的企业里面平台是一个团队数据是一个团队或者平台有很多拨人数据有很多拨人但不管怎样平台就是平台数据就是数据我们说平台和数据的关系就是我中间画的一个阴阳图。所以在这里面可以看到我们不是简单的把平台和数据的工作拼在一起它就是8字环。我们可以看到8字环的奥妙在于从平台的策略与规划、设计与实现这是两步。你有了最初的原型以后有了基础平台以后马上要进入数据运营。大家可以看到第三步要在这个里面有简单的数据要去发现让数据人员去分析理解、要去探索、要去资产化、要去运营到了这一步之后再回到我们的平台侧去进行开发运维再进行优化治理。
平台和数据是对立的还是说平台孕育了数据数据也孕育了平台在这里面我们树立了什么样的观点我觉得是大家要去好好思考的。如果你是数据你去想想你跟平台的关系。如果你是平台你去想想你跟数据的关系是什么这样的关系处理不好以后基本上是不会有最佳实践的。 所以第一个是要解决敏捷性的问题因为你在这里面可以很快进入数据阶段从而更敏捷。同时我们要避免刚才说的拉钩断掉的问题。要连接平台和数据释放平台对数据的支撑力平台本来对数据有很好的支撑力怎么能释放出来这是我们要考虑的。 还有一个是“风险”我们要通过这种方式不断的实践、验证将风险消化在日常中。而非做了一个3年规划到第二年才发现风险是巨大的。 针对如上内容给出几点建议。
你是否试图通过大数据解决未知问题还是天天在做已知的报表你是否有去做预测是否有做机器学习是否有对预测性问题的分析你是否有去引入外部数据来解决问题大家也可以看到刚才我为了要回答最佳实践作为一个产品经理他要去获得的数据源不仅限于阿里内部客户和云上客户如果我不能去看那些使用了非阿里大数据客户的情况的话他本身也不是一个大数据思维的工作方式所以我觉得它是一个思考的模式无处不在。你对待数据的态度。很多时候数据处理完就没事了。其实你在这里面不断的探索、挖掘、分析其中他人不知道的问题这才是价值。你能发现问题、解决问题就是价值价值不是虚的问题能解决了就是有价值。但是我们做了吗在这个过程当中你也许会说人家没有给我提需求如果别人提了需求你来做这叫支撑。如果你能发现问题让别人去做这叫驱动。什么叫数据驱动型如果这些事情我们都不干它不就是一个虚无飘渺的东西吗关于我们组织的问题虽然说我们在做大数据但是我们对它的态度是什么呢每个人在谈PPT的时候都会说数据是资产从来没有人说服务器是资产。但是你做的时候你一定会说“我没有服务器我怎么能活呢我怎么能做事情呢”我们看到就变成这样一个模式在这种模式下你可以看到貌似数据无处不在但是数据到处不能用因为到处都是孤岛。我们可以看到在数据驱动型的组织里面整个业务本身是受数据驱动的比如说蚂蚁金服所以你的数据在中间业务在外面。这样的情况下你才可能把本末倒置的问题解决掉这是关于组织的问题。 我们对驱动组织做了一个分类数据支撑了我们运营、生产最基本的工作还是支撑了我们的管理工作还是对决策起到了作用到底在哪一个层面上一定要基于可持续发展的策略进行规划以终为始去想这个问题这个终可能是一年、两年、也可能是三年。阿里有句话路走对了就不怕远。但是我们走错了本来往东的就走西了。在规划阶段要看四个方面。
第一TCO和TVOTCO是我们整体运营的成本我们要花的钱。TVO是我们想要得到的价值是什么第二技术方案。第三可持续发展。第四风险控制。
挑重点来说第一大家都谈到TCO我觉得大家要注意财务的结构不同的公司的喜好程度是不一样的有的希望现金流更充足有的希望一下子能把钱花出去。要符合企业财务的成本结构也就是说你要把它变成一次性的资产支出还是变成日常的运营支出要想清楚企业要的是什么如果这个搞不清楚后面就是很大的矛盾。 第二在这个过程中不要忽视隐性支出要知道隐性成本是什么的不能对隐性成本是视而不见的。TVO我们要以终为始兑现数据的业务价值。 做大数据的同学不管是做数据还是做平台如果我们不能帮助企业兑现数据的业务价值可能很快就会面临残酷的结果。这里的价值就是我们通过支撑业务、驱动业务也罢你一定要挖掘出数据的价值的。 关于技术方案。说到定制化通常因为我们后面看到了风险定制化就变成黑盒。我们说定制化和产品化的边界要考虑清楚。当我们无限的扩充自己定制化边界以后你要想到有一天这些东西变成黑盒子以后它意味着什么另外你是选择服务器还是无服务器我们的聚焦点是平台还是数据这是大家要去考虑。 还有业务适配不要总是推倒重来。风险应尽早暴露大家知道规划出来都是PPT文档文档里面都是坑你越晚执行坑就埋得越久前面滚雪球滚得很大了后面解决起来成本就非常大了。跟软件开发缺陷解决的原理是一样的。这个里面一定要有风险意识。 关于规划在设计阶段要支持快速的实现。并非要求你一天做到但在互联网行业去做可能两周、一个月往往三个月就是个阶段能快速实现三个月真的是一个很长的时间。
架构的设计从全面性、系统、链路这都是很美好的事情但是我真心给出建议是够用就好了不要过度设计。 技术选型在PoC我们要找的是什么好用、能用、不能用你要在这个里面找到它们的边界、它们的拐点。你总是找每个系统里面最好的那一点但是你不知道这个里面不可用的点在哪里我举一个例子大家就明白了就是你评测这个系统的时候你要知道它哪个地方更好哪个地方好用、哪个地方能用、哪个地方不能用当有人承诺所有都是最好用的时候你就一定要注意。要避免定制化部分的滚雪球避免定制化陷阱。 在落地实现方面举个例子数据增量对开发者而言做数据开发时比如我写一个数据的生产过程那时候的数据量很小你不会考虑分区。180天以后因为你没有考虑外延它慢慢就增多到180倍了这个最佳实践大家是要留意的。后面我们的团队也会总结出来一个技术方面的最佳实践。包括数据倾斜、作业调度与安全模型、细粒度这些大家都要考虑到。 在数据价值呈现中要结合我们的数据探索和模型固化因为数据仓库都是讲模型固化的一定要有模型。但是模型大家知道周期会变长、会变得僵化、业务会变得不灵活所以我们一定要把模型固化和数据探索结合起来结合刚才那位同学关注的数据混合和数据仓库的关系在我看来数据仓库更适合做模型这一块的工作数据混合往往更适合去做数据探索。你可以在数据探索中很快的发觉隐藏的问题更快速的进行数据分析但也会面临挑战数据授权、产出是问题。因为你无法把你所有的数据都放在里面让每个人想看什么就看什么。数据仓库我们拼了命的做安全仍然受到大家的挑战这是现实问题。
探索之后如何更敏捷的做数据仓库呢那么你通过这个里面探索出来的模型来提高复用通过复用来提升效率。通过模型传播知识例如我如何了解我客户的活跃程度呢我们通过模型拿到这个模型以后另外一个同学也就理解了这个模型里面藏的是知识。还有降低成本所以我们把Schema、Schema less这两种结合起来将会进一步提高我们数据处理分析的敏捷性。
还有就是数据资产化否则的话你永远都说不清楚你自己的价值你其实在帮别人做一个什么呢你是在做别人成本的事情你只有把它资产化了做数据的人才能说清楚自己的价值在哪里。通过资产化可以做什么要为治理提供依据你只有列得清清楚楚了才知道哪个地方花多了、哪个地方花少了花得健康不健康要有这样健康排名。有了这个排名我们就可以做数据运营。
很多时候数据运营被解释成数据化运营。数据化运营和数据运营是截然不同的概念。数据化运营是指拿了数据以后去做运营工作。数据运营指的是说要把我的数据运营起来。这里可以结合货币的概念流动性。要提高数据的流动性提高在数据管理团队以外的投放量这是很金融化的一个词我在准备的时候就是看了金融的模型来做这个事情。因为要解决流动性的问题金融行业最有经验所以我也看了模型。
投放量我们可以看到这是我们的数据管理团队大家都像小蜜蜂一样很勤劳数据获取、加工组织、存储。。。小蜜蜂和蜂王都很勤快。那猫头鹰在哪里呢这个图怎么没显示出来做数据分析的人不是小蜜蜂应该是猫头鹰非常敏锐眼睛很毒。数据分析要发现、要探索、要应用、要建模在这里通过数据运营核心要做什么呢控制数据的流动性变化趋势你的数据谁在用流到哪个地方去你现在公司的数据流动性你要采取紧缩政策还是宽松政策我们一定要把这个事情做起来你可以通过数据安全来做也可以通过专门的团队来做如果没有这部分就会有风险。 关于数据安全、数据生产管理、数据质量管理、开发管理我们也要做到适可而止不要过度。以安全为例最初的时候我作为MaxCompute PD给客户推荐 MaxCompute是有细粒度安全管理的你一定要用上。后来客户慢慢教育了我细粒度的安全管理固然很好但他到用的那一天他自然会用。他没用的那一天固然有他的理由。因为任何管理越细成本就越高。企业是否愿意在这方面投资这就是一个现实的问题。如果我没有那么多的投资势必就会考虑把数据的授权范围做到以部门、团队为授权对象授权粒度以一个项目为主就够了。所以要平衡细粒度安全管理和管理成本并做出选择。包括生产管理基线开发环境质量管理等一定要在管理上将责任落实到人还要实现完善的监督机制去确保这个能落实保证数据质量。
优化和治理往往是个沉重的话题。先说我们的城市以前谈城市管理现在谈城市治理。城市小的时候管理就够了城市大了就要治理了治理什么三个字脏乱差。就像我们的系统大到一定程度后也会出现脏乱差。所以需要治理要从计算层面、存储、质量、模型、安全、成本方面进行全方位治理这当中最有效的抓手就是成本。在整个治理的闭环中有现状分析、问题诊断、治理、优化、效果反馈这些我们都要去落实才能根本上治理脏乱差。
最后我们来看基于MaxCompute构建大数据平台。从数据开发是一套Dataworks的平台通过接入业务数据源到数据接入、到数据处理、数据服务以及到应用这是一个完整的大数据解决方案。在整个大数据平台中我们强调小核心、大外围。其实在大数据平台中数据处理占据了80%以上的成本所以一定要让它简单。阿里基于这样一个策略推出了完整的解决方案。处理方面有MaxCompute机器学习方面有PAI在流计算方面我们有Stream Compute。
刚才谈到的关于数据那部分内容这是平台、这是数据由这张图映射到刚才我们说的数据中孕育着平台、平台中孕育着数据的这样一个设计理念。在上面这是以数据为中心的在下面这是以平台为中心的整个合成我们想要的大数据处理平台。 同时我们也分析了很多客户很多客户都已经选择了Hadoop。所以我们也推出了MMA迁移工具和迁移服务来帮助我们把Hadoop这样的集群迁移到阿里云的MaxCompute和Dataworks以及后面的机器学习PAI、流计算等等来帮助我们加速、提效、提高准确性。
最后总结一下从方法到落地我背后的思想就是8字环。这边是数据、这边是平台。平台侧一定要支持按需裁减的方案。在这个过程中要分阶段实施整个过程中性能、成本、灵活扩展性、数据的安全以及稳定运维的复杂度是我们要关注的问题。数据侧我们要关注并打通数据的全链路要关注全域数据以及数据资产化。
总之通过我们背后的指导思想和我们给出的技术解决方案希望与大家能够一起探索一些新的基于云上的数据仓库构建的最佳实践从而尽量避免走弯路。这就是所有我今天想跟大家分享的内容与目的非常感谢 欢迎加入“MaxCompute开发者社区2群”,点击链接申请加入或扫描二维码https://h5.dingtalk.com/invite-page/index.html?bizSource____source____corpIddingb682fb31ec15e09f35c2f4657eb6378finviterUidE3F28CD2308408A8encodeDeptId0054DC2B53AFE745
本文为阿里云原创内容未经允许不得转载。
云栖号 - 上云就看云栖号
