资讯专栏INFORMATION COLUMN

data pipeline 中充斥着惊人的浪费,只是选择视而不见

JellyBool / 2091人阅读

摘要:殊不知机器只是成本,集群规模只说明我们在大量浪费,不说明任何其他问题。这也是因为组织架构决定软件架构的事情。节省所有人的时间。

越来越多的公司言并称大数据,而大数据管道和存储集群的规模甚至可以是业务集群的一百倍的规模。这里有多少机器是真正在做有价值的事情,而有多少cpu cycle是白白被浪费掉了呢?data pipeline 中充斥着惊人的浪费!只是我们选择视而不见。廉不知耻地把集群规模到了xxx台做为自己的功劳。殊不知机器只是成本,集群规模只说明我们在大量浪费,不说明任何其他问题。以下是我的吐槽正文:

重复建设

大数据很火,写简历上非常好就业。于是各个部门都进行着重复性地建设,从数据上报开始就报多份,各自有各自的采集agent。看一个机器上agent的进程名基本上可以推倒出一个公司的组织架构。你要是用storm,我就用samza。你们都走日志kafka,我就用udp和statsd。你们用elasticsearch,我就用influxdb,后来的要挤进来为了有区分度就用了druid。各种类似的技术栈被挂在数据管道的后面做着重复性的类似的工作。

RD太忙了,我们来兼容吧

建设data pipeline的同学和做业务的RD是两帮人。所以就出现了日志是“非结构化数据”的需求。日志从来都不是非结构化的好不好。因为搞数据人懒得和RD沟通,或者不愿意推动RD去修改业务代码,所以就得做各种定制。什么正则解析啦,什么去掉时间戳的头啦,什么multiline连接啦。就是json我都觉得是浪费磁盘和cpu的序列化格式。

另外日志的路径和rotate的方式总是多种多样的吧。这也是因为组织架构决定软件架构的事情。谁规定了就一定是做data pipeline的人要去监控业务的日志路径和rotate方式。为什么不是data pipeline规定了一个目录结构让业务一定要打到这个目录里,而rotate为什么不能是agent发起的,日志写入方去follow?

把这两者的关系反转过来,可以节省大量在格式解析,序列化反序列化,日志分拣上带来的无谓的开销。制定规范和标准让rd去调整业务代码,而不是跟着业务后面去改采集和解析。

各自为战的数据集群

kafka是集群吧,logstash是集群吧,elasticsearch是集群吧。每个集群都有自己的分布式节点的管理系统(zk的,etcd的,自己撸的),都有自己的数据分区策略。数据在不同的集群中倒腾来倒腾去,就在不断地做rehash,重新分组到不同的partition上。带来的是巨大的内网带宽的消耗。

把数据从一个集群拷贝到另外一个集群就那么好玩么?吹嘘自己每秒处理多少数据就那么爽?其实deep down,你知道你做的工作不过就是倒个手而已,不是么。

暴力检索

Map-reduce暴力全表扫描早就是过气的技术了。暴力使用hadoop,或者使用hive隐形暴力地mr,堆大量机器地捞数据。业务一些机器学习的算法真地需要这么干,但是大部分BI SQL,绝对是可以充分利用列式存储和各种索引结构的。无论是elasticsearch还是spark sql都有大量成熟的解决方案了。用索引和不用索引,那效率可是百倍的差距。

是的,全部吐槽无数据无干货,纯感性吐槽。

RoR的启发

纵观现在Data pipeline & 监控 & 日志检索 & BI多维查询的技术栈,非常类似当年的spring,各种可插拔,各种可配置。而我们需要的就是ruby on rails,横空出世,高举出convention over configuration的旗号,把一个集成好伸手就用不需思考的解决方案全盘端出。打通各自为战的管道和存储集群,整合最牛的索引和存储格式,把data pipeline的拼装从专业技术变成commodities。亟需这样一个从业务内打日志开始,到出时间序列图的端到端的完整解决方案,把广大从业人员从低水平的重复建设里解脱出来。

你不就是想省几台机器嘛

不在乎这几台机器的公司多得是。省计算资源真没啥好吹嘘的。更为宝贵的资源是RD和PM的时间。当产品研发的同学想要对一个事情进行监控,BI的时候,他能不能完全自主地把全流程跑完?现在很多时候我们需要考虑新增的数据需要占用不少的新机器,需要去申请。新打的日志要通知另外一个部门去采集,然后再通知另外一个部门去计算,然后去通知另外一个部门去做图表。这样的效率能高吗?搞数据的部门别高冷地一副带你的数据来,带你的需求来,哦对了,带你的机器来,我帮你搞搞的态度。而是真地实现平台化,自助化。别各个部门都跟着业务后面做需求,我这加点东西,你那就得加点东西。节省所有人的时间。时间才是最宝贵的东西。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/17532.html

相关文章

  • 互联网"凛冬",看大厂HR怎么说~

    摘要:写在前面的话最近互联网朋友圈充斥着一股恐慌的气息。本人作为一名,万不敢称资深,只是呆过几年大型央企和大型互联网企业,聊有一点自己的看法罢了。如果不放心,以一周为期,对展示在面前的机会进行初步分级。也可以略高于期望,以此探一探对方的反应。 showImg(https://segmentfault.com/img/bVblxeY?w=1008&h=298); 写在前面的话   最近互联网朋...

    renweihub 评论0 收藏0
  • 【Java深入学习系列】之CPU分支预测(Branch Prediction)模型

    摘要:有分支预测期的我们来看分支预测器在条件分支跳转中的应用。现代流水线级数非常长,分支预测失败可能会损失个左右的时钟周期,因此对于复杂的流水线,好的分支预测器非常重要。 说明: 本文以stackoverflow上Why is it faster to process a sorted array than an unsorted array?为原型,翻译了问题和高票回答并加入了大量补充说明...

    dunizb 评论0 收藏0
  • Python爬虫之Scrapy学习(基础篇)

    摘要:下载器下载器负责获取页面数据并提供给引擎,而后提供给。下载器中间件下载器中间件是在引擎及下载器之间的特定钩子,处理传递给引擎的。一旦页面下载完毕,下载器生成一个该页面的,并将其通过下载中间件返回方向发送给引擎。 作者:xiaoyu微信公众号:Python数据科学知乎:Python数据分析师 在爬虫的路上,学习scrapy是一个必不可少的环节。也许有好多朋友此时此刻也正在接触并学习sc...

    pkhope 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<