1.基础技术
基础技术是大数据技术的基石，主要要考虑两个大的问题：怎么提高性能？以及怎么保证数据可靠性？
提升性能最主要的方式是数据分片，让每个分片独立的计算，需要查询的时候可以路由到指定的分片，这样可以发挥分布式的优势。
保证数据可靠性的方式就是将同一份数据存储多个副本，并且分布在不同的机器上，这样当一台机器出现故障甚至损坏，数据也可以从其他副本恢复，不过数据复制本身的实现非常的复杂，需要考虑如何复制以及如何保证复制的一致性、实时性、更新策略等各种问题，比如一致性则需要考虑到使用不同的一致性模型来实现。
当然除了上面的数据分片和可靠性之外，尽量将单机性能压缩要极致也是需要考虑的，这样就需要采用尽可能高效的数据结构和算法，实现单个节点效率的最大化，从而提升整个集群的性能。
2.数据采集
数据采集可以有日志系统采集、网络数据采集以及硬件设备数据采集等，对于日志系统的采集可以采用系统埋点发送日志的方式主动推送，也可以使用数据采集框架，比如：Flume，Logstash等；如果是网络数据，则优先采用公开的API调用来采集，如果没有API可能需要爬虫的方式来采集；设备数据采集主要针对一些带有传感器的物理设备，这种一般会有专门的SDK用于采集。
3.数据传输
数据传输可以分为：实时大规模的数据传输、定时批量的数据传输。
对于实时大规模的数据传输，采用的常见方式就是消息队列，例如: Kafka、RocketMQ等，主要用来实现应用解耦、异步以及流量削峰等应用，并且很容易实现高可用、高伸缩的架构。
对于定时批量的数据传输，也叫作数据同步，比如从原始数据(ODS)的数据库中，比如MySQL、Oracle等业务数据库，批量加载数据，然后同步到大数据的平台，比如数据仓库中，这中间可能涉及到大批量数据加载、数据的转换，数据的存储，可能需要借助一些批量计算的框架进行，同时需要考虑数据的准确、可靠等内容。
序列化：数据传输的基础就是数据序列化，需要将对象序列化为字节流才可以真正的在网络中进行通信，如何高效的序列化、反序列化、传输等都是需要考虑的性能点。
4.数据存储
大数据存储主要针对于：海量、异构、结构化和非结构化等数据提供高性能、高可靠的存储以及访问能力，一方面可以解决大数据量的存储和高吞吐的访问，另一方面要支撑大规模数据分析、计算的平台。
4.1 物理存储
对于物理计算机，最主要的是内置存储比如：CPU寄存器、L1/L2/L3 cache、RAM等，内置存储的速度非常快，但是容量非常小，并且有易失性，因此计算机都会将操作系统、程序、文件等保存到硬盘，需要使用时会加载到内存，硬盘这类存储就属于外挂存储，特点是容量大、断电不丢失，但是缺点是速度慢，外挂存储又分为：直连式存储(DAS)、网络化存储(FAS)，直连式存储就是直接插到计算机上面的存储设备，比如常见的SSD，机械硬盘等，网络存储是通过网络的方式共享的存储，又可以分为：网络接入存储(NAS)、存储区域网络(SAN)，比如iSCSI这种块设备存储就属于SAN的范畴。
针对不同场景，往往选择不同的分布式存储方案，常见的存储类型有：文件存储、块存储、对象存储这三类。
文件存储：比如上面说的NAS，另外还有NFS、SMB、FTP等服务都属于文件存储。
块存储：最简单的就是本地磁盘设备、磁盘阵列这些属于DAS，另外还有SAN，比如iSCSI等。
对象存储：物理存储中暂时没有对象存储。
4.2 分布式存储系统
常见的分布式存储系统有：HDFS、OpenStack Swift、Ceph、GlusterFS、Ozone等，其中比如HDFS、GlusterFS属于文件存储，Swift和Ozone就属于对象存储，Ceph则兼具3类存储的能力。
4.3 分布式数据库
除了分布式文件存储系统之外，很大的一部分就是数据库，有的数据库依赖外部的存储系统，但有的数据库本身具有存储功能，数据库最大的特点是本身具有对数据库检索和分析的能力，根据应用的场景不同，又可以进一步细分：
4.3.1 分布式关系型数据库
这类数据库可以非常好的弥补单机的关系数据库不足，同时分布式关系型数据库完全支持单机数据库的所有特性，并且提供的充分的水平扩展和容错能力，常见的分布式关系型数据库有：TiDB、Greenplum等，另外还有阿里云的PolarDB，这类数据库主要解决单机业务数据库的瓶颈问题，主要用在OLTP场景。
4.3.2 分析型数据库
分析型数据库主要面向OLAP(分析应用)的数据库，可以对数据进行在线的复杂分析、即席查询等挖掘类型的业务，是数据库领域中很大的一个分支，比较流行的分析数据库有：Kylin、Druid、Clickhouse、Vertica、Doris，另外还有阿里云的AnalyticDB。
4.3.3 搜索引擎
搜索引擎可以支持海量数据的精确和全文检索等，并且提供分布式、高性能、高可用的搜索分析系统，常见的搜索引擎平台有：ElasticSearch、Solr，其中ElasticSearch应用比较多。
4.3.4 文档数据库
文档型数据库是NoSQL中的一个重要分支，主要用来存储、索引面向文档类型的数据或半结构化数据，目前业界比较流行的文档型数据库有：MongoDB、CouchDB、ArangoDB(文档模型)。
4.3.5 列式存储数据库
列式数据库是以列为存储架构进行数据存储的数据库，主要用于批量数据处理和查询，适合大批量数据的联机事务和统计分析等，常见的列式数据库有：Phoenix、Cassandra、Hbase、Kudu、ScyllaDB等，其实上面分析型数据库也有一些是列式存储的架构，并不是孤立的，只是应用场景不大相同。
4.3.6 图数据库
图数据库也属于NoSQL，是将图形理论应用到实体和关系信息存储当中，图数据库主要实现的就是图这种数据结构的存储、查询、图算法等，要素就是顶点和边，有些图数据库也可以处理键值对，图数据库就是解决复杂关系的计算和存储问题，常见的图数据库有：Neo4J、ArangoDB、OrientDB等。
4.3.7 键值数据库
这个是最简单也是应用最多的数据库，常见的键值数据库性能都特别高，比如：Redis、Memcached、rocksdb、leveldb、TiKV、腾讯的Tendis。
5.数据计算
5.1 流式计算(Streaming compute)
流式计算是利用分布式的思想和方法，对海量源源不断的“流”式数据进行实时处理，流式计算更加强调计算的对象是数据流和低时延，流式数据其实就是一种不断增长，无限的数据集。流式计算我们有时候又叫做实时计算，其实并不完全一样，共同点是流式计算和实时计算都要求低延时，但是从对象来说流式计算的对象是无限流，但是实时计算的对象不一定是数据流，有可能是批量数据，交互式查询等各种形式。
常见的流式计算框架有：Flink、Spark Streaming、Storm、Kafka streams，其中目前flink的社区最为活跃，支持流批一体，功能强大，是流计算框架的首选，如果是spark生态可以使用spark streaming。
5.2 批量计算(Batch compute)
批量计算是对已经存储好的静态数据进行大规模批处理的计算，批量计算强调的是规模大、并行化、时延相对高，计算是主动以任务或作业形式发起的，批量计算我们有时候又叫做离线计算，其实同样不等价，离线计算更多的是强调计算的特征是非实时，包括计算和生成结果等都是非实时的，而批量计算重点是任务的输入是批量的数据集，数据的生成和读取是非绑定的，各自环节可以单独完成，如果硬件水平非常好，那么批量计算同样可以做到时延非常低。
常见的批量计算框架有：MapReduce、Hive、Spark等，目前Spark由于内存计算的特性应用比较活跃。
其实从上面看，数据处理有两大门派，分别是：流式计算和批量计算，这两个概念是基于技术或者数据类型本身的概念，而实时计算和离线计算更多的是根据需要，强调时延的高低，内容反馈的及时性，其中并不涉及到数据本身的规模。因此流式计算和批量计算更多的是在大数据分析场景，而实时计算和离线计算更多的是通用的计算场景。
5.3 即席查询(Ad Hoc)
即席查询就是用户可以根据业务的需求，非常灵活的选择查询的条件，系统根据条件进行快速的查询和分析并返回结果，即席查询的分析模式兼具了良好的时效性和灵活性，是对流式计算和批量计算的一种很好的补充，和批量计算比起来，即席查询更加便捷，具有交互式，因此我们也常把即席查询叫做交互式分析。
常见的即席查询框架有：Impala、Presto、Drill等。
5.4 图计算
图计算是一种针对特殊数据结构 - 图数据的计算类型，数据本身一般是以大规模图或网络的形式呈现的，比如社交网络、病毒传播途径、路网数据等，经常会转换成图这种模型后进行计算分析，图数据非常好的表达的数据之前的关联性，要处理巨大的图数据，也需要大规模的集群采取并行方式计算。
常见的图计算框架：Google Pregel、Spark GraphX、GraphChi、Apache Giraph等，另外图数据库也承担了很多图计算的功能，这里的图计算框架往往是仅仅对于输入进行计算，而不强调具体的存储。
其实数据存储部分的数据库和数据计算也有很多共同的部分，甚至是可交换的，同样数据计算重点强调的是计算本身，而很多分析型的数据库本身就具有比较强的计算能力，比如Druid、Clickhouse、Impala、Presto、SparkSQL这些引擎本身都可以实现大规模的计算和分析，通常虽细分的领域不同，但在架构设计中往往是你中有我我中有你。
比如在中小型的灵活业务分析中，为了减少部署成本我们可以选择TiDB或Doris作为数据库，成本低、灵活性高、反馈快，非常方便的用于各类业务查询和分析；但针对大型业务中，就要求我们具备很强的调优能力对TiDB或Doris设计索引指标或根据业务对数据表拆分或调优来提高性能，随着业务的增大，比如到200亿以上级别的数据，而且数据维度特别高，并发也非常大的时候，就不适合继续使用TiDB或者Doris了，这时候可以选择：Druid、Clickhouse、Impala、Presto、Kylin、SparkSQL等平台，Presto相对于Impala查询SQL支持更好，灵活性更高，而且支持的数据源也更丰富，但是性能上要比Impala低一些，如果需要丰富的支持可以选择Presto，但是如果要求支持高并发，高性能的复杂SQL查询那么可以选择Impala，对于预先设计好的维度的查询可以选用Kylin，如果是对海量数据大宽表的聚合分析，当然首选Druid或Clickhouse，都可以实现很高的性能，但是并发支持不如Impala高，只是单次计算的响应时效非常好，如果是Hadoop生态可以选用Druid，其他情况可以选择Clickhouse，如果是大规模的批量分析，计算复杂但是时效性要求不太高的情况下，可以选用SparkSQL。当然上面这些选项只是一个大概的方向，具体还要做充分的调研、调试之后再做最终选型，选择最适合目前业务和未来一段时间增长需求的平台。
7.数据仓库
和数据库相比，数据仓库重点在于大规模数据的摄取、管理和分析，正常来说数据库的设计要求结构紧凑，尽量省空间，冗余尽量少，读写优化，查询尽量落在比较少的数据上而提高性能，适合高并发，频繁的查询下能快速响应，而数据仓库重点是表格结构大而全，设计简单，存储冗余而且松散，一般只是对批量数据读取做优化，而且支持单次复杂的查询，作用在大规模的历史数据上，因此单次分析时间较长，查询都是任务型的，不会特别频繁，所以数据仓库看起来和OLAP分析型数据库很像，但OLAP数据库仍然强调时效性和大量表设计的优化，这点和数据仓库不同，数据仓库看起来更像是摄取各类原始数据然后存储起来，提供其他二次分析数据源的地方，对企业来说是一个统一的数据管理中心，因此在数据仓库基础上又诞生出数据湖的概念。
常见的数据仓库有：Hive、Pig、Apache Hudi等，目前已经有企业基于Hudi构建自己的数据湖。
8.分布式协调系统
大规模分布式系统中各节点之间需要任务协调，才能有效实现分工，例如系统扩容添加节点，我们怎么从原集群中获取配置？当机器状态改变时，如何通知集群中其他节点？当master发生故障时，如果从其他备用节点选举新的master并完成故障切换？以上这些常见的分布式系统中的问题，都需要分布式协调系统来辅助完成，很多组件内置了分布式协调系统，也有很多组件使用第三方的分布式协调系统，但是本质上实现的目标都是类似的，分布式协调系统主要提供：统一命名服务，状态一致性服务，集群配置信息保存和管理等服务。
常见的第三方分布式协调系统有：zookeeper、Eureka、Consul，另外还可以使用Etcd，Redis等间接实现分布式协调。
9.集群资源管理和调度
资源管理主要应对的是多任务、多租户的情况，可以让计算更具弹性，给每个任务或者用户限定CPU、内存、网络等物理资源，实现资源隔离和多任务的调度。
除了常见的虚拟化或容器化的资源隔离方案外，常用的大数据系统资源管理系统有：Google Omega和Borg、Yarn、Mesos。
另外值得一提的是，3个著名的资源管理的平台：Omega，Borg，Kubernetes都是Google研发出来的，这3个容器管理系统，分别对应3个不同的工程师对应不同的体系，按照时间线依次为：Borg->Omega->Kubernetes，期间经过不断的改进和延伸，目前Kubernetes已经非常流行，Google在这方面一直是走在最前沿的。
除了集群资源调度的平台外，还有一些常见的监控界面系统，方便部署或运维，比如：Ambari、Cloudera Manager、Hue等。
10.工作流和任务管理引擎
目前随着业务不断复杂，大数据的任务量也不断增加，多个任务经常是同时执行并且需要有各种复杂的依赖关系，因此就会涉及到工作流管理的问题，首先对于工作流会抽象为有向无环图(DAG)，然后依次将任务构建成DAG然后进行管理，对于开发人员说只需要关注某一个具体的任务即可，而不用考虑复杂的依赖关系。
常见的工作流管理平台有：Oozie、Azkaban、Airflow等。