谈笑间学会-数仓技术架构设计

1、前言

• 为何要谈数据仓库技术架构设计呢？

  技术架构设计是建设数仓的必备因素之一，分层架构为我们捋清了数据的架构及分层规范，并没有真正落地到具体的实施？

  有人说技术架构有什么好设计的？直接开整呗？

事实上并不是如此，成功始于计划，终于变化～

总而言之，言而总之，数仓设计是需要有技术方案来落地的。那么主要包含哪些呢？

离线、实时、离线+实时呗

2、离线技术架构

• 首先我们来看一波架构图吧
  

• 小结
  • 离线技术架构无非包括以下几块内容的技术选型
    • 数据采集：datax、sqoop、flume
    • 数据存储：HDFS、Hive
    • 数据计算：MapReduce、sparksql、spark、hive、kylin、presto、impala
    • 任务调度：Oozie、crontab、azkaban

3、离线+实时 技术架构

• 小结：
  • 离线技术架构无非包括以下几块内容的技术选型
    • 数据采集：datax、sqoop、flume
    • 数据存储：HDFS、Hive、kafka、hbase、Redis、RDBMS
    • 数据计算：MapReduce、sparksql、spark、hive、sparkMlib、SparkStreaming、kylin、presto、impala
    • 任务调度：Oozie、crontab、azkaban、dolphin等等

4、实时技术架构

• 实时引擎对比
  

• 小结

  • 实时数仓是一种理想化的目标，大部分实时数仓还是和离线进行结合在一起的。
  • 实时任务目前支持的业务复杂度有限，如果既要追求毫秒级响应，又要增加逻辑复杂度还是需要多思量、多思量呢

• 下面来描述一下实时数仓的技术选型

  • 数据采集：flume、canal、Maxwell、ogg、CDC
  • 数据存储：Hbase、Es、kafka、Kudu、hive+impala/kylin/presto
  • 数据计算：storm、sparkstreaming、structstreaming、flink、flinkSQL、kylin、presto、impala
  • 任务调度：Oozie、crontab、azkaban、dolphin等等

个人建议

• 如果离线能满足业务那就使用离线，如果离线实在满足不了，那么可以考虑准实时，如果准实时也满足不了，在考虑实时吧。
• 为什么这样讲呢？
  • 1、在追求速率的时候也会迎面而来一种挑战——资源问题，实时作业可不是运行一下就可以了呦，是一直占用着资源的呦，如果建设实时数仓，那么机器、服务器资源问题需要优先考虑呦。
  • 2、实时数仓建设最好选择落盘到k-v数据库中。为什么呢？为了merge操作，你懂得，哈哈哈…

参考链接：

https://tech.meituan.com/2018/10/18/meishi-data-flink.html
https://developer.aliyun.com/article/691541