cube大数据

⑴ 如何架构大数据系统 hadoop

Hadoop在可伸缩性、健壮性、计算性能和成本上具有无可替代的优势，事实上已成为当前互联网企业主流的大数据分析平台。本文主要介绍一种基于Hadoop平台的多维分析和数据挖掘平台架构。作为一家互联网数据分析公司，我们在海量数据的分析领域那真是被“逼上梁山”。多年来在严苛的业务需求和数据压力下，我们几乎尝试了所有可能的大数据分析方法，最终落地于Hadoop平台之上。
1. 大数据分析大分类
Hadoop平台对业务的针对性较强，为了让你明确它是否符合你的业务，现粗略地从几个角度将大数据分析的业务需求分类，针对不同的具体需求，应采用不同的数据分析架构。
按照数据分析的实时性，分为实时数据分析和离线数据分析两种。
实时数据分析一般用于金融、移动和互联网B2C等产品，往往要求在数秒内返回上亿行数据的分析，从而达到不影响用户体验的目的。要满足这样的需求，可以采用精心设计的传统关系型数据库组成并行处理集群，或者采用一些内存计算平台，或者采用HDD的架构，这些无疑都需要比较高的软硬件成本。目前比较新的海量数据实时分析工具有EMC的Greenplum、SAP的HANA等。
对于大多数反馈时间要求不是那么严苛的应用，比如离线统计分析、机器学习、搜索引擎的反向索引计算、推荐引擎的计算等，应采用离线分析的方式，通过数据采集工具将日志数据导入专用的分析平台。但面对海量数据，传统的ETL工具往往彻底失效，主要原因是数据格式转换的开销太大，在性能上无法满足海量数据的采集需求。互联网企业的海量数据采集工具，有Facebook开源的Scribe、LinkedIn开源的Kafka、淘宝开源的Timetunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求，并将这些数据上载到Hadoop中央系统上。
按照大数据的数据量，分为内存级别、BI级别、海量级别三种。
这里的内存级别指的是数据量不超过集群的内存最大值。不要小看今天内存的容量，Facebook缓存在内存的Memcached中的数据高达320TB，而目前的PC服务器，内存也可以超过百GB。因此可以采用一些内存数据库，将热点数据常驻内存之中，从而取得非常快速的分析能力，非常适合实时分析业务。图1是一种实际可行的MongoDB分析架构。

图1 用于实时分析的MongoDB架构
MongoDB大集群目前存在一些稳定性问题，会发生周期性的写堵塞和主从同步失效，但仍不失为一种潜力十足的可以用于高速数据分析的NoSQL。
此外，目前大多数服务厂商都已经推出了带4GB以上SSD的解决方案，利用内存+SSD，也可以轻易达到内存分析的性能。随着SSD的发展，内存数据分析必然能得到更加广泛的应用。
BI级别指的是那些对于内存来说太大的数据量，但一般可以将其放入传统的BI产品和专门设计的BI数据库之中进行分析。目前主流的BI产品都有支持TB级以上的数据分析方案。种类繁多，就不具体列举了。
海量级别指的是对于数据库和BI产品已经完全失效或者成本过高的数据量。海量数据级别的优秀企业级产品也有很多，但基于软硬件的成本原因，目前大多数互联网企业采用Hadoop的HDFS分布式文件系统来存储数据，并使用MapRece进行分析。本文稍后将主要介绍Hadoop上基于MapRece的一个多维数据分析平台。
数据分析的算法复杂度
根据不同的业务需求，数据分析的算法也差异巨大，而数据分析的算法复杂度和架构是紧密关联的。举个例子，Redis是一个性能非常高的内存Key-Value NoSQL，它支持List和Set、SortedSet等简单集合，如果你的数据分析需求简单地通过排序，链表就可以解决，同时总的数据量不大于内存（准确地说是内存加上虚拟内存再除以2），那么无疑使用Redis会达到非常惊人的分析性能。
还有很多易并行问题（Embarrassingly Parallel），计算可以分解成完全独立的部分，或者很简单地就能改造出分布式算法，比如大规模脸部识别、图形渲染等，这样的问题自然是使用并行处理集群比较适合。
而大多数统计分析，机器学习问题可以用MapRece算法改写。MapRece目前最擅长的计算领域有流量统计、推荐引擎、趋势分析、用户行为分析、数据挖掘分类器、分布式索引等。
2. 面对大数据OLAP大一些问题

