大数据平台设计（人人都在说大数据，大数据平台如何设计）

本文目录

• 人人都在说大数据，大数据平台如何设计
• 大数据分析系统平台方案有哪些
• 设计一个大数据实时分析平台要怎么做呢
• 高校实验室大数据开发平台建设方案
• 如何创建一个大数据平台

人人都在说大数据，大数据平台如何设计

大数据相对以前数据，体现在一个量上，以前每天产生的数据可能只有M级别，现在你的公司产生的数据GB级别，扩展到社会都是PB级别的。数据每天都在爆炸性地增长。需要我们利用更复杂的技术，从海量的数据中发现数据的规律，然后应用都数据中，打个比方，以前的输入法“约吗”输入就想复杂，至少需要拼很多的拼音字母，现在就可以直接两个字母就出来了，这一功能就是利用大数据的特性，主要表现在当社会对这个词的使用频率高到一定程度就可以自动加入到词库中，供用户使用，不需要做其它的更改，就达到更新最新用语的目的。这就是大数据的一个应用范例。

所以大数据平台的设计需要根据业务的场景或者发展方向大数据平台其实也是一样的道理，比如现在的风险识别，当我们使用支付宝、微信支付的时候，背后的支付监控数据平台就在默默地工作着，当发现在异常的时候就显示出来或者系统按照设定的策略进行系统级的处理，系统处理不了的，显示或者给相关业务人员，业务人员就可以在第一时间处理，减少用户或者公司的损失。

所以，大数据平台的设计需要根据公司的业务场景或者发展方向，然后设计适应当前业务发展的数据平台。

比如说我们希望建设一个人力资源管理的数据平台，在这样的场景下，我们的数据平台就需要承载数据的功能。大数据应用到人力资源精确管理上可有效解决人力资源配置不合理的问题，优化人力资源配置，提高人力资源投入产出效率。要想实现人力资源的精确化管理就要明确工作标准，将工作内容具体化和定量化。

大数据分析系统平台方案有哪些

大数据分析系统平台方案有很多，其中就有广州思迈特软件Smartbi的大数据分析系统平台方案。大数据分析系统平台方案深度洞察用户数据,帮企业用数据驱动产品改进及运营监控，思迈特软件Smartbi是企业级商业智能和大数据分析品牌，经过多年持续自主研发，凝聚大量商业智能最佳实践经验，整合了各行业的数据分析和决策支持的功能需求。满足最终用户在企业级报表、数据可视化分析、自助探索分析、数据挖掘建模、AI智能分析等大数据分析需求。
Smartbi产品功能设计全面，涵盖数据提取、数据管理、数据分析、数据共享四个环节，帮助客户从数据的角度描述业务现状，分析业务原因，预测业务趋势，推动业务变革。
思迈特软件Smartbi是国家认定的“高新技术企业”，广东省认定的“大数据培育企业”， 广州市认定的“两高四新企业”，获得了来自国家、地方政府、国内外权威分析机构、行业组织、知名媒体的高度关注和认可，斩获“大数据百强企业”、“中国十佳商业智能方案商”、“中国科技创新企业100强”等100+荣誉奖项！
凭借NLP和数据挖掘功能入选Gartner“中国AI创业公司代表厂商（2020）”，凭借思迈特软件Smartbi入选“Gartner?增强分析2020代表厂商”。

设计一个大数据实时分析平台要怎么做呢

