ZB 级的大数据探索与应用实践「附 PPT」

据报告显示到 2025 年，全球将产生 180ZB 的数据。这些海量的数据正是企业进行数字化转型的核心生产因素，然而真正被有效存储、使用和分析的数据不到百分之十。如何从 ZB 级的数据中寻找分析有价值的信息并回馈到业务发展才是关键。11 月 30 日 UCan 技术沙龙大数据专场（北京站）邀请了 5 位资深大数据技术专家分享他们对大数据的探索和应用实践。

大数据业务常态化的处理手段与架构衍变

很多开发人员在解决实际的业务问题时，经常会面临如何选择大数据框架的困惑。比如有十亿条数据需要进行聚合操作，是把数据放在 HBase+Phoenix 还是 Kudu+Impala 或是 Spark 上进行呢？到底哪种方案才能够达到降低开发运营成本且性能足够高的效果呢？ UCloud 大数据工程师刘景泽分享了他的思考。

要想对数据进行分析决策，首先要有数据来源，其次要将采集到的数据进行存储，然后把这些数据进行汇总、聚合、计算，最后反馈到数据应用层。目前市面上主流的大数据框架有几百种，总结下来主要分为数据采集层、数据存储层、数据计算层和数据应用层。除此之外，一套完整的大数据技术栈还包括了任务调度、集群监控、权限管理和元数据管理。

面对数量众多、种类繁杂的技术栈，选择的自由度很高，但前提是不能把强依赖的框架给拆分开。这里刘景泽给出了一个通用型架构如下图所示：

图中左边 OLTP SDK 指的是后台接口，可以调用很多大数据的服务。从接口或者从 Flume 采集到的数据，直接送到 Kafka，然后送到 ES，再通过 ES 进行建模。整个过程相当于只使用了 ELK 这套系统，虽然很简单，但这也是一个大数据框架。对于数据量比较大、业务范围比较广的公司，往往要求原始数据要做冷备留存，这时 HDFS 就可以作为一个数据冷备的集群，HDFS + Hive 作为冷备也是非常常见的方案。

当业务规模发展到足够大的时候，需要进行一些聚合操作，如果从单独的一个框架拉出来的数据是不完整的，可能需要多个框架同时操作然后进行 join，这样操作的效率非常低。要解决这个问题，可以用大宽表的思路：第一步先把业务数据存放在 MySQL 或者 HBase 里面。然后通过