OLAP分析需要进行大量的数据分组和表间关联，而这些显然不是NoSQL和传统数据库的强项，往往必须使用特定的针对BI优化的数据库。比如绝大多数针对BI优化的数据库采用了列存储或混合存储、压缩、延迟加载、对存储数据块的预统计、分片索引等技术。

Hadoop平台上的OLAP分析，同样存在这个问题，Facebook针对Hive开发的RCFile数据格式，就是采用了上述的一些优化技术，从而达到了较好的数据分析性能。如图2所示。
然而，对于Hadoop平台来说，单单通过使用Hive模仿出SQL，对于数据分析来说远远不够，首先Hive虽然将HiveQL翻译MapRece的时候进行了优化，但依然效率低下。多维分析时依然要做事实表和维度表的关联，维度一多性能必然大幅下降。其次，RCFile的行列混合存储模式，事实上限制死了数据格式，也就是说数据格式是针对特定分析预先设计好的，一旦分析的业务模型有所改动，海量数据转换格式的代价是极其巨大的。最后，HiveQL对OLAP业务分析人员依然是非常不友善的，维度和度量才是直接针对业务人员的分析语言。
而且目前OLAP存在的最大问题是：业务灵活多变，必然导致业务模型随之经常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube（多维立方体）重新定义并重新生成，业务人员只能在此Cube上进行多维分析，这样就限制了业务人员快速改变问题分析的角度，从而使所谓的BI系统成为死板的日常报表系统。
使用Hadoop进行多维分析，首先能解决上述维度难以改变的问题，利用Hadoop中数据非结构化的特征，采集来的数据本身就是包含大量冗余信息的。同时也可以将大量冗余的维度信息整合到事实表中，这样可以在冗余维度下灵活地改变问题分析的角度。其次利用Hadoop MapRece强大的并行化处理能力，无论OLAP分析中的维度增加多少，开销并不显著增长。换言之，Hadoop可以支持一个巨大无比的Cube，包含了无数你想到或者想不到的维度，而且每次多维分析，都可以支持成千上百个维度，并不会显著影响分析的性能。


而且目前OLAP存在的最大问题是：业务灵活多变，必然导致业务模型随之经常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube（多维立方体）重新定义并重新生成，业务人员只能在此Cube上进行多维分析，这样就限制了业务人员快速改变问题分析的角度，从而使所谓的BI系统成为死板的日常报表系统。
3. 一种Hadoop多维分析平台的架构
整个架构由四大部分组成：数据采集模块、数据冗余模块、维度定义模块、并行分 析模块。

数据采集模块采用了Cloudera的Flume，将海量的小日志文件进行高速传输和合并，并能够确保数据的传输安全性。单个collector宕机之后，数据也不会丢失，并能将agent数据自动转移到其他的colllecter处理，不会影响整个采集系统的运行。如图5所示。

数据冗余模块不是必须的，但如果日志数据中没有足够的维度信息，或者需要比较频繁地增加维度，则需要定义数据冗余模块。通过冗余维度定义器定义需要冗余的维度信息和来源（数据库、文件、内存等），并指定扩展方式，将信息写入数据日志中。在海量数据下，数据冗余模块往往成为整个系统的瓶颈，建议使用一些比较快的内存NoSQL来冗余原始数据，并采用尽可能多的节点进行并行冗余；或者也完全可以在Hadoop中执行批量Map，进行数据格式的转化。

维度定义模块是面向业务用户的前端模块，用户通过可视化的定义器从数据日志中定义维度和度量，并能自动生成一种多维分析语言，同时可以使用可视化的分析器通过GUI执行刚刚定义好的多维分析命令。
并行分析模块接受用户提交的多维分析命令，并将通过核心模块将该命令解析为Map-Rece，提交给Hadoop集群之后，生成报表供报表中心展示。
核心模块是将多维分析语言转化为MapRece的解析器，读取用户定义的维度和度量，将用户的多维分析命令翻译成MapRece程序。核心模块的具体逻辑如图6所示。