PetaBase-V作为Vertica基于亿信分析产品的定制版，提供面向大数据的实时分析服务，采用无共享大规模并行架构（MPP），可线性扩展集群的计算能力和数据处理容量，基于列式数据库技术，使 PetaBase-V 拥有高性能、高扩展性、高压缩率、高健壮性等特点，可完美解决报表计算慢和明细数据查询等性能问题。
大数据实时分析平台（以下简称PB-S），旨在提供数据端到端实时处理能力（毫秒级／秒级／分钟级延迟），可以对接多数据源进行实时数据抽取，可以为多数据应用场景提供实时数据消费。作为现代数仓的一部分，PB-S可以支持实时化、虚拟化、平民化、协作化等能力，让实时数据应用开发门槛更低、迭代更快、质量更好、运行更稳、运维更简、能力更强。
整体设计思想
我们针对用户需求的四个层面进行了统一化抽象：
统一数据采集平台
统一流式处理平台
统一计算服务平台
统一数据可视化平台
同时，也对存储层保持了开放的原则，意味着用户可以选择不同的存储层以满足具体项目的需要，而又不破坏整体架构设计，用户甚至可以在Pipeline中同时选择多个异构存储提供支持。下面分别对四个抽象层进行解读。
1)统一数据采集平台
统一数据采集平台，既可以支持不同数据源的全量抽取，也可以支持增强抽取。其中对于业务数据库的增量抽取会选择读取数据库日志，以减少对业务库的读取压力。平台还可以对抽取的数据进行统一处理，然后以统一格式发布到数据总线上。这里我们选择一种自定义的标准化统一消息格式UMS（Unified Message Schema）做为 统一数据采集平台和统一流式处理平台之间的数据层面协议。
UMS自带Namespace信息和Schema信息，这是一种自定位自解释消息协议格式，这样做的好处是：
整个架构无需依赖外部元数据管理平台；
消息和物理媒介解耦（这里物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通过物理媒介支持多消息流并行，和消息流的自由漂移。
平台也支持多租户体系，和配置化简单处理清洗能力。
2)统一流式处理平台
统一流式处理平台，会消费来自数据总线上的消息，可以支持UMS协议消息，也可以支持普通JSON格式消息。同时，平台还支持以下能力：
支持可视化／配置化／SQL化方式降低流式逻辑开发／部署／管理门槛
支持配置化方式幂等落入多个异构目标库以确保数据的最终一致性
支持多租户体系，做到项目级的计算资源／表资源／用户资源等隔离
3)统一计算服务平台
统一计算服务平台，是一种数据虚拟化／数据联邦的实现。平台对内支持多异构数据源的下推计算和拉取混算，也支持对外的统一服务接口（JDBC／REST）和统一查询语言（SQL）。由于平台可以统一收口服务，因此可以基于平台打造统一元数据管理／数据质量管理／数据安全审计／数据安全策略等模块。平台也支持多租户体系。
4)统一数据可视化平台
统一数据可视化平台，加上多租户和完善的用户体系／权限体系，可以支持跨部门数据从业人员的分工协作能力，让用户在可视化环境下，通过紧密合作的方式，更能发挥各自所长来完成数据平台最后十公里的应用。
以上是基于整体模块架构之上，进行了统一抽象设计，并开放存储选项以提高灵活性和需求适配性。这样的RTDP平台设计，体现了现代数仓的实时化／虚拟化／平民化／协作化等能力，并且覆盖了端到端的OLPP数据流转链路。
具体问题和解决思路
下面我们会基于PB-S的整体架构设计，分别从不同维度讨论这个设计需要面对的问题考量和解决思路。
功能考量主要讨论这样一个问题：实时Pipeline能否处理所有ETL复杂逻辑？
我们知道，对于Storm／Flink这样的流式计算引擎，是按每条处理的；对于Spark Streaming流式计算引擎，按每个mini-batch处理；而对于离线跑批任务来说，是按每天数据进行处理的。因此处理范围是数据的一个维度（范围维度）。
另外，流式处理面向的是增量数据，如果数据源来自关系型数据库，那么增量数据往往指的是增量变更数据（增删改，revision）；相对的批量处理面向的则是快照数据（snapshot）。因此展现形式是数据的另一个维度（变更维度）。
单条数据的变更维度，是可以投射收敛成单条快照的，因此变更维度可以收敛成范围维度。所以流式处理和批量处理的本质区别在于，面对的数据范围维度的不同，流式处理单位为“有限范围”，批量处理单位为“全表范围”。“全表范围”数据是可以支持各种SQL算子的，而“有限范围”数据只能支持部分SQL算子。
复杂的ETL并不是单一算子，经常会是由多个算子组合而成，由上可以看出单纯的流式处理并不能很好的支持所有ETL复杂逻辑。那么如何在实时Pipeline中支持更多复杂的ETL算子，并且保持时效性？这就需要“有限范围”和“全表范围”处理的相互转换能力。
设想一下：流式处理平台可以支持流上适合的处理，然后实时落不同的异构库，计算服务平台可以定时批量混算多源异构库（时间设定可以是每隔几分钟或更短），并将每批计算结果发送到数据总线上继续流转，这样流式处理平台和计算服务平台就形成了计算闭环，各自做擅长的算子处理，数据在不同频率触发流转过程中进行各种算子转换，这样的架构模式理论上即可支持所有ETL复杂逻辑。
2)质量考量
上面的介绍也引出了两个主流实时数据处理架构：Lambda架构和Kappa架构，具体两个架构的介绍网上有很多资料，这里不再赘述。Lambda架构和Kappa架构各有其优劣势，但都支持数据的最终一致性，从某种程度上确保了数据质量，如何在Lambda架构和Kappa架构中取长补短，形成某种融合架构，这个话题会在其他文章中详细探讨。
当然数据质量也是个非常大的话题，只支持重跑和回灌并不能完全解决所有数据质量问题，只是从技术架构层面给出了补数据的工程方案。关于大数据数据质量问题，我们也会起一个新的话题讨论。
3)稳定考量
这个话题涉及但不限于以下几点，这里简单给出应对的思路：
高可用HA
整个实时Pipeline链路都应该选取高可用组件，确保理论上整体高可用；在数据关键链路上支持数据备份和重演机制；在业务关键链路上支持双跑融合机制
SLA保障
在确保集群和实时Pipeline高可用的前提下，支持动态扩容和数据处理流程自动漂移
弹性反脆弱
? 基于规则和算法的资源弹性伸缩
? 支持事件触发动作引擎的失效处理
监控预警
集群设施层面，物理管道层面，数据逻辑层面的多方面监控预警能力
自动运维
能够捕捉并存档缺失数据和处理异常，并具备定期自动重试机制修复问题数据
上游元数据变更抗性
?上游业务库要求兼容性元数据变更
? 实时Pipeline处理显式字段
4)成本考量
这个话题涉及但不限于以下几点，这里简单给出应对的思路：
人力成本
通过支持数据应用平民化降低人才人力成本
资源成本
通过支持动态资源利用降低静态资源占用造成的资源浪费
运维成本
通过支持自动运维／高可用／弹性反脆弱等机制降低运维成本
试错成本
通过支持敏捷开发／快速迭代降低试错成本
5)敏捷考量
敏捷大数据是一整套理论体系和方法学，在前文已有所描述，从数据使用角度来看，敏捷考量意味着：配置化，SQL化，平民化。
6)管理考量
数据管理也是一个非常大的话题，这里我们会重点关注两个方面：元数据管理和数据安全管理。如果在现代数仓多数据存储选型的环境下统一管理元数据和数据安全，是一个非常有挑战的话题，我们会在实时Pipeline上各个环节平台分别考虑这两个方面问题并给出内置支持，同时也可以支持对接外部统一的元数据管理平台和统一数据安全策略。
以上是我们探讨的大数据实时分析平台PB-S的设计方案。

