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的时候，他能不能彻底自主地把全流程跑完？如今不少时候咱们须要考虑新增的数据须要占用很多的新机器，须要去申请。新打的日志要通知另一个部门去采集，而后再通知另一个部门去计算，而后去通知另一个部门去作图表。这样的效率能高吗？搞数据的部门别高冷地一副带你的数据来，带你的需求来，哦对了，带你的机器来，我帮你搞搞的态度。而是真地实现平台化，自助化。别各个部门都跟着业务后面作需求，我这加点东西，你那就得加点东西。节省全部人的时间。时间才是最宝贵的东西。