图6中根据JobConf参数进行Map和Rece类的拼装并不复杂，难点是很多实际问题很难通过一个MapRece Job解决，必须通过多个MapRece Job组成工作流（WorkFlow），这里是最需要根据业务进行定制的部分。图7是一个简单的MapRece工作流的例子。

MapRece的输出一般是统计分析的结果，数据量相较于输入的海量数据会小很多，这样就可以导入传统的数据报表产品中进行展现。

⑵ 如何架构大数据系统 hadoop

大数据数量庞大，格式多样化。大量数据由家庭、制造工厂和办公场所的各种设备、互联网事务交易、社交网络的活动、自动化传感器、移动设备以及科研仪器等生成。它的爆炸式增长已超出了传统IT基础架构的处理能力，给企业和社会带来严峻的数据管理问题。因此必须开发新的数据架构，围绕“数据收集、数据管理、数据分析、知识形成、智慧行动”的全过程，开发使用这些数据，释放出更多数据的隐藏价值。

一、大数据建设思路

1）数据的获得

四、总结

基于分布式技术构建的大数据平台能够有效降低数据存储成本，提升数据分析处理效率，并具备海量数据、高并发场景的支撑能力，可大幅缩短数据查询响应时间，满足企业各上层应用的数据需求。

⑶ 大数据BI里面大家都有提到Cube，有的提倡打Cube，有的说不打Cube，到底哪个才是最好的

各有各的好处，如果你的大数据产品不能直接处理超大数据量，通过打cube的方式能够减低系统压力，如果能够运算足够多的数据，当然是不打cube的方式更好！
首先，不打cube能够让你的分析层的数据更厚，分析的结果也就更准确；其次，也能让你的数据分析更加灵活，因为原始的数据全部都能调配出来，进行运算，当你的分析需求改变的时候，不会因为cube造成分析的阻碍，这点我觉得很重重要，当每次的业务部门分析需求发生变化时如果都需要数周或数月的重新搭建，将造成很大的损失，都说商场如战场，争分夺秒嘛。
目前国内传统的打cube的大数据产品很多，不打cube的，敏捷型的产品也有，比如永洪科技的大数据产品，就是很不错的，在面对国内某电信行业巨头大规模超过百亿级的数据分析需求时，永洪的产品也能有很好的表现。当然也不是所有公司都能有百亿级的数据产生，但是灵活的需求分析，以及厚重的数据层都将是所有数据分析非常重要的组成部分，如果不灵活将会失去分析的先机或分析的意义，如果数据层过薄将严重影响分析的准确性。
如果一定要说的话，永洪科技那种那么不打cube的大数据BI才是行业发展的趋势，应该是要远远优于传统BI的模式的。

⑷ 大数据在金融行业有哪些典型应用

大数据在金融领域中有哪些应用？应用很广，定价、授信、风控领域尤其多，我这边主要用到的分析软件是单位的帆软FineBI系统，应用案例随便说两个： 车险。其实根据车主的日常行车路线、里程、行车习惯、出险记录、职业、年龄、性别，可以给出非常不同的定价。比如一个开中级车，每天固定路线往返几公里通勤的熟练女白领车主，和一个开同样车型每天在珠三角或者长三角跑生意的中年暴躁小老板车主，假设后者出险概率是前者的3倍，那么完全可以定3倍于前者的价格（商业部分）。对于保险公司，前者才是优质客户，后者做了生意也是赔钱货，不如赶到竞争对手那里去。 贷款。现在各种小额贷款、消费贷款、供应链金融，都是在吃4大行懒得吃的散客市场，之所以他们懒得吃，就是怕麻烦。最麻烦的就是授信环节，对于一个没有固定资产等担保物的客户，能授信多少额度是个问题。淘宝能做小微是因为商家的流水在他们手里，白领的消费贷敢做是因为有稳定的现金流收入。但除了淘宝可以做到比较准确的模型，其他的业务都非常的粗放，基本每个领域都是根据几条死规则来做业务。这意味着这个市场还有很大的潜力可以挖掘，比如一个小老板，其实风险不大，他需要100w周转，但你没把握估算他的风险，只敢贷50w出去，就少赚了那50w的利息。