高校实验室大数据开发平台建设方案

大数据人才应用能力成长平台——Tempo Talents，从产业人才需求的视角，通过模式创新、技术创新，为高校大数据人才培养提供从平台、课程内容到教学管理的系统解决方案。平台核心围绕“人才应用能力培养”，以实践为基础，将大数据人才培养所需的知识、技能和方法论三个层面互相融合，核心是通过学生动手实践，培养数据思维及解决问题的能力。

Tempo Talents核心应用场景
Tempo Talents——大数据应用能力成长平台核心面向大数据管理应用、数据科学与大数据技术、交叉学科等大数据相关专业，应用于教学实践、集中实训、在线竞赛、学习交流等场景。

Tempo Talents核心特点
1、DT-CMPA人才能力地图，让学习目标清晰明确
基于大数据行业人才标准及一万多个大数据相关岗位招聘需求解析，定义岗位素质模型，从岗位胜任力出发，规划学习路径和学习路线。基于人才能力地图，高校可以根据自己的学科建设目标、人才培养方向，进行课程体系的规划。而学生也能根据自己的就业目标，规划学习路径，让学生学习更具目标感，清楚学什么、为什么学。

2、专业课程实践资源，满足不同类型教学、实验需求
1）系统课程体系设计，名师专业课程打造
与多位高校老师沟通合作，围绕大数据学习路线的两个基础一个链条，打造9大方向、数百个分类，开发设计1000多个原子课，为高校实践教学提供丰富的课程资源。

