none
Strategy: cube deploying while others use them as data source. RRS feed

  • Frage

  • Dear All

    Our cube is a central information source, so many other systems (applications, data exports, reports) using this cube as data source.
    We have also a restricted change management, what means, each of these applications and also our cube have to plan its releases over weeks.
    So, actually when we developing some changes in our cube and release the changes, some of the data consumer fails (because of changed dimension names, deleted calculations, and so on). Well, there is only one cube, which will be changed. To deny this gap, all the development teams have to schedule the releases based on ours.
    How it is possible to create an environment to give the other developer teams the chance to modify they systems and to adopt the changes of data source.
    Our only realistic idea is to versioning the cube on every deployment. For example we deploy the cube under the name CUBE_NAME_v1. The next release will be named CUBE_NAME_v1_1, and so on. Only a defined number of releases will be left on the server and the obsolete cubes will be deleted (for example more than three releases old).
    This solution is complex and requires much maintenance.  Has someone faced such challenge? Some ideas?

    Thanking in anticipation.

    Montag, 12. September 2011 14:14

Antworten

  • Hallo Heinz,

    Deine Bedenken, was die Wartbarkeit von mehrere parallelen, versionierten Cube betrifft kann ich nachvollziehen; die Verarbeitungszeit summiert sich, ebenso die Last auf den Quellsystemen und der Speicherbedarf; RAM wie Storage.

    Die Frage lässt sich so aber auch schwer beantworten, es hängt sehr davon ab, was ihr wie oft ändert und wie signifikant die Änderungen sind.
    Und bisher gibt es eher kaum bis gar keine Konzepte für "Agile Development" / Scrum im BI Bereich.

    Ich könnte mir vorstellen, das es sinnvoll wäre, es in Minor und Major Releases aufzuteilen; regelmäßige Minor Releases mit einfachen unkritischen Änderungen, und langfristig geplante Major-Releases mit finalen, weitreichenden Änderungen.

    - Neue Dimensionen sind allgemein unkritisch.
    - Dimensionen umbenennen würde ich so umsetzen, das für Minor's es als neue, zusätzliche Dimension angelegt wird, die alte Dimension wird dann zum Major entfernt.
    - Gleiches gilt dann für die Measures.

    Wenn die verwendeten Applikationen von euch entwickelt werden, könntet ihr bei geplanten Änderungen in den "Annotations" der Dimensionen hinterlegen, das diese zum nächsten Major entfernt wird und besser nicht für neue Reports & Co verwendet werden sollte; halt als kleiner Hinweis. Das muss aber eben der Client unterstützen, sonst bringt es nicht.

    Das würde zumindest etwas die Wartung reduzieren und es wird immer nur ein Cube verwendet. Über das QueryLog könntest Du kontrollieren, welche Dimensionen immer noch verwendet werden, obwohl sie "deprecated" sind ... ist nur leider nicht so ganz leicht.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Montag, 12. September 2011 18:11

Alle Antworten

  • Yo, das kann man so machen.

    Montag, 12. September 2011 14:21
    Moderator
  • Hallo Heinz,

    Deine Bedenken, was die Wartbarkeit von mehrere parallelen, versionierten Cube betrifft kann ich nachvollziehen; die Verarbeitungszeit summiert sich, ebenso die Last auf den Quellsystemen und der Speicherbedarf; RAM wie Storage.

    Die Frage lässt sich so aber auch schwer beantworten, es hängt sehr davon ab, was ihr wie oft ändert und wie signifikant die Änderungen sind.
    Und bisher gibt es eher kaum bis gar keine Konzepte für "Agile Development" / Scrum im BI Bereich.

    Ich könnte mir vorstellen, das es sinnvoll wäre, es in Minor und Major Releases aufzuteilen; regelmäßige Minor Releases mit einfachen unkritischen Änderungen, und langfristig geplante Major-Releases mit finalen, weitreichenden Änderungen.

    - Neue Dimensionen sind allgemein unkritisch.
    - Dimensionen umbenennen würde ich so umsetzen, das für Minor's es als neue, zusätzliche Dimension angelegt wird, die alte Dimension wird dann zum Major entfernt.
    - Gleiches gilt dann für die Measures.

    Wenn die verwendeten Applikationen von euch entwickelt werden, könntet ihr bei geplanten Änderungen in den "Annotations" der Dimensionen hinterlegen, das diese zum nächsten Major entfernt wird und besser nicht für neue Reports & Co verwendet werden sollte; halt als kleiner Hinweis. Das muss aber eben der Client unterstützen, sonst bringt es nicht.

    Das würde zumindest etwas die Wartung reduzieren und es wird immer nur ein Cube verwendet. Über das QueryLog könntest Du kontrollieren, welche Dimensionen immer noch verwendet werden, obwohl sie "deprecated" sind ... ist nur leider nicht so ganz leicht.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Montag, 12. September 2011 18:11
  • Hallo.

    Hmm, habe schon befürchtet, dass es hier nicht so einfach wird. Würde mich aber sehr freuen, wenn noch weitere Rückmeldungen aus der "Realität" kommen, wie man mit so einer Herausforderung umgeht.

    Vielen Dank.

    Dienstag, 13. September 2011 07:54