⑸ 大数据分析界的“神兽”Apache Kylin有多牛

1.Apache Kylin是什么？

在现在的大数据时代，越来越多的企业开始使用Hadoop管理数据，但是现有的业务分析工具（如Tableau，Microstrategy等）
往往存在很大的局限，如难以水平扩展、无法处理超大规模数据、缺少对Hadoop的支持；而利用Hadoop做数据分析依然存在诸多障碍，例如大多数分析
师只习惯使用SQL，Hadoop难以实现快速交互式查询等等。神兽Apache Kylin就是为了解决这些问题而设计的。

Apache Kylin，中文名麒（shen）麟（shou） 是Hadoop动物园的重要成员。Apache
Kylin是一个开源的分布式分析引擎，最初由eBay开发贡献至开源社区。它提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持大
规模数据，能够处理TB乃至PB级别的分析任务，能够在亚秒级查询巨大的Hive表，并支持高并发。

Apache
Kylin于2014年10月在github开源，并很快在2014年11月加入Apache孵化器，于2015年11月正式毕业成为Apache顶级项
目，也成为首个完全由中国团队设计开发的Apache顶级项目。于2016年3月，Apache
Kylin核心开发成员创建了Kyligence公司，力求更好地推动项目和社区的快速发展。

Kyligence是一家专注于大数据分析领域创新的数据科技公司，提供基于Apache
Kylin的企业级智能分析平台及产品，以及可靠、专业、源码级的商业化支持；并推出Apache Kylin开发者培训，颁发全球唯一的Apache
Kylin开发者认证证书。

2.Kylin的基本原理和架构

下面开始聊一聊Kylin的基本原理和架构。简单来说，Kylin的核心思想是预计算，即对多维分析可能用到的度量进行预计算，将计算好的结果保
存成Cube，供查询时直接访问。把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询，这决定了Kylin能够拥有很好的快速查询和高并发能
力。

上图所示就是一个Cube的例子，假设我们有4个dimension，这个Cube中每个节点（称作Cuboid）都是这4个dimension
的不同组合，每个组合定义了一组分析的dimension（如group
by），measure的聚合结果就保存在这每个Cuboid上。查询时根据SQL找到对应的Cuboid，读取measure的值，即可返回。

为了更好的适应大数据环境，Kylin从数据仓库中最常用的Hive中读取源数据，使用
MapRece作为Cube构建的引擎，并把预计算结果保存在HBase中，对外暴露Rest
API/JDBC/ODBC的查询接口。因为Kylin支持标准的ANSI
SQL，所以可以和常用分析工具（如Tableau、Excel等）进行无缝对接。下面是Kylin的架构图。

说到Cube的构建，Kylin提供了一个称作Layer Cubing的算法。简单来说，就是按照dimension数量从大到小的顺序，从Base
Cuboid开始，依次基于上一层Cuboid的结果进行再聚合。每一层的计算都是一个单独的Map Rece任务。如下图所示。

MapRece的计算结果最终保存到HBase中，HBase中每行记录的Rowkey由dimension组成，measure会保存在
column
family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有
良好的快速响应和高并发。

有了这些预计算的结果，当收到用户的SQL请求，Kylin会对SQL做查询计划，并把本该进行的Join、Sum、Count Distinct等操作改写成Cube的查询操作。

Kylin提供了一个原生的Web界面，在这里，用户可以方便的创建和设置Cube、管控Cube构建进度，并提供SQL查询和基本的结果可视化。

根据公开数据显示，Kylin的查询性能不只是针对个别SQL，而是对上万种SQL 的平均表现，生产环境下90%ile查询能够在在3s内返回。在上个月举办的Apache Kylin

