火热的数据中台，是否终究一地鸡毛( 二 ) 在前面我写过关于数据中台

大数据平台当前应用的最多的地方仍然是在类似智慧城市大项目建设，集团类而且偏运营服务类行业中，类似电信行业和金融行业。而在传统制造行业等大数据平台建设只能说很一般，包括大点的大数据平台建设项目都少。即使是对于传统的制造企业，往往开始启动大数据平台建设项目，往往也是前几年的从传统信息化到消费互联网的转型，到自建垂直一体化电商平台的时候，伴随进行大数据平台的建设。
简单总结就是，大数据平台对大部分企业来说都是杀鸡用牛刀，即企业所面临的数据容量，类型复杂度，处理性能要求等都远远不需要采用大数据平台来解决。
采用大数据平台就意味着更高的人力和产品成本投入，往往投入产出性价比极低。
对于大数据技术平台，我原来给出过一个技术架构可参考：
文章插图
如果从整体分层来说可以包括数据源层，数据整合层和应用分析层，数据管控治理层几大部分。从核心功能来说又包括了数据采集集成，数据存储，数据处理，数据分析，数据能力开放等几个关键的能力。即使你看现在的数据中台架构，你会看到其核心技术平台能力实际上和大数据平台基本是一致的。
大数据平台本身偏技术平台概念
对于大数据平台这个词，本身偏技术平台的概念，即常说的围绕Hadoop开源生态体系构建的一个覆盖数据采集，集成，存储，处理和分析的技术平台。通过这个技术平台来解决我们日常遇到的数据存储，数据分析方面的问题。
但是即使这样大数据平台里面涉及到的技术点仍然相当多，基于Hadoop平台也还需要我们做大量的定制开发，其它开源工具的整合和集成操作。
比如数据采集和集成来说，对于日志类可能会采用Flume来实现，对于网页抓取你得采用开源爬虫工具软件，对于结构化数据集成仍然采用ETL工具，而对于结构化和非结构化之间的集成可以采用类似Sqoop工具来实现。而这些都必须进行整合和定制。
对于数据分析也是同样的道理，从最早经常说的Hive数据分析，到Impala和Spark ，本身也需要基于你处理的数据规模，时效性要求等各方面去评估具体采用哪个。比如对于Hive由于基于传统的MapReduce ，如果遇到海量数据处理有优势，但是如果对于即席交互式查询就比类似Spark这种内存处理慢很多。而对于类似传统海量结构化数据的处理，往往采用类似MPP架构的Impala往往能够得到更好的效果。
从传统BI到大数据平台
文章插图
对于传统企业内部，更多的应该是使用了大数据技术的传统BI平台，或者是融合了传统BI+大数据的混合平台，而不能单纯说是大数据平台。因此在谈大数据平台的时候，一味去否定传统BI是不合适的。
在没有和互联网打通的传统企业内部，更多接触的仍然是结构化数据，优先要解决的是围绕企业核心价值链的数据建模和企业战略，各业务域KPI体系的建立，决策支持和分析这些内容。在整个数据建模和分析过程中，还要考虑去解决数据不一致性，重复等问题，建立数据管控和治理体系。
传统BI平台在发展过程中会遇到问题和瓶颈，使用传统的技术架构无法解决，需要我们在传统BI技术架构的构建中引入大数据相关技术和工具，从这意义上更多应该叫使用了大数据技术的传统BI平台。
使用了大数据技术的传统BI平台
在数据存储和查询效率层面，传统BI遇到瓶颈，可以看到在大量的上千万即上亿数据量的结构化数据表中，要进行查询统计分析输出KPI指标性能下降非常明显。为了解决查询效率问题，有两个思路，一个是引入了MPP数据库来解决，一个则是引入Hadoop平台进行存储，虽然是结构化数据但是仍然引入Hadoop平台，重点是解决分布式存储和查询性能问题。
其次，虽然传统企业以结构化数据为主，但是仍然出现对大数据量的非结构化数据的采集和处理，这个时候我们可能引入了Hadoop平台，将数据采集，清理存储后最终还是再导入我们的结构化数据仓库。可以看到在这个过程中大数据技术解决了对非结构化数据的处理和整合问题。
融合传统BI能力的大数据平台
对于原来没有规划建设BI系统的企业，在构建BI系统的时候更多考虑的就是直接构建大数据平台同时完全融合传统BI应该具备的能力。即既保留了传统BI ，又实现了远期对大数据平台和应用的扩展能力。