大数据分析的下一代的架构的思考

这些年随着hadoop和大数据以及去IOE的流行，很多公司开始着手将第一代的BI系统迁往大数据平台。oracle里边的数据量越来越大，很多的报表已经无法通过oracle计算出来，而oracle成本地增加也促使他们开始追逐大数据的风。

第一代的IOTA的架构主要是lambda的架构，目前很多公司依然在往这条的道路上迁移。典型的Lambda架构主要解决两个方面实时计算与离线计算。下图是典型的Lambda的架构图。

从上图我们可以看到其实数据进入包含两块一个是类似传统的BI比如数据库的数据通过ETL的工具进入到大数据平台然后进行ETL的计算，另外的一块主要是类似点击流IOT等实时的数据通过流处理的工具进行计算。无论是实时计算还是离线的计算，最终用户要拿到计算的结果都是通过结果数据库提供给堆外的用户系统去使用。

经过多年的实践这一套方法已经在很多公司落地成熟，但是随着数据量的越来越大这种问题也是越来越突出。

一般而言ETL计算的都是T+1的报表，大部分是在晚上12点钟之后开始抽取相关数据库的数据然后开始计算，当数据量越来越大的时候报表计算的时间就会变长，第二天早上看到报表的时间也会相应推迟甚至跑不出来。

实时在白天计算的数据跟T+1计算的数据有出入

数仓的架构必然会产生大量的中间表，这导致大数据平台数据集聚膨胀。

针对以上的问题Linkedin 提出了kappa的相关思想，希望通过流去统一相关的计算。

基本的架构图如下稍微做了一些改动。

那如何用流计算系统对全量数据进行重新计算，步骤如下：

1、用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。

2、当需要全量计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。

3、当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除。

这种方法的认可度很低，主要是有以下的缺点。

历史数据和实时数据计算都通过流计算计算量太大，资源消耗太多

实时的计算严重依赖外部的redis等组件，资源消耗巨大

所以按照目前业界对数据的实时性越来越高的要求以及数据量越来越大的趋势，我觉得未来应该是统一的计算模式，而不再分离线与实时的这种方式。具体的架构图如下：

其实我们都知道当你要建立通用的实时流计算你必须统一处理格式，否则每来一种格式你就解析一下，这种服务与交互方式是无法想象的。原来数据库的抽取的方式无非就是采用类似jdbc将数据select出来，这种方式一般都是T+1的方式，因为业务数据库一般白天服务的时候不让你动。那实时数据的获取一般是通过log获取如mysql的binlog与oracle的redolog。那为何不把这些传输的数据格式进行统一。同样的点击流，日志的获取方式也可以进行协议的统一。

如果实时的获取数据不成问题那么，接下来便是计算。通过相关的ad-hoc计算引擎对数据进行实时计算，并每隔一段时间将数据通过dumper将数据归档到历史数据库当中，可以在一张表下建实时和离线的目录，ad-hoc可以自由选择需要计算的区域。

除此之外其实我们知道目前的移动端和web端其实是具备一定的计算能力的，可以通过server对前端埋点的SDK计算配置，让前端对相关的数据进行预计算。同样的通过ad-hoc的计算结果也可以通过sdkserver推送回去进行实时的反馈。

其实目前已经有一些比较不错的ad-hoc引擎在像这个方向上努力。笔者目前了解的有palo,indexR等。之后有时间可以深入剖析下ad-hoc引擎。虽然去ETL似乎还很远，需求和渴望就在哪，技术的方向就在哪！