Meetup中，来自美团、京东、网络等互联网公司分享了他们的使用情况。例如，在京东云海的案例中，单个Cube最大有8个维度，最大数据条数4亿，最
大存储空间800G，30个Cube共占存储空间4T左右。查询性能上，当QPS在50左右，所有查询平均在200ms以内，当QPS在200左右，平均
响应时间在1s以内。

北京移动也在meetup上展示了Kylin在电信运营商的应用案例，从数据上看，Kylin能够在比Hive/SparkSQL在更弱的硬件配置下获得更好的查询性能。 目前，有越来越多的国内外公司将Kylin作为大数据生产环境中的重要组件，如ebay、银联、网络、中国移动等。大家如果想了解更多社区的案例和动态，可以登录Apache Kylin官网或Kyligence博客进行查看。

3.Kylin的最新特性

Kylin的最新版本1.5.x引入了不少让人期待的新功能，可扩展架构将Kylin的三大依赖（数据源、Cube引擎、存储引
擎）彻底解耦。Kylin将不再直接依赖于Hadoop/HBase/Hive，而是把Kylin作为一个可扩展的平台暴露抽象接口，具体的实现以插件的
方式指定所用的数据源、引擎和存储。

开发者和用户可以通过定制开发，将Kylin接入除Hadoop/HBase/Hive以外的大数据系统，比如用Kafka代替Hive作数据源，用
Spark代替MapRece做计算引擎，用Cassandra代替HBase做存储，都将变得更为简单。这也保证了Kylin可以随平台技术一起演
进，紧跟技术潮流。

在Kylin
1.5.x中还对HBase存储结构进行了调整，将大的Cuboid分片存储，将线性扫描改良为并行扫描。基于上万查询进行了测试对比结果显示，分片的存
储结构能够极大提速原本较慢的查询5-10倍，但对原本较快的查询提速不明显，综合起来平均提速为2倍左右。

除此之外，1.5.x还引入了Fast
cubing算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Recer，从而降低对网络瓶颈的压力。对500多个Cube任务
的实验显示，引入Fast cubing后，总体的Cube构建任务提速1.5倍。

目前，社区正在着手准备Apache Kylin 1.5.2版本的发布，目前正处于Apache Mailing list投票阶段，预计将会在本周在Kylin官网发布正式下载。

在本次的1.5.2版本中，Kylin带来了总计
36个缺陷修复、33个功能改进、6个新功能。一些主要的功能改进包括对HyperLogLog计算效率的提升、在Cube构建时对Convert
data to hfile步骤的提速、UI上对功能提示的体验优化、支持hive view作为lookup表等等。

另一个新消息是Kylin将支持MapR和CDH的Hadoop发行版，具体信息可见KYLIN-1515和KYLIN-1672。相应的测试版本是MapR5.1和CDH5.7。

UI上提供了一个重要更新，即允许用户在Cube级别进行自定义配置，以覆盖kylin.properties中的全局配置。如在cube中定义kylin.hbase.region.count.max 可以设置该cube在hbase中region切分的最大数量。

另
一个重要的功能是Diagnosis。用户经常会遇到一些棘手的问题，例如Cube构建任务失败、SQL查询失败，或Cube构建时间过长、SQL查询时
间过长等。但由于运维人员对Kylin系统了解不深，很难快速定位到root cause所在地。我们在mailing
list里也经常看到很多用户求助，由于不能提供足够充分的信息，社区也很难给出一针见血的建议。

当用户遇到查询、Cube/Model管理的问题，单击System页面的Diagnosis按钮，系统会自动抓取当前Project相关的信息并打包成
zip文件下载到用户本地。这个包会包含相关的Metadata、日志、HBase配置等。当用户需要在mailing
list求助，也可以附上这个包。

⑹ 大数据量更新

已经建立来唯一索引了，多个进程是没有源问题的。服务器也是有交换量的。你可以在服务器上设置一下网络交换量，让更多的系统资源参与数据交换。然后进程数也不是越多越好，开太多了服务器拖不动反而慢。我感觉2~4个是最快的。