㈠ 设计一个大数据实时分析平台要怎么做呢
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的设计方案。
㈡ 创建大数据项目的五大步骤
创建大数据项目的五大步骤
企业需要积极的提升他们的数据管理能力。这并非意味着他们应该制定繁琐的流程和监督机制。明智的企业会配合他们的数据活动的生命周期制定灵活的流程和功能：根据业务需求启动更轻更严格、更强大的功能，并根据需求的增加来提升质量或精度。
一些企业正在利用新兴技术来应对新的数据源，但大多数企业仍然面临着需要努力管理好他们已经掌握或者应当掌握的数据信息的困境，而当他们试图部署大数据功能时，发现自己还需要面对和处理新的以及当下实时的数据。
为了能够实现持久成功的大数据项目，企业需要把重点放在如下五个主要领域。
1、确立明确的角色分工和职责范围。
对于您企业环境中的所有的数据信息，您需要对于这些数据信息所涉及的关键利益相关者、决策者有一个清晰的了解和把控。当数据信息在企业的系统传输过程中及其整个生命周期中，角色分工将发生变化，而企业需要对这些变化有一个很好的理解。当企业开始部署大数据项目之后，务必要明确识别相关数据的关键利益相关者，并做好这些数据信息的完善和迭代工作。
2、加强企业的数据治理和数据管理功能。
确保您企业的进程足够强大，能够满足和支持大数据用户和大数据技术的需求。进程可以是灵活的，并应充分考虑到业务部门和事务部门的需求，这些部门均伴有不同程度的严谨性和监督要求。
确保您企业的参考信息架构已经更新到包括大数据。这样做会给未来的项目打好最好的使用大数据技术和适当的信息管理能力的基础。
确保您企业的元数据管理功能足够强大，能够包括并关联所有的基本元数据组件。随着时间的推移，进行有序的分类，满足业务规范。
一旦您开始在您企业的生产部门推广您的解决方案时，您会希望他们长期持续的使用该解决方案，所以对架构功能的定义并监督其发挥的作用是至关重要的。确保您企业的治理流程包括IT控制的角色，以帮助企业的利益相关者们进行引导项目，以最佳地利用这些数据信息。其还应该包括您企业的安全和法务团队。根据我们的经验，使用现有的监督机制能够达到最佳的工作状态，只要企业实施了大数据应用，并专注于快速在进程中处理应用程序，而不是阻碍进程的通过。
3、了解环境中的数据的目的和要求的精度水平，并相应地调整您企业的期望值和流程。
无论其是一个POC，或一个已经进入主流业务流程的项目，请务必确保您对于期望利用这些数据来执行什么任务，及其质量和精度处于何种级别有一个非常清晰的了解。这种方法将使得企业的项目能够寻找到正确的数据来源和利益相关者，以更好地评估这些数据信息的价值和影响，进而让您决定如何最好地管理这些数据信息。更高的质量和精度则要求更强大的数据管理和监督能力。
随着您企业大数据项目的日趋成熟，考虑建立一套按照数据质量或精确度分类的办法，这将使得数据用户得以更好的了解他们所使用的是什么，并相应地调整自己的期望值。例如，您可以使用白色、蓝色或金色来分别代表原始数据、清理过的数据，经过验证可以有针对性的支持分析和使用的数据。有些企业甚至进一步完善了这一分类方法：将数据从1到5进行分类，其中1是原始数据，而5是便于理解，经过整理的、有组织的数据。
4、将对非结构化的内容的管理纳入到您企业的数据管理能力。
非结构化数据一直是企业业务运营的一部分，但既然现在我们已经有了更好的技术来探索，分析和这些非结构化的内容，进而帮助改善业务流程和工业务洞察，所以我们最终将其正式纳入我们的数据管理是非常重要的。大多数企业目前都被困在了这一步骤。
数据库中基本的、非结构化的数据是以评论的形式或者自由的形式存在的，其至少是数据库的一部分，应该被纳入到数据管理。但挖掘这些数据信息则是非常难的。
数字数据存储在传统的结构化数据库和业务流程外，很少有许多的治理范围分组和数据管理的实现，除了当其被看作是一个技术问题时。一般来说，除了严格遵守相关的安全政策，今天的企业尚未对其进行真正有效的管理。当您的企业开始大跨步实现了大数据项目之后，您会发现这一类型的数据信息迅速进入了您需要管理的范畴，其输出会影响您企业的商业智能解决方案或者甚至是您企业的业务活动。积极的考虑将这些数据纳入到您企业的数据管理功能的范围，并明确企业的所有权，并记录好这些数据信息的诸如如何使用、信息来源等等资料。
不要采取“容易的轻松路线”，单纯依靠大数据技术是您企业唯一正式的非结构化数据管理的过程。随着时间的推移，企业将收集越来越多的非结构化数据，请务必搞清楚哪些数据是好的，哪些是坏的，他们分别来自何处，以及其使用是否一致，将变得越来越重要，甚至在其生命周期使用这个数据都是至关重要的。
要保持这种清晰，您可以使用大数据和其他工具，以了解您企业所收集的数据信息，确定其有怎样的价值，需要怎样的管理，这是至关重要的。大多数进入您企业的大数据系统的非结构化数据都已经经过一些监控了，但通常是作为一个BLOB（binarylargeobject）二进制大对象和非结构化的形式进行的。随着您的企业不断的在您的业务流程中“发掘”出这一类型的数据，其变得更加精确和有价值。其可能还具有额外的特点，符合安全，隐私或法律和法规的元素要求。最终，这些数据块可以成为新的数据元素或添加到现有的数据，但您必须有元数据对其进行描述和管理，以便尽可能最有效地利用这些数据。
5、正式在生产环境运行之前进行测试。
如果您的企业做的是一次性的分析或完整的一次性的试点，这可能并不适用于您的企业，但对大多数企业来说，他们最初的大数据工作将迅速发展，他们找到一个可持续利用他们已经挖掘出的极具价值的信息的需求。这意味着需要在您的沙箱环境中进行测试，然后才正式的在您的生产环境运。
㈢ 最近公司接到一个项目,数据实时监控大屏展示怎么做,推荐一下
大数据看班，平台和拼控
㈣ 鐧句嚎绾у疄鏃跺ぇ鏁版嵁鍒嗘瀽椤圭洰锛屼负浠涔堜笉鐢℉adoop
銆銆1. Hadoop闆嗙兢鐨勬墿灞曟ф槸鍏朵竴澶х壒鐐癸紝Hadoop鍙浠ユ墿灞曡嚦鏁板崈涓鑺傜偣锛屽规暟鎹鎸佺画澧為暱锛屾暟鎹閲忕壒鍒宸ㄥぇ鐨勯渶姹傚緢鍚堥傘
銆銆2. Hadoop鐨勬垚鏈鏄鍏跺彟涓澶т紭鍔匡紝鐢变簬Hadoop鏄寮婧愰」鐩锛岃屼笖涓嶄粎浠庤蒋浠朵笂鑺傜害鎴愭湰锛岀‖浠朵笂鐨勮佹眰涔熶笉楂樸傜洰鍓嶅幓IOE娼娴侀庤岋紝浣庢垚鏈鐨凥adoop涔熸槸涓澶ф帹鎵嬨
銆銆3. Hadoop鐢熸佺兢娲昏穬锛屽叾鍛ㄨ竟寮婧愰」鐩涓板瘜锛孒Base, Hive锛孖mpala绛夌瓑鍩虹寮婧愰」鐩浼楀氥
銆銆
㈤ 大数据数仓项目架构
云上数据仓库解决方案： https://www.aliyun.com/solution/datavexpo/datawarehouse
离线数仓架构
离线数仓特点
基于Serverless的云上数据仓库解决方案
架构特点
实时数仓架构
[图片上传失败...(image-ec3d9a-1629814266849)]
实时数仓架构特点
秒级延迟，实时构建数据仓库，架构简单，传统数仓平滑升级
架构特点
数据仓库的输入数据源和输出系统分别是什么？
输入系统：埋点产生的用户行为数据、javaEE后台产生的业务数据、个别公司有爬虫数据。
输出系统：报表系统、用户画像系统、推荐系统
1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）
2）CDH：国内使用最多的版本，但 CM不开源，但其实对中、小公司使用来说没有影响（建议使用）10000美金一个节点 CDP
3）HDP：开源，可以进行二次开发，但是没有CDH稳定，国内使用较少
服务器使用物理机还是云主机？
1）机器成本考虑：
（1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，惠普品牌。一般物理机寿命5年左右。
（2）云主机，以阿里云为例，差不多相同配置，每年5W
2）运维成本考虑：
（1）物理机：需要有专业的运维人员（1万*13个月）、电费（商业用户）、安装空调
（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松
3）企业选择
（1）金融有钱公司和阿里没有直接冲突的公司选择阿里云（上海）
（2）中小公司、为了融资上市，选择阿里云，拉倒融资后买物理机。
（3）有长期打算，资金比较足，选择物理机。
根据数据规模大家集群
属于 研发部 /技术部/数据部，我们属于 大数据组 ，其他还有后端项目组，前端组、测试组、UI组等。其他的还有产品部、运营部、人事部、财务部、行政部等。
大数据开发工程师=>大数据组组长=》项目经理=>部门经理=》技术总监
职级就分初级，中级，高级。晋升规则不一定，看公司效益和职位空缺。
京东：T1、T2应届生；T3 14k左右 T4 18K左右 T5 24k-28k左右
阿里：p5、p6、p7、p8
小型公司（3人左右）：组长1人，剩余组员无明确分工，并且可能兼顾javaEE和前端。
中小型公司（3~6人左右）：组长1人，离线2人左右，实时1人左右（离线一般多于实时），组长兼顾和javaEE、前端。
中型公司（5 10人左右）：组长1人，离线3 5人左右（离线处理、数仓），实时2人左右，组长和技术大牛兼顾和javaEE、前端。
中大型公司（10 20人左右）：组长1人，离线5 10人（离线处理、数仓），实时5人左右，JavaEE1人左右（负责对接JavaEE业务），前端1人（有或者没有人单独负责前端）。（发展比较良好的中大型公司可能大数据部门已经细化拆分，分成多个大数据组，分别负责不同业务）
上面只是参考配置，因为公司之间差异很大，例如ofo大数据部门只有5个人左右，因此根据所选公司规模确定一个合理范围，在面试前必须将这个人员配置考虑清楚，回答时要非常确定。
IOS多少人 安卓多少人 前端多少人 JavaEE多少人 测试多少人
（IOS、安卓） 1-2个人 前端1-3个人； JavaEE一般是大数据的1-1.5倍，测试：有的有，有的没有。1个左右。 产品经理1个、产品助理1-2个，运营1-3个
公司划分：
0-50 小公司
50-500 中等
500-1000 大公司
1000以上 大厂 领军的存在
转自： https://blog.csdn.net/msjhw_com/article/details/116003357