什么是大数据采集平台？_百度知道
什么是大数据采集平台？
我有更好的答案
未至科技数据中心解决方案是以组织价值链分析模型为理论指导，结合组织战略规划和面向对象的方法论，对组织信息化战略进行规划重造立足数据，以数据为基础建立组织信息化标准，提供面向数据采集、处理、挖掘、分析、服务为组织提供一整套的基础解决方案。未至数据中心解决方案采用了当前先进的大数据技术，基于Hadoop架构，利用HDFS、Hive、Impala等大数据技术架构组件和公司自有ETL工具等中间件产品，建立了组织内部高性能、高效率的信息资源大数据服务平台，实现组织内数亿条以上数据的秒级实时查询、更新、调用、分析等信息资源服务。未至数据中心解决方案将，为公安、教育、旅游、住建等各行业业务数据中心、城市公共基础数据库平台、行业部门信息资源基础数据库建设和数据资源规划、管理等业务提供了一体化的解决方案。
采纳率：95%
你需要这方面的数据吗？
为您推荐：
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。51CTO旗下网站
为什么选择这样的大数据平台架构？
大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。
作者：傅一平来源：| 13:10
当前BAT基本公开了其大数据平台架构，从网上也能查询到一些资料，关于大数据平台的各类技术介绍也不少，但在那个机制、那个环境、那个人才、那个薪酬体系下，对于传统企业，可借鉴的东西也是有限的。
技术最终为业务服务，没必要一定要追求先进性，各个企业应根据自己的实际情况去选择自己的技术路径。
与传统的更多从技术的角度来看待大数据平台架构的方式不同，笔者这次，更多的从业务的视角来谈谈关于大数据架构的理解，即更多的会问为什么要采用这个架构，到底能给业务带来多大价值，实践的最终结果是什么。
它不一定具有通用性，但从一定程度讲，这个架构可能比BAT的架构更适应大多数企业的情况，毕竟，大多数企业，数据没到那个份上，也不可能完全自研，商业和开源的结合可能更好一点，权当抛砖引玉。
大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个&能用&原则，清晰且容易理解，能指导建设，这里将大数据平台划分为&五横一纵&。
具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。
何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。
同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。
数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。
数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。
数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习等。
数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。
数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。
数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。
1、数据采集层，这是基础。
离线批量采集，采用的是HADOOP，这个已经成为当前流线采集的主流引擎了，基于这个平台，需要部署数据采集应用或工具。
诸如BAT都是自己研发的产品，一般企业，可以采用商用版本，现在这类选择很多，比如华为BDI等等，很多企业技术实力有，但起步的时候往往对于应用场景的理解比较弱，细节做工很差，导致做出来的产品难以达到要求，比如缺乏统计功能等，跟BAT差距很大，传统企业去采购这类产品，要谨慎小心。
一个建议是，当采购产品的时候，除了技术先进性和指标外，更多的应该问问是版本啥时候上线的，是否在哪里成功部署，是否有足够多的客户，如果能做个测试就更好，否则，你就是小白鼠哦，这个坑踩了不少。
能做和做成产品是两个境界的事情，小的互联网企业当然也能做出对于自己好用的采集工具，但它很难抽象并打造出一个真正的产品，BAT自研其实形成了巨大的优势。
实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。
除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。
爬虫当前也逐渐成为很多企业的采集标配，因为互联网新增数据主要靠它，可以通过网页的解析获取大量的上网信息，什么舆情分析、网站排名啥的，建议每个企业都应该建立企业级的爬虫中心，如果它未在你的大数据平台规划内，可以考虑一下，能拿的数据都不拿，就没什么好说了。
企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。
还有一个就是，如果有可能，笔者建议将数据采集平台升级为数据交换平台，因为其实企业内有大量的数据流动，不仅仅是单向的数据采集，而且有很多数据交换，比如需要从ORACLE倒数据到GBASE，从HBASE倒数据到ASTER等等，对于应用来讲，这个价值很大。
既然数据采集和数据交换有很多功能非常类似，为什么不做整合呢?也便于统一管理，感觉企业的数据交换大量都是应用驱动，接口管理乱七八糟，这也是我的一个建议。
总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求：
多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集(使用flume、消息队列、OGG等技术)和批量数据分布式采集等能力(SQOOP、FTP
VOER HDFS)，比基于传统ETL性能有量级上的提升，这是根本。
可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低采集难度，每配置一个数据接口耗时很短，以降低人工成本。
统一调度管控能力：实现采集任务的统一调度，可支持Hadoop的多种技术组件(如 MapReduce、Spark 、HIVE)、关系型数据库存储过程、
shell脚本等，支持多种调度策略(时间/接口通知/手工)。
2、数据处理层，现在有个词叫混搭，的确是这样。
Hadoop的HIVE是传统数据仓库的一种分布式替代。应用在传统ETL中的数据的清洗、过滤、转化及直接汇总等场景很适合，数据量越大，它的性价比越高。但目前为止看，其支撑的数据分析场景也是有限的，
简单的离线的海量分析计算是它所擅长的，相对应的，复杂的关联交叉运算其速度很慢。
一定程度讲，比如企业客户统一视图宽表用HIVE做比较低效，因为涉及到多方数据的整合，但不是不可以做，最多慢点嘛，还是要讲究个平衡。
hadoop到了X000台集群的规模也撑不住了,当前很多企业的数据量应该会超过这个数量，除了像阿里等自身有研发能力的企业(比如ODPS)，是否也要走向按照业务拆分Hadoop集群的道路?诸如浙江移动已经拆分了固网、移网、创新等多个hadoop集群。
Hadoop的SPARK的很适合机器学习的迭代，但能否大规模的应用于数据关联分析，能否一定程度替代MPP，还需要实践来验证。
MPP应该来说，是采用分布式架构对于传统数据仓库最好的替代，毕竟其实际上是变了种的关系型数据库，对于SQL提供完整支持，在HIVE做了转化分析后，数据仓库的融合建模用它来做性能绰绰有余，其性价比较传统DB2更好一点，比如经过实用，Gbase30-40台集群就能超过2台顶配的IBM
MPP现在产品很多，很难做优劣判断，但一些实践结果可以说下，GBASE不错，公司很多系统已经在上面跑了，主要还是国产的，技术服务保障相对靠谱，ASTER还有待观望，自带一些算法库是有其一些优势，GreenPlum、Vertica没用过，不好说。
现在有个说法是MPP最终也要被Hadoop那套框架替代，毕竟诸如SPARK啥的都在逐步稳定和成熟，但在短期内，我觉得还是很靠谱的，如果数据仓库要采用渐进的演化方式，MPP的确是很好的选择。
现在诸如中国移动，eBAY等大量公司都在采用这类混搭结构，以适应不同的应用场景，显然是一种自然的选择。
大数据平台的三驾马车，少不了流处理。
对于很多企业来讲，其显然是核武器般的存在，大量的应用场景需要它，因此务必要进行建设，比如在IOE时代不可想象的实时、准实时数据仓库场景，在流处理那里就变得很简单了，以前统计个实时指标，也是很痛苦的事情，当前比如反欺诈实时系统，一天系统就申请部署好了。
只尝试过STORM和IBM STREAM，推荐IBM
STREAM，虽然是商业版本，但其处理能力超过STORM不是一点半点，据说STORM也基本不更新了，但其实数据量不大，用啥都可以，从应用的角度讲，诸如IBM这种商业版本，是不错的选择，支撑各类实时应用场景绰绰有余。
流处理集群以流处理技术结合内存数据库，用以实时及准实时数据处理，基于IBM Streams流处理集群承载公司的实时业务：
3、数据分析层，与时俱进吧。
先谈谈语言，R和Python是当前数据挖掘开源领域的一对基友，如果要说取舍，笔者真说不出来，感觉Python更偏向工程一点，比如有对分词啥的直接支撑，R的绘图能力异常强大。但他们原来都以样本统计为主，因此大规模数据的支撑有限。
笔者还是更关注分布式挖掘环境，SPARK是一种选择，建议可以采用SPARK+scala，毕竟SPARK是用scala写的，对很多原生的特性能够快速支持。
TD的MPP数据库ASTER也内嵌了很多算法，应该基于并行架构做了很多优化，似乎也是一种选择，以前做过几度交往圈，速度的确很快，但使用资料屈指可数，还需要老外的支持。
传统的数据挖掘工具也不甘人后，SPSS现在有IBM SPSS Analytic
Server，加强了对于大数据hadoop的支撑，业务人员使用反馈还是不错的。
也许未来机器学习也会形成高低搭配，高端用户用spark，低端用户用SPSS，也是要适应不同的应用场景。
深度学习现在渐成潮流，TensorFlow是个选择，公司当前也部署了一套，希望有机会使用，往人工智能方向演进是大势所趋。
无论如何，工具仅仅是工具，最终靠的还是建模工程师驾驭能力。
4、数据开放层，也处在一个战国时代。
有些工程师直接将HIVE作为查询输出，虽然不合理，也体现出计算和查询对于技术能力要求完全不同，即使是查询领域，也需要根据不同的场景，选择不同的技术。
HBASE很好用，基于列存储，查询速度毫秒级，对于一般的百亿级的记录查询那也是能力杠杠的，具有一定的高可用性，我们生产上的详单查询、指标库查询都是很好的应用场景。但读取数据方面只支持通过key或者key范围读取，因此要设计好rowkey。
Redis是K-V数据库，读写速度比HBASE更快，大多时候，HBASE能做的，Redis也能做，但Redis是基于内存的，主要用在key-value
的内存缓存，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术，但如果数据越来越大，那么，HBASE估计就是唯一的选择了?
另外已经基于IMPALA提供互联网日志的实时在线查询应用，也在尝试在营销平台采用SQLFire和GemFire实现分布式的基于内存的SQL关联分析，虽然速度可以，但也是BUG多多，引入和改造的代价较大。
Kylin当前算是基于hadoop/SPARK的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。
5、数据应用层，百花齐放吧。
每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考：
6、数据管理层，路漫漫其修远兮
大数据平台的管理有应用管理和系统管理之分，从应用的角度讲，比如我们建立了DACP的可视化管理平台，其能适配11大搭数据技术组件，可以实现对各类技术组件的透明访问能力，同时通过该平台实现从数据设计、开发到数据销毁的全生命周期管理，并把标准、质量规则和安全策略固化在平台上，实现从事前管理、事中控制和事后稽核、审计的全方位质量管理和安全管理。
其它诸如调度管理、元数据管理、质量管理当然不在话下，因为管住了开发的源头，数据管理的复杂度会大幅降低。
从系统管理的角度看，公司将大数据平台纳入统一的云管理平台管理(私有云)，云管理平台包括支持一键部署、增量部署的可视化运维工具、面向多租户的计算资源管控体系(多租户管理、安全管理、资源管理、负载管理、配额管理以及计量管理)和完善的用户权限管理体系，提供企业级的大数据平台运维管理能力支撑，当然这么宏大的目标要实现也非一日之功。
总结下大数据平台的一些革命性价值。
大数据时代，大多数企业的架构必然向着分布式、可扩展及多元化发展，所谓合久必分，不再有一种技术能包打天下了，
这冲击着传统企业集中化的技术外包模式，挑战是巨大的。
大数据及云计算时代，面多这么多技术组件，要采用一项新的技术，机遇和风险共存：
对于大数据平台的商业版本，企业面对的是合作伙伴的服务跟不上，因为发展太快，对于开源版本，企业面临的是自身运维能力和技术能力的挑战，对于自主能力实际要求更高。
当前BAT、华为、新型互联网等企业在风卷残云般的席卷人才， 对于诸如运营商等大型企业的人才挑战是巨大的，但同时也蕴含着机会，
事实上，对于致力于搞大数据的人来讲，来运营商等企业搞也是不错的选择，因为一方面企业在转型，另一方面数据量够大，技术主导的机会更多。【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条聚焦关注聚焦头条
24H热文一周话题本月最赞
讲师：157553人学习过
讲师：297250人学习过
讲师：43219人学习过
CTO专属活动
精选博文论坛热帖下载排行
本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念，阐述了切实可行的软件架构设计方法，提供了可操作性极强的完整的架...
订阅51CTO邮刊从 200 多个数据库采集数据到大数据平台，有什么方案？ - V2EX
从 200 多个数据库采集数据到大数据平台，有什么方案？
315 天前 &curran12
有 200 多个数据库,数据结构大部分一致，SQLServer 和 Oracle 居多，需要采集交易数据到大数据平台，要保证数据准确性，实时性要求不高，大家有什么稳妥的方案？
1332 次点击所在节点 &
noNOno315 天前不知道数据量如何，实时性要求不高，写 ETL 脚本，离线处理调度呗
gouchaoer315 天前你这个需要每天增量备份么，不需要的话用 sqoop 之类的吧
gouchaoer315 天前需要增量备份的话，你是导入 hive 还是 hbase 之类的呢，我的方案是写脚本每天去数据库查询导出成 text 文本，然后脚本再调用 hive 命令行导入 hive
gouchaoer315 天前
noNOno315 天前数据接入可以用 hbase 集成 hive。我现在数据处理都是先存入 hbase，然后每日处理，持久化到 hive
curran12315 天前@ 既然采集肯定要入仓的，我觉得考虑的地方有几个点：
1、网络稳定性：分为 200 多个库的出口和数据平台入口，200 多个库分布在全国各地，一般都在内网，需要走网络映射，不能保证每次抽取出口网络都正常，而且调度时太大的流量会对数据平台入口网络照成影响，这个需要了解每个库的数据增量来安排调度。
2、某个库采集任务失败后要保证最终采集的数据准确，而且这么多表不可能每天都盯着，需要失败后自动重试
gouchaoer315 天前@ 这 2 个需求都不是问题，你应该是每天增量备份的吧，那我这个方法增量备份有个问题就是需要一个自增的 int 的主键，否则你每天增量备份都不知道从哪一行开始读。。。。我也有意写个 php 工具开源出来，sqoop 太难用了
momo4tg315 天前我觉得 hbase 可以作为一个数据备份，先把数据存在 hdfs 中，通过 spark 去重，计算得到的结果再存入 hbase，保证 hbase 里面的数据已经是干净准确的，再根据需要持久化到另外一个库中，比如某个 OLAP 的数据库。楼上说的每天增量备份都不知道从哪一行开始读，你按天增量，计算的时候去重就好了啊，我之前做的一个数据仓库因为主要是各个系统的订单数据，很多都是 T+1 会有更新的，所以 我都是每天读取 D-3 的数据，然后用 spark 作计算的
badttt315 天前阿里的 DataX
第 1 页 ／ 共 1 页&
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到
上打开本讨论主题的完整版本。
是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
is a community of developers, designers and creative people.大数据为王的情况下，小企业要怎么构建自己的大数据平台？
大家应该常常遇到这样的情况：
过节回家打开车票购买网站得到一个页面提示： 服务器崩溃；准备趁着假期玩一把游戏，又遇上垃圾的土豆服务器；不玩游戏看看剧总行吧，打开AB 站之后又崩了。。。
当然遇到服务器崩溃这事并不是个例，毕竟让他崩溃的原因太特么多了。
数据过载、磁盘已满甚至是服务器灰尘太多都有可能造成他崩溃。。。
我想这个互联网圈子里没有任何一个大佬敢打包票说自家服务器不会崩。
所以为了减少自家服务器崩溃这事，很多大企业在自家服务器维护上就砸了不少钱。
毕竟服务器上还负载了大数据分析，企业需要根据大数据不断优化和升级自家产品才能给用户提供更个性化的服务。
当然除了大企业，现在很多小型企业也开始搞大数据，纷纷表示要搞个自己的大数据分析，紧跟大佬步伐。
就因为这，我一个做 IT 销售的朋友 Z 赚的是盆满钵满。。。
我们羡慕归羡慕，但不得不承认他面对的各类客户真的都很有耐心。
他以前就给我们分享过这样一个故事：
他接到客户电话，人上来就财大气粗的的说了句：我们要做大数据分析，准备加两台服务器。你这边给我拿两款最贵的服务器。
按常理说这种金主爸爸的单子是最好接的。但是 Z实诚啊，非要问清客户是买来做什么，还说：
“最贵的不一定是最适合的，您可以详细给我说说具体用来做什么我再根据需求帮您挑选？？”
这种不在五斗米面前折腰的销售很少见了，要知道最贵的产品提成肯定最高啊！！！
在沟通后，朋友了解到原来客户是一个全国连锁游艺公司的采购，最近公司想要上线大数据分析平台，所以准备买两台最强服务器加持一下。
想着做大数据分析嘛，用最贵的肯定算的快！
这话听着没毛病，但是做了好几年 IT 销售的 Z 却发现里面问题多了去了！
又连接问了几个问题，比如：他们公司现有的服务器是什么？大数据分析负载很高，有没有考虑过后期的硬件维护等问题。
经过这次更深入的谈话后， Z 终于搞清楚了这家公司的情况：
他们公司还有几台以机械硬盘为核心的传统存储器，所以决定还是买两台性能最强的服务器加强一下后自建大数据分析平台。
虽然只是个做销售的，但是 Z 很快就抓到了问题，传统的服务器在对面大数据处理的时候灵活性肯定不够，先不说部署有多复杂，而且后期的运维成本还很高。
在给客户说明问题后，客户有点不耐烦了，公司上线大数据分析平台这事很急，你给我两台最贵的服务器不就好了吗？？扯这么多？
要是一般人应该也不会管这客户怎么想的，直接卖两台服务器算了。
很明显 Z 不是一般人，但他也知道作为一个采购对技术这块肯定不太懂。
又耐心给客户解释:
大数据分析其实是一个相对复杂的应用，整个架构中包含了多种不同角色的应用服务器和数据库服务器。
虽然可以像客户原先设想的那样将这些不同的应用和数据库都安装在2台高配置服务器上，但是这样在实际使用中可能产生不少问题。。。
比如一台服务器上安装过多应用，可能会造成不同应用之间争抢资源，导致影响服务器整体性能下降；或者不同应用程序之间，潜在的兼容问题可能导致软件故障如死机，蓝屏等情况发生的概率大大增加。
而且服务器也有边际效用递减规律，高端服务器在到达一定配置之后，再去提升配置提高性能，投入的成本会更高。
所以建议客户使用数量更多的服务器采用分布式的架构，去分担这些工作负载。
当然更多的物理服务器也可能带来更多的管理问题，包括需要更多的机架空间，等等。所以这些问题，都需要客户根据自己的实际情况去考量和平衡。
采购听后决定问问公司的技术人员，得到的反馈是这样的：
考虑到成本和后期维护问题，他们决定听取Z的意见使用分布式的架构。问题是机架空间虽然能再扩一些出来，但肯定不会太多所以希望戴尔直营这边能帮忙想想办法，尽量减少机架空间。
听到这Z决定询问公司的技术专家，希望能给他们提供出一套完整的解决方案。
根据这家游艺公司的问题，戴尔直销的技术专家考虑到运算效率、数据安全以及运维成本后给建议 C6320 + 小加速的解决方案。
因为这家公司机架空间有限，所以在主数据库系统硬盘的选择上，戴尔直销的技术专家则是建议他们使用戴尔PowerEdge C6320
首先，C6320 所占空间比其他硬盘小
举个例子：
如果12台服务器使用R630那种1U的服务器，需要12U的机架空间，那么使用C6320就只需要6U的机架空间，听上去只差了6U的机架空间，但实际机架空间节省了50%。
这对客户来说其实相当于节省了一半的机房空间，其实对客户来说也包含着非常巨大的经济收益。
其次，在性能上 C6320有很大的提升
而且采用了最新一代的英特尔至强E5-2600 v3处理器，每个插槽提供最多18个内核，高达512GB的DDR4内存。
和DDR3RAM相比，DDR4内存可将内存带宽提高多达15%，功耗减少多达30%，以及72TB的灵活的本地存储。
后期数据存储的爆炸性增长，系统的架构开放、性能卓越、弹性扩展、成本可控等要求肯定会越来越高，所以C6320 肯定是最适合的。
为了能做到效率最大化，戴尔直销技术专家又搭配了一组与数据库、操作系统有着广泛兼容性的块存储设备、软硬结合的端到端的小加速解决方案。
小加速方案主要是通过闪存卡来提升数据库的性能, 可以帮助小企业客户解决严重数据库磁盘IO的性能瓶颈。
听到方案之后，客户虽然觉得这样比在原有的传统服务器上搭建大数据分析更安全。 但是新的问题又来了，自己公司的技术人员能不能完成这一套构建？？？
但是对于戴尔直销而言，这根本就不算个问题。
因为戴尔直销不仅提供解决方案还配套了免费的部署服务，而且买了之后还有专门的戴尔官方认证工程师提供后续的技术支持服务，7*24小时全天候在线。
当初我们都问过Z，干销售销量上去不就行了吗，为什么非要花这么多时间去询问客户遇到的问题？？？
Z 想了想，告诉我们：真正的销售，是根据用户遇到的问题痛点再给以客户专业和合理的建议，而不是急忙推荐自家产品。
毕竟只有真正的了解到用户所想所需和所求，才能更大程度上的解决问题同时也大大提高客户对他们的认可程度嘛。
这样一传十十传百，销量还愁啥？？
当然更重要的就是团队和产品都很强！
专业的后援团：戴尔直销团队
戴尔拥有20多年的直销经验，不仅能够服务大型企业，也能适应市场发展，专注服务成长型企业。
而且每个电话销售的背后都有专业的技术团队支撑，能给客户提供更专业的建议。
强劲的技术线：戴尔产品性能
因为强大的技术支撑，戴尔产品应用案例遍布全球，获得了来自全球用户的肯定，自然能更好的为国内客户进行IT建设规划。
完善的售后保障：戴尔白金服务
戴尔直销配备了原厂服务，从前期部署到上门安装以及使用过程中的维护，都配有更专业的售前与售后支持，遇到任何IT问题，7x24小时实时都能找到专人解决。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点51CTO旗下网站
开源大数据平台实施和使用中的难点
开源大数据技术是一种新一代技术和构架，它以成本较低、以快速的采集、处理和分析技术，从各种超大规模的数据中提取价值。然而庞大的开源大数据技术体系，使得大数据平台在实施和使用的过程中遇到很多难点。
作者：刘刚来源：| 10:39
开源大数据技术是一种新一代技术和构架，它以成本较低、以快速的采集、处理和分析技术，从各种超大规模的数据中提取价值。大数据技术不断涌现和发展，让我们处理海量数据更加容易、更加便宜和迅速，成为分析和挖掘海量数据价值的一个利器，甚至可以改变许多行业的商业模式。
庞大的开源大数据技术体系，使得大数据平台在实施和使用的过程中遇到很多难点，Think
Big团队总结了在开源大数据平台设施的整个过程及花费的时间，如下图所示：
大数据平台的优化和运维
大数据平台的优化和运维应该是开源大数据平台实施的难点、也是构建大数据平台对人员的技术和经验要求最高的阶段，贯穿整个大数据平台实施过程。
大数据平台的数据整合、数据治理和数据湖
对于传统的企业使用大数据平台，数据整合、数据治理和数据湖也是非常重要和比较困难的阶段，全公司不同数据源之间的数据整合面临：数据的一致性、数据的完整性、数据的准确性、数据的安全等问题如何解决，当然还有不同数据(如：冷数据、温数据和热数据)怎么来存放，进而实现高效的数据存储和分析。这些都是我们在大数据实施过程中需要花很多时间和经验来实现的，很多的公司基本上都在直接或间接的使用大数据技术，有可能感觉大数据整合、治理、数据湖没有那么重要，把功能实现了，就觉得把大数据平台用的非常好了，其实不然，就像我上面提到的那张图，功能的实现只占大数据平台实施的一小部分。
大数据平台上面的数据建模
由于大数据平台面临数据的一致性、数据的完整性、数据的准确性等问题所以导致大数据平台上面的建模变得比较困难，此外还有不同行业面临的大数据平台建模问题各不相同。传统行业在大数据上面的建模面临的挑战还是非常多的，有的模型甚至不适合在开源大数据平台上面建模，不要一味的去和互联行业大数据平台上面的应用做比较，因为，互联网的业务比传统的业务模型简单很多。
数据挖掘和算法的实现
大数据平台的数据挖掘技术有Hadoop的Mahout、Spark的Mllib、SparkR等，这个现有的挖掘库存在很多问题，如：分布式计算。对整个团队的人员要求非常的高。
应用开发(类似于传统EDW的BI功能)
类似于在Hadoop上面实现一个传统的EDW的功能，常见用的比较多的就是SQL on
Hadoop技术，如：Hive、Impala、Tez、Presto、Kylin、SparkSQL等。
大数据平台的选择和搭建
主要是Apache Hadoop、Hortonworks HDP和Cloudera CDH的选择，Apache
Hadoop是纯开源的，Hortonworks HDP是开源Hadoop生态系统的管理，Cloudera CDH是开源Hadoop生态系统的增强。【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
热点原创关注头条头条
24H热文一周话题本月最赞
讲师：5人学习过
讲师：1人学习过
讲师：4人学习过
精选博文论坛热帖下载排行
本书并不是关于Web服务的又一本开发手册，抑或是开发技术的宝典之类的读物。本书的作者来自于IBM软件开发中心的SOA技术中心，作为最早的一...
订阅51CTO邮刊