快速变化的大数据处理建议

时间:2018-01-25 02:20:11

标签: sql database hadoop apache-spark bigdata

我的团队面临以下困境:我们需要一些架构/资源建议:

注意:我们的数据是半结构化的

总体任务:

  

我们有一个我们在白天处理的半大数据

     
      
  • 每天这个“过程”每天执行1-5次

  •   
  • 每个“流程”需要30分钟到5个小时

  •   
  • 半大数据= ~1百万行

  •   
  • 每一行都会在过程中的1-10次更新

         
        
    • 在此更新期间,所有其他行可能会更改,因为我们会为UI
    • 聚合这些行   
  •   

我们目前正在做什么:

  
      
  • 我们目前的系统功能齐全,价格昂贵且不一致

  •   
  • 我们使用SQL db存储所有数据,并根据流程需要检索/更新

  •   

未解决的问题和预期目标:

  
      
  • 由于这个过程是用户触发的,我们永远都不知道何时扩大/缩小,这会导致高峰值,而且Azure不容易根据需求进行自动缩放而没有我们想要远离的数据仓库因为缺乏聚合和其他各种“错误”问题
  •   
  • 因为db的常量IO,当1个进程开始时我们达到了100%的DTU(我们使用的是Azure P1 DB)当然,如果多个进程同时启动,这将迫使我们增长得更多(这是非常可能)
  •   
  • 但我们了解高计算任务带来的成本,我们认为有更好的方法可以解决这个问题(SQL大约优化了99%,还有很多工作要做)
  •   
  • 我们正在寻找一些可以:
  • 的工具   
  • 快速处理大量交易
  •   
  • 可以处理大量数据的持续更新
  •   
  • 支持所有主要聚合
  •   
  • 是“合理”定价的(我知道这是一个有争议的关键词,只需轻描淡写..)
  •   

考虑:

  
      
  • Apache Spark
  •   
  • 我们没有大量的HDP经验,所以这里的优点/缺点肯定会有用(用例是否适合工具?)
  •   
  • ArangoDB
  •   
  • 看起来很有希望..看起来很快,并且我们需要所有聚合......
  •   
  • Azure数据仓库      
        
    • 我们碰到了太多不同的问题,只是对我们不起作用。
    •   
  •   
  • 欢迎任何GPU加速计算或其他一些高端创意。
  •   
  • 很难尝试所有这些并比较哪一个最合适,因为我们有一个功能齐全的系统,需要根据我们的方式进行调整。
  •   
  • 因此,在我们触发之前,我们欢迎任何事前的意见。
  •   

0 个答案:

没有答案