2）创新原子课设计，知行合一
Q:何为“原子课”？
A:将课程中涉及的技术点、知识点“原子化”拆分，从基础原理、特性到最终应用，层层递进，用闯关的模式引导学生学习和实践，目的是让学生将每一个知识点吃透、掌握与应用。
基于原子课实现“个性化定制课堂”，老师可根据人才培养需求、学科特色、所用教材在原子课程库中自由挑选、灵活搭配难易度合适的知识点原子，灵活组合，实现“个性化定制课堂”。
3）个性化定制课堂，因材施教
定制化“教学课堂”，自定义教学计划，学生学习行为与评测结果记录，洞察和解析学生学习路径与成果，过程与结果并重，探索教学目标达成的最佳方案。
3、千余个项目应用实践经验，培养学生数据思维及解决问题的能力
基于美林数据上千个行业头部客户大数据建设项目经验，以行业应用为引导，以真实项目案例为基础，内嵌6大行业，100+项目实训，让学生了解行业最新实践与应用场景，通过实战演练提升学生解决实际问题的能力。

对于大数据学习而言，最难的不是Python的一段代码实现、也不是算法原理的掌握，而是在具体业务场景中，将业务问题数据化，利用分析工具、大数据知识去找到解决方案。
针对每一个实训项目，我们都将项目落地全过程进行深度剖析，还原项目落地全流程。将分析方法论、业务问题转化为数学问题的思维方式、知识技能的应用技巧等，全部融入到具体的项目实训案例中，让学生通过实训，掌握方法、提升思维模式。
4、一体化实践运行平台，提供丰富实验实训环境
1）技术创新，实验环境管理智能高效
基于容器与虚拟化技术，提供在线编程、远程命令行、交互式编程、远程桌面等实验实训环境，通过无感知的实验资源分配与回收替代复杂的实验环境管理，让实验管理智能高效。
2）编码式加拖拽式双环境，应用型与开发型兼顾
既有以原理、技术教学为目标的编码环境，也有以应用为目标的拖拽式环境。拖拽式数据可视化分析与机器学习建模平台，以应用为目标，与编码环境充分融合，满足大数据分析应用实践，为交叉学科大数据人才应用能力培养提供环境支持。

5、激发学生学习热情，打造“自驱型”能力成长平台
闯关、竞赛、自主探索的数据游乐场，打破传统的学习模式，打造专业与趣味性融合的学习体验，充分激发学生自主学习热情，打造“自驱型”能力成长平台。

如何创建一个大数据平台

1. 　所谓的大数据平台不是独立存在的，比如百度是依赖搜索引擎获得大数据并开展业务的，阿里是通过电子商务交易获得大数据并开展业务的，腾讯是通过社交获得大数据并开始业务的，所以说大数据平台不是独立存在的，重点是如何搜集和沉淀数据，如何分析数据并挖掘数据的价值。

3. 　　我可能还不够资格回答这个问题，没有经历过一个公司大数据平台从无到有到复杂的过程。不过说说看法吧，也算是梳理一下想法找找喷。

4. 　　这是个需求驱动的过程。

5. 曾经听过spotify的分享，印象很深的是，他们分享说，他们的hadoop集群第一次故障是因为，机器放在靠窗的地方，太阳晒了当机了（笑）。从简单的没有机房放在自家窗前的集群到一直到现在复杂的数据平台，这是一个不断演进的过程。

6. 对小公司来说，大概自己找一两台机器架个集群算算，也算是大数据平台了。在初创阶段，数据量会很小，不需要多大的规模。这时候组件选择也很随意，Hadoop一套，任务调度用脚本或者轻量的框架比如luigi之类的，数据分析可能hive还不如导入RMDB快。监控和部署也许都没时间整理，用脚本或者轻量的监控，大约是没有ganglia、nagios，puppet什么的。这个阶段也许算是技术积累，用传统手段还是真大数据平台都是两可的事情，但是为了今后的扩展性，这时候上Hadoop也许是不错的选择。

7. 当进入高速发展期，也许扩容会跟不上计划，不少公司可能会迁移平台到云上，比如AWS阿里云什么的。小规模高速发展的平台，这种方式应该是经济实惠的，省了运维和管理的成本，扩容比较省心。要解决的是选择平台本身提供的服务，计算成本，打通数据出入的通道。整个数据平台本身如果走这条路，可能就已经基本成型了。走这条路的比较有名的应该是netflix。

