企业级大数据中台架构实战【3】（数据中台体系）

企业级大数据中台架构实战【3】（数据中台体系）

数据架构目标

大家有没有遇到下面这种情形

情形1:

每个月总有那么几次别人反馈数据不准的问题，并且有些人反映我们的数据，脏，乱，差，不准确，最终导致业务方不满意，对数据团队产生抱怨情绪。

情形2：

取数不断，需求不断，疲于奔命，四处救火，一会这里有问题，一会那里有问题，最终团队内部成为人肉取数机，天天加班，成为了一名真正的SQL-BOY。到了年底考核，你们团队加班最多，但是产出价值最低，考虑到你们还是有苦劳的，给你个中等把，一脸懵逼，还不知道所以然。

聊到这里，上面情形面对的问题是不是我们在设计架构时候，就需要考虑解决的问题。为什么数据不准确，为什么产数据的数据没有价值，得不到业务认可，得不到老板的认可，那么这几个为什么引出的我们的架构目标。

一个数据团队假设有5个人，平均薪水2w，那么对企业来说，一个月的成本10w，一年的人工成本120w，再加上IT成本，至少200w+。企业不会养闲人的。成本在这里，那么我们架构的目标其实也在这里，就是如何减少企业成本，提高效率。数据价值该如何体现，是我们架构的主要目标。

高管会关心目前公司产品运转现状，数据是否录得好的增长，营收情况如何，企业效率是否有所提高。从宏观层面，大数据能够很好概括、监控公司的产品大盘，整体性反馈用户行为。

产品运营会关心，当前用户满意度如何，AB测试下的新功能是否显著有效，产品现有功能是否稳定，用户行为是怎样的，运营活动效果表现如何?从微观层面，大数据能够刻画每类乃至每个用户的行为模式和反馈，并且通过洞察这些行为打造相关的效率工具。

研发、测试和运维会关心，我们所打造所维护的软件服务、系统、客户端是否足够健壮，可用性是否得到保障，各个模块是否反应足够敏捷快速。大数据通过合理的数据埋点，能够轻易勾勒出全链路的产品服务质量，打造企业独有的APM工具系统。

大数据中台架构

为了面向业务服务服务建模，为了整合资源，为了让数据复用，为了让数据的价值得到更好的分析挖掘，为了.....，我们设计了下面大数据中台分层架构。

大数据中台总体分层架构耦合性比较低，分为PAAS(platform as a service)层、 DAAS (data as a service)层、DA(data application)层共三层架构。

数据仓库层可以分为四层，分别是ODS层、 DW层、 DM层、 DA层等。

为什么这样设计?清晰的数据结构，每一个数据分层它的作用域，在使用表的时候能更方便的定位和理解;屏蔽业务的影响，不需要每次业务的变动，就需要重新接入数据，进行计算;屏蔽原始数据的异常，经过前面几层的数据清洗，后续数据分析得到的数据都是非常干净的数据;减少重复开发工作，严格规范数据分层的作用，开发出来一些公共的数据，可以极大的减少数据的重复计算;将复杂的数据统计逻辑简单化，将复杂的任务按照分层，分层一个个任务，每一层只是处理其中的一步，后续数据自测的时候，进行数据准确性校验，同时后续万一数据有问题了，修复问题后重新跑数据，我们没必要把数据数据都跑一遍，只要跑有问题的那一张表后面的任务流程就可以了。

其实最重要的是，我们可以做数据地图，当我们业务部门特别多的时候，我们给他们开发宽表数据，对应的宽表，如果有一张表有问题，我们可以通过数据地图快速的定位找到这张宽表从哪里来的，涉及到哪些数据源，做了哪些清洗等。

各层作用

PAAS层

我们需要考虑，从数据采集，数据处理，数据存储，数据分析挖掘，数据可视化等一些列的组件技术，还包括任务调度，数据建模，数据治理等一些列工具等。

DAAS层

构建离线数据仓库架构和实时数据仓库架构，平台级别。涉及到规范层面，数据库及表的命名规范;业务总线矩阵，明确各个业务所属的分析主题模块，业务过程所属的数据域，一致性维度和事实，数据口径全平台统一;还有维度与业务过程之间关系矩阵等等。

维度建模流程：

首先，需求调研，需求分析，确定分析的业务模块，确定所属的数据域

然后，构建维度事实总线矩阵，明确业务过程;明确业务过程维度之间的关系，同时明确统计指标(原生指标，派生指标)

其次，维度事实模型设计，指标结果表的设计，一般在mysql，hbase，ck等

最后，进行数据准确性校验，上线

DA层

这层主要是数据应用，数据业务化的过程，也是数据价值的输出，同时也是和业务形成完整闭环的过程。一般通过Bi报表将业务的客观数据呈现出来，反映业务的一个现状，提供给业务方做决策支撑。

同时我们还可以做用户画像，运营改善，精细化运营，广告投放，预警，告警，用户价值挖掘等等。

数据来自业务，数据最终也要赋能业务，实现业务数据化，数据资产化，资产服务化，服务业务化，让企业真真切切的达到降本增效。