企业如何选择数据分析架构？——谈谈3种架构的利弊
anyushan 2019-07-01
在之前的文章《讲透大数据，我只需要一顿饭》里，我用做饭这件大家身边的事情来介绍了大数据及数据分析工程，应该能够让大家对数据分析这件看上去很专业的行业有了一定的认识，很高兴的是文章也得到了很多数据圈专业人士的共鸣和互动。
这篇文章我们会顺着之前的思路，稍微深入一点，聊聊数据分析架构。
什么叫数据分析架构，说的通俗点，其实就是数据采集（买菜）、数据建模（配菜）、数据加工（炒菜）、数据分析（吃菜）这些数据分析流程应该如何划分功能模块（专业化分工），才能方便灵活、规模化、最大化的满足广大数据消费者（吃货）的数据分析（美食）需求。
就好比吃饭这件事，我们可以自己在厨房里做，去饭店吃，或者叫外卖等不同方式，这几种吃饭方式是人类生活方式的一种进化，更是通过不同的专业化分工满足了吃货们不同时期、不同层次的需求。
而数据分析作为一件相对来说比吃饭更专业的事情，也同样需要通过流程设计和专业化分工来满足更广泛的数据消费需求，我们通常叫做架构设计。
闲话少说，先直接上图，我把迄今为止的数据分析架构的历史简单分为三个阶段：
企业如何选择数据分析架构？——谈谈3种架构的利弊
数据分析1.0阶段：业务报表
这个阶段是数据分析的初始阶段。随着数据库技术的出现，企业纷纷开始信息化建设，业务流程信息化沉淀了大量数字化的业务数据，而数据分析的需求其实大家一直都有，既然有了数据沉淀，通过这些数据进行报表统计和数据分析的需求自然就出现了。
1.0阶段，数据分析开始萌芽，数据加工、报表统计都在业务系统里直接进行的（数据产生和数据分析都在同一个系统里进行，所以这个时候还没有数据采集一说）。这就好比自己在家里做饭吃，可以想象，由于食材（数据）、厨房（数据库资源）、手艺（专业能力）等方面的限制，吃饭的体验不会太好，主要满足吃饱（报表统计）的需求。
当然现代业务报表有了很大的改变，比如帆软finereport一类的报表工具，可以跨业务系统、跨数据库取数做报表做分析，甚至对接数据集市、数据仓库（接下来我正要说）。
企业如何选择数据分析架构？——谈谈3种架构的利弊
finereport制作的dashboard
数据分析2.0阶段：数据集市
由于在业务系统里直接做数据分析体验不好，还可能会影响正常的业务流程，而企业数据分析的需求越来越完善，业务人员自然而然的希望在业务系统之外专门搭建一个用于数据分析的独立新系统，既能用于支持数据分析，又可以不影响正常的业务流程，于是，数据集市应运而生。
从数据集市开始，数据分析开始作为一个正式的行业出现，出现了从业务系统到数据集市的数据采集和传输（买菜）需求，另外，数据加工，数据分析等专业岗位和从业人员开始出现。
这就好比饭店的出现使得在吃饭这件事上出现了专业化分工，同时也开创了餐饮行业。饭店里有人专门买菜，配菜，炒菜，大厨开始出现，这一方式很好的满足了广大吃货在省事、美食选择、口感方面的需求，体验自然是棒棒的。
数据分析2.5阶段：数据仓库
随着企业数据分析活动如火如荼的开展，数据集市开始越建越多，同样的数据加工逻辑、指标等难免在分散的数据集市里被重复计算，浪费计算资源不说，经常就会出现数据统计口径不一致的问题，让领导们不知道自己该相信哪个数据。
这就好比饭店开的多了，同样的菜品在不同的饭店里难免会雷同，但是同一个“鱼香肉丝”不同饭店做出来的的口味难免会不一样，吃货们肯定会迷惑哪家才是最正宗的，也希望知道哪个才是最好吃的。
这个时候，数据仓库概念应运而生。
数据仓库为了解决数据集市分散建设带来的数据不一致、重复计算浪费资源等问题，提倡以一个集中式平台来统一进行数据采集、数据清洗、数据加工，并且向外部提供各种数据分析产品和服务。
数据仓库算是开创了数据分析史真正意义上的一个时代，对数据分析行业的发展和成熟有着不可磨灭的贡献：
诞生了专门的数据仓库技术（MPP，massively parallel processing）以及一大批相关的专业厂商，来解决大量数据需要集中进行存储、加工和分析的技术难题
发展了体系化的数据仓库系统建设方法论和最佳实践
培养了一大批数据仓库从业人员(DWer)
既然，数据仓库时代在数据分析史上有着如此重要的地位，并且在今天仍然有着深远的影响，那么，问题来了。
为什么数据仓库阶段只是2.5而不是3.0呢？
首先，从架构的角度来看，个人认为数据仓库相对于数据集市并没有本质的区别，这个从上面的“数据分析架构发展的三个阶段”图中也能看出来，数据集市和数据仓库的架构是非常相似的，数据仓库可以简单的认为是一个超级数据集市，区别只在于规模，这就好比为了规范菜品质量，让大家能够一站式吃到各种五花八门的菜品，我们开了个超级大饭店，虽然这个饭店很大，但仍然是个饭店。
其次，数据仓库以解决数据集市数据分散、数据口径不统一为目标，提出了打造企业级统一业务视图的愿景（The single view of business ），其建设方法强调数据采集规范化，数据管理标准化以及数据加工流程化，这种建设思路从数据管理的角度来说是非常有价值的，产出了很多成熟的数据管理规范和数据治理方法论。
但......是......
从数据分析的角度来看，虽然数仓系统的建设的确一定程度上满足了业务部门的数据分析需求，然而，传统数据仓库建设方法在灵活的支持各种数据需求、敏捷的响应分析请求、普及企业数据驱动的分析文化方面，却始终心有余而力不足。
造成这种情况，虽然有着技术、成本方面的原因，但架构耦合性高、建设方法过于僵化也是重要原因，比如：
数据仓库集中式的平台架构方式，将数据加工和数据服务都通过一个平台来支持，必然会造成资源竞争，无法兼顾。这就好比一个饭店里，后厨占得地方太大，堂食的空间就小了，能够同时响应的消费者数量必然受到限制。
数据仓库的数据加工是层层递进、环环相扣的方式，有着严格的加工流程，并且涉及到多个角色的互相配合，任何一个数据分析需求，从需求的提出到最终实现，快的要好几周，慢的要好几个月，自然是跟不上业务的快速变化。客户到了饭店，只要是想点个菜单上没有的菜品，饭店都需要把买菜、洗菜、配菜、炒菜这些环节都走一遍，上菜起码得等2、3个小时甚至是第二天才有，没有哪个消费者能忍受的了吧。
很多数仓采用数据驱动的建设方式，不管是不是需要的数据，先往仓库里放，总觉得以后会用的上，导致仓库规模极速膨胀，并且存在大量无产出数据，运维成本和难度非常大。就好像开个饭店不管客人喜欢吃什么，先把能买到的菜都买来，抛开成本不说，光是运输、清洗、仓储的工作量就能把人给耗死。
数仓建设有着成熟完善的数据治理配套理论，什么元数据管理、数据标准管理、数据质量管理等等，但是这些理论的落地往往最走变成了一纸规范，却没法和数据仓库建设过程有机的结合，最后变成了你定你的规范，我建我的系统，或者是我先建系统，你再定规范，随着系统越来越庞大，没人能够很清楚的知道仓库里到底有什么，整个数仓自然就变的难以管理和使用。
于是，虽然数据仓库进行了数十年的发展，很多企业也是花了大量的人力和成本来进行数据仓库系统的建设，但缺乏敏捷性的平台建设方式，自主选择少，服务响应慢，各类数据消费者的满意度始终都不高。
因此，慢慢的，很多企业中的数据仓库系统，开始变得有点古代皇宫御膳房的味道，汇集各种食材，对于食材、流程、样式有着严格的加工规范，充分保证了菜品的质量和水准，但是其上菜速度、翻台率以及能够服务的食客数量都受到了极大的限制，所以只有能力为特定群体（皇家）提供各种特定的菜品。
企业如何选择数据分析架构？——谈谈3种架构的利弊
所以，虽然数据仓库对于数据存储、数据采集、数据加工、数据治理这些方面发展了成熟的方法论（相当于专业的饭店后厨管理理论），但对于满足各种灵活、敏捷、普及的数据分析需求，其作用一直是被诟病的。
而进入到今天的大数据时代，这个弊病就更加的明显。
大数据浪潮带来的挑战不仅仅是数据量的爆发式增长，更重要的是把个人、企业、政府对数据、数据分析的重视性提升到了前所未有的高度，整个社会对数据分析的需求也呈现爆发式的增长。所以，Gartner提出了平民数据科学家（citizen data scientist）的概念，更有厂商和业内大牛喊出了“人人都是数据分析师”的口号。
企业如何满足成千上万的内部员工对于数据分析的需求？企业如何满足千万级以上的外部客户对于数据分析的需求？政府如何满足上亿的社会大众对于数据分析的需求？这成了大数据时代的数据架构师们需要去回答的问题。
可以说，用户日益增长的数据分析需求与落后的数据服务能力之间的矛盾已经成为大数据时代的主要矛盾。
所以，数据仓库强调数据加工流程而忽视数据服务效率，过于严苛、繁琐的建设方法，数据开发与数据治理脱节的问题，使得其难以快速进行规模化扩展，也就无法应对爆发式的数据分析和数据服务需求，抛开技术、成本上的限制不说，传统数仓的建设方法论显然也是无法解决大数据时代的主要矛盾的。
那，大数据时代，大数据分析架构的出路在哪呢？什么样的数据平台建设方法才是最有效的？是否可以在数据仓库成熟的建设方法论上进行改造来应对爆发式的数据分析需求？