8. 也有一个阶段，你发现云服务的费用太高，虽然省了你很多事，但是花钱嗖嗖的。几个老板一合计，再玩下去下个月工资发布出来了。然后无奈之下公司开始往私有集群迁移。这时候你大概需要一群靠谱的运维，帮你监管机器，之前两三台机器登录上去看看状态换个磁盘什么的也许就不可能了，你面对的是成百上千台主机，有些关键服务必须保证稳定，有些是数据节点，磁盘三天两头损耗，网络可能被压得不堪重负。你需要一个靠谱的人设计网络布局，设计运维规范，架设监控，值班团队走起7*24小时随时准备出台。然后上面再有平台组真的大数据平台走起。

9. 然后是选型，如果有技术实力，可以直接用社区的一整套，自己管起来，监控部署什么的自己走起。这个阶段部署监控和用户管理什么的都不可能像两三个节点那样人肉搞了，配置管理，部署管理都需要专门的平台和组件；定期Review用户的作业和使用情况，决定是否扩容，清理数据等等。否则等机器和业务进一步增加，团队可能会死的很惨，疲于奔命，每天事故不断，进入恶性循环。

10. 当然有金钱实力的大户可以找Cloudera，Hortonworks，国内可以找华为星环，会省不少事，适合非互联网土豪。当然互联网公司也有用这些东西的，比如Ebay。

11. 接下去你可能需要一些重量的组件帮你做一些事情。

12. 比如你的数据接入，之前可能找个定时脚本或者爬log发包找个服务器接收写入HDFS，现在可能不行了，这些大概没有高性能，没有异常保障，你需要更强壮的解决方案，比如Flume之类的。

13. 你的业务不断壮大，老板需要看的报表越来越多，需要训练的数据也需要清洗，你就需要任务调度，比如oozie或者azkaban之类的，这些系统帮你管理关键任务的调度和监控。

14. 数据分析人员的数据大概可能渐渐从RDBMS搬迁到集群了，因为传统数据库已经完全hold不住了，但他们不会写代码，所以你上马了Hive。然后很多用户用了Hive觉得太慢，你就又上马交互分析系统，比如Presto，Impala或者SparkSQL。

15. 你的数据科学家需要写ML代码，他们跟你说你需要Mahout或者Spark MLLib，于是你也部署了这些。

16. 至此可能数据平台已经是工程师的日常工作场所了，大多数业务都会迁移过来。这时候你可能面临很多不同的问题。

17. 比如各个业务线数据各种数据表多的一塌糊涂，不管是你还是写数据的人大概都不知道数据从哪儿来，接下去到哪儿去。你就自己搞了一套元数据管理的系统。

18. 你分析性能，发现你们的数据都是上百Column，各种复杂的Query，裸存的Text格式即便压缩了也还是慢的要死，于是你主推用户都使用列存，Parquet，ORC之类的。

19. 又或者你发现你们的ETL很长，中间生成好多临时数据，于是你下狠心把pipeline改写成Spark了。

20. 再接下来也许你会想到花时间去维护一个门户，把这些零散的组件都整合到一起，提供统一的用户体验，比如一键就能把数据从数据库chua一下拉到HDFS导入Hive，也能一键就chua一下再搞回去；点几下就能设定一个定时任务，每天跑了给老板自动推送报表；或者点一下就能起一个Storm的topology；或者界面上写几个Query就能查询Hbase的数据。这时候你的数据平台算是成型了。

21. 当然，磕磕碰碰免不了。每天你都有新的问题和挑战，否则你就要失业了不是？

22. 你发现社区不断在解决你遇到过的问题，于是你们架构师每天分出很多时间去看社区的进展，有了什么新工具，有什么公司发布了什么项目解决了什么问题，兴许你就能用上。

23. 上了这些乱七八糟的东西，你以为就安生了？Hadoop平台的一个大特点就是坑多。尤其是新做的功能新起的项目。对于平台组的人，老板如果知道这是天然坑多的平台，那他也许会很高兴，因为跟进社区，帮忙修bug，一起互动其实是很提升公司影响力的实情。当然如果老板不理解，你就自求多福吧，招几个老司机，出了问题能马上带路才是正道。当然团队的技术积累不能不跟上，因为数据平台还是乱世，三天不跟进你就不知道世界是什么样了。任何一个新技术，都是坑啊坑啊修啊修啊才完善的。如果是关键业务换技术，那需要小心再小心，技术主管也要有足够的积累，能够驾驭，知道收益和风险。