海量数据的挑战：数据分析平台架构
【IT168 技术】 本文的作者谢超是 Admaster 数据挖掘总监， 云计算实践者， 10 年数据仓库和数据挖掘咨询经验，现专注于分布式平台上的海量数据挖掘和 机器学习。
以下是文章全文：
随着互联网、 挪移互联网和物联网的发展， 谁也无法否认， 我们已经切实地 迎来了一个海量数据的时代，数据调查公司 IDC 估计 2022 年的数据总量将达到 1.8 万亿 GB，对这些海量数据的分析已经成为一个非常重要且紧迫的需求。
作为一家互联网数据分析公司， 我们在海量数据的分析领域那真是被“逼上 梁山”。 多年来在严苛的业务需求和数据压力下， 我们几乎尝试了所有可能的大 数据分析方法，最终落地于 Hadoop 平台之上。
Hadoop 在可伸缩性、茁壮性、计算性能和成本上具有无可替代的优势，事 实上已成为当前互联网企业主流的大数据分析平台。本文主要介绍一种基于  Hadoop 平台的多维分析和数据挖掘平台架构。
大数据分析的分类
Hadoop 平台对业务的针对性较强，为了让你明确它是否符合你的业务，现 粗略地从几个角度将大数据分析的业务需求分类， 针对不同的具体需求， 应采用 不同的数据分析架构。
1、按照数据分析的实时性，分为实时数据分析和离线数据分析两种。
实时数据分析普通用于金融、 挪移和互联网 B2C 等产品， 往往要求在数秒内 返回上亿行数据的分析，从而达到不影响用户体验的目的。要满足这样的需求， 可以采用精心设计的传统关系型数据库组成并行处理集， 或者采用一些内存计 算平台， 或者采用 HDD 的架构， 这些无疑都需要比较高的软硬件成本。 目前比较 新的海量数据实时分析工具有 EMC 的 Greenplum、SAP 的 HANA 等。
对于大多数反馈时间要求不是那末严苛的应用， 比如离线统计分析、 机器学 习、搜索引擎的反向索引计算、推荐引擎的计算等，应采用离线分析的方式，通 过数据采集工具将日志数据导入专用的分析平台。但面对海量数据，传统的ETL 工具往往彻底失效， 主要原因
是数据格式转换的开消太大， 在性能上无法满足海 量数据的采集需求。互联网企业的海量数据采集工具，有 Facebook 开源的    Scribe、LinkedIn 开源的 Kafka、淘宝开源的 Timetunnel、Hadoop 的 Chukwa  等，均可以满足每秒数百 MB 的日志数据采集和传输需求，并将这些数据上载到 Hadoop 中央系统上。
2、按照大数据的数据量，分为内存级别、 BI 级别、海量级别三种。

这里的内存级别指的是数据量不超过集的内存最大值。不要小看今天内存 的容量， Facebook 缓存在内存的Memcached 中的数据高达 320TB，而目前的 PC 服务器，内存也可以超过百 GB。因此可以采用一些内存数据库，将热点数据常 驻内存之中， 从而取得非常快速的分析能力， 非常适合实时分析业务。 图 1 是一 种实际可行的 MongoDB 分析架构。
转播到腾讯微博
图 1 用于实时分析的 MongoDB 架构
MongoDB 大集目前存在一些稳定性问题， 会发生周期性的写阻塞和主从同 步失效，但仍不失为一种潜力十足的可以用于高速数据分析的 NoSQL。
此外， 目前大多数服务厂商都已经推出了带 4GB 以上 SSD 的解决方案， 利用 内存+SSD，也可以轻易达到内存分析的性能。 随着 SSD 的发展， 内存数据分析必 然能得到更加广泛的应用。
BI 级别指的是那些对于内存来说太大的数据量，但普通可以将其放入传统 的 BI 产品和专
门设计的 BI 数据库之中进行分析。目前主流的 BI 产品都有支持 TB 级以上的数据分析方案。种类繁多，就不具体列举了。
海量级别指的是对于数据库和 BI 产品已经彻底失效或者成本过高的数据  量。 海量数据级别的优秀企业级产品也有不少， 但基于软硬件的成本原因， 目前 大多数互联网企业采用 Hadoop 的 HDFS 分布式文件系统来存储数据，并使用  MapReduce 进行分析。本文稍后将主要介绍 Hadoop 上基于MapReduce 的一个多 维数据分析平台。
3、数据分析的算法复杂度
根据不同的业务需求， 数据分析的算法也差异巨大， 而数据分析的算法复杂 度和架构是密切关联的。举个例子， Redis 是一个性能非常高的内存 Key-Value NoSQL，它支持 List 和 Set、SortedSet 等简单集合，如果你的数据分析需求简 单地通过排序，链表就可以解决，同时总的数据量不大于内存(准确地说是内存 加之虚拟内存再除以 2)，那末无疑使用 Redis 会达到非常惊人的分析性能。
还有不少易并行问题(Embarrassingly Parallel)，计算可以分解成彻底独 立的部份， 或者
很简单地就能改造出分布式算法， 比如大规模脸部识别、 图形渲 染等，这样的问题自然是使用并行处理集比较适合。

而大多数统计分析，机器学习问题可以用 MapReduce 算法改写。 MapReduce
目前最擅长的计算领域有流量统计、推荐引擎、趋势分析、用户行为分析、数据 挖掘分类器、分布式索引等。
面对大数据 OLAP 分析的一些问题
第 2 页：  面对大数据 OLAP 分析的一些问题
OLAP 分析需要进行大量的数据分组和表间关联，而这些显然不是 NoSQL 和 传统数据库的强项，往往必须使用特定的针对 BI 优化的数据库。比如绝大多数 针对 BI 优化的数据库采用了列存储或者混合存储、压缩、延迟加载、对存储数据 块的预统计、分片索引等技术。
Hadoop 平台上的 OLAP 分析，同样存在这个问题， Facebook 针对Hive 开辟 的 RCFile 数据格式，就是采用了上述的一些优化技术，从而达到了较好的数据 分析性能。如图 2 所示。
转播到腾讯微博
图 2 RCFile 的行列混合存
然而，对于 Hadoop 平台来说，单单通过使用 Hive 摹仿出 SQL，对于数据分 析来说远远不够，首先 Hive 虽然将 HiveQL 翻译MapReduce 的时候进行了优化， 但依然效率低下。 多维分析时依然要做事实表和维度表的关联， 维度一多性能必 然大幅下降。其次， RCFil
e 的行列混合存储模式，事实上限制死了数据格式， 也就是说数据格式是针对特定分析预先设计好的，一旦分析的业务模型有所改 动，海量数据转换格式的代价是极其巨大的。最后， HiveQL 对 OLAP 业务分析人 员依然是非常不友善的，维度和度量才是直接针对业务人员的分析语言。
而且目前 OLAP 存在的最大问题是：业务灵便多变，必然导致业务模型随之 时常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube(多 大数据etl工具有哪些维立方体)重新定义并重新生成， 业务人员只能在此 Cube 上进行多维分析， 这样 就限制了业务人员快速改变问题分析的角度，从而使所谓的 BI 系统成为死板的 日常报表系统。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。