大数据秋招学习笔记13

实时数仓项目：
离线需求：
就是在计算开始前已知所有输入数据，输入数据不会产生变化，一般计算量级较大，计算时间也较长。例如今天早上一点，把昨天累积的日志，计算出所需结果。最经典的就是Hadoop 的 MapReduce 方式；一般是根据前一日的数据生成报表，虽然统计指标、报表繁多，但是对时效性不敏感。
实时需求：
输入数据是可以以序列化的方式一个个输入并进行处理的，也就是说在开始的时候并不需要知道所有的输入数据。与离线计算相比，运行时间短，计算量级相对较小。强调计算过程的时间要短，即所查当下给出结果。主要侧重于对当日数据的实时监控，通常业务逻辑相对离线需求简单一些，统计指标也少一些，但是更注重数据的时效性，以及用户的交互性。
1）模拟日志生成器：使用脚本模拟日志生成，将日志发送给某一个指定的端口。
2）IDEA上编写SpringBoot程序，采集模拟生成的日志数据（SpringBoot内嵌 Tomcat，发布应用程序端口供日志脚本访问）。
3）在 SpringBoot程序中，对日志数据进行分流，根据日志类型（事件|启动）将采集到的日志数据发送到不同的 kafka 主题中去（使用 KafkaTemplate对接收到的数据进行分流）。
4）将SpringBoot 程序打jar包发送至linux服务器。
5）搭建日志采集集群，并通过 Nginx 进行反向代理。（修改模拟日志生成的配置，发送到的服务器路径修改为 nginx 的）。
6）Nginx (“engine x”) 是一个高性能的 HTTP 和反向代理服务器,特点是占有内存少，并发能力强。正向代理类似一个跳板机，代理访问外部资源。反向代理（Reverse Proxy）方式是指以代理服务器来接受 internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
反向代理的实现：
（1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上。
（2）服务器返回自己的服务到负载均衡设备。
（3）负载均衡将服务器的服务返回用户。
用户和负载均衡设备直接通信，也意味着用户做服务器域名解析时，解析得到的IP其实是负载均衡的IP，而不是服务器的IP，这样有一个好处是，当新加入/移走服务器时，仅仅需要修改负载均衡的服务器列表，而不会影响现有的服务。
7）Nginx 主要应用：
（1）静态网站部署：
Nginx 是一个 HTTP 的 web 服务器，可以将服务器上的静态文件（如 HTML、图片等）通过 HTTP 协议返回给浏览器客户端。
（2）负载均衡：
负载均衡通常是指将请求"均匀"分摊到集群中多个服务器节点上执行，这里的均匀是指
在一个比较大的统计范围内是基本均匀的，并不是完全均匀。
（3）静态代理：
把所有静态资源的访问改为访问 nginx，而不是访问 tomcat，这种方式叫静态代理。因为 nginx 更擅长于静态资源的处理，性能更好，效率更高。
所以在实际应用中，我们将静态资源比如图片、css、html、js 等交给 nginx 处理，而
不是由 tomcat 处理。动态资源，如 jsp 由 tomcat 或其他 web 服务器完成。
（4）虚拟主机：
虚拟主机，就是把一台物理服务器划分成多个“虚拟”的服务器，这样我们的一台物理服务器就可以当做多个服务器来使用，从而可以配置多个网站。
Nginx 提供虚拟主机的功能，就是为了让我们不需要安装多个 Nginx，就可以运行多个域名不同的网站。
Nginx 下，一个 server 标签就是一个虚拟主机。nginx 的虚拟主机就是通过 nginx.conf
中 server 节点指定的，想要设置多个虚拟主机，配置多个 server 节点即可。
比如一个公司有多个二级域名，没有必要为每个二级域名都提供一台 Nginx 服务器，就可以使用虚拟主机技术，在一台 nginx 服务器上，模拟多个虚拟服务器。
8）Elasticsearch基础：
ElasticSearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。
Elasticsearch 是一个近实时的搜索平台，从生成文档索引到文档成为可搜索，有一个
轻微的延迟(通常是一秒钟)。
Elasticsearch使用场景：
（1）电商搜索引擎，使用 Elasticsearch 存储商品与品类信息，提供搜索和搜索建议功能（全文检索）。
（2）日志系统，收集、分析日志数据，可以使用 Logstash (Elasticsearch/Logstash/Kibana 栈的一部分)来收集，然后将这些数据提供给
Elasticsearch，通过搜索和聚合计算挖掘有价值的信息，最后通过 Kibana 进行可视化展示。
（3）价格提醒平台，在价格变动时，让用户可以收到通知。抓取供应商的价格，推入
Elasticsearch，并使用其反向搜索(Percolator)功能来匹配用户的价格通知设置，找到匹配后将提醒推送给用户。
（4）BI(商业智能)，分析业务大数据，挖掘有价值的商务信息。可以使用 Elasticsearch来存储数据，然后使用 Kibana (Elasticsearch/Logstash/Kibana 堆栈的一部分)进行可视化展示。
ElasticSearch 的特点：
（1）天然分片，天然集群：ES 把数据分成多个 shard，多个 shard 可以组成一份完整的数据，这些 shard 可以分布在集群中的各个机器节点中。随着数据的不断增加，集群可以增加多个分片，把多个分片放到多个机子上，以达到负载均衡，横向扩展。
在实际运算过程中，每个查询任务提交到某一个节点，该节点必须负责将数据进行整理汇聚，再返回给客户端，也就是一个简单的节点上进行 Map 计算，在一个固定的节点上进行 Reduce得到最终结果向客户端返回。
这种集群分片的机制造就了 elasticsearch 强大的数据容量及运算扩展性。
（2）天然索引：ES 所有数据都是默认进行索引的，这点和 MySQL 正好相反，MySQL 是默认不加索引，要加索引必须特别说明，ES 只有不加索引才需要说明。而 ES 使用的是倒排索引和 MySQL 的 B+Tree 索引不同。
传统的关系性数据库对于关键词的查询，只能逐字逐行的匹配，性能非常差。
倒排索引的保存数据的方式是：单词→记录, 基于分词技术构建倒排索引,每个记录保
存数据时，都不会直接存入数据库。系统先会对数据进行分词，然后以倒排索引结构保存。
9）Kibana：
Elasticsearch 提供了一套全面和强大的 REST API，我们可以通过这套 API 与 ES 集群进行交互。Kibana 是为 Elasticsearch 设计的开源分析和可视化平台。你可以使用 Kibana 来搜索，查看存储在 Elasticsearch 索引中的数据并与之交互。你可以很容易实现高级的数据分析和可视化，以图表的形式展现出来。Kibana 本身只是一个工具，不需要分发，不涉及集群，访问并发量也不会很大。
10）Elasticsearch 与关系型数据库的对应：
Index对应Table，Document对应Row，Field对应Column。ElasticSearch是用一个json
来表示一个 document。
假设有如下实体：
public class Movie {
String id;
String name;
Double doubanScore;
List actorList;
}
public class Actor{
String id;
String name;
}
保存到 ES 中应该是：
{
“id”:“1”,
“name”:“operation red sea”,
“doubanScore”:“8.5”,
“actorList”:[
{“id”:“1”,“name”:“zhangyi”},
{“id”:“2”,“name”:“haiqing”},
{“id”:“3”,“name”:“zhanghanyu”}
]
}
11）实现功能：当日用户首次登录（日活）统计。（日志数据）
实现思路：
（1）SparkStreaming 消费 kafka 数据。
要保证数据的精准一次性消费（Exactly-once）。
数据何时会丢失：
比如实时计算任务进行计算，到数据结果存盘之前，进程崩溃，假设在进程崩溃前kafka调整了偏移量，那么 kafka 就会认为数据已经被处理过，即使进程重启，kafka 也会从新的偏移量开始，所以之前没有保存的数据就被丢失掉了。
数据何时会重复：
如果数据计算结果已经存盘了，在 kafka 调整偏移量之前，进程崩溃，那么 kafka 会
认为数据没有被消费，进程重启，会重新从旧的偏移量开始，那么数据就会被 2 次消费，又会被存盘，数据就被存了 2 遍，造成数据重复。
如果同时解决了数据丢失和数据重复的问题，那么就实现了精确一次消费的语义了。
如何解决：
策略一：利用关系型数据库的事务进行处理
出现丢失或者重复的问题，核心就是偏移量的提交与数据的保存，不是原子的。如果能做成要么数据保存和偏移量都成功，要么两个失败，那么就不会出现丢失或者重复了。这样的话可以把存数据和修改偏移量放到一个事务里。这样就做到前面的成功，如果后面做失败了，就回滚前面那么就达成了原子性，这种情况先存数据还是先修改偏移量没影响。
好处：事务方式能够保证精准一次性消费。
问题与限制：
（1）数据必须都要放在某一个关系型数据库中，无法使用其他功能强大的 nosql 数据库。
（2）事务本身性能不好。
（3）如果保存的数据量较大，一个数据库节点不够，要使用多个节点的话，还要考虑分布式事务的问题。分布式事务会带来管理的复杂性，一般企业不选择使用，有的企业会把分布式事务变成本地事务，例如把 Executor 上的数据通过 rdd.collect 算子提取到Driver 端，由 Driver 端统一写入数据库，这样会将分布式事务变成本地事务的单线程操作，降低了写入的吞吐量。
使用场景：数据足够少（通常经过聚合后的数据量都比较小，明细数据一般数据量都比较大），并且支持事务的数据库。
策略二：手动提交偏移量+幂等性处理：
我们知道如果能够同时解决数据丢失和数据重复问题，就等于做到了精确一次消费。那就各个击破。
首先解决数据丢失问题，办法就是要等数据保存成功后再提交偏移量，所以就必须手工来控制偏移量的提交时机。但是如果数据保存了，没等偏移量提交进程挂了，数据会被重复消费。怎么办？
那就要把数据的保存做成幂等性保存。即同一批数据反复保存多次，数据不会翻倍，保存一次和保存一百次的效果是一样的。如果能做到这个，就达到了幂等性保存，就不用担心数据会重复了。
难点:
话虽如此，在实际的开发中手动提交偏移量其实不难，难的是幂等性的保存，有的时候并不一定能保证，这个需要看使用的数据库，如果数据库本身不支持幂等性操作，那只能优先保证的数据不丢失，数据重复难以避免，即只保证了至少一次消费的语义。一般有主键的数据库都支持幂等性操作 upsert。
使用场景:
处理数据较多，或者数据保存在不支持事务的数据库上。
偏移量保存在哪：
本身 kafka 0.9 版本以后 consumer 的偏移量是保存在 kafka 的__consumer_offsets主题中。但是如果用这种方式管理偏移量，有一个限制就是在提交偏移量时，数据流的元素结构不能发生转变，即提交偏移量时数据流，必须是InputDStream[ConsumerRecord[String, String]] 这种结构。但是在实际计算中，数据难免发生转变，或聚合，或关联，一旦发生转变，就无法在利用以下语句进行偏移量的提交：
xxDstream.asInstanceOf[CanCommitOffsets].commitAsync(offsetRanges)
因为 offset 的存储于 HasOffsetRanges，只有 kafkaRDD 继承了他，所以假如我们对 KafkaRDD 进行了转化之后，其它 RDD 没有继承 HasOffsetRanges，所以就无法再获取offset 了。
实际生产中通常会利用 ZooKeeper,Redis,Mysql 等工具手动对偏移量进行保存。
我们是通过 Redis 完成的去重，其实也可以在 ES 中进行去重操作。但是通过 Redis 去重，保留的是前面的数据，有就不向里加。通过 ES 或者其他数据库去重，是完成的替换，保留的是后面的数据根据实际的需求选择合适的实现。
（2）利用 redis 过滤当日已经计入的日活设备（对一个用户的多次访问进行去重）。
Redis 的五大数据类型中，String 和 Set 都可以完成去重功能，但是 String 管理不适合整体操作，比如设置失效时间或者获取当天用户等操作,所以我们项目中使用的是 Set类型，处理批量管理以外，还可以根据 saddAPI 的返回结果判断用户是否已经存在。
（3）把每批次新增的当日日活信息保存到 ES 中。（创建一个样例类，用于封装需要的日志数据。）
（4）从 ES 中查询出数据，可以使用Kibana进行可视化查询，也可以发布成数据接口，可视化工程进行调用。
12）实现功能：当日新增付费用户首单分析。（业务数据）
实现思路：
（1）数据采集：
从 MySQL 数据库中采集业务数据到 Kafka，并对数据进行分流处理（ODS 层），分流数据处理之后，将数据写回 Kafka。我们这里使用 canal 和 Maxwell 两种方式实现。
canal 是用 java 开发的基于数据库增量日志解析，提供增量数据订阅&消费的中间件。目前，canal 主要支持了 MySQL 的 binlog 解析，解析完成后才利用 canal client 来处理。获得的相关数据。（数据库同步需要阿里的 otter 中间件，基于 canal）。
常见场景1：更新缓存
常见场景2：抓取业务数据新增变化表，用于制作拉链表
常见场景3：抓取业务表的新增变化数据，用于制作实时统计（我们就是这种场景）
canal 会追踪整个数据库的变更，把所有的数据变化都发到一个 topic 中了，但是为了后续处理方便，应该把这些数据根据不同的表，分流到不同的主题中去。
Maxwell 和 canal 工具对比：
（1）Maxwell 没有 canal 那种 server+client 模式，只有一个 server 把数据发送到消息队列或 redis。如果需要多个实例，通过指定不同配置文件启动多个进程。
（2）Maxwell 有一个亮点功能，就是 canal 只能抓取最新数据，对已存在的历史数据没有办法处理。而 Maxwell 有一个 bootstrap 功能，可以直接引导出完整的历史数据用于初始化，非常好用。
（3）Maxwell 不能直接支持 HA，但是它支持断点还原，即错误解决后重启继续上次点儿读取数据。
（4）Maxwell 只支持 json 格式，而 Canal 如果用 Server+client 模式的话，可以自定义格式。
（5）Maxwell 比 Canal 更加轻量级。
canal 每一条 SQL 会产生一条日志，如果该条 Sql 影响了多行数据，则会通过集合的方式归集在这条日志中。（即使是一条数据也会是数组结构）maxwell 以影响的数据为单位产生日志，即每影响一条数据就会产生一条日志。如果想知道这些日志是否是通过某一条 sql 产生的可以通过 xid 进行判断，相同的 xid 的日志来自同一 sql。
当原始数据是数字类型时,maxwell 会尊重原始数据的类型不增加双引，变为字符串。canal 一律转换为字符串。
canal 数据中会带入表结构。maxwell 更简洁。
（2）判断是否为首单用户：
每笔订单都要判断是否是该用户的首单，判断是否首单的要点，在于该用户之前是否参与过消费（下单）。那么如何知道用户之前是否参与过消费，如果临时从所有消费记录中查询，是非常不现实的。那么只有将“用户是否消费过”这个状态进行保存并长期维护起来。在有需要的时候通过用户 id 进行关联查询。
在实际生产中，这种用户状态是非常常见的比如“用户是否退过单”、“用户是否投过
诉”、“用户是否是高净值用户”等等。我们要想保存状态，大家可能会想到在 Redis 中保存，Redis 可以实现，但是这个状态可能包含历史数据，数据量比较大，而且历史数据保存在内存中，对内存压力也比较大。所以考虑到：
1、这是一个保存周期较长的数据。
2、必须可修改状态值。
3、查询模式基本上是 k-v 模式的查询。
所以综上这三点比较，状态适合保存在 Hbase 中。
（3）订单表与维度表的关联：
在查询订单的时候，订单与 Hbase 中省份和用户的维度表进行关联，才能获取省份名称、用户性别、用户年龄等对应字段，完成后面的统计。
维度数据和状态数据非常像，但也有不同之处。
相同点：
长期保存维护
可修改
使用 k-v 方式查询
不同点：
数据变更的时机不同
状态数据往往因为事实数据的新增变化而变更
维度数据只会受到业务数据库中的变化而变更
综上:
根据共同点，维度数据也是非常适合使用 hbase 存储的，稍有不同的是维度数据必须启动单独的实时计算来监控维度表变化来更新实时数据。
（4）将订单关联后的宽表保存到 ES，利用 Kibana 进行分析展示。
13）实现功能：订单明细实付金额分摊
实现思路：
（1）准备订单明细数据：前面我们已经将订单和用户、是否首单状态以及省份进行关联，并且将宽表保存到了ES 中，但是订单表中缺少订单明细，通过订单明细我们才能与商品进行关联，所以我们需要先准备订单明细数据，再让订单明细与商品进行关联。
订单和订单明细，都是实时产生的业务数据，如果将订单明细也当作维表进行处理，不能保证订单明细肯定先存在于维表中，所以订单明细也应该作为事实表进行处理。然后再用订单明细和商品维表进行关联，获取商品相关信息。
订单明细事实表和商品、品牌、spu 等维表关联：
方法 1：用明细表依次和每个维度表进行关联
订单明细和商品关联：
order_detail --> sku_id
订单明细商品宽表和 spu 关联
订单明细宽表(spu_id) --> spu 得到 spuname
订单明细商品和 spu 宽表和品牌关联
订单明细宽表(tm_id) --> tm 得到 tm_name
订单明细商品、spu、品牌宽表和品类关联
订单明细宽表（category3_id) --> cate 得到 cate_name
这种方式，订单明细事实表记录很多，每条记录都进行 4 次关联，效率较低。
方法 2：维度退化
先用商品维度表和 Spu、品牌、品类维度表提前进行关联（维度退化）
订单明细和 --> sku 维度宽表
我们使用这种方式。
在 Hbase 中创建表与维表对应，接收用户数据的新增和修改保存到 Hbase 。
采集 Kafka 中维表数据到 Hbase 对应的表中。
先用商品维度表和 Spu、品牌、品类维度表提前进行关联（维度退化），
订单明细和 --> sku 维度宽表。
将关联后的订单明细宽表写入到 kafka 中。
将订单表写入 Kafka（DWD 层）。
（2）双流合并：所以除了订单事实表与维表进行合并形成宽表，还需要订单事实表与订单明细事实表进行合并形成更大的宽表。
双流合并的问题：
由于订单流和订单明细流，两个流的数据是独立保存，独立消费，很有可能同一业务的数据，分布在不同的批次。因为 join 算子只 join 同一批次的数据。如果只用简单的 join 流方式，会丢失掉不同批次的数据，无法保证同一批次的订单和订单明细在同一采集周期中。
解决策略：
（1）通过缓存
思路：
两个流做满外连接因为网络延迟等关系，不能保证每个窗口中的数据 key 都能匹配上，这样势必会出现三种情况：(Some,Some)，(None,Some)，(Some,None),根据这三种情
况，下面做一下详细解析：
◼ (Some，Some)
1 号流和 2 号流中 key 能正常进行逻辑运算，但是考虑到 2 号流后续可能会有剩下的
数据到来，所以需要将 1 号流中的 key 保存到 redis，以等待接下来的数据。
◼ (None,Some)
找不到 1 号流中对应 key 的数据，需要去 redis 中查找 1 号流的缓存，如果找不到，
则缓存起来，等待 1 号流。
◼ (Some,None)
找不到 2 号流中的数据，需要将 key 保存到 redis，以等待接下来的数据，并且去 redis中找 2 号流的缓存，如果有，则 join，然后删除 2 号流的缓存。
优点：不会造成数据重复。
缺点：缓存处理代码编写复杂，尤其是流 join 比较多的情况。
（2）通过滑动窗口+数据去重
优点：处理代码相对简单
缺点：会造成数据重复，需要对重复数据进行处理。
注意：必须是滑动窗口，如果是滚动的话，也没有解决 join 问题。
去重使用redis，set类型，sadd方法返回0则过滤。
（3）订单明细实付金额分摊：计算出订单中每一笔商品分摊后的实付金额。
主订单的应付金额【origin_total_amount】一般是由所有订单明细的商品单价数量汇总【order_pricesku_num】组成。但是由于优惠、运费等都是以订单为单位进行计算的，所以减掉优惠、加上运费会得到一个最终实付金额【final_total_amount】。但问题在于如果是以商品进行交易额分析，就需要把优惠、运费分摊到购买的每个商品中。
一般是由订单明细每种商品的消费占总订单的比重进行分摊，比如总价 1000 元的商品，由 600 元和 400 元的 A、B 两种商品组成，但是经过打折和加运费后，实际付款金额变为810，那么 A 的分摊实付金额为 486 元和 B 的分摊实付金额为 324 元。
由于明细的分摊是由占比而得，那就会进行除法，除法就有可能出现除不尽的情况。比如：原价 90 元，三种商品每件 30 元。没有优惠但有 10 元运费，总实付金额为 100元。按占比分摊各三分之一，就会出现三个 33.33 元。加起来就会出现 99.99 元。就会出现差一分钱的情况。
而我们要求所有订单明细的实付分摊加总必须和订单的总实付相等。所以我们要的是 100=33.33+33.33+33.34。
算法一：如果计算时该明细不是最后一笔
使用乘除法公式：实付分摊金额 / 实付总金额 = （数量 * 单价）/原始总金额
调整移项可得实付分摊金额 = 实付总金额 * (数量 * 单价) / 原始总金额
算法二：如果计算时该明细是最后一笔
使用减法公式：
实付分摊金额= 实付总金额 - (其他明细已经计算好的【实付分摊金额】的合计)
判断是否是最后一笔
判断公式：
如果该条明细 (数量单价) == 原始总金额 -（其他明细【数量单价】的合计）
整个计算中需要的两个合计值：
◼ 其他明细已经计算好的【实付分摊金额】的合计
◼ 订单的已经计算完的明细的【数量*单价】的合计
如何保存这两个合计？保存在 redis 中。
（4）将订单及明细保存到 ClickHouse。
ClickHouse：是一个列式存储数据库，主要用于在线分析处理查询（OLAP），能够使用 SQL 查询实时生成分析数据报告。ClickHouse 像很多 OLAP 数据库一样，单表查询速度优于关联查询，而且ClickHouse 的两者差距更为明显。
（5）发布数据接口（统计新增交易额）：从 ClickHouse 中，查询出订单和订单明细数据，并提供数据接口，方便其它使用者进行统计分析。
14）实现功能：ADS 聚合以及可视化
实现思路：
（1）ADS 层写入：
ads 层，主要是根据各种报表及可视化来生成统计数据。通常这些报表及可视化都是基于某些维度的汇总统计。
统计表分为三个部分：时间点、维度、度量
时间点：即统计结果产生的时间，或者本批次数据中业务日期最早的时间。
维度：统计维度，比如地区、商品名称、性别
度量：汇总的数据，比如金额、数量
每个批次进行一次聚合，根据数据的及时性要求，可以调整批次的时间长度，将聚合后的结果一波一波的存放到数据库中。
聚合数据本身并不麻烦，利用 reducebykey 或者 groupbykey 都可以聚合，但是麻烦的是实现精确性一次消费。因为聚合数据不是明细，没有确定的主键，所以没有办法实现幂等。那么如果想实现精确一次消费，就要考虑利用关系型数据库的事务处理。
用本地事务管理最大的问题是数据保存操作要放在 driver 端变成单线程操作，性能降低。但是由于本业务保存的是聚合后的数据所以数据量并不大，即使单线程保存也是可以接受的，因此数据库和偏移量选用 mysql 进行保存。
（2）发布查询接口
（3）利用DataV实现可视化查询

