如何设计企业级大数据分析平台
统企业的OLAP几乎都是基于关系型数据库，在面临“大数据”分析瓶颈，甚至实时数据分析的挑战时，在架构上如何应对?本文试拟出几个大数据OLAP平台的设计要点，意在抛砖引玉。
突破设计原则
建设企业的大数据管理平台(Big Data Management Platform)，第一个面临的挑战来自历史数据结构，以及企业现有的数据库设计人员的观念、原则。数据关系、ACID在关系数据库几十年的统治时期是久得人心，不少开发人员都有过为文档、图片设计数据表，或将文档、图片序列化为二进制文件存入关系数据库的经历。在BDMP之上，我们需要对多种不同的格式的数据进行混合存储，这就必须意识到曾经的原则已经不再适用——One size dosen’t fit all，新的原则——One size fits a bunch.
以下是我列出的一些NoSQL数据库在设计上的模式：
文档数据库：数据结构是类JSON，可以使用嵌入(Embed)或文档引用(Reference)的方式来为两个不同的文档对象建立关系;
列簇数据库：基于查询进行设计，有宽行(Wild Rows)和窄行(Skinny Rows)的设计决策;
索引数据库：基于搜索进行设计，在设计时需要考虑对对每个字段内容的处理(Analysis)。
搜索和查询的区别在于，对返回内容的排序，搜索引擎侧重于文本分析和关键字权重的处理上，而查询通常只是对数据进行单列或多列排序返回即可。
数据存储的二八原则
不少企业在解决海量数据存储的问题上，要么是把关系数据库全部往Hadoop上一导入，要么是把以前的非结构化数据如日志、点击流往NoSQL数据库中写入，但最后往往发现前者还是无法解决大数据分析的性能瓶颈，后者也无法回答数据如何发挥业务价值的问题。
在数据的价值和使用上，其实也存在着二八原则：
20%的数据发挥着80%的业务价值;
80%的数据请求只针对20%的数据。
目前来看，不管是数据存储处理、分析还是挖掘，最完整和成熟的生态圈还是基于关系型数据库，比如报表、联机分析等工具;另外就是数据分析人员更偏重于查询分析语言如SQL、R、Python数据分析包而不是编程语言。
企业大数据平台建设的二八原则是，将20%最有价值的数据——以结构化的形式存储在关系型数据库中供业务人员进行查询和分析;而将80%的数据——以非结构化、原始形式存储在相对廉价的Hadoop等平台上，供有一定数据挖掘技术的数据分析师或数据工程师进行下一步数据处理。经过加工的数据可以以数据集市或数据模型的形式存储在NoSQL数据库中，这也是后面要讲到的“离线”与“在线”数据。
理解企业的数据处理需求
数据库到数据仓库，是事务型数据到分析型数据的转变，分析型数据需要包括的是：分析的主题、数据的维度和层次，以及数据的历史变化等等。而对大数据平台来说，对分析的需求会更细，包括：
查询：快速响应组合条件查询、模糊查询、标签
搜索：包括对非结构化文档的搜索、返回结果的排序
统计：实时反映变化，如电商平台的在线销售订单与发货计算出的库存显示
挖掘：支持挖掘算法、机器学习的训练集
针对不同的数据处理需求，可能需要设计不同的数据存储，还需要考虑如何快速地将数据复制到对应的存储点并进行合适的结构转换，以供分析人员快速响应业务的需求。
离线数据与在线数据
根据不同的企业业务，对“离线”的定义其实不一样，在这里离线数据特指在业务场景中适用于“历史数据”的部分。常见的历史数据查询分析一般来自于特定时间段，设计上需要考虑的是将数据存入历史库中时，建立时间索引。另一种情况是某种业务问题的定位或分析，在数据量巨大的情况下，基于Hadoop或Spark等框架编写分析算法并直接在平台上运行，可以大大节约数据导出导入、格式转换与各种分析工具对接的时间。
在线数据处理按照存储和分析的先后顺序，可分为批处理(先存储后分析)和流处理(先分析后存储)两类。Cassandra数据库的设计采用上数据追加写入模式，可以支持实时批处理;流式计算平台则有Apache Storm、Yahoo S4等开源框架，商业平台有Amazon Kenisis(部署在云端)。企业的实时分析需求往往有特定的应用场景，需要对业务和现行系统有深入的理解才能设计出一个合理的架构。
如何建立完整可用的安全大数据平台
整体而言，大数据平台从平台部署和数据分析过程可分为如下几步：
1、linux系统安装
一般使用开源版的Redhat系统--CentOS作为底层平台。为了提供稳定的硬件基础，在给硬盘做RAID和挂载数据存储节点的时，需要按情况配置。例如，可以选择给HDFS的namenode做RAID2以提高其稳定性，将数据存储与操作系统分别放置在不同硬盘上，以确保操作系统的正常运行。
2、分布式计算平台/组件安装
目前国内外的分布式系统的大多使用的是Hadoop系列开源系统。Hadoop的核心是HDFS，一个分布式的文件系统。在其基础上常用的组件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
先说下使用开源组件的优点：1）使用者众多，很多bug可以在网上找的答案（这往往是开发中最耗时的地方）。2）开源组件一般免费，学习和维护相对方便。3）开源组件一般会持续更新，提供必要的更新服务『当然还需要手动做更新操作』。4）因为代码开源，若出bug可自由对源码作修改维护。
再简略讲讲各组件的功能。分布式集群的资源管理器一般用Yarn，『全名是Yet Another Resource Negotiator』。常用的分布式数据数据『仓』库有Hive、Hbase。Hive可以用SQL查询『但效率略低』，Hbase可以快速『近实时』读取行。外部数据库导入导出需要用到Sqoop。Sqoop将数据从Oracle、MySQL等传统数据库导入Hive或Hbase。Zookeeper是提供数据同步服务，Yarn和Hbase需要它的支持。Impala是对hive的一个补充，可以实现高效的SQL查询。ElasticSearch是一个分布式的搜索引擎。针对分析，目前最火的是Spark『此处忽略其他，如基础的MapReduce 和 Flink』。Spark在core上面有ML lib，Spark Streaming、Spark QL和GraphX等库，可以满足几乎所有常见数据分析需求。
值得一提的是，上面提到的组件，如何将其有机结合起来，完成某个任务，不是一个简单的工作，可能会非常耗时。
3、数据导入
前面提到，数据导入的工具是Sqoop。用它可以将数据从文件或者传统数据库导入到分布式平台『一般主要导入到Hive，也可将数据导入到Hbase』。
4、数据分析
数据分析一般包括两个阶段：数据预处理和数据建模分析。
数据预处理是为后面的建模分析做准备，主要工作时从海量数据中提取可用特征，建立大宽表。这个过程可能会用到Hive SQL，Spark QL和Impala。
数据建模分析是针对预处理提取的特征/数据建模，得到想要的结果。如前面所提到的，这一块最好用的是Spark。常用的机器学习算法，如朴素贝叶斯、逻辑回归、决策树、神经网络、TFIDF、协同过滤等，都已经在ML lib里面，调用比较方便。
5、结果可视化及输出API
可视化一般式对结果或部分原始数据做展示。一般有两种情况，行熟悉展示，和列查找展示。在这里，要基于大数据平台做展示，会需要用到ElasticSearch和Hbase。Hbase提供快速『ms级别』的行查找。 ElasticSearch可以实现列索引，提供快速列查找。
平台搭建主要问题：
1、稳定性 Stability
理论上来说，稳定性是分布式系统最大的优势，因为它可以通过多台机器做数据及程序运行备份以确保系统稳定。但也由于大数据平台部署于多台机器上，配置不合适，也可能成为最大的问题。 曾经遇到的一个问题是Hbase经常挂掉，主要原因是采购的硬盘质量较差。硬盘损坏有时会到导致Hbase同步出现问题，因而导致Hbase服务停止。由于硬盘质量较差，隔三差五会出现服务停止现象，耗费大量时间。结论：大数据平台相对于超算确实廉价，但是配置还是必须高于家用电脑的。
2、可扩展性 Scalability
如何快速扩展已有大数据平台，在其基础上扩充新的机器是云计算等领域应用的关键问题。在实际2B的应用中，有时需要增减机器来满足新的需求。如何在保留原有功能的情况下，快速扩充平台是实际应用中的常见问题。
上述是自己项目实践的总结。整个平台搭建过程耗时耗力，非一两个人可以完成。一个小团队要真正做到这些也需要耗费很长时间。
目前国内和国际上已有多家公司提供大数据平台搭建服务，国外有名的公司有Cloudera，Hortonworks，MapR等，国内也有华为、明略数据、星环等。另外有些公司如明略数据等还提供一体化的解决方案，寻求这些公司合作对 于入门级的大数据企业或没有大数据分析能力的企业来说是最好的解决途径。
对于一些本身体量较小或者目前数据量积累较少的公司，个人认为没有必要搭建这一套系统，暂时先租用AWS和阿里云就够了。对于数据量大，但数据分析需求较简单的公司，可以直接买Tableau，Splunk，HP Vertica，或者IBM DB2等软件或服务即可。
