实时数仓方实际落地如何选型和构建

实时数仓方实际落地如何选型和构建

一、为何需要实时数仓架构

随着数字化进程的推进，企业产生的数据越来越多，与此同时企业对数据的需求也变得越来越复杂多样。如何解决大规模复杂数据的存储和计算，已经成为很多企业必须面对的问题？这值得我们深思。
最初企业存储数据都在数仓中存储，但是随着数据量的增大，传统数据的方案在时效性上和数据维护上变得越来越困难。实时数仓架构应运而生。然而问题并不是这么简单，在具体方案落地上实时数仓有很多方案可以选择，那么面对不同的业务和应用场景我们到底应该选择哪种技术方案呢？这是困扰好多大数据架构师的问题。

二、数仓如何分层&各层用途

数仓一般分为：ODS层、DWD层、DWS层和ADS层。这里我会分别展开说一下。这部分内容大家了解数仓中每层数据的特点即可，具体研发中同学们可以根据项目再做深入体会。

1）ODS层：ODS是数据接入层，所有进入数据的数据首先会接入ODS层。一般来说ODS层的数据是多复杂多样的。从数据粒度上看ODS层是粒度最细的数据层。

2）DWD层：为数据仓库层，数据明细层的数据应是经过ODS清洗，转后的一致的、准确的、干净的数据。DWD层数据粒度通常和ODS的粒度相同，不同的是该层的数据质量更高，字段更全面等。在数据明细层会保存BI系统中所有的历史数据，例如保存近10年来的数据。

3）DWS层：数据集市层，该层数据是面向主题来组织数据的，通常是星形或雪花结构的数据。从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了。

4）ADS层：数据应用层，它是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。其汇总的目标主要是按照应用需求进行的。

三、数仓分层的必要性

数仓分层的总体思路是用空间换时间，其目的是通过数仓分层，使得数仓能够更好地应对需求的变更，和提高数据的稳定性。

1）用空间换时间：通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。

2）能更好地应对需求的变更：如果不分层的话，如果源业务系统的业务规则发生变化，将会影响整个数据清洗过程，工作量巨大。

3）提高数据处理过程的稳定性：通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，每一层的处理逻辑都相对简单和容易理解。

这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。

四、从Lambda架构说起

大部分实时数仓，其实是从Lambda架构演化而来的，因此在介绍实时数仓方案前我们先回顾下Lambda架构。
Lambda架构将数据分为实时数据和离线数据。
针对实时数据使用流式计算引擎进行计算（例如Flink），针对离线数据使用批量计算引擎（例如Spark）计算。然后分别将计算结果存储在不同的存储引擎上对外提供数据服务。

这种架构的优点是离线数据和实时数据各自计算，既能保障实时为业务提供服务，又能保障历史数据的快速分析。它分别结合了离线计算引擎与流式计算引擎二者的优势。

但是有一个缺点是离线数据和实时数据的一致性比较难保障，一般在离线数据产生后会使用离线数据清洗实时数据来保障数据的强一致性。

五、Kappa架构解决哪些问题

接下来要讲的这种架构，它是基于Lambda架构上的优化版本，Kappa架构。这种架构将数据源的数据全部转换为流式数据，并将计算统一到流式计算引擎上。

这种方式的特点使架构变得更加简单，但是不足之处是需要保障数据都是实时的数据，如果数据是离线的话也需要转化为流式数据的架构进行数据处理，具体架构可结合这张图来看。

六、深入实时数仓架构［五种方案讲解］

在正式讨论实时数仓前，我们先看下行业对实时数仓的主要需求，这有助于我们理解实时数仓各种方案设计的初衷，了解它是基于哪些需求应运而生的。

这也将帮助我们从更多维度上思考需求、条件、落地难点等等一些关键要素之间如何评估和权衡，最终实现是基于现有条件下的功能如何将其价值最大化。

传统意义上我们通常将数据处理分为离线的和实时的。对于实时处理场景，我们一般又可以分为两类：

一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；另一类诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可接受。

基于以上查询需求，业界常见的实时数仓方案有这几种。

目前老的项目大部分还在使用的标准分层体现+流计算+批量计算的方案。未来大家可能都会迁移到标准分层体系+流计算+数据湖，和基于全场景MPP数据库实现的方案上。

七、具体选型建议

（1）对于业务简单，且以流式数据为主数据流的大数据架构可以采用Kappa架构。

（2）如果业务以流计算为主，对数据分层，数据权限，多主题数据要求比较高，建议使用方案2的基于标准分层+流计算。

（3）如果业务的流数据是批数据都比较多，且流数据和批数据直接的关联性不大，建议使用方案3的标准分层体现+流计算+批量计算。这种情况下分别能发挥流式计算和批量计算各自的优势。

（4）方案4是一个比较完善的数仓方案，要支持更大规模的和复杂的应用场景，建议大数据研发人员在20以上的团队，可以重点考虑。

（5）对于大数据研发组团队为10人左右，要维护像方案2、3、4那样以ODS、DWD、DWS、ADS数据分层的方式进行实时数仓建设的话，就需要投入更多的资源。建议使用方案5一站式实现简单的实时数仓。

八、大厂方案分享

其实每个大厂根据自己业务特点的不同，也会选择不同的解决方案。下面为大家简要分享下OPPO、滴滴和比特大陆的方案，以便大家能够更好地理解这篇分享中五种架构的具体落地。

举例来说，OPPO的实时计算平台架构，其方案其实类似于方案2的基于标准分层+流计算。

滴滴的大数据平台架构是这样的，它的方案其实类似于方案2的基于标准分层+流计算。

再结合比特大陆的方案看下，其方案类型方案3的标准分层体现+流计算+批量计算，同时也引入了ClickHouse，可以看到比特大陆的数据方案是很复杂的。

九、结语&延伸思考

**本文介绍了市面上常见实时数仓方案，并对不同方案的优缺点进行了介绍。在使用过程中我们需要根据自己的业务场景选择合适的架构。
另外想说明的是实时数仓方案并不是“搬过来”，而是根据业务“演化来”的，具体设计的时候需要根据自身业务情况，找到最适合自己当下的实时数仓架构。**