大数据秋招学习笔记13相关推荐

大数据Hadoop教程-学习笔记01【大数据导论与Linux基础】
视频教程:哔哩哔哩网站:黑马大数据Hadoop入门视频教程,总时长:14:22:04 教程资源:https://pan.baidu.com/s/1WYgyI3KgbzKzFD639lA-_g,提取码: ...
hadoop大数据开发技术学习笔记第三天：（前序）MySQL数据库进阶
hadoop大数据开发技术学习笔记第三天:(前序)MySQL数据库进阶一.回顾知识 1.myschool数据库和数据表的创建 (1)创建数据库 (2)数据库模型图 (3)创建数据表grand (4) ...
大数据Hadoop教程-学习笔记02【Apache Hadoop、HDFS】
视频教程:哔哩哔哩网站:黑马大数据Hadoop入门视频教程教程资源:https://pan.baidu.com/s/1WYgyI3KgbzKzFD639lA-_g 提取码: 6666 [P001-P ...
大数据第一阶段学习笔记
开始:2022年11月6日以下内容仅为个人笔记整理.(第一阶段的内容并不完全.硬件上有点问题,暂时无法解决,空着的部分后续补上.) 第0章大数据介绍大数据可以从事的职位有: 大数据工程师数据分 ...
.NET 大数据实时计算--学习笔记
摘要纯 .Net 自研大数据实时计算平台,在中通快递服务数百亿包裹,处理数据万亿计!将分享大数据如何落地以及设计思路,技术重难点. 目录背景介绍计算平台架构项目实战背景介绍计算平台架构分 ...
2021秋招学习笔记
PS:csdn上有很多图片加载不出来,有PDF版在我的资源.(如果没有1积分可以评论我,直接发给你邮箱) 文章目录 Java基础篇学习(7/3-7/4) 数据类型泛型.反射.注解.序列化(加实例) ...
大讲台大数据特训学习笔记
什么是大数据技术? 对于一个从事大数据行业人来说,一切数据都是有意义的.因为通过数据采集.数据存储.数据管理.数据分析与挖掘.数据展现等,我们可以发现很多有用的或有意思的规律和结论. 比如,北京公交一 ...
百万大数据架构师学习笔记
什么是大数据技术? 对于一个从事大数据行业人来说,一切数据都是有意义的.因为通过数据采集.数据存储.数据管理.数据分析与挖掘.数据展现等,我们可以发现很多有用的或有意思的规律和结论. 比如,北京公交一 ...
大数据课程体系-学习笔记概要
目录目录大数据课程体系简介学习阶段不定时更新大数据课程体系简介作为一名物联网工程专业的学生,对于大数据有着不同寻常的热情,在有了一定的Android基础和J2EE基础后,希望学习更多的数 ...

大数据秋招学习笔记13

大数据秋招学习笔记13相关推荐

最新文章

热门文章