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

越来越多的公司言并称大数据，而大数据管道和存储集群的规模甚至可以是业务集群的一百倍的规模。这里有多少机器是真正在做有价值的事情，而有多少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的时候，他能不能完全自主地把全流程跑完？现在很多时候我们需要考虑新增的数据需要占用不少的新机器，需要去申请。新打的日志要通知另外一个部门去采集，然后再通知另外一个部门去计算，然后去通知另外一个部门去做图表。这样的效率能高吗？搞数据的部门别高冷地一副带你的数据来，带你的需求来，哦对了，带你的机器来，我帮你搞搞的态度。而是真地实现平台化，自助化。别各个部门都跟着业务后面做需求，我这加点东西，你那就得加点东西。节省所有人的时间。时间才是最宝贵的东西。

关键字：数据库, 日志, pipeline, 集群

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！