本文主要是介绍谁懂？这23个关于大数据的灵魂拷问！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在企业内训行业也深耕蛮多年了，每次做大数据培训，都会遇到一些发人深省的灵魂拷问。
在这些拷问的人群中，有一些是没有接触过大数据平台，有一些甚至已经是大数据老兵。
那趁着这次机会，让我们索性一次把这些问题言简意赅的聊清楚。
1、究竟什么是大数据？这么受企业追捧，是智商税不？
大数据是海量数据模式下，对数据进行存储以及计算的一种架构，或者说生态。数据量达到这个级别，单机数据库、MPP架构都无法支撑的时候，只能寻求大数据架构去做解决。
大数据采用天然分布式架构，没有单机、MPP架构的包袱，单纯为海量数据而生的技术。它一定是将来的一个趋势。
2、那为什么有些企业上大数据架构后，效率反而降低？
因为数据没有达到一定规模，大数据在进行数据存储与计算时，调度周期会比较长。因为要考虑到海量数据规模后，大文件存储时要进行拆分，然后存储后进行备份。计算时避免移动数据，要调度计算任务紧贴数据节点运算。整个调度周期会很长。
对于小数据量来说，调度周期已经超过了最终计算所需的时长，效率当然会下降。就好比原来一个人可以解决的问题，交给大数据架构后，变成了10个人、100个人来处理，光分配任务就占用了很久时间。
3、数据仓库由原来的Oracle换到大数据平台Hive或Spark SQL后，查询起来变慢这么多？
大数据数据仓库，比如Hive、Spark SQL，它们的场景主要是集中在跑批分析。也就是DWD、DWS、DIM、ADS层构建，这些任务在运行时，一般使用的是全量数据，或者当天的增量数据，使用Hive、Spark SQL一次性将它们计算完成。这是它们的适用场景。这些任务可能要跑几个小时。
至于Oracle支持的快速的OLTP增删改查，以及快速OLAP分析，Hive、Spark SQL效率是比较低的，这不是它们擅长的场景，并且底层是海量的数据，以及复杂的调度。
4、那原来架构中的OLAP任务，应该怎么处理？
可以使用MPP架构的数据库，如Clickhouse、Droid、GreenPlum等产品。或者使用MOLAP工具，进行预计算处理。
5、既然能够使用MPP架构的数据库处理，为什么还要使用大数据产品？
MPP架构有扩展性问题，以及热点问题。在一定数据规模下，问题不明显，一旦数据量达到海量，问题就会非常严重。所以中大型规模数据，可以使用MPP架构，超大规模数据的处理必须走大数据。
MPP架构目前会和大数据架构并存，主要解决中等规模数据的OLAP分析。
6、Oracle到大数据数据仓库，迁移成本为什么这么高？
首先是语法兼容问题，其次是底层调度架构不同。即使SQL完全兼容，在大数据平台这里的运行效率也会下降，所以就涉及到调优的问题。当然，在生产中任何迁移都很麻烦。
就以全局排序为例，Hive中要拆分为局部排序来减少最终的数据量，否则计算效率会很差。
7、大数据架构中为什么会使用如此多的产品？
主要是构建分布式存储、资源管理、通用计算，这里在软件层面在单机操作系统上，构建了一个分布式的操作系统。比如最常见的选型：HDFS、YARN、MR。
其次，大数据场景中，数据格式比较多，有结构化、非结构化、半结构化。分别需要专门的产品去进行存储与处理。再加上图计算、数据分析、实时场景、搜索检索场景，场景复杂了，需要的产品就多了。
8、不同产品中存储不同的数据，是否会导致数据孤岛？数据孤岛应该怎么解决？
会的，数据孤岛一般的解决方案是建立数据湖。数据在进入不同的存储系统之前，先扔到数据湖中进行存储，它是用来存储原始数据的，这样就打破了数据孤岛的问题。
然后数据湖中的一些数据，如果要进行后续的处理，再从湖中流入其它产品进行运算即可。
9、数据湖目前的实现思路有？
一般有两种思路，目前像Hudi、Iceberg这些产品主要在不同计算引擎层面，如Hive、Spark、Flink，添加hudi、iceberg的依赖，这样不同计算引擎就可以在存储系统中创建一个统一类型的Hudi表、Iceberg表。这样就可以实现统一处理与调用，以达到数据共享的效果。
另外一种数据湖的思路，就是在一个产品中，与其它产品进行互通。比如Hive存储结构化数据，但它可以配置与HBase互通，这样在Hive中就可以直接查询HBase中存储的NoSQL数据；同理，也可以和ES打通，直接查询与操作ES中的文本数据进行检索任务。这种方式其实对于企业使用来说，更接近湖的概念。
10、什么是中台？为什么中台的概念这么火？
中台的目的是为了复用企业的资产，比如多个产品都有登录注册，那就可以直接把登录注册功能作为业务中台的一个服务，让其它所有产品都接入。这样首先是数据互通，其次开发新产品时可以使用中台的共有功能，而减少建设成本。使得开发更加敏捷，能够快速响应客户的需求。
这样的建设蓝图，对各大企业来说，都是很有吸引力的。节省了成本，换来更大的效益。
11、什么样的企业适合建设中台？
资产足够的企业，比如业务线、产品丰富，能够复用的功能足够多。其次中台建设目标要明确，后续中台会换来哪些效益，为哪些新业务赋能，解决旧业务的哪些痛点，这部分要提前进行衡量。
12、什么是数据中台？
数据中台更像是围绕着数据仓库、数据湖的一种上层服务建设，使得数据更好的在企业中被使用。例如数据中台中有数据商城对数据进行流通，数据资产目录对数据进行分类组织，数据脱敏解决数据安全问题，数据质量管理提升数据质量等。
达成的目的就是数据可以在一个界面里直观的进行组织、查找、流通，以便快速挖掘出其更多的价值。
13、为什么很多企业的数据中台建设不起来？
首先数据中台建设的目的不明确，可能后期领导都没什么信心。其次中台部门的考核指标要明确，为公司提升了哪些效率，节约了哪些成本。最后中台部门需要有足够的权限，其余部门才会配合。
14、大数据的流处理场景建设起来为什么很麻烦？
数据是实时接入，所以要考虑数据在网络中传输、处理过程中的数据丢失问题，数据重复问题（重复发送、重复采集），数据乱序问题。这些问题被解决后，才会进行数据处理。
而且流处理中的实时数据，计算后就会被清空，那么上述问题就变得更加复杂。当然还有流任务计算错误，应该如何处理？重放？应该怎么设计？
15、在流处理场景中为什么要使用Lambda架构，或者Kappa架构？
因为流处理得到的计算结果，一般不认为准确；或者要达到准确的程度，付出的代价会比较高。此时，会同时采用批处理架构，定期进行跑批，比如10分钟一次，来研判流处理任务结果是否准确。
当然这种架构下，可以将每10分钟节点的批处理结果作为精确结果，其余时间的流处理结果作为实时参考。
16、流处理场景中要与数据仓库中的数据进行关联，该如何操作？
添加索引，且使用查询效率较高的产品，比如HBase。
17、在大数据产品中，是否可以尽量建立较多的索引来提升查询效率。
当然可以，但索引越多，意味着写性能越差。因为写入数据时，要维护的索引表会越多，这和传统架构是一样的。
18、大数据的流处理计算中，为什么要使用Kafka？不使用行不行？
Kafka的目的主要是为了抗压，避免数据源实时产生的数据有不可预测的并发，导致大数据平台挂掉。当然也有组织数据的目的，数据源较多的情况下，可以由Kafka作为中间件来对数据进行管理。
如果生产中没有这两部分的需求，那就可以不使用Kafka，比如就一条数据链路，且数据量也不大的情况下。
19、在大数据数据仓库建设过程中，为什么有的企业会使用多个数据库产品来分层？
因为不同的层，功能要求不同。
比如ODS贴源层，存储业务数据库中的历史数据，但它还要为应用系统开发操作接口，以免数据在业务数据库删除后，业务系统无法进行操作。那么ODS就需要一定的事务特性。
DWD、DWS、DIM层主要用于跑批计算，跑批性能是它们更加关注的。
ADS层存储运算结果，面向应用，此时它们关注的功能点，要看业务端需求，比如查询效率、复杂检索，或者OLAP分析。
那么这时候，单个产品无法满足的情况下，就会用到多个数据库产品。
20、大数据场景中保证数据可靠性的因素是？
副本，必须是多副本备份。但会带来存储成本。
21、MapReduce性能比较低，是不是已经被淘汰了？
从官网来看，目前MR性能也不低。其次技术没有优劣，它们都有适合自己的场景。
Spark性能虽然比较高，但大量使用内存，在资源不够且数据量大的情况下，会出现OOM的情况，导致任务失败。MR虽然慢一些，但任务总会执行完成，所以目前有的企业依然在使用MR。
22、大数据场景中的小文件问题为何如此突出？
在大数据场景下数据分散在各个节点存储，那势必要有一个管理节点保存数据的位置信息。这些位置信息都记录在内存中，小文件数量越多，占用的内存空间就越大。
其次，大数据计算方式为移动计算而非移动数据，小文件越多，要分发的计算任务就越多，计算效率就越低（主要耗时在调度上）。
23、大数据场景会带来各种问题，企业能否放弃使用大数据架构？
大数据场景带来的问题，或者说海量数据带来的问题，这是不可避免的，每个企业在数据达到一定规模后都会遇到。
目前大数据技术依然在继续发展，只能期待后续的技术更新能够逐步解决这部分问题。当然可以肯定的是，旧的问题被解决，新的问题也一定会到来。
OK，这次和大家聊了这么多，希望都能有所收获。如果你喜欢这种形式，请帮忙点赞分享，这是对我最大的鼓励！这里是数舟，我们下期再会！
这篇关于谁懂？这23个关于大数据的灵魂拷问！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
