Enlace: https://www.zhihu.com/question/27974418/answer/1862026844
Fuente: Zhihu
Los derechos de autor pertenecen al autor. Para reimpresión comercial, comuníquese con el autor para obtener autorización, para reimpresión no comercial, indique la fuente.
1
Hadoop es solo un término general para un conjunto de herramientas. Consta de tres partes: HDFS, Yarn y MapReduce. Las funciones son almacenamiento de archivos distribuido, programación de recursos y computación.
Hablando lógicamente, esto es suficiente y se puede completar el análisis de big data.
Pero el primer problema es problemático. Este conjunto es equivalente a usar Yarn para programar recursos y leer el contenido de los archivos HDFS para el cálculo de MR. Quiere escribir código Java, pero ¿cuál es la mejor herramienta para hacer datos? SQL! Entonces Hive es equivalente a la SQLización de este conjunto de procesos estándar.
Hive puede entenderse simplemente como agregar su propio analizador y optimizador de SQL a Hadoop, escribir un fragmento de SQL, analizarlo en código Java y luego ejecutar MR. Los datos subyacentes todavía están en HDFS.
Esto parece perfecto, pero el problema es que los programadores lo encuentran muy lento. El motivo es MR, que necesita escribir y leer archivos con frecuencia. En ese momento, apareció Spark basado en memoria. Spark reemplaza a MR. Puede generar gráficos acíclicos dirigidos para SQL, y con la optimización de varios operadores y dependencias amplias y estrechas, la velocidad de cálculo ha alcanzado una nueva altura.
Es lógico que esto esté perfectamente resuelto.
Pero, pensemos, ¿de dónde salieron estos datos? ¿Hemos estado lidiando con datos estáticos hasta ahora? Cosas como la verificación de pagos en línea que necesitan devolver resultados en tiempo real no pueden esperar a que Spark calcule en lotes.
Antes de resolver el problema, volvamos atrás y pensemos de dónde provienen los datos. Hay dos tipos de datos generales: datos comerciales y datos de registro.
Los datos comerciales son los datos estructurados en la base de datos, regulares y ordenados. ¿Cómo llegan los datos comerciales a Hive? El código abierto generalmente se importa a través de Sqoop, como una tabla, si hay pocos datos, importaré todas las tablas todos los días, lo que se denomina sincronización completa; si los datos son particularmente grandes, solo se sincronizarán los cambios diarios y las nuevas incorporaciones, lo que se denomina sincronización incremental.
Sin embargo, este tipo de sincronización va a la zaga y se realiza en la oscuridad de la noche cuando los recursos informáticos del clúster están relativamente inactivos, y también se realiza el análisis fuera de línea correspondiente.
¿Cómo obtener los datos en tiempo real?
2
¿Cómo entender en tiempo real? Venga y procese un lote, y luego obtenga un poco más de detalle, venga uno y procese uno.
Por ejemplo, si compra algo, habrá datos de pedidos adicionales en la base de datos de la plataforma y la aplicación generará datos de registro de comportamiento. Cuando se insertan datos de pedidos en la base de datos, generalmente hay un binlog , que registra los datos insertados, actualizados o eliminados. Siempre que podamos obtener este binlog en tiempo real, es equivalente a obtener datos en tiempo real.
¿Cómo obtener binlog? Esto se refiere al mecanismo de respaldo maestro-esclavo de la base de datos. Generalmente, el binlog de la base de datos principal está sincronizado con la base de datos de respaldo. Hay una herramienta llamada canal que puede disfrazarse como una base de datos de respaldo para extraer el binlog de la base de datos principal, analizarlo, empaquetarlo y finalmente desecharlo, lo que equivale a obtener los datos en tiempo real .
¿Puede el canal manejarlo directamente después de obtener el binlog? Sí, pero hay una cosa en la que todos deben pensar. El 1 de mayo se acerca, tanta gente hace pedidos y consume a la vez, ¿y si las noticias del canal no se pueden consumir todas a la vez? Por ejemplo, el mensajero solo le envía un mensajero todos los días, y usted recibe el dinero y los bienes después de recibirlos. Entonces, de repente, un día, el mensajero te envió mil piezas a tu piso de abajo, y bajaste para moverlas una por una, y el mensajero tuvo que esperar a que terminaras de moverlas antes de regresar. Eres inteligente e inmediatamente lo pensaste, colócalo en el gabinete expreso, puedes moverlo lentamente si tienes tiempo, y no ocupará el tiempo del servicio de mensajería.
Esta es la cola de mensajes, y Kafka desempeña ese papel: asíncrono, desacoplado y eliminación de picos. Los datos del canal generalmente se envían a Kafka o RocketMQ, que se pueden almacenar durante un período de tiempo. Luego, el programa descendente extrae el mensaje en tiempo real para calcular.
3
Habiendo dicho tanto aguas abajo, ¿quién consumirá y calculará estos datos en tiempo real aguas abajo? Recuerde Spark, sí, está aquí nuevamente, Spark streaming es un buen reproductor para procesar datos de transmisión en tiempo real.
Spark es un término general para un conjunto completo de componentes. Por ejemplo, puede usar Java para escribir tareas de Spark, usar Spark SQL para escribir SQL y usar Spark MLib para completar el entrenamiento del modelo de aprendizaje automático, etc. Spark Streaming se usa para procesar datos de transmisión en microlotes.
具体而言，离线数据我们是等半夜数据都抽到 Hive 中再计算，而 Spark Streaming 则是实时数据来一小批，它就处理一小批。所以本质上讲，Spark Streaming 还是批处理，只不过是每一批数据很少，并且处理很及时，从而达到实时计算的目的。
Spark 本身的流行使得 Spark Streaming 也一直大范围使用。
这一套有什么逻辑缺陷吗？
我们可以想一想，实时数据和离线数据最大的差异，是时效性。离线数据像湖水，该多少就多少，就在那里；实时数据像水流，绵绵不绝。时间，便是非常重要的一个特质。当一条数据来的时候，我们需要知道这条数据是什么时候产生的，这便是业务时间。但我们拿到这条数据时往往是业务时间之后的一小会，这边是处理时间。真正世界里的实时数据肯定不是像 Spark Streaming 那样一批一批来的，而是一个一个的事件。对此，Flink 帮助我们解决了这些问题。
4
无论是业务数据还是日志数据，往往都有相应的时间标志字段，代表着这条消息的业务时间。你可以让 Flink 选择这个时间，这样，Flink 就知道当前处理到哪个时间点了。
Flink 不同于 Spark Streaming 的微批次处理，它是一条一条数据处理的。这样的数据一般是先来后到的，但难免会有些数据沿途受阻晚来了几秒钟，这就会导致两个问题：数据延迟和乱序数据。这也是做实时数据的非常关注的问题。
如何防止数据延迟？如果是上游数据迟了，就加大上游资源；如果是数据突然激增，导致 Flink 处理不过来导致任务出现延迟，就加大 Flink 的资源，比如并发。
数据乱序呢？
同样的，我们一般也通过上游和 Flink 本身来分别保证。
我们上面提到了消息的快递柜 Kafka，Kafka 有分区的概念，就像是不同的通道，一条消息来了后，可以走 A，也可以走 B，也可以走 C。那么问题来了，现在面试官问你，业务数据抛入 Kafka，如何保证消息的顺序性呢？
(5月4日 更)
顺序性一般有两方面需要保证。我们举一个小小的例子，一个用户下单的场景，有两个基本共识：
- 同一个用户的订单状态会先后变化；
- 不同用户的不同订单也有先后之分。
所以我们解决数据的顺序性一般也是从这两方面考虑。如果你还记得大学高数里的多元函数求偏导，对于 x 和 y 两个变量，求 x 的偏导会假设 y 为常量，反之同理。我们考虑这个问题也一样，如果不能同时兼顾这两方面，那就一个一个去优化吧！这种思想也称为贪婪算法，在很多地方都有应用，这里暂时说到这里。
回到问题，那么如何保证同一用户的订单顺序呢？很简单，前面我们提到的链路是，数据库中插入或更新数据时，会实时产生该条数据的 binlog，canal 获取、解析、包装这条 binlog 并抛入 Kafka。
而 Kafka 由于有分区的存在，很可能同一个订单的消息会被发送到不同的分区中，这样的话，如果下游的 Flink 任务消费不同分区速率不同，就可能导致先到的数据反而被后消费，产生顺序误差。解决的办法即保证同一订单的消息进入 Kafka 的同一分区即可。
Kafka 的每一条消息都会有 messageKey 和 message 两个结构，如果没有直接给消息指定分区，那么 messageKey 决定了消息进入哪个分区，在 canal 中，我们便可以设定消息如何进入 Kafka。数据库中的业务数据，会存在一张张的表中，表一般都会有主键，来唯一标识一条数据，我们一般也就是通过设定 canal 选择 binlog 所在表的主键来决定其进入 Kafka 的分区。这样，就基本解决了第一个问题。
(5月9日 更)
但这只保证了同一订单数据的顺序性，并未保证不同订单之间的顺序性。聪明的你可能已经想到，如果 Kafka 只设定一个分区那不就保证了吗？但这其实算是本末倒置，Kafka 本身相当于快递柜，多个分区相当于多个柜子，能存储更多的数据，提高并发，如果为了顺序性而牺牲并发量，那就得不偿失了，而且一般本身数据的乱序无论是在概率和重要性方面都不如并发重要的。就比如我要统计每小时的订单数，即使数据乱序了，只要在窗口区间内计算结果也不怎么受影响。
但这并不是说我们就不考虑数据在全局的顺序性了。
我们如何去认识乱序或延迟数据呢？
既然这种情况是偶发性的，那么一般可以这么做，在实时的流数据中，如果想要拿到 T 时刻的数据，只要等一小会儿比如 1s，就能保证在 T+1s 的时刻拿到 T 时刻的所有数据。
上面这句话其实理解起来也很简单，比如幼儿园老师组织小朋友们春游，约定了早上 8:00 集合发车，即 8:00 触发一个事件。但总有那么几个调皮捣蛋的学生会迟到几分钟，于是老师说好的 8 点发车实际上是8:05，大家觉得也没啥问题，回家就跟家长说，我们今天 8:00 发车春游啦。
在 Flink 中，这种机制就叫做 watermark。
上面我们说过，每一条数据一般都会自带一个时间字段，来标志这条数据的业务时间，即什么时候发生的。然后 Flink 提取这个时间字段，就知道了目前 Flink 任务进行到几点了。
那么既然要考虑乱序或迟到数据，我们一般也会让 Flink 当前的时间稍微迟几秒钟。比如我们认为大部分情况下乱序或迟到的数据都在 1s 以内，那么来一条数据，比如这条数据自带的时间是 08:00:01，那我们就认为 08:00:00 时刻的数据才刚到齐。但回过头来说，在大多数场景下，毕竟乱序或迟到数据算是占比很小了。
5
是不是看到这里有点抽象了？下一节我们聊聊 